CVE-2022-50650

Source
https://nvd.nist.gov/vuln/detail/CVE-2022-50650
Import Source
https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2022-50650.json
JSON Data
https://api.osv.dev/v1/vulns/CVE-2022-50650
Downstream
Published
2025-12-09T00:00:24.598Z
Modified
2025-12-09T03:22:52.866161Z
Summary
bpf: Fix reference state management for synchronous callbacks
Details

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 preparefuncexit. 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 refobjids. 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 bpftimersetcallback which only executes it once, even for multiple executions it would be safe, as reference state is NULL and checkreferenceleak would force program to release state before BPFEXIT. 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 callbackctx's PTRTOSTACK, we still have to copy caller's referencestate to callback's bpffuncstate, but we enforce that whatever references it adds to that referencestate has been released before it hits BPFEXIT. This requires introducing a new callbackref member in the reference state to distinguish between caller vs callee references. Hence, checkreferenceleak now errors out if it sees we are in callbackfn 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 referencestate, but cannot mutate it, to be able to use pointers acquired by the caller. They must only undo their changes (by releasing their own acquiredrefs before BPFEXIT) on top of caller referencestate before returning (at which point the caller and callback state will match anyway, so no need to copy it back to caller).

Database specific
{
    "cna_assigner": "Linux",
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2022/50xxx/CVE-2022-50650.json"
}
References

Affected packages

Git / git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Affected ranges

Type
GIT
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Events
Introduced
69c087ba6225b574afb6e505b72cb75242a3d844
Fixed
4ed5155043c97ac8912bcf67331df87c833fb067
Fixed
caa176c0953cdfd5ce500fb517ce1ea924a8bc4c
Fixed
aed931fd3b6e28f19cc140ff90aa5046ee2aa4e1
Fixed
9d9d00ac29d0ef7ce426964de46fa6b380357d0a

Affected versions

v5.*

v5.12
v5.12-rc1
v5.12-rc1-dontuse
v5.12-rc2
v5.12-rc3
v5.12-rc4
v5.12-rc5
v5.12-rc6
v5.12-rc7
v5.12-rc8
v5.13
v5.13-rc1
v5.13-rc2
v5.13-rc3
v5.13-rc4
v5.13-rc5
v5.13-rc6
v5.13-rc7
v5.14
v5.14-rc1
v5.14-rc2
v5.14-rc3
v5.14-rc4
v5.14-rc5
v5.14-rc6
v5.14-rc7
v5.15
v5.15-rc1
v5.15-rc2
v5.15-rc3
v5.15-rc4
v5.15-rc5
v5.15-rc6
v5.15-rc7
v5.15.1
v5.15.10
v5.15.11
v5.15.12
v5.15.13
v5.15.14
v5.15.15
v5.15.16
v5.15.17
v5.15.18
v5.15.19
v5.15.2
v5.15.20
v5.15.21
v5.15.22
v5.15.23
v5.15.24
v5.15.25
v5.15.26
v5.15.27
v5.15.28
v5.15.29
v5.15.3
v5.15.30
v5.15.31
v5.15.32
v5.15.33
v5.15.34
v5.15.35
v5.15.36
v5.15.37
v5.15.38
v5.15.39
v5.15.4
v5.15.40
v5.15.41
v5.15.42
v5.15.43
v5.15.44
v5.15.45
v5.15.46
v5.15.47
v5.15.48
v5.15.49
v5.15.5
v5.15.50
v5.15.51
v5.15.52
v5.15.53
v5.15.54
v5.15.55
v5.15.56
v5.15.57
v5.15.58
v5.15.59
v5.15.6
v5.15.60
v5.15.61
v5.15.62
v5.15.63
v5.15.64
v5.15.65
v5.15.66
v5.15.67
v5.15.68
v5.15.69
v5.15.7
v5.15.70
v5.15.71
v5.15.72
v5.15.73
v5.15.74
v5.15.8
v5.15.9
v5.16
v5.16-rc1
v5.16-rc2
v5.16-rc3
v5.16-rc4
v5.16-rc5
v5.16-rc6
v5.16-rc7
v5.16-rc8
v5.17
v5.17-rc1
v5.17-rc2
v5.17-rc3
v5.17-rc4
v5.17-rc5
v5.17-rc6
v5.17-rc7
v5.17-rc8
v5.18
v5.18-rc1
v5.18-rc2
v5.18-rc3
v5.18-rc4
v5.18-rc5
v5.18-rc6
v5.18-rc7
v5.19
v5.19-rc1
v5.19-rc2
v5.19-rc3
v5.19-rc4
v5.19-rc5
v5.19-rc6
v5.19-rc7
v5.19-rc8
v5.19.1
v5.19.10
v5.19.11
v5.19.12
v5.19.13
v5.19.14
v5.19.15
v5.19.16
v5.19.2
v5.19.3
v5.19.4
v5.19.5
v5.19.6
v5.19.7
v5.19.8
v5.19.9

v6.*

v6.0
v6.0-rc1
v6.0-rc2
v6.0-rc3
v6.0-rc4
v6.0-rc5
v6.0-rc6
v6.0-rc7
v6.0.1
v6.0.2

Linux / Kernel

Package

Name
Kernel

Affected ranges

Type
ECOSYSTEM
Events
Introduced
5.13.0
Fixed
5.15.75
Type
ECOSYSTEM
Events
Introduced
5.16.0
Fixed
5.19.17
Type
ECOSYSTEM
Events
Introduced
5.20.0
Fixed
6.0.3