Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 156683 - CVE-2005-1369 i2c alarms sysfs DoS
CVE-2005-1369 i2c alarms sysfs DoS
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Peter Staubach
Brian Brock
: Security
Depends On:
  Show dependency treegraph
Reported: 2005-05-03 07:59 EDT by Mark J. Cox
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-11-09 04:47:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Proposed patch (2.29 KB, patch)
2005-11-08 09:53 EST, Peter Staubach
no flags Details | Diff

  None (edit)
Description Mark J. Cox 2005-05-03 07:59:50 EDT
The (1) it87 and (2) via686a drivers in I2C for Linux 2.6.x before, 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.
Comment 3 Peter Staubach 2005-11-08 09:51:31 EST
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.
Comment 4 Peter Staubach 2005-11-08 09:53:51 EST
Created attachment 120814 [details]
Proposed patch
Comment 5 Peter Staubach 2005-11-08 13:15:55 EST
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?
Comment 6 Mark J. Cox 2005-11-09 04:47:38 EST
Thanks for the analysis, closing this as NOTABUG

Note You need to log in before you can comment on or make changes to this bug.