The Linux kernel's IPMI driver message-handling layer: A use-after-free in a kernel driver reachable from the host's

Impact

A use-after-free in a kernel driver reachable from the host's IPMI device nodes gives a local attacker a path to kernel memory corruption and, from there, to privilege escalation on the host. On a bare-metal GPU node the significance is the direction of travel: this is a route from an unprivileged tenant process, through the kernel, toward the interface that talks to the BMC. It is the host-side half of the out-of-band security story, and it is the half that operators tend not to inventory because it lives in the kernel rather than in firmware. The per-user message limit was miscounted in several paths, producing a use-after-free. This is the in-kernel code every host uses to talk to its own BMC over the KCS or SSIF interface.

Who can reach it

A local process on the host with access to the IPMI character devices (/dev/ipmi*). On many stock server images those permissions are looser than they should be, and any container or tenant workload given access to them is in position.

What to do

Kernel update and reboot - which on a GPU node means draining long-running training jobs, so it lands in the same expensive maintenance window as everything else kernel-level. There is a genuinely effective config-only mitigation that costs nothing: unless a workload needs in-band IPMI, do not expose /dev/ipmi* to it, and consider blacklisting the ipmi_devintf module entirely on tenant-facing bare metal. Most operators poll their BMCs over the network anyway and do not need the in-band path at all.

References