Skip to content
Fencer Vulns
high 7.8

CVE-2023-52452 json

bpf: Fix accesses to uninit stack slots

published 2024-02-22 2 y ago modified 2026-10-30 10 d ago also EUVD-2023-57077

cvss
7.8
version 3.1, NVD
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 15%
public exploits
0
none known

Summary

In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix accesses to uninit stack slots

Privileged programs are supposed to be able to read uninitialized stack memory (ever since 6715df8d5) but, before this patch, these accesses were permitted inconsistently. In particular, accesses were permitted above state->allocated_stack, but not below it. In other words, if the stack was already "large enough", the access was permitted, but otherwise the access was rejected instead of being allowed to "grow the stack". This undesired rejection was happening in two places: - in check_stack_slot_within_bounds() - in check_stack_range_initialized() This patch arranges for these accesses to be permitted. A bunch of tests that were relying on the old rejection had to change; all of them were changed to add also run unprivileged, in which case the old behavior persists. One tests couldn't be updated - global_func16 - because it can't run unprivileged for other reasons.

This patch also fixes the tracking of the stack size for variable-offset reads. This second fix is bundled in the same commit as the first one because they're inter-related. Before this patch, writes to the stack using registers containing a variable offset (as opposed to registers with fixed, known values) were not properly contributing to the function's needed stack size. As a result, it was possible for a program to verify, but then to attempt to read out-of-bounds data at runtime because a too small stack had been allocated for it.

Each function tracks the size of the stack it needs in bpf_subprog_info.stack_depth, which is maintained by update_stack_depth(). For regular memory accesses, check_mem_access() was calling update_state_depth() but it was passing in only the fixed part of the offset register, ignoring the variable offset. This was incorrect; the minimum possible value of that register should be used instead.

This tracking is now fixed by centralizing the tracking of stack size in grow_stack_state(), and by lifting the calls to grow_stack_state() to check_stack_access_within_bounds() as suggested by Andrii. The code is now simpler and more convincingly tracks the correct maximum stack size. check_stack_range_initialized() can now rely on enough stack having been allocated for the access; this helps with the fix for the first issue.

A few tests were changed to also check the stack depth computation. The one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.

Patch / fix

  • Linux Linux 5.11, 5.12, 6.1.191, 6.6.14, 6.7.2, 6.8
  • linux Debian 14, Debian 13 6.6.15-1

debian advisories DEBIAN-CVE-2023-52452

  • linux-gcp-6.5 Ubuntu 22.04 LTS 6.5.0-1022.24~22.04.1
  • linux-hwe-6.5 Ubuntu 22.04 LTS 6.5.0-41.41~22.04.2
  • linux-oem-6.5 Ubuntu 22.04 LTS 6.5.0-1024.25
  • linux-azure-6.5 Ubuntu 22.04 LTS 6.5.0-1022.23~22.04.1
  • linux-riscv-6.5 Ubuntu 22.04 LTS 6.5.0-40.40.1~22.04.1
  • linux-nvidia-6.5 Ubuntu 22.04 LTS 6.5.0-1021.22
  • linux-oracle-6.5 Ubuntu 22.04 LTS 6.5.0-1024.24~22.04.1
  • linux-starfive-6.5 Ubuntu 22.04 LTS 6.5.0-1015.16~22.04.1

ubuntu advisories UBUNTU-CVE-2023-52452

Ubuntu security data © Canonical Ltd., from https://github.com/canonical/ubuntu-security-notices via OSV; changed: normalised to fixed package versions per release. CC BY-SA 4.0

  • kernel-rt SLE Micro 5.4, SLE Micro 5.3, openSUSE Leap Micro 5.4 +1 more 5.14.21-150400.15.71.1
  • kernel-source-rt SLE Micro 5.4, SLE Micro 5.3 5.14.21-150400.15.71.1
  • kernel-rt SLE Micro 5.5, Real Time Module 15 SP5, openSUSE Leap 15.5 5.14.21-150500.13.38.1
  • kernel-syms-rt Real Time Module 15 SP5, openSUSE Leap 15.5 5.14.21-150500.13.38.1
  • kernel-rt_debug Real Time Module 15 SP5, openSUSE Leap 15.5 5.14.21-150500.13.38.1
  • kernel-source-rt SLE Micro 5.5, Real Time Module 15 SP5, openSUSE Leap 15.5 5.14.21-150500.13.38.1
  • kernel-syms SLE High Performance Computing 15 SP4-ESPOS, Manager Server 4.3, Manager Proxy 4.3 +3 more 5.14.21-150400.24.111.1
  • kernel-source SLE High Performance Computing 15 SP4-ESPOS, Manager Server 4.3, Manager Proxy 4.3 +3 more 5.14.21-150400.24.111.1

suse advisories SUSE-SU-2024:0977-1SUSE-SU-2024:0910-1SUSE-SU-2024:0900-2SUSE-SU-2024:0900-1SUSE-SU-2024:0858-1SUSE-SU-2024:0855-1

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2023-52452 updated cvss 6.7

kernel: bpf: Fix accesses to uninit stack slots

  • Red Hat Enterprise Linux 8 perf, kernel, bpftool, kernel-rt, kernel-core, kernel-tools, +29 more Red Hat Enterprise Linux 9 rv, perf, rtla, kernel, bpftool, libperf, +82 more
    affected: workaround, no fix available “As a temporary solution, set the following sysctl: kernel.unprivileged_bpf_disabled = 1”
  • Red Hat Enterprise Linux 6 perf, kernel, python-perf, kernel-kdump, kernel-firmware, kernel-bootwrapper, +1 more Red Hat Enterprise Linux 7 perf, kernel, bpftool, kernel-rt, python-perf, kernel-kdump, +8 more
    not affected: vulnerable code not present

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
2 y ago

Exploit prediction

0.24% chance of exploitation in the next 30 days, higher than 15% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
NVD 3.1 7.8 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Affected products

  • Linux Linux

Classification

Weakness
Technology feeds

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.