# CVE-2022-50650: bpf: Fix reference state management for synchronous callbacks > A flaw in the Linux kernel BPF verifier mishandles reference states for synchronous callbacks, potentially allowing privilege escalation or code execution. - **Severity:** High 7.8 (`CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H`) - **Exploited in the wild:** Not known - **Login needed:** Any signed-in user - **Attackable:** Local or same network only - **Victim action needed:** Not needed - **Fix available:** Yes - **Published:** 9 Dec 2025 - **Updated:** 15 Oct 2026 - **Also known as:** DEBIAN-CVE-2022-50650, GHSA-f9w8-ggmf-6h55, UBUNTU-CVE-2022-50650 ## What is CVE-2022-50650? CVE-2022-50650 is a high-severity vulnerability in Linux, published on 9 Dec 2025. It can only be exploited from the same machine or local network, with no action from the victim. ### Official 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). ## Which versions are affected by CVE-2022-50650? ## How do I fix CVE-2022-50650? Apply the vendor's patch. ## Is CVE-2022-50650 being exploited? There is no known exploitation of CVE-2022-50650 in the wild and no public exploit code. ## Fix prompt for AI coding agents ```text Check this codebase for CVE-2022-50650 and fix it if it is affected. What it is: CVE-2022-50650 is a high-severity vulnerability in Linux, published on 9 Dec 2025. It can only be exploited from the same machine or local network, with no action from the victim. Exploitation: There is no known exploitation of CVE-2022-50650 in the wild and no public exploit code. Affected product: Linux. No package-level version data is available, so check the vendor advisory linked from the reference page. Task: 1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies. 2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it. 3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead. 4. Run the tests and summarise what changed and why. 5. If nothing in the project is affected, say so and change nothing. Reference: https://insights.sbomify.com/CVE-2022-50650/ (Markdown: https://insights.sbomify.com/CVE-2022-50650/index.md) ``` ## Sources - CVE record: https://www.cve.org/CVERecord?id=CVE-2022-50650 - NVD: https://nvd.nist.gov/vuln/detail/CVE-2022-50650 - OSV: https://osv.dev/vulnerability/CVE-2022-50650 --- From sbomify Insights: https://insights.sbomify.com/CVE-2022-50650/ Summaries are generated and may contain mistakes; the official description above is the record.