LiveActive security incident?Get immediate response
CVE Record

CVE-2022-50650: bpf: Fix reference state management for synchronous callbacks

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).

UnknownCVSS not scoredNot KEV-listedUpdated
Glexia's TakeAutomated analysismoderate

Security readout for executives and security teams

Plain-English summary

This Linux kernel issue involves the eBPF verifier incorrectly modeling callback behavior. A bad verifier decision can let unsafe eBPF programs pass checks. Business urgency depends on whether systems allow eBPF program loading by users or workloads. No public source provided here shows active exploitation or a CVSS score.

Executive priority

Prioritize patching internet-facing, multi-tenant, developer, and container-host systems first. Treat as a kernel hardening issue with potentially serious local impact, but not as an internet-wormable emergency based on the provided evidence.

Technical view

The flaw is in BPF reference state management for synchronous callbacks. The verifier treated callbacks as executing once, while for_each-style helpers may run them multiple times. This can mishandle acquired or released references between caller and callback frames. Kernel stable fixes add callback-specific reference tracking and leak checks.

Likely exposure

Linux systems running affected kernel versions are potentially exposed. Practical exposure is higher where untrusted users, containers, or services can load eBPF programs. Distribution backports may change version-based conclusions, so validate against vendor kernel advisories and patch status.

Exploitation context

The provided sources do not show active exploitation, KEV listing, public exploit code, or a CVSS rating. Exploitation would likely require local ability to submit eBPF programs, which is commonly restricted by privileges, kernel settings, or container policy.

Researcher notes

The key question is whether the verifier can accept programs that mutate caller reference state through repeated synchronous callbacks. Sources identify stable fixes but do not provide exploitability analysis, CVSS, or distro-specific package names. Validate using kernel source history and vendor backport metadata.

Mitigation direction

  • Apply the relevant Linux kernel stable update or distribution-provided backport.
  • Check vendor advisories for the exact fixed package for your distribution.
  • Restrict eBPF loading to trusted administrators where operationally possible.
  • Review container and workload policies that grant BPF-related capabilities.

Validation and detection

  • Inventory Linux kernel versions across servers, containers hosts, and appliances.
  • Map installed kernels to distribution advisories and fixed builds.
  • Confirm whether BPF loading is restricted for non-admin users.
  • Verify relevant stable kernel commits are present or backported.
Prepared
Confidence
medium
Sources
6

Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.

Potential ATT&CK relevance

Conservative CVE-to-ATT&CK context

These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.

ATT&CK lookup starting points

Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.

cve · low confidence lookup

CVE-2022-50650 mapping review

Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.

Open ATT&CK lookup
Vulnerability profileCVE Program record
Severity
Unknown
CVSS
Not scored
Known Exploited
No
Published
Official CVE source material

CNA and ADP enrichment extracted from CVE v5

These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.

0CVSS vectors
0Timeline events
0ADP providers
5Source links

CVSS and timeline data

No CVSS vectors or timeline events were available in the normalized CVE source material.

Affected products

Products and packages named in the record

VendorProductVersion / packageStatus
LinuxLinux69c087ba6225b574afb6e505b72cb75242a3d844, 69c087ba6225b574afb6e505b72cb75242a3d844, 69c087ba6225b574afb6e505b72cb75242a3d844, 69c087ba6225b574afb6e505b72cb75242a3d844unaffected
LinuxLinux5.13, 0, 5.15.75, 5.19.17, 6.0.3, 6.1affected
Weakness

CWE details

No CWE listed

CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.