CVE-2026-43489: Linux Kernel Use-After-Free Vulnerability

CVE-2026-43489 Overview

CVE-2026-43489 is a Linux kernel vulnerability in the liveupdate (LUO) subsystem. The flaw resides in the luo_file retrieve tracking logic, where failed retrieve() attempts are not recorded. When luo_retrieve_file() returns an error, the retrieved boolean in struct luo_file is never updated. Userspace can then reissue the LIVEUPDATE_SESSION_RETRIEVE_FD ioctl, triggering retries against partially freed or inconsistent serialized state. The finish() callback at session close compounds the problem by assuming retrieve was never attempted. Affected file handlers such as memfd can invoke kho_restore_folio() on folios already restored, producing kernel warnings and unstable state.

Critical Impact

Repeated ioctl calls after a failed retrieve operate on freed or inconsistent kernel data structures, leading to warnings, undefined behavior, and potential local denial of service.

Affected Products

• Linux kernel branches containing the liveupdate (LUO) subsystem with luo_file retrieve logic
• Stable kernel trees referenced by commits 1d3ad69484dc and f85b1c6af5bc
• Distributions shipping kernels with the LUO LIVEUPDATE_SESSION_RETRIEVE_FD ioctl interface

Discovery Timeline

• 2026-05-13 - CVE-2026-43489 published to NVD
• 2026-05-13 - Last updated in NVD database

Technical Details for CVE-2026-43489

Vulnerability Analysis

The Linux kernel liveupdate (LUO) subsystem tracks successful retrieval attempts on a LUO file to prevent duplicate retrievals. Repeated retrievals are dangerous because retrieved files have their serialized data structures freed, leaving the file in a state inconsistent with what the retrieve code expects. The retrieved boolean in struct luo_file exists specifically to enforce single-retrieve semantics and to inform the finish() callback what cleanup remains.

The defect appears on the error path. When luo_retrieve_file() fails partway through, it returns the error immediately without recording that retrieve was attempted. Userspace receives an errored LIVEUPDATE_SESSION_RETRIEVE_FD ioctl but faces no barrier against retrying. A retry walks into structures that may already be partially freed.

The memfd handler illustrates the impact. If memfd restores 8 of 10 folios and fails on the 9th, a retry calls kho_restore_folio() again on the first folio, which is an invalid operation and emits a warning. The finish() callback inherits the same broken assumption, attempting to access or free structures that may no longer exist [CWE-754: Improper Check for Unusual or Exceptional Conditions].

Root Cause

The root cause is incomplete state tracking on the error path of luo_retrieve_file(). The original boolean encoded only two states: not attempted, or succeeded. It could not represent a failed attempt, leaving the retry and finish paths blind to partial work already performed.

Attack Vector

A local user with permission to invoke the LIVEUPDATE_SESSION_RETRIEVE_FD ioctl can trigger the condition by issuing the ioctl, inducing a retrieve failure, and reissuing the call. The vulnerability requires local access to the LUO interface and is constrained to environments where liveupdate is enabled. The fix converts the boolean to an integer encoding three states: 0 for not attempted, positive for success, and negative carrying the prior error code returned directly on retry and passed to finish().

No public exploit code is available. See the kernel commit details and the follow-up commit for the patch.

Detection Methods for CVE-2026-43489

Indicators of Compromise

• Kernel warnings or WARN_ON traces referencing kho_restore_folio() after a failed liveupdate session
• Repeated LIVEUPDATE_SESSION_RETRIEVE_FD ioctl calls from the same process following an error return
• Unexpected liveupdate session close failures or finish() callback errors in dmesg

Detection Strategies

• Audit dmesg and kernel ring buffer logs for warnings emitted by kho_restore_folio() and the luo_file code paths
• Correlate process-level ioctl usage against liveupdate session identifiers to flag retry patterns after failures
• Inventory kernel versions across the fleet and identify hosts running pre-patch builds containing the LUO subsystem

Monitoring Recommendations

• Forward kernel logs to a central SIEM and alert on warning-level entries from liveupdate or memfd restore functions
• Track ioctl call frequencies per session via eBPF or audit subsystem instrumentation
• Monitor session lifecycle metrics for abnormal finish() failures or premature termination

How to Mitigate CVE-2026-43489

Immediate Actions Required

• Apply the upstream kernel patches referenced by commits 1d3ad69484dc and f85b1c6af5bc and reboot affected hosts
• Restrict access to the LIVEUPDATE_SESSION_RETRIEVE_FD ioctl to trusted system components and privileged users
• Disable the liveupdate subsystem on hosts that do not require it until patches are deployed

Patch Information

The fix changes the retrieved field in struct luo_file from a boolean to an integer. A value of 0 means retrieve was never attempted, a positive value means it succeeded, and a negative value stores the error code from a failed attempt. Subsequent retry calls return the stored error directly, and finish() uses the value to decide which cleanup is safe. Apply vendor kernel updates from your distribution that incorporate the upstream commits.

Workarounds

• Block userspace processes from issuing repeated LIVEUPDATE_SESSION_RETRIEVE_FD ioctls through seccomp filters or LSM policy
• Avoid invoking liveupdate flows on workloads until patched kernels are rolled out
• Reboot or recreate sessions immediately after any retrieve failure to avoid leaving the kernel in an inconsistent state

# Verify the running kernel version and identify the LUO commit
uname -r
# Confirm patch presence via distribution package manager (example: Debian/Ubuntu)
apt-cache policy linux-image-$(uname -r)
# Restrict ioctl access via auditd rule
auditctl -a always,exit -F arch=b64 -S ioctl -F key=luo_retrieve