CVE-2023-53024
Published: 27 March 2025
Summary
CVE-2023-53024 is a high-severity an unspecified weakness vulnerability in Linux Linux Kernel. Its CVSS base score is 7.1 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 0.4th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified are NIST 800-53 CM-6 (Configuration Settings) and SI-2 (Flaw Remediation).
Deeper analysis
CVE-2023-53024 is a pointer leak vulnerability in the Linux kernel's BPF subsystem stemming from insufficient speculative store bypass (SSB) mitigation for Spectre v4. A prior mitigation inserted lfence instructions after initializing a stack slot with a pointer or spilling a pointer to the stack. However, it failed to address cases where a stack slot is first initialized with a pointer (requiring sanitization) and then overwritten with a scalar value. This allows the second write to be vulnerable to SSB, resulting in speculative pointer-as-scalar type confusion that enables leakage of the pointer's numerical value.
A local attacker with low privileges (PR:L) can exploit this by loading an unprivileged BPF program. The attack involves spilling a kernel pointer, such as the frame pointer, to a stack slot, overwriting it with a user-controlled scalar, and then using a branch-based cache side channel to leak pointer bits. For example, the provided BPF bytecode aliases the frame pointer, stores it to the stack (triggering an lfence), overwrites with a scalar (bypassing lfence due to prior initialization), and speculatively loads the pointer to encode bits in cache state via timed accesses. Repeating this recovers full 64-bit addresses on amd64, achieving high confidentiality impact (C:H) without integrity or availability disruption.
Kernel patches address this by extending sanitization to scalars overwriting stack slots that previously held pointers, inserting lfence instructions in these cases. Relevant stable commits include 01bdcc73dbe7be3ad4d4ee9a59b71e42f461a528, 81b3374944d201872cfcf82730a7860f8e7c31dd, aae109414a57ab4164218f36e2e4a17f027fcaaa, b0c89ef025562161242a7c19b213bd6b272e93df, and da75dec7c6617bddad418159ffebcb133f008262. The fix assumes pointer spills occur under register pressure from LLVM, minimizing performance impact on real-world BPF programs, and does not depend on environment flags like allow_uninit_stack or ptr_leaks to ensure consistent protection.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2023-59696
Vulnerability details
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation To mitigate Spectre v4, 2039f26f3aca ("bpf: Fix leakage due to insufficient speculative store bypass mitigation") inserts lfence instructions after 1)…
more
initializing a stack slot and 2) spilling a pointer to the stack. However, this does not cover cases where a stack slot is first initialized with a pointer (subject to sanitization) but then overwritten with a scalar (not subject to sanitization because the slot was already initialized). In this case, the second write may be subject to speculative store bypass (SSB) creating a speculative pointer-as-scalar type confusion. This allows the program to subsequently leak the numerical pointer value using, for example, a branch-based cache side channel. To fix this, also sanitize scalars if they write a stack slot that previously contained a pointer. Assuming that pointer-spills are only generated by LLVM on register-pressure, the performance impact on most real-world BPF programs should be small. The following unprivileged BPF bytecode drafts a minimal exploit and the mitigation: [...] // r6 = 0 or 1 (skalar, unknown user input) // r7 = accessible ptr for side channel // r10 = frame pointer (fp), to be leaked // r9 = r10 # fp alias to encourage ssb *(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, to be leaked // lfence added here because of pointer spill to stack. // // Ommitted: Dummy bpf_ringbuf_output() here to train alias predictor // for no r9-r10 dependency. // *(u64 *)(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr // 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID, // store may be subject to SSB // // fix: also add an lfence when the slot contained a ptr // r8 = *(u64 *)(r9 - 8) // r8 = architecturally a scalar, speculatively a ptr // // leak ptr using branch-based cache side channel: r8 &= 1 // choose bit to leak if r8 == 0 goto SLOW // no mispredict // architecturally dead code if input r6 is 0, // only executes speculatively iff ptr bit is 1 r8 = *(u64 *)(r7 + 0) # encode bit in cache (0: slow, 1: fast) SLOW: [...] After running this, the program can time the access to *(r7 + 0) to determine whether the chosen pointer bit was 0 or 1. Repeat this 64 times to recover the whole address on amd64. In summary, sanitization can only be skipped if one scalar is overwritten with another scalar. Scalar-confusion due to speculative store bypass can not lead to invalid accesses because the pointer bounds deducted during verification are enforced using branchless logic. See 979d63d50c0c ("bpf: prevent out of bounds speculation on pointer arithmetic") for details. Do not make the mitigation depend on !env->allow_{uninit_stack,ptr_leaks} because speculative leaks are likely unexpected if these were enabled. For example, leaking the address to a protected log file may be acceptable while disabling the mitigation might unintentionally leak the address into the cached-state of a map that is accessible to unprivileged processes.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise TechniquesAI
Why these techniques?
This kernel pointer leak vulnerability in BPF enables local attackers to bypass KASLR via speculative execution side-channel, directly facilitating further kernel exploitation for privilege escalation.
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Requires timely identification, reporting, and correction of the BPF pointer leak flaw through kernel patching to close the SSB mitigation gap.
Enforces secure kernel configuration settings, such as disabling unprivileged BPF, to block loading of exploitable BPF programs by low-privilege attackers.
Implements memory protection mechanisms including speculative execution barriers like lfence to mitigate pointer-as-scalar type confusion in BPF stack slots.