CVE-2023-53024
Publication date:
27/03/2025
In the Linux kernel, the following vulnerability has been resolved:<br />
<br />
bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation<br />
<br />
To mitigate Spectre v4, 2039f26f3aca ("bpf: Fix leakage due to<br />
insufficient speculative store bypass mitigation") inserts lfence<br />
instructions after 1) initializing a stack slot and 2) spilling a<br />
pointer to the stack.<br />
<br />
However, this does not cover cases where a stack slot is first<br />
initialized with a pointer (subject to sanitization) but then<br />
overwritten with a scalar (not subject to sanitization because<br />
the slot was already initialized). In this case, the second write<br />
may be subject to speculative store bypass (SSB) creating a<br />
speculative pointer-as-scalar type confusion. This allows the<br />
program to subsequently leak the numerical pointer value using,<br />
for example, a branch-based cache side channel.<br />
<br />
To fix this, also sanitize scalars if they write a stack slot<br />
that previously contained a pointer. Assuming that pointer-spills<br />
are only generated by LLVM on register-pressure, the performance<br />
impact on most real-world BPF programs should be small.<br />
<br />
The following unprivileged BPF bytecode drafts a minimal exploit<br />
and the mitigation:<br />
<br />
[...]<br />
// r6 = 0 or 1 (skalar, unknown user input)<br />
// r7 = accessible ptr for side channel<br />
// r10 = frame pointer (fp), to be leaked<br />
//<br />
r9 = r10 # fp alias to encourage ssb<br />
*(u64 *)(r9 - 8) = r10 // fp[-8] = ptr, to be leaked<br />
// lfence added here because of pointer spill to stack.<br />
//<br />
// Ommitted: Dummy bpf_ringbuf_output() here to train alias predictor<br />
// for no r9-r10 dependency.<br />
//<br />
*(u64 *)(r10 - 8) = r6 // fp[-8] = scalar, overwrites ptr<br />
// 2039f26f3aca: no lfence added because stack slot was not STACK_INVALID,<br />
// store may be subject to SSB<br />
//<br />
// fix: also add an lfence when the slot contained a ptr<br />
//<br />
r8 = *(u64 *)(r9 - 8)<br />
// r8 = architecturally a scalar, speculatively a ptr<br />
//<br />
// leak ptr using branch-based cache side channel:<br />
r8 &= 1 // choose bit to leak<br />
if r8 == 0 goto SLOW // no mispredict<br />
// architecturally dead code if input r6 is 0,<br />
// only executes speculatively iff ptr bit is 1<br />
r8 = *(u64 *)(r7 + 0) # encode bit in cache (0: slow, 1: fast)<br />
SLOW:<br />
[...]<br />
<br />
After running this, the program can time the access to *(r7 + 0) to<br />
determine whether the chosen pointer bit was 0 or 1. Repeat this 64<br />
times to recover the whole address on amd64.<br />
<br />
In summary, sanitization can only be skipped if one scalar is<br />
overwritten with another scalar. Scalar-confusion due to speculative<br />
store bypass can not lead to invalid accesses because the pointer<br />
bounds deducted during verification are enforced using branchless<br />
logic. See 979d63d50c0c ("bpf: prevent out of bounds speculation on<br />
pointer arithmetic") for details.<br />
<br />
Do not make the mitigation depend on !env->allow_{uninit_stack,ptr_leaks}<br />
because speculative leaks are likely unexpected if these were enabled.<br />
For example, leaking the address to a protected log file may be acceptable<br />
while disabling the mitigation might unintentionally leak the address<br />
into the cached-state of a map that is accessible to unprivileged<br />
processes.
Severity CVSS v4.0: Pending analysis
Last modification:
22/01/2026
