Bug 171716 - 20050901 ipmi poweroff: fix chassis control
20050901 ipmi poweroff: fix chassis control
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Peter Martuccelli
Brian Brock
: Reopened, Security
Depends On:
  Show dependency treegraph
Reported: 2005-10-25 11:45 EDT by Mark J. Cox (Product Security)
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-20 17:01:34 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Mark J. Cox (Product Security) 2005-10-25 11:45:22 EDT
Al Viro found that the IPMI power control function proc_write_chassctrl was
badly written, it directly used userspace pointers, it assumed that strings were
terminated, and it used the evil sscanf function.  This converts over to
using the sysctl interface for this data and changes the semantics to be a
little more logical.

This looks like it has a security implication.

This code was introduced to RHEL4 in Update2 in the patch 

Patch upstream was:
but note that other fixes were also made around the same time;
Comment 5 Peter Martuccelli 2006-12-12 09:57:43 EST
The upstream code changed the /proc interface so we cannot accept the patch in
RHEL.  We would end up breaking the API used by existing applications.
Comment 6 Marcel Holtmann 2006-12-12 10:13:23 EST
The question is if we can come up with a patch that addresses the issues without
changing the /proc interface.
Comment 7 Peter Martuccelli 2006-12-13 14:22:52 EST
Outside of the two lines mentioned in the first comment, the whole patch is
about changing the /proc interface to move the ipmi devices to /proc/sys using
the sysctl interface.  We cannot come up with an alternative patch to resolve
this issue.  This is secondary, the string is null terminated, and follows the
correct default code path to power down the system based on the sscanf usage. 
There is no security issue here to resolve, and no bug(s) to fix.  As part of
IPMI maintenance I would update the poweroff module to keep in sync with
upstream, but as I mentioned it would break the user space API.

Let me know if there is a CVE for this BZ entry.
Comment 8 Marcel Holtmann 2006-12-13 17:48:49 EST
As to my knowledge, we never assigned a CVE name for this issue, but this means
basically nothing. However thanks for the additional explanation and feel free
to close this one as NOTABUG now.
Comment 9 Marcel Holtmann 2007-03-20 17:01:34 EDT
Closing this one as WONTFIX now, since it seems it is impossible to fix this
issue without breaking the user space API.

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