The (1) it87 and (2) via686a drivers in I2C for Linux 2.6.x before
184.108.40.206, and 2.6.12 before 2.6.12-rc2, create the sysfs "alarms" file
with write permissions, which allows local users to cause a denial of
service (CPU consumption) by attempting to write to the file, which
does not have an associated store function.
Note that although RHEL2.1 and RHEL3 contain backported lm_sensors, these do not
look vulnerable to this issue and have valid (444) modes.
I looked through the entire source base for instances of DEVICE_ATTR, checking
for instances which looked wrong.
The two drivers, it87 and via686a, had write permission set in the sysfs node,
although there was no set function. Additionally, the wireless ipw2200 driver
also had two instances of sysfs nodes with write permission, but with no set
Interestingly, the USB cytherm driver had two nodes which were read-only, but
for which there was a set function. The set functions are basically noop
routines, just returning the passed in count to indicate that they successfully
wrote the requested data and returned no error.
Created attachment 120814 [details]
After a little more looking and thinking, I am not sure why the situation,
which is described, would or even could occur. The support already checks
to see if there is a "store" method if any of the write permission bits are
set and if there is not, then an error is returned when the file is
attempted to be opened for writing.
These changes are easy enough and simple enough, but is there really
anything to fix?
Thanks for the analysis, closing this as NOTABUG