Message-ID: <2025032719-CVE-2023-53024-8d19@gregkh>
Date: Thu, 27 Mar 2025 17:44:11 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: CVE-2023-53024: bpf: Fix pointer-leak due to insufficient speculative store bypass mitigation

Description
===========

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) 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.

The Linux kernel CVE team has assigned CVE-2023-53024 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.19.207 with commit 872968502114d68c21419cf7eb5ab97717e7b803 and fixed in 4.19.272 with commit aae109414a57ab4164218f36e2e4a17f027fcaaa
	Issue introduced in 5.4.146 with commit f5893af2704eb763eb982f01d573f5b19f06b623 and fixed in 5.4.231 with commit 81b3374944d201872cfcf82730a7860f8e7c31dd
	Issue introduced in 5.10.56 with commit 0e9280654aa482088ee6ef3deadef331f5ac5fb0 and fixed in 5.10.166 with commit da75dec7c6617bddad418159ffebcb133f008262
	Issue introduced in 5.14 with commit 2039f26f3aca5b0e419b98f65dd36481337b86ee and fixed in 5.15.91 with commit 01bdcc73dbe7be3ad4d4ee9a59b71e42f461a528
	Issue introduced in 5.14 with commit 2039f26f3aca5b0e419b98f65dd36481337b86ee and fixed in 6.1.9 with commit b0c89ef025562161242a7c19b213bd6b272e93df
	Issue introduced in 5.14 with commit 2039f26f3aca5b0e419b98f65dd36481337b86ee and fixed in 6.2 with commit e4f4db47794c9f474b184ee1418f42e6a07412b6
	Issue introduced in 5.13.8 with commit 0b27bdf02c400684225ee5ee99970bcbf5082282

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2023-53024
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	kernel/bpf/verifier.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/aae109414a57ab4164218f36e2e4a17f027fcaaa
	https://git.kernel.org/stable/c/81b3374944d201872cfcf82730a7860f8e7c31dd
	https://git.kernel.org/stable/c/da75dec7c6617bddad418159ffebcb133f008262
	https://git.kernel.org/stable/c/01bdcc73dbe7be3ad4d4ee9a59b71e42f461a528
	https://git.kernel.org/stable/c/b0c89ef025562161242a7c19b213bd6b272e93df
	https://git.kernel.org/stable/c/e4f4db47794c9f474b184ee1418f42e6a07412b6

Powered by blists - more mailing lists