Look up another CVE · open CVE-2023-52920 in the interactive tracker
CVE-2023-52920
bpf: support non-r10 register spill/fill to/from stack in precision tracking
Published 2024-11-05 (23 months ago) by the Linux kernel CNA. Subsystem include/linux. Debian urgency: not yet assigned.
What to do, per Debian release
Debian's own status for CVE-2023-52920 in every release this site tracks, and what each one means in practice. Every status below is the one the Debian Security Team publishes for this CVE. source
| Release | Status | Version | What this means |
|---|---|---|---|
| Debian 12bookworm | vulnerable | 6.1.190-1 | No fix published anywhere yet, neither in Debian nor upstream for the series bookworm tracks. Watch the Debian tracker page for this CVE. Advisories for bookworm have historically landed a median of 23 days after publication. |
| Debian 13trixie | fixed | 6.8.9-1 | Update the kernel and reboot. Fixed in 6.8.9-1. A running kernel keeps the old code until the machine restarts. |
| Debian 14forky | fixed | 6.8.9-1 | Update the kernel and reboot. Fixed in 6.8.9-1. A running kernel keeps the old code until the machine restarts. |
| Debian unstablesid | fixed | 6.8.9-1 | Update the kernel and reboot. Fixed in 6.8.9-1. A running kernel keeps the old code until the machine restarts. |
The vulnerability
What the bug is
Use instruction (jump) history to record instructions that performed register spill/fill to/from stack, regardless if this was done through read-only r10 register, or any other register after copying r10 into it *and* potentially adjusting offset. To make this work reliably, we push extra per-instruction flags into instruction history, encoding stack slot index (spi) and stack frame number in extra 10 bit flags we take away from prev_idx in instruction history. We don't touch idx field for maximum performance, as it's checked most frequently during backtracking. This change removes basically the last remaining practical limitation of precision backtracking logic in BPF verifier. It fixes known deficiencies, but also opens up new opportunities to reduce number of verified states, explored in the subsequent patches. There are only three differences in selftests' BPF object files according to veristat, all in the positive direction (less states). File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) -------------------------------------- ------------- --------- --------- ------------- ---------- ---------- ------------- test_cls_redirect_dynptr.bpf.linked3.o cls_redirect 2987 2864 -123 (-4.12%) 240 231 -9 (-3.75%) xdp_synproxy_kern.bpf.linked3.o syncookie_tc 82848 82661 -187 (-0.23%) 5107 5073 -34 (-0.67%) xdp_synproxy_kern.bpf.linked3.o syncookie_xdp 85116 84964 -152 (-0.18%) 5162 5130 -32 (-0.62%) Note, I avoided renaming jmp_history to more generic insn_hist to minimize number of lines changed and potential merge conflicts between bpf and bpf-next trees. Notice also cur_hist_entry pointer reset to NULL at the beginning of instruction verification loop. This pointer avoids the problem of relying on last jump history entry's insn_idx to determine whether we already have entry for current instruction or not. It can happen that we added jump history entry because current instruction is_jmp_point(), but also we need to add instruction flags for stack access. In this case, we don't want to entries, so we need to reuse last added entry, if it is present. Relying on insn_idx comparison has the same ambiguity problem as the one that was fixed recently in [0], so we avoid that. [0] https://patchwork.kernel.org/project/netdevbpf/patch/20231110002638.4168352-3-andrii@kernel.org/
Where it lives
The fix touches these files. If the subsystem is one you do not use, the practical exposure is lower, though the package is still the vulnerable one.
include/linux/bpf_verifier.h
kernel/bpf/verifier.c
tools/testing/selftests/bpf/progs/verifier_subprog_precision.c
tools/testing/selftests/bpf/verifier/precise.c
- What this is
- BPF [CORE]MAINTAINERS section matched on include/linux/bpf* · bpf@vger.kernel.org · Maintained
Check it on the machine
grep -wE 'CONFIG_BPF|CONFIG_BPF_SYSCALL' /boot/config-$(uname -r)Reads the booted kernel's own configuration, on the machine and nowhere else. =y is built in, =m is a module, and an is not set line means the code is not there.
Show whether Debian builds this, per release
Debian builds this code. Every release below compiles the affected file into the kernels it ships.
- bookworm, trixie, forky, sidy
- y
- built into the kernel image on every flavour - only a patch removes it
- Build switches
- CONFIG_BPF, CONFIG_BPF_SYSCALL
- Reads as
- all on means the file is compiled; any one off means it is not.
From the configuration Debian publishes for every kernel flavour it builds. It covers only the architectures Debian ships a linux-config package for, and nothing about a kernel you built yourself. Debian's own status above stays authoritative about the source package.MAINTAINERS kbuild Makefiles Debian linux-config packages
Signals
- Published
- 2024-11-05 (23 months ago)source
- CVSS
- 7.8 high
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:Hsource recompute it - Attack vector
- local (AV:L)source
- EPSS
- 0.25%, higher than 15.8% of all CVEssource
- CISA KEV
- not listedthe KEV catalogue
- Debian urgency
- not yet assignedsource
- Subsystem
- include/linux
Upstream fixes
The versions the CNA records as introducing and fixing this, and the commit for each. source
| Introduced | Fixed in | Commit |
|---|---|---|
| 5.3 | 6.6.64 | ecc2aeeaa08a |
| 5.3 | 6.6.70 | 199f04528737 |
| 5.3 | 6.6.140 | e4da60feca4d |
| 5.3 | 6.8 | 41f6f64e6999 |
Why the CNA scored it this way
Quoted from the kernel CNA's own scoring file, word for word. A highlighted metric carries the most severe value CVSS v3.1 defines for it, which is what pushes the score up. source
- AV:LAttack vector, local
- The bug is reached only by loading an attacker-crafted BPF program through the local bpf() syscall into the verifier; there is no network or adjacent-protocol path into precision backtracking.
- AC:LAttack complexity, low
- The attacker fully controls the program that triggers non-r10 stack spill/fill and incorrect state pruning; with CAP_PERFMON (common alongside CAP_BPF), bpf_bypass_spec_v1() disables Spectre sanitization so exploitation does not depend on external conditions.
- PR:LPrivileges required, low
- Exploitation requires CAP_BPF (and typically CAP_PERFMON), which are delegatable non-root capabilities routinely granted to containers and observability/networking agents rather than full init-namespace root, matching prior kernel CNA BPF scoring.
- UI:NUser interaction, none
- The attacker loads and attaches the malicious BPF program themselves; no separate victim action such as mounting a filesystem or opening a file is required.
- S:UScope, unchanged
- Successful exploitation yields host-kernel memory corruption and local privilege escalation within the same OS security authority, not a VM escape, IOMMU bypass, or other cross-boundary effect.
- C:HConfidentiality impact, high
- Incorrect precision tracking lets the verifier accept a path that adds an attacker-controlled offset to a map pointer, enabling out-of-bounds reads of kernel memory (Tao Lyu demonstrated arbitrary read).
- I:HIntegrity impact, high
- The same map-pointer OOB write primitive supports arbitrary kernel writes and control-flow hijacking; the reporter successfully escalated to root privilege.
- A:HAvailability impact, high
- The resulting out-of-bounds map access corrupts kernel memory and can oops/panic the kernel, and related non-r10/subprog backtracking paths also hit verifier WARN_ONCE backtracking bugs.