VYPR
Unrated severityNVD Advisory· Published Dec 9, 2025· Updated Apr 15, 2026

CVE-2022-50650

CVE-2022-50650

Description

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix reference state management for synchronous callbacks

Currently, verifier verifies callback functions (sync and async) as if they will be executed once, (i.e. it explores execution state as if the function was being called once). The next insn to explore is set to start of subprog and the exit from nested frame is handled using curframe > 0 and prepare_func_exit. In case of async callback it uses a customized variant of push_stack simulating a kind of branch to set up custom state and execution context for the async callback.

While this approach is simple and works when callback really will be executed only once, it is unsafe for all of our current helpers which are for_each style, i.e. they execute the callback multiple times.

A callback releasing acquired references of the caller may do so multiple times, but currently verifier sees it as one call inside the frame, which then returns to caller. Hence, it thinks it released some reference that the cb e.g. got access through callback_ctx (register filled inside cb from spilled typed register on stack).

Similarly, it may see that an acquire call is unpaired inside the callback, so the caller will copy the reference state of callback and then will have to release the register with new ref_obj_ids. But again, the callback may execute multiple times, but the verifier will only account for acquired references for a single symbolic execution of the callback, which will cause leaks.

Note that for async callback case, things are different. While currently we have bpf_timer_set_callback which only executes it once, even for multiple executions it would be safe, as reference state is NULL and check_reference_leak would force program to release state before BPF_EXIT. The state is also unaffected by analysis for the caller frame. Hence async callback is safe.

Since we want the reference state to be accessible, e.g. for pointers loaded from stack through callback_ctx's PTR_TO_STACK, we still have to copy caller's reference_state to callback's bpf_func_state, but we enforce that whatever references it adds to that reference_state has been released before it hits BPF_EXIT. This requires introducing a new callback_ref member in the reference state to distinguish between caller vs callee references. Hence, check_reference_leak now errors out if it sees we are in callback_fn and we have not released callback_ref refs. Since there can be multiple nested callbacks, like frame 0 -> cb1 -> cb2 etc. we need to also distinguish between whether this particular ref belongs to this callback frame or parent, and only error for our own, so we store state->frameno (which is always non-zero for callbacks).

In short, callbacks can read parent reference_state, but cannot mutate it, to be able to use pointers acquired by the caller. They must only undo their changes (by releasing their own acquired_refs before BPF_EXIT) on top of caller reference_state before returning (at which point the caller and callback state will match anyway, so no need to copy it back to caller).

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

Linux kernel BPF verifier incorrectly manages reference state for synchronous callbacks, allowing multiple releases or leaks when callbacks execute more than once.

Vulnerability

Overview

The Linux kernel's BPF (Berkeley Packet Filter) verifier) contains a flaw in how it tracks reference state for synchronous callback functions. The verifier currently treats all callbacks—both synchronous and asynchronous—as if they will execute exactly once during program verification. However, several BPF helpers (e.g., bpf_loop, bpf_for_each_map_elem) invoke the callback multiple times in a loop. This mismatch leads to incorrect reference counting: the verifier may see a reference released inside the callback and assume it is freed permanently, while in reality the callback can release the same reference multiple times, causing use-after-free or double-free conditions [1][2].

Exploitation and

Attack Surface

To exploit this vulnerability, an attacker must have the ability to load and execute a crafted BPF program on a system where the affected kernel version is running. No special privileges beyond CAP_BPF or CAP_SYS_ADMIN are typically required, but the attacker must be able to interact with the BPF subsystem. The bug is triggered when a BPF program uses a synchronous callback helper that acquires or releases references (e.g., to kernel objects like bpf_spin_lock or bpf_timer). The verifier's incorrect state tracking can lead to the program being accepted even though it would cause reference leaks or double releases at runtime [1].

Impact

A successful exploitation could allow an attacker to corrupt kernel memory, potentially leading to privilege escalation, denial of service, or information disclosure. Specifically, the verifier may fail to detect that a reference acquired inside a callback is not properly released after multiple callback invocations, resulting in a memory leak. Conversely, it may incorrectly assume a reference is released when it is actually freed multiple times, leading to a use-after-free condition. Both scenarios can be leveraged to compromise the kernel's integrity [1][2].

Mitigation

Status

Patches have been applied to the Linux kernel stable branches. The fix involves updating the verifier's reference state management to account for multiple callback executions by tracking reference counts per-callback invocation. Users should update their kernels to versions containing the commits referenced in [1] and [2] (e.g., 9d9d00ac29d0 and caa176c0953c). No workaround is available; applying the kernel patch is the only mitigation.

AI Insight generated on May 19, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

2
  • Linux/Kernelinferred2 versions
    (expand)+ 1 more
    • (no CPE)
    • (no CPE)

Patches

4

Vulnerability mechanics

Generated on May 9, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

4

News mentions

0

No linked articles in our index yet.