summaryrefslogtreecommitdiffstats
path: root/arch/arm/mach-s5p64x0
diff options
context:
space:
mode:
authorNeil Horman <nhorman@tuxdriver.com>2012-01-02 15:31:23 -0500
committerGreg Kroah-Hartman <gregkh@suse.de>2012-01-04 16:31:29 -0800
commiteea915bb0d1358755f151eaefb8208a2d5f3e10c (patch)
tree35d593bde3caa1b79751e0ec1a6c6333b2a72506 /arch/arm/mach-s5p64x0
parent8f257a142fc3868d69de3f996b95d7bdbc509560 (diff)
firmware: Fix an oops on reading fw_priv->fw in sysfs loading file
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> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Diffstat (limited to 'arch/arm/mach-s5p64x0')
0 files changed, 0 insertions, 0 deletions