CVE-2022-50650 (GCVE-0-2022-50650)
Vulnerability from cvelistv5
Published
2025-12-09 00:00
Modified
2026-10-15 21:41
Severity ?
VLAI Severity ?
EPSS score ?
Summary
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).
References
| URL | Tags | |
|---|---|---|
Impacted products
{
"containers": {
"adp": [
{
"metrics": [
{
"other": {
"content": {
"id": "CVE-2022-50650",
"options": [
{
"Exploitation": "none"
},
{
"Automatable": "no"
},
{
"Technical Impact": "total"
}
],
"role": "CISA Coordinator",
"timestamp": "2026-10-15T21:31:45.674520Z",
"version": "2.0.3"
},
"type": "ssvc"
}
}
],
"providerMetadata": {
"dateUpdated": "2026-10-15T21:41:22.127Z",
"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"shortName": "CISA-ADP"
},
"title": "CISA ADP Vulnrichment"
}
],
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"include/linux/bpf_verifier.h",
"kernel/bpf/verifier.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "4ed5155043c97ac8912bcf67331df87c833fb067",
"status": "affected",
"version": "69c087ba6225b574afb6e505b72cb75242a3d844",
"versionType": "git"
},
{
"lessThan": "caa176c0953cdfd5ce500fb517ce1ea924a8bc4c",
"status": "affected",
"version": "69c087ba6225b574afb6e505b72cb75242a3d844",
"versionType": "git"
},
{
"lessThan": "aed931fd3b6e28f19cc140ff90aa5046ee2aa4e1",
"status": "affected",
"version": "69c087ba6225b574afb6e505b72cb75242a3d844",
"versionType": "git"
},
{
"lessThan": "9d9d00ac29d0ef7ce426964de46fa6b380357d0a",
"status": "affected",
"version": "69c087ba6225b574afb6e505b72cb75242a3d844",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"include/linux/bpf_verifier.h",
"kernel/bpf/verifier.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "5.13"
},
{
"lessThan": "5.13",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.75",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.19.*",
"status": "unaffected",
"version": "5.19.17",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.0.*",
"status": "unaffected",
"version": "6.0.3",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.1",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.75",
"versionStartIncluding": "5.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.19.17",
"versionStartIncluding": "5.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.0.3",
"versionStartIncluding": "5.13",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1",
"versionStartIncluding": "5.13",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix reference state management for synchronous callbacks\n\nCurrently, verifier verifies callback functions (sync and async) as if\nthey will be executed once, (i.e. it explores execution state as if the\nfunction was being called once). The next insn to explore is set to\nstart of subprog and the exit from nested frame is handled using\ncurframe \u003e 0 and prepare_func_exit. In case of async callback it uses a\ncustomized variant of push_stack simulating a kind of branch to set up\ncustom state and execution context for the async callback.\n\nWhile this approach is simple and works when callback really will be\nexecuted only once, it is unsafe for all of our current helpers which\nare for_each style, i.e. they execute the callback multiple times.\n\nA callback releasing acquired references of the caller may do so\nmultiple times, but currently verifier sees it as one call inside the\nframe, which then returns to caller. Hence, it thinks it released some\nreference that the cb e.g. got access through callback_ctx (register\nfilled inside cb from spilled typed register on stack).\n\nSimilarly, it may see that an acquire call is unpaired inside the\ncallback, so the caller will copy the reference state of callback and\nthen will have to release the register with new ref_obj_ids. But again,\nthe callback may execute multiple times, but the verifier will only\naccount for acquired references for a single symbolic execution of the\ncallback, which will cause leaks.\n\nNote that for async callback case, things are different. While currently\nwe have bpf_timer_set_callback which only executes it once, even for\nmultiple executions it would be safe, as reference state is NULL and\ncheck_reference_leak would force program to release state before\nBPF_EXIT. The state is also unaffected by analysis for the caller frame.\nHence async callback is safe.\n\nSince we want the reference state to be accessible, e.g. for pointers\nloaded from stack through callback_ctx\u0027s PTR_TO_STACK, we still have to\ncopy caller\u0027s reference_state to callback\u0027s bpf_func_state, but we\nenforce that whatever references it adds to that reference_state has\nbeen released before it hits BPF_EXIT. This requires introducing a new\ncallback_ref member in the reference state to distinguish between caller\nvs callee references. Hence, check_reference_leak now errors out if it\nsees we are in callback_fn and we have not released callback_ref refs.\nSince there can be multiple nested callbacks, like frame 0 -\u003e cb1 -\u003e cb2\netc. we need to also distinguish between whether this particular ref\nbelongs to this callback frame or parent, and only error for our own, so\nwe store state-\u003eframeno (which is always non-zero for callbacks).\n\nIn short, callbacks can read parent reference_state, but cannot mutate\nit, to be able to use pointers acquired by the caller. They must only\nundo their changes (by releasing their own acquired_refs before\nBPF_EXIT) on top of caller reference_state before returning (at which\npoint the caller and callback state will match anyway, so no need to\ncopy it back to caller)."
}
],
"metrics": [
{
"cvssV3_1": {
"baseScore": 7.8,
"baseSeverity": "HIGH",
"vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"version": "3.1"
},
"scenarios": [
{
"lang": "en",
"value": "AV:L - The bug is in the BPF verifier\u2019s handling of synchronous callbacks and is reached by loading a crafted eBPF program via the local bpf() syscall (then running/attaching it). Per kernel guidance, BPF verifier bugs are Local, not network-reachable.\nAC:L - The attacker fully controls the program, map contents, and callback logic; with a multi-element map (e.g. 16 entries), the callback deterministically releases the same acquired reference multiple times. No race or victim-dependent state is required.\nPR:L - Exercising bpf_for_each_map_elem/bpf_loop with referenced objects needs CAP_BPF (or equivalent BPF load rights), which is commonly available to non-root local users or delegated service accounts without full root. Consistent with other BPF verifier scores, the highest reasonable deployment is PR:L.\nUI:N - The attacker loads and executes the malicious BPF program themselves (e.g. via BPF_PROG_TEST_RUN or an attach point they control); no separate victim action is required.\nS:U - Impact is kernel memory corruption and privilege escalation within the same OS security authority. This is standard local kernel compromise, not a VM/IOMMU boundary escape.\nC:H - The verifier bug allows a callback to under-release-track a caller\u2019s acquired reference so runtime multi-iteration release causes refcount underflow and UAF of sockets/kfunc objects, enabling arbitrary kernel memory disclosure.\nI:H - The same UAF of refcounted kernel objects is exploitable for heap reuse and arbitrary write / control-flow hijacking, as confirmed by the underflow_prog regression case that would release once per map element.\nA:H - Refcount underflow and use-after-free of kernel objects can oops/panic the kernel even without a full exploit, and the attacker can trigger the program repeatedly."
}
]
}
],
"providerMetadata": {
"dateUpdated": "2026-08-05T08:59:14.920Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/4ed5155043c97ac8912bcf67331df87c833fb067"
},
{
"url": "https://git.kernel.org/stable/c/caa176c0953cdfd5ce500fb517ce1ea924a8bc4c"
},
{
"url": "https://git.kernel.org/stable/c/aed931fd3b6e28f19cc140ff90aa5046ee2aa4e1"
},
{
"url": "https://git.kernel.org/stable/c/9d9d00ac29d0ef7ce426964de46fa6b380357d0a"
}
],
"title": "bpf: Fix reference state management for synchronous callbacks",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2022-50650",
"datePublished": "2025-12-09T00:00:24.598Z",
"dateReserved": "2025-12-08T23:57:43.371Z",
"dateUpdated": "2026-10-15T21:41:22.127Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"vulnrichment": {
"containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2022-50650\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"total\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-10-15T21:31:45.674520Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-10-15T21:31:46.478Z\"}}], \"cna\": {\"title\": \"bpf: Fix reference state management for synchronous callbacks\", \"metrics\": [{\"cvssV3_1\": {\"version\": \"3.1\", \"baseScore\": 7.8, \"baseSeverity\": \"HIGH\", \"vectorString\": \"CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"AV:L - The bug is in the BPF verifier\\u2019s handling of synchronous callbacks and is reached by loading a crafted eBPF program via the local bpf() syscall (then running/attaching it). Per kernel guidance, BPF verifier bugs are Local, not network-reachable.\\nAC:L - The attacker fully controls the program, map contents, and callback logic; with a multi-element map (e.g. 16 entries), the callback deterministically releases the same acquired reference multiple times. No race or victim-dependent state is required.\\nPR:L - Exercising bpf_for_each_map_elem/bpf_loop with referenced objects needs CAP_BPF (or equivalent BPF load rights), which is commonly available to non-root local users or delegated service accounts without full root. Consistent with other BPF verifier scores, the highest reasonable deployment is PR:L.\\nUI:N - The attacker loads and executes the malicious BPF program themselves (e.g. via BPF_PROG_TEST_RUN or an attach point they control); no separate victim action is required.\\nS:U - Impact is kernel memory corruption and privilege escalation within the same OS security authority. This is standard local kernel compromise, not a VM/IOMMU boundary escape.\\nC:H - The verifier bug allows a callback to under-release-track a caller\\u2019s acquired reference so runtime multi-iteration release causes refcount underflow and UAF of sockets/kfunc objects, enabling arbitrary kernel memory disclosure.\\nI:H - The same UAF of refcounted kernel objects is exploitable for heap reuse and arbitrary write / control-flow hijacking, as confirmed by the underflow_prog regression case that would release once per map element.\\nA:H - Refcount underflow and use-after-free of kernel objects can oops/panic the kernel even without a full exploit, and the attacker can trigger the program repeatedly.\"}]}], \"affected\": [{\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"69c087ba6225b574afb6e505b72cb75242a3d844\", \"lessThan\": \"4ed5155043c97ac8912bcf67331df87c833fb067\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"69c087ba6225b574afb6e505b72cb75242a3d844\", \"lessThan\": \"caa176c0953cdfd5ce500fb517ce1ea924a8bc4c\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"69c087ba6225b574afb6e505b72cb75242a3d844\", \"lessThan\": \"aed931fd3b6e28f19cc140ff90aa5046ee2aa4e1\", \"versionType\": \"git\"}, {\"status\": \"affected\", \"version\": \"69c087ba6225b574afb6e505b72cb75242a3d844\", \"lessThan\": \"9d9d00ac29d0ef7ce426964de46fa6b380357d0a\", \"versionType\": \"git\"}], \"programFiles\": [\"include/linux/bpf_verifier.h\", \"kernel/bpf/verifier.c\"], \"defaultStatus\": \"unaffected\"}, {\"repo\": \"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git\", \"vendor\": \"Linux\", \"product\": \"Linux\", \"versions\": [{\"status\": \"affected\", \"version\": \"5.13\"}, {\"status\": \"unaffected\", \"version\": \"0\", \"lessThan\": \"5.13\", \"versionType\": \"semver\"}, {\"status\": \"unaffected\", \"version\": \"5.15.75\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.15.*\"}, {\"status\": \"unaffected\", \"version\": \"5.19.17\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"5.19.*\"}, {\"status\": \"unaffected\", \"version\": \"6.0.3\", \"versionType\": \"semver\", \"lessThanOrEqual\": \"6.0.*\"}, {\"status\": \"unaffected\", \"version\": \"6.1\", \"versionType\": \"original_commit_for_fix\", \"lessThanOrEqual\": \"*\"}], \"programFiles\": [\"include/linux/bpf_verifier.h\", \"kernel/bpf/verifier.c\"], \"defaultStatus\": \"affected\"}], \"references\": [{\"url\": \"https://git.kernel.org/stable/c/4ed5155043c97ac8912bcf67331df87c833fb067\"}, {\"url\": \"https://git.kernel.org/stable/c/caa176c0953cdfd5ce500fb517ce1ea924a8bc4c\"}, {\"url\": \"https://git.kernel.org/stable/c/aed931fd3b6e28f19cc140ff90aa5046ee2aa4e1\"}, {\"url\": \"https://git.kernel.org/stable/c/9d9d00ac29d0ef7ce426964de46fa6b380357d0a\"}], \"x_generator\": {\"engine\": \"bippy-1.2.0\"}, \"descriptions\": [{\"lang\": \"en\", \"value\": \"In the Linux kernel, the following vulnerability has been resolved:\\n\\nbpf: Fix reference state management for synchronous callbacks\\n\\nCurrently, verifier verifies callback functions (sync and async) as if\\nthey will be executed once, (i.e. it explores execution state as if the\\nfunction was being called once). The next insn to explore is set to\\nstart of subprog and the exit from nested frame is handled using\\ncurframe \u003e 0 and prepare_func_exit. In case of async callback it uses a\\ncustomized variant of push_stack simulating a kind of branch to set up\\ncustom state and execution context for the async callback.\\n\\nWhile this approach is simple and works when callback really will be\\nexecuted only once, it is unsafe for all of our current helpers which\\nare for_each style, i.e. they execute the callback multiple times.\\n\\nA callback releasing acquired references of the caller may do so\\nmultiple times, but currently verifier sees it as one call inside the\\nframe, which then returns to caller. Hence, it thinks it released some\\nreference that the cb e.g. got access through callback_ctx (register\\nfilled inside cb from spilled typed register on stack).\\n\\nSimilarly, it may see that an acquire call is unpaired inside the\\ncallback, so the caller will copy the reference state of callback and\\nthen will have to release the register with new ref_obj_ids. But again,\\nthe callback may execute multiple times, but the verifier will only\\naccount for acquired references for a single symbolic execution of the\\ncallback, which will cause leaks.\\n\\nNote that for async callback case, things are different. While currently\\nwe have bpf_timer_set_callback which only executes it once, even for\\nmultiple executions it would be safe, as reference state is NULL and\\ncheck_reference_leak would force program to release state before\\nBPF_EXIT. The state is also unaffected by analysis for the caller frame.\\nHence async callback is safe.\\n\\nSince we want the reference state to be accessible, e.g. for pointers\\nloaded from stack through callback_ctx\u0027s PTR_TO_STACK, we still have to\\ncopy caller\u0027s reference_state to callback\u0027s bpf_func_state, but we\\nenforce that whatever references it adds to that reference_state has\\nbeen released before it hits BPF_EXIT. This requires introducing a new\\ncallback_ref member in the reference state to distinguish between caller\\nvs callee references. Hence, check_reference_leak now errors out if it\\nsees we are in callback_fn and we have not released callback_ref refs.\\nSince there can be multiple nested callbacks, like frame 0 -\u003e cb1 -\u003e cb2\\netc. we need to also distinguish between whether this particular ref\\nbelongs to this callback frame or parent, and only error for our own, so\\nwe store state-\u003eframeno (which is always non-zero for callbacks).\\n\\nIn short, callbacks can read parent reference_state, but cannot mutate\\nit, to be able to use pointers acquired by the caller. They must only\\nundo their changes (by releasing their own acquired_refs before\\nBPF_EXIT) on top of caller reference_state before returning (at which\\npoint the caller and callback state will match anyway, so no need to\\ncopy it back to caller).\"}], \"cpeApplicability\": [{\"nodes\": [{\"negate\": false, \"cpeMatch\": [{\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.15.75\", \"versionStartIncluding\": \"5.13\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"5.19.17\", \"versionStartIncluding\": \"5.13\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.0.3\", \"versionStartIncluding\": \"5.13\"}, {\"criteria\": \"cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*\", \"vulnerable\": true, \"versionEndExcluding\": \"6.1\", \"versionStartIncluding\": \"5.13\"}], \"operator\": \"OR\"}]}], \"providerMetadata\": {\"orgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"shortName\": \"Linux\", \"dateUpdated\": \"2026-08-05T08:59:14.920Z\"}}}",
"cveMetadata": "{\"cveId\": \"CVE-2022-50650\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-10-15T21:41:22.127Z\", \"dateReserved\": \"2025-12-08T23:57:43.371Z\", \"assignerOrgId\": \"416baaa9-dc9f-4396-8d5f-8c081fb06d67\", \"datePublished\": \"2025-12-09T00:00:24.598Z\", \"assignerShortName\": \"Linux\"}",
"dataType": "CVE_RECORD",
"dataVersion": "5.2"
}
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
- Confirmed: The vulnerability is confirmed from an analyst perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
- Patched: This vulnerability was successfully patched by the user reporting the sighting.
- Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
- Not confirmed: The user expresses doubt about the veracity of the vulnerability.
- Not patched: This vulnerability was not successfully patched by the user reporting the sighting.
Loading…
Loading…