Linux Kernel up to 6.18.16/6.19.6/7.0-rc1 ipmi smi_work null pointer dereference

Summaryinfo

A vulnerability identified as critical has been detected in Linux Kernel up to 6.18.16/6.19.6/7.0-rc1. This affects the function smi_work of the component ipmi. The manipulation leads to null pointer dereference. This vulnerability is referenced as CVE-2026-23322. No exploit is available. You should upgrade the affected component.

Detailsinfo

A vulnerability was found in Linux Kernel up to 6.18.16/6.19.6/7.0-rc1 and classified as critical. This issue affects the function smi_work of the component ipmi. The manipulation with an unknown input leads to a null pointer dereference vulnerability. Using CWE to declare the problem leads to CWE-476. A NULL pointer dereference occurs when the application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exit. Impacted is availability. The summary by CVE is:

In the Linux kernel, the following vulnerability has been resolved: ipmi: Fix use-after-free and list corruption on sender error The analysis from Breno: When the SMI sender returns an error, smi_work() delivers an error response but then jumps back to restart without cleaning up properly: 1. intf->curr_msg is not cleared, so no new message is pulled 2. newmsg still points to the message, causing sender() to be called again with the same message 3. If sender() fails again, deliver_err_response() is called with the same recv_msg that was already queued for delivery This causes list_add corruption ("list_add double add") because the recv_msg is added to the user_msgs list twice. Subsequently, the corrupted list leads to use-after-free when the memory is freed and reused, and eventually a NULL pointer dereference when accessing recv_msg->done. The buggy sequence: sender() fails -> deliver_err_response(recv_msg) // recv_msg queued for delivery -> goto restart // curr_msg not cleared! sender() fails again (same message!) -> deliver_err_response(recv_msg) // tries to queue same recv_msg -> LIST CORRUPTION Fix this by freeing the message and setting it to NULL on a send error. Also, always free the newmsg on a send error, otherwise it will leak.

It is possible to read the advisory at git.kernel.org. The identification of this vulnerability is CVE-2026-23322 since 01/13/2026. Technical details of the vulnerability are known, but there is no available exploit.

The vulnerability scanner Nessus provides a plugin with the ID 304068 (Linux Distros Unpatched Vulnerability : CVE-2026-23322), which helps to determine the existence of the flaw in a target environment.

Upgrading to version 6.18.17, 6.19.7 or 7.0-rc2 eliminates this vulnerability. Applying the patch c08ec55617cb9674a060a3392ea08391ab2a4f74/65ff5d1e4410df05edfbeb7bf2d62f7681ce1d53/594c11d0e1d445f580898a2b8c850f2e3f099368 is able to eliminate this problem. The bugfix is ready for download at git.kernel.org. The best possible mitigation is suggested to be upgrading to the latest version.

The vulnerability is also documented in the databases at Tenable (304068) and CERT Bund (WID-SEC-2026-0861). Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Affected

• Google Container-Optimized OS
• Debian Linux
• Google Cloud Platform
• Red Hat Enterprise Linux
• Ubuntu Linux
• SUSE Linux
• Oracle Linux
• SUSE openSUSE
• Open Source Linux Kernel
• RESF Rocky Linux

Productinfo

Type

• Operating System

Vendor

• Linux

Name

• Kernel

Version

• 6.18.0
• 6.18.1
• 6.18.2
• 6.18.3
• 6.18.4
• 6.18.5
• 6.18.6
• 6.18.7
• 6.18.8
• 6.18.9
• 6.18.10
• 6.18.11
• 6.18.12
• 6.18.13
• 6.18.14
• 6.18.15
• 6.18.16
• 6.19.0
• 6.19.1
• 6.19.2
• 6.19.3
• 6.19.4
• 6.19.5
• 6.19.6
• 7.0-rc1

License

• open-source

Website

• Vendor: https://www.kernel.org/

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion