Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 156683 - CVE-2005-1369 i2c alarms sysfs DoS
Summary: CVE-2005-1369 i2c alarms sysfs DoS
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Peter Staubach
QA Contact: Brian Brock
Whiteboard: impact=moderate,reported=20050427,pub...
Depends On:
TreeView+ depends on / blocked
Reported: 2005-05-03 11:59 UTC by Mark J. Cox
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2005-11-09 09:47:38 UTC
Target Upstream Version:

Attachments (Terms of Use)
Proposed patch (deleted)
2005-11-08 14:53 UTC, Peter Staubach
no flags Details | Diff

Description Mark J. Cox 2005-05-03 11:59:50 UTC
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 14:51:31 UTC
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 14:53:51 UTC
Created attachment 120814 [details]
Proposed patch

Comment 5 Peter Staubach 2005-11-08 18:15:55 UTC
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 09:47:38 UTC
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.