CVE-2023-52920: bpf: support non-r10 register spill/fill to/from stack in precision tracking
In the Linux kernel, the following vulnerability has been resolved:
bpf: support non-r10 register spill/fill to/from stack in precision tracking
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/
Security readout for executives and security teams
Plain-English summary
CVE-2023-52920 is a Linux kernel BPF verifier issue fixed by upstream stable commits. The public record describes a verifier precision-tracking correction, not a confirmed breach or exploit campaign. Business urgency is mainly for organizations running affected Linux kernels, especially where kernel updates are delayed.
Executive priority
Treat as a kernel maintenance priority, not an emergency based on current public evidence. Patch during normal or accelerated Linux update cycles, with higher priority for internet-facing, multi-user, or high-value systems.
Technical view
The fix updates BPF verifier precision backtracking to correctly track register spill/fill operations through stack accesses, including non-r10 registers derived from r10. The CVE record lists Linux kernel versions as affected and references four stable kernel commits. No CVSS score, CWE, exploitability detail, or concrete security impact is provided in the source bundle.
Likely exposure
Potential exposure is limited to Linux systems running affected kernel builds. The record does not identify distributions, configurations, or required privileges. Confirm exposure through kernel version inventory and vendor advisories for packaged kernels.
Exploitation context
CISA KEV status is false in the provided bundle, and no cited source reports active exploitation. The sources do not provide a proof of concept, attacker prerequisites, or practical exploit conditions.
Researcher notes
The public description is commit-oriented and lacks impact classification. Analysis should focus on the BPF verifier code paths changed by the referenced commits and downstream backport status. Avoid assuming exploitability beyond what vendors or maintainers state.
Mitigation direction
Review Linux vendor advisories for CVE-2023-52920 applicability.
Update affected kernels to vendor-provided fixed builds.
Prioritize systems allowing broad BPF use or rapid kernel attack-surface exposure.
Track the referenced upstream stable commits in kernel change management.
Validation and detection
Inventory Linux kernel versions across servers, endpoints, and appliances.
Compare installed kernels with vendor advisories for this CVE.
Verify whether fixed upstream commits are included in your kernel package.
Document exceptions where vendor backport status is unclear.
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-2023-52920 mapping review
Open the CVE-to-ATT&CK bridge for reviewed, inferred, or future official mappings tied to this CVE.
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
3Timeline events
0ADP providers
5Source links
Vulnerability timeline
Timeline events are normalized from CVE metadata, CNA source timelines, ADP timelines, and KEV metadata when present.
CVE reservedCVE Program
The CVE ID was reserved by the assigning CNA.
CVE publishedCVE Program
The CVE record was published.
Nov 5, 2024, 10:09 UTC (UTC+00:00)
CVE updatedCVE Program
The CVE record metadata indicates this as the latest update time.