From ${URL} : CVE-2013-2852: b43 wireless driver The b43 driver reports error strings that can be interpreted as format strings. Under normal conditions, this is not a problem, but it is possible for the "fwpostfix" module parameter to change the filenames used to fetch firmware. When such a file is not found, the filename will be processed as a format string. This flaw could potentially allow escalation from uid-0 to ring-0, so except for certain environments, it is not too serious. If b43 hardware is available, this should show itself easily. I don't have any available for testing, but it seems it would show itself like this: # rmmod b43 # modprobe b43 fwpostfix=AA%xBB ... # dmesg ... b43-0 ERROR: Firmware file "b43AAdeff80ccBB/a0g1bsinitvals5.fw" not found Using %n instead of %x would lead to exciting crashes. :) It has been fixed in the upstream wireless tree: http://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/commit/?id=9538cbaab6e8b8046039b4b2eb6c9d614dc782bd CVE-2013-2851: block layer The block layer uses the "disk_name" field as a format string in a number of places. While this is normally not a problem due to how disk names are created (statically or incrementally), there is currently at least one way to define nearly arbitrary names via md. Instead of filtering md, this should be fixed within the kernel's interfaces. This flaw could potentially allow escalation from uid-0 to ring-0, so except for certain environments, it is not too serious. The test case is trivial: # echo md_%x.%x.%x.%x > /sys/module/md_mod/parameters/new_array # ls /dev/md_* /dev/md_c12cc370.df66d800.df66d80c.c13da45b Using %n instead of %x leads to exciting crashes. :) The fix has been sent upstream: http://marc.info/?l=linux-kernel&m=137055204522556&w=2 With the above fixes, a series of additional format string related clean ups has also been sent upstream: http://marc.info/?l=linux-kernel&m=137055207522563&w=2
CVE-2013-2852 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-2852): Format string vulnerability in the b43_request_firmware function in drivers/net/wireless/b43/main.c in the Broadcom B43 wireless driver in the Linux kernel through 3.9.4 allows local users to gain privileges by leveraging root access and including format string specifiers in an fwpostfix modprobe parameter, leading to improper construction of an error message. CVE-2013-2851 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2013-2851): Format string vulnerability in the register_disk function in block/genhd.c in the Linux kernel through 3.9.4 allows local users to gain privileges by leveraging root access and writing format string specifiers to /sys/module/md_mod/parameters/new_array in order to create a crafted /dev/md device name.
(In reply to Agostino Sarubbo from comment #0) > From ${URL} : > > CVE-2013-2852: b43 wireless driver > > The b43 driver reports error strings that can be interpreted as format > strings. Under normal conditions, this is not a problem, but it is > possible for the "fwpostfix" module parameter to change the filenames > used to fetch firmware. When such a file is not found, the filename > will be processed as a format string. This flaw could potentially allow > escalation from uid-0 to ring-0, so except for certain environments, > it is not too serious. > > If b43 hardware is available, this should show itself easily. I don't have > any available for testing, but it seems it would show itself like this: > # rmmod b43 > # modprobe b43 fwpostfix=AA%xBB > ... > # dmesg > ... > b43-0 ERROR: Firmware file "b43AAdeff80ccBB/a0g1bsinitvals5.fw" not found > > Using %n instead of %x would lead to exciting crashes. :) > > It has been fixed in the upstream wireless tree: > > http://git.kernel.org/cgit/linux/kernel/git/linville/wireless.git/commit/ > ?id=9538cbaab6e8b8046039b4b2eb6c9d614dc782bd In 3.9.7 as e0e29b683d6784ef59bbc914eac85a04b650e63c. > CVE-2013-2851: block layer > > The block layer uses the "disk_name" field as a format > string in a number of places. While this is normally not a problem due > to how disk names are created (statically or incrementally), there > is currently at least one way to define nearly arbitrary names via > md. Instead of filtering md, this should be fixed within the kernel's > interfaces. This flaw could potentially allow escalation from uid-0 to > ring-0, so except for certain environments, it is not too serious. > > The test case is trivial: > # echo md_%x.%x.%x.%x > /sys/module/md_mod/parameters/new_array > # ls /dev/md_* > /dev/md_c12cc370.df66d800.df66d80c.c13da45b > > Using %n instead of %x leads to exciting crashes. :) > > The fix has been sent upstream: > http://marc.info/?l=linux-kernel&m=137055204522556&w=2 > > > With the above fixes, a series of additional format string related clean > ups has also been sent upstream: > http://marc.info/?l=linux-kernel&m=137055207522563&w=2 In linux.git as ffc8b30866879ed9ba62bd0a86fecdbd51cd3d191, fix in 3.10.1.
