GNU FreeIPMI ipmi-oem before 1.6.18: Same shape as its predecessor and the same fleet consequence: a hostile BMC

Impact

Same shape as its predecessor and the same fleet consequence: a hostile BMC response corrupts memory in the tool on your management host. The operationally important detail is that this is the second round - an operator who updated to 1.6.17 believing FreeIPMI's OEM response parsing was fixed is still exposed. Treat the ipmi-oem response parser as untrusted code handling untrusted input until proven otherwise, rather than assuming a given release closed the class. A further set of response-message buffer overflows found after the 1.6.17 fix, meaning the first round of hardening did not cover the whole parser.

Who can reach it

Your management tooling querying a BMC that returns crafted responses - a compromised controller, a node brought in from an untrusted source, or an attacker able to interpose on IPMI traffic across the management VLAN.

What to do

Package update to FreeIPMI 1.6.18 or later everywhere ipmi-oem runs. Cheap: distribution package update, no reboot, no firmware. Given that OEM extension parsing has now produced two rounds of overflows, the stronger move for most GPU operators is to stop using ipmi-oem for routine fleet polling at all - vendor-specific OEM IPMI commands are rarely load-bearing, and dropping them removes this parser from your control plane entirely.

References