CVE-2026-92483: liveupdate: Remember FLB retrieve() status
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, luoflbretrieveone() 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 retrievestatus 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: luofile: remember retrieve() status") which did the same for LUO files.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Change LUO’s tracking from a simple retrieved boolean to a retrieve_status integer that records whether FLB retrieve() was attempted/succeeded/failed; if retrieve() is attempted again for the same FLB, return the stored error code immediately (do not call the FLB’s retrieve() callback again).
Linux kernel liveupdate (luo_file / luo_flb_retrieve_one) retrieve status tracking (retrieved bool -> retrieve_status) = store retrieve_status to avoid multiple retrievals of the same FLB; on retry return stored retrieve_status error immediately
Event History
Frequently Asked Questions
What sequence can trigger the problematic retry?
A retrieve attempt must first fail for an FLB, followed by an attempt to retrieve another file registered with that same FLB. In the affected behavior, the second attempt invokes the FLB retrieve callback again.
Why is retrying after a failed retrieve unsafe?
The failed attempt may already have restored and freed KHO pages, leaving the FLB in a state the normal retrieve logic does not expect. A subsequent callback invocation can therefore operate on changed or partially freed serialized state.
How does the resolved behavior handle later retrieve attempts for the same FLB?
It records the status from the first retrieve attempt. If that attempt failed, later attempts directly return the recorded error instead of calling the retrieve callback again.