Use After Free Affecting perf6.18-debuginfo package, versions <1:6.18.20-20.229.amzn2023


Severity

Recommended
0.0
high
0
10

Based on Amazon Linux security rating.

Threat Intelligence

EPSS
0.01% (4th percentile)

Do your applications use this vulnerable package?

In a few clicks we can analyze your entire application and see what components are vulnerable in your application, and suggest you quick fixes.

Test your applications

Snyk Learn

Learn about Use After Free vulnerabilities in an interactive lesson.

Start learning
  • Snyk IDSNYK-AMZN2023-PERF618DEBUGINFO-16348829
  • published3 May 2026
  • disclosed25 Mar 2026

Introduced: 25 Mar 2026

CVE-2026-23322  (opens in a new tab)
CWE-416  (opens in a new tab)

How to fix?

Upgrade Amazon-Linux:2023 perf6.18-debuginfo to version 1:6.18.20-20.229.amzn2023 or higher.
This issue was patched in ALAS2023-2026-1596.

NVD Description

Note: Versions mentioned in the description apply only to the upstream perf6.18-debuginfo package and not the perf6.18-debuginfo package as distributed by Amazon-Linux. See How to fix? for Amazon-Linux:2023 relevant fixed versions and status.

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.

CVSS Base Scores

version 3.1