Skip to main content

Linux Kernel CVE-2026-43489

| EUVDEUVD-2026-30025 MEDIUM
2026-05-13 Linux GHSA-hv64-4pwv-7xc6
5.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
5.5 MEDIUM
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
vuln.today AI
4.7 MEDIUM

Local ioctl access with low privileges (PR:L, AV:L); triggering a specific mid-operation retrieve failure for retry requires deliberate effort (AC:H); no confidentiality or integrity impact confirmed.

3.1 AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H
4.0 AV:L/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
SUSE
MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Attack Vector
Local
Attack Complexity
Low
Privileges Required
Low
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

Lifecycle Timeline

5
Analysis Generated
Jun 26, 2026 - 19:27 vuln.today
CVSS changed
Jun 26, 2026 - 19:22 NVD
5.5 (MEDIUM)
Patch available
May 13, 2026 - 16:33 EUVD
CVE Published
May 13, 2026 - 15:08 nvd
MEDIUM 5.5
CVE Published
May 13, 2026 - 15:08 nvd
UNKNOWN (no severity yet)

DescriptionNVD

In the Linux kernel, the following vulnerability has been resolved:

liveupdate: luo_file: remember retrieve() status

LUO keeps track of successful retrieve attempts on a LUO file. It does so to avoid multiple retrievals of the same file. Multiple retrievals cause problems because once the file is retrieved, the serialized data structures are likely freed and the file is likely in a very different state from what the code expects.

The retrieve boolean in struct luo_file keeps track of this, and is passed to the finish callback so it knows what work was already done and what it has left to do.

All this works well when retrieve succeeds. When it fails, luo_retrieve_file() returns the error immediately, without ever storing anywhere that a retrieve was attempted or what its error code was. This results in an errored LIVEUPDATE_SESSION_RETRIEVE_FD ioctl to userspace, but nothing prevents it from trying this again.

The retry is problematic for much of the same reasons listed above. The file is likely in a very different state than what the retrieve logic normally expects, and it might even have freed some serialization data structures. Attempting to access them or free them again is going to break things.

For example, if memfd managed to restore 8 of its 10 folios, but fails on the 9th, a subsequent retrieve attempt will try to call kho_restore_folio() on the first folio again, and that will fail with a warning since it is an invalid operation.

Apart from the retry, finish() also breaks. Since on failure the retrieved bool in luo_file is never touched, the finish() call on session close will tell the file handler that retrieve was never attempted, and it will try to access or free the data structures that might not exist, much in the same way as the retry attempt.

There is no sane way of attempting the retrieve again. Remember the error retrieve returned and directly return it on a retry. Also pass this status code to finish() so it can make the right decision on the work it needs to do.

This is done by changing the bool to an integer. A value of 0 means retrieve was never attempted, a positive value means it succeeded, and a negative value means it failed and the error code is the value.

AnalysisAI

State management failure in the Linux kernel liveupdate subsystem allows a local low-privileged user to trigger a use-after-free or double-free condition by retrying a failed LIVEUPDATE_SESSION_RETRIEVE_FD ioctl, resulting in kernel crash or WARN and full availability loss. The luo_file struct's retrieve status is never recorded on failure, leaving the kernel's serialization state machine inconsistent; a retry re-enters retrieve logic against partially freed data structures such as kho folio mappings. No public exploit exists and EPSS is 0.02%, placing this firmly in low-priority territory absent active use of the liveupdate feature.

Technical ContextAI

The vulnerability is in the liveupdate (LUO) subsystem of the Linux kernel, specifically the luo_file object which manages file-level state during live update sessions exposed via the LIVEUPDATE_SESSION_RETRIEVE_FD ioctl. A retrieve boolean in struct luo_file is intended to gate re-entry into the retrieval path and inform the finish() callback of what work has already been done. The root cause is a missing write to this field on the failure path of luo_retrieve_file(): on error, the function returns immediately without recording the attempt, leaving the state machine believing no retrieval was ever started. On retry, the kernel calls back into retrieve logic against data structures - including kho (kernel handover) folio mappings used by memfd - that may have been partially torn down. For instance, kho_restore_folio() called on an already-restored folio triggers a kernel WARN and invalid memory access. The finish() callback on session close similarly misreads the unset flag and may attempt to free nonexistent structures. The fix promotes the bool to an integer (0=never attempted, positive=succeeded, negative=cached error code), memoizing both success and failure outcomes. CWE is not formally assigned, but the class is improper state tracking on error paths, analogous to CWE-672 (Operation on Resource After Expiration). Affected CPE: cpe:2.3:a:linux:linux:*:*:*:*:*:*:*:*.

RemediationAI

Upgrade to Linux kernel 6.19.9 or Linux 7.0 (post-fix). The upstream stable patches are available at https://git.kernel.org/stable/c/f85b1c6af5bc3872f994df0a5688c1162de07a62 (6.x stable) and https://git.kernel.org/stable/c/1d3ad69484dc1cc53be62d2554e7ef038a627af9 (7.x stable); distributions should track their vendor's backport of these commits. As a compensating control for unpatched systems, restrict access to the LIVEUPDATE_SESSION_RETRIEVE_FD ioctl via seccomp-bpf filtering or strict DAC/MAC policies on the liveupdate device or session file descriptor - this prevents unprivileged local users from reaching the vulnerable code path, though privileged processes would retain access. Environments that do not use the liveupdate feature can eliminate the attack surface entirely by rebuilding the kernel without the relevant CONFIG option (verify the exact symbol against the affected kernel tree); note this disables live kernel update and migration functionality. No workarounds short of these are available given the kernel-space nature of the flaw.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Performance Computing 15 SP7 Not-Affected

Share

CVE-2026-43489 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy