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: n/a
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

The vulnerability resides in the Linux kernel’s liveupdate component. When a retrieve operation fails, the kernel does not record the failure, allowing the operation to be retried. A subsequent retry can attempt to access or free data structures that have already been freed or are in an inconsistent state, which can trigger kernel panics. This results in a denial‑of‑service condition and could potentially lead to loss of data integrity for the updated component.

Affected Systems

All Linux kernel builds that include the liveupdate framework are affected, regardless of distribution. Version information is not specified, so every kernel variant that ships with liveupdate should be examined.

Risk and Exploitability

The EPSS score is < 1%, indicating a very low but non‑negligible exploitation probability, and the CVE is not listed in the CISA KEV catalog. The problem originates in kernel space but is triggered via user‑space ioctl calls, so an attacker with local access to the liveupdate interface can exploit the flaw. Because the kernel may crash on repeated failed tries, the main impact is a local denial of service. No remote code execution path is disclosed. The severity cannot be precisely quantified without a CVSS score, but the potential for a kernel panic makes the risk high for affected systems.

Generated by OpenCVE AI on May 14, 2026 at 15:52 UTC.

Remediation

No vendor fix or workaround currently provided.

OpenCVE Recommended Actions

  • Deploy the official kernel update that corrects the retrieve error handling in liveupdate.
  • Upgrade to the latest stable kernel release from your distribution’s repository.
  • If an update is not immediately available, avoid using liveupdate for critical components and monitor the system for kernel panics after an update attempt.

Generated by OpenCVE AI on May 14, 2026 at 15:52 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

Type Values Removed Values Added
Weaknesses CWE-390
References

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 : Awaiting Analysis

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

Modified: 2026-05-22T16:33:17.283

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-05-14T16:00:15Z

Weaknesses