| commit | a5a0cdd640258b80e116de11517dd6482ab6f229 | |
| author | Neil Horman <nhorman@tuxdriver.com> | |
| Mon, 2 Jan 2012 20:31:23 +0000 (2 15:31 -0500) | ||
| committer | Greg Kroah-Hartman <gregkh@suse.de> | |
| Thu, 12 Jan 2012 19:29:17 +0000 (12 11:29 -0800) | ||
| tree | f7a304d689c63ac3b00f3b9bc0c1e5506ac9a5e4 | treesnapshot (tar.gz zip) |
| parent | 170797705f7ccb335e9fe3f61967a4d465846642 | commitdiff |
firmware: Fix an oops on reading fw_priv->fw in sysfs loading file
commit eea915bb0d1358755f151eaefb8208a2d5f3e10c upstream.
This oops was reported recently:
firmware_loading_store+0xf9/0x17b
dev_attr_store+0x20/0x22
sysfs_write_file+0x101/0x134
vfs_write+0xac/0xf3
sys_write+0x4a/0x6e
system_call_fastpath+0x16/0x1b
The complete backtrace was unfortunately not captured, but details can be found
here:
https://bugzilla.redhat.com/show_bug.cgi?id=769920
The cause is fairly clear.
Its caused by the fact that firmware_loading_store has a case 0 in its
switch statement that reads and writes the fw_priv->fw poniter without the
protection of the fw_lock mutex. since there is a window between the time that
_request_firmware sets fw_priv->fw to NULL and the time the corresponding sysfs
file is unregistered, its possible for a user space application to race in, and
write a zero to the loading file, causing a NULL dereference in
firmware_loading_store. Fix it by extending the protection of the fw_lock mutex
to cover all of the firware_loading_store function.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
commit eea915bb0d1358755f151eaefb8208a2d5f3e10c upstream.
This oops was reported recently:
firmware_loading_store+0xf9/0x17b
dev_attr_store+0x20/0x22
sysfs_write_file+0x101/0x134
vfs_write+0xac/0xf3
sys_write+0x4a/0x6e
system_call_fastpath+0x16/0x1b
The complete backtrace was unfortunately not captured, but details can be found
here:
https://bugzilla.redhat.com/show_bug.cgi?id=769920
The cause is fairly clear.
Its caused by the fact that firmware_loading_store has a case 0 in its
switch statement that reads and writes the fw_priv->fw poniter without the
protection of the fw_lock mutex. since there is a window between the time that
_request_firmware sets fw_priv->fw to NULL and the time the corresponding sysfs
file is unregistered, its possible for a user space application to race in, and
write a zero to the loading file, causing a NULL dereference in
firmware_loading_store. Fix it by extending the protection of the fw_lock mutex
to cover all of the firware_loading_store function.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
| drivers/base/firmware_class.c | diffblobblamehistory |