CVE-2026-92483

None

CVSS

—

EPSS

0.2%

Published

Sep 17, 2026

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A kernel bug can let repeated attempts to load certain saved data corrupt memory and crash the system or allow unauthorized code to run.

Exploitation: Local Privilege
Attacker needs: Local User
Complexity: Moderate
Impact: Privilege Gain
Component: OS kernel
Class: Use After Free
Remediation: Upgrade
Effort: Medium
Patch risk: Low

What it actually does

Failure to record retrieve() errors on FLB objects allows subsequent retrieve attempts on the same FLB to invoke the callback again after serialized structures have been freed, resulting in use-after-free.

Why it matters to the business

Systems relying on the liveupdate mechanism face elevated risk of kernel instability or local code execution; the low EPSS and lack of KEV listing indicate limited immediate external threat but still require prompt patching to protect kernel integrity.

How an attack unfolds

An attacker with local access triggers a failing retrieve() on an FLB, then forces a second retrieve on a related object; because the error is not cached the callback executes against already-freed KHO pages, enabling memory corruption.

How to fix it

Update to a kernel containing the referenced fix that replaces the retrieved boolean with a retrieve_status integer; rebuild and deploy the updated kernel image across all affected hosts.

How to confirm the fix worked

Confirm the liveupdate source contains the retrieve_status integer handling (0 = never attempted, positive = success, negative = error code) and that luo_flb_retrieve_one no longer retries on cached failures.

Typical attack path

Obtain local execution on a Linux system using the liveupdate subsystem
Register multiple files under the same FLB and induce a retrieve failure
Trigger a second retrieve attempt before the FLB state is reset
Exploit the resulting use-after-free for privilege escalation or denial of service

How to detect it

Inspect kernel liveupdate logs and audit records for repeated retrieve attempts on the same FLB identifier; correlate with any subsequent page-fault or slab-use-after-free warnings in dmesg.

What your security team should do

Prioritize kernel updates for all liveupdate-enabled systems within standard change windows
Monitor upstream stable branches for backports of the retrieve_status change
Review any custom liveupdate tooling for similar uncached error paths

The record

In the Linux kernel, the following vulnerability has been resolved: liveupdate: Remember FLB retrieve() status LUO keeps track of successful retrieve attempts on an FLB. It does so to avoid multiple retrievals of the same FLB. Multiple retrievals cause problems because once the FLB is retrieved, the serialized data structures are likely freed and the FLB is likely in a very different state from what the code expects. All this works well when retrieve succeeds. When it fails, luo_flb_retrieve_one() returns the error immediately, without ever storing anywhere that a retrieve was attempted or what its error code was. If the user attempts to retrieve another file registered with the same FLB, LUO will attempt to call the FLB's retrieve() callback again. The retry is problematic for much of the same reasons listed above. The FLB is likely in a very different state than what the retrieve logic normally expects (e.g. some KHO pages may have already been restored and freed). There is no sane way of attempting the retrieve again. Remember the error retrieve returned and directly return it on a retry. This is done by changing the retrieved bool to a retrieve_status 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. This is similar to commit f85b1c6af5bc ("liveupdate: luo_file: remember retrieve() status") which did the same for LUO files.

Affected packages

Ecosystem	Package	Introduced	Fixed