Red Hat Bugzilla – Bug 171716
20050901 ipmi poweroff: fix chassis control
Last modified: 2007-11-30 17:07:21 EST
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 NULL 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 linux-2.6.9-openipmi-update.patch Patch upstream was: http://linux.bkbits.net:8080/linux-2.6/cset@431f7eed11l7ZEzNoZLGB5k2Y4Ce2A but note that other fixes were also made around the same time; http://linux.bkbits.net:8080/linux-2.6/related/drivers/char/ipmi/ipmi_poweroff.c
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.
The question is if we can come up with a patch that addresses the issues without changing the /proc interface.
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.
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.
Closing this one as WONTFIX now, since it seems it is impossible to fix this issue without breaking the user space API.