CVE-2023-53024

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 &amp;= 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-&gt;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.