Description
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.
Published: 2026-05-13
Score: 5.5 Medium
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The Linux kernel’s liveupdate subsystem has a flaw in how it handles retrieval failures of LUO files. When a retrieve operation fails, the kernel does not record the error state, so the operation may be retried. Each retry can attempt to use or free data structures that have already been released or are inconsistent, which can lead to a kernel panic. This results in a denial‑of‑service effect. The bug is a consequence of improper error handling and is represented by CWE‑390.

Affected Systems

All Linux kernel builds that ship with the liveupdate framework are affected, regardless of distribution. The exact affected versions are not precisely enumerated, but any kernel prior to the patch that changes the retrieve status handling is vulnerable.

Risk and Exploitability

Based on the description, the likely attack vector is a local user‑space ioctl that triggers the liveupdate retrieve operation. The CVSS score is 5.5, indicating moderate severity, while the EPSS score is less than 1%, showing a very low but non‑zero exploitation probability. The flaw is confined to the kernel; once a kernel panic occurs, the attacker cannot continue executing code in the affected context. No remote code execution path is disclosed, but the potential to crash the system makes the risk for affected installations significant, especially in environments that rely on liveupdate for critical patches.

Generated by OpenCVE AI on August 14, 2026 at 02:54 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Apply the official Linux kernel update that includes the fix for liveupdate retrieve status handling.
  • Update to the latest stable kernel from your distribution’s repositories, which contains the patch.
  • If an update cannot be applied immediately, disable the liveupdate functionality or prevent liveupdate sessions from being started until the kernel patch is installed.

Generated by OpenCVE AI on August 14, 2026 at 02:54 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Thu, 14 May 2026 14:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Thu, 14 May 2026 12:15:00 +0000


Wed, 13 May 2026 17:15:00 +0000

Type Values Removed Values Added
Weaknesses CWE-416

Wed, 13 May 2026 15:15:00 +0000

Type Values Removed Values Added
Description 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.
Title liveupdate: luo_file: remember retrieve() status
First Time appeared Linux
Linux linux Kernel
CPEs cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Vendors & Products Linux
Linux linux Kernel
References

Subscriptions

Linux Linux Kernel
cve-icon MITRE

Status: PUBLISHED

Assigner: Linux

Published:

Updated: 2026-05-13T15:08:33.810Z

Reserved: 2026-05-01T14:12:56.012Z

Link: CVE-2026-43489

cve-icon Vulnrichment

No data.

cve-icon NVD

Status : Analyzed

Published: 2026-05-13T16:16:52.230

Modified: 2026-06-26T19:16:26.843

Link: CVE-2026-43489

cve-icon Redhat

Severity :

Publid Date: 2026-05-13T00:00:00Z

Links: CVE-2026-43489 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-08-14T03:00:04Z

Weaknesses