Setting a DASD (Direct Access Storage Device) device offline while another process is trying to open that device caused a race in the dasd_open function. The dasd_open function tried to read a pointer from the private_data field after the structure has already been freed, resulting in a dereference of an invalid pointer. With this update, the aforementioned pointer is now stored in a different structure; thus, preventing the race condition.
linux-2.6.18-s390-dasd-fix-open-offline-race.patch
Description: dasd: fix race between open and offline
Symptom: Oops when dasd_open tries to dereference an invalid pointer.
Problem: The dasd_open function uses the private_data pointer of
the gendisk to find the drivers internal structures that
represent this DASD device. When a DASD device is set
offline, and a process tries to open the device at the
same time, then there is a small race window, in which
dasd_open could first read a pointer from the
private_data field and then try to use it, after the
structure has already been freed.
Solution: To close this race window, we will store a pointer to a
different internal structure (dasd_devmap) in the
private_data field. The devmap entries are not deleted
when a device is set offline, and we already have proper
locking and reference counting in place, so that we can
safely get from a devmap to the other structures of
a DASD device.
Server architecture(s): System z
Server type: s390x
General component: kernel
Other components involved: No
Does the server have the latest GA firmware?
Yes.
Has the problem been shown to occur on more than one system?
Yes.
Is a tested patch available?
Yes.
If yes to the above, has it been approved upstream?
The patch will be sent upstream for inclusion into a 2.6.39 release
candidate.
What is the latest official Red Hat build on which this bug has been seen?
RHEL 5.6
The patch has been tested and fixes the problem.
With best regards,
Hendrik
Patch(es) available in kernel-2.6.18-259.el5
You can download this test kernel (or newer) from http://people.redhat.com/jwilson/el5
Detailed testing feedback is always welcomed.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Setting a DASD (Direct Access Storage Device) device offline while another process is trying to open that device caused a race in the dasd_open function. The dasd_open function tried to read a pointer from the private_data field after the structure has already been freed, resulting in a dereference of an invalid pointer. With this update, the aforementioned pointer is now stored in a different structure; thus, preventing the race condition.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.
http://rhn.redhat.com/errata/RHSA-2011-1065.html
linux-2.6.18-s390-dasd-fix-open-offline-race.patch Description: dasd: fix race between open and offline Symptom: Oops when dasd_open tries to dereference an invalid pointer. Problem: The dasd_open function uses the private_data pointer of the gendisk to find the drivers internal structures that represent this DASD device. When a DASD device is set offline, and a process tries to open the device at the same time, then there is a small race window, in which dasd_open could first read a pointer from the private_data field and then try to use it, after the structure has already been freed. Solution: To close this race window, we will store a pointer to a different internal structure (dasd_devmap) in the private_data field. The devmap entries are not deleted when a device is set offline, and we already have proper locking and reference counting in place, so that we can safely get from a devmap to the other structures of a DASD device. Server architecture(s): System z Server type: s390x General component: kernel Other components involved: No Does the server have the latest GA firmware? Yes. Has the problem been shown to occur on more than one system? Yes. Is a tested patch available? Yes. If yes to the above, has it been approved upstream? The patch will be sent upstream for inclusion into a 2.6.39 release candidate. What is the latest official Red Hat build on which this bug has been seen? RHEL 5.6 The patch has been tested and fixes the problem. With best regards, Hendrik