From: Vineet Gupta <vineet.gupta@linux.dev>
To: bpf@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
x86@kernel.org, stable@vger.kernel.org,
Vineet Gupta <vineet.gupta@linux.dev>
Subject: [PATCH bpf v3 0/2] bpf, x86: fix per-CPU address resolution into an extended register
Date: Fri, 14 Aug 2026 15:02:52 -0700 [thread overview]
Message-ID: <20260814220254.3797467-1-vineet.gupta@linux.dev> (raw)
The JIT resolves a per-CPU address with
add <dst>, gs:[this_cpu_off]
but builds the REX prefix with add_1mod(), which sets REX.B. The
destination is encoded in ModRM.reg, which REX.R extends, and the memory
operand is disp32 with no base, so REX.B does nothing and the high
register bit is dropped. Every extended destination therefore resolves
into whichever register shares the low three bits:
R5 -> RAX R7 -> RBP R8 -> RSI R9 -> RDI
The address is left unadjusted and an unrelated register is clobbered.
Patch 1 switches to add_2mod() so the bit goes through REX.R.
Clang reloads the address into R1 before each per-CPU access, so the
destination is never an extended register and the bug has been dormant
since v6.10. GCC keeps several per-CPU addresses live at once, which is
how it turned up: test_progs-bpf_gcc panics the kernel in
global_percpu_data/init, with the address of a .percpu variable in R5.
Patch 2 covers every register. A functional test only catches this if
the address happens to land in an extended register, so the test matches
the JITed add instead.
Changes in v3:
- Fold the five per-register programs into one that loads every
register, and drop the comment explaining the register choice
(Eduard Zingerman).
- Move the percpu_data declaration inside the arch guard, so other
targets no longer carry a .percpu section and an unused map (bpf-ci).
- Match the movabsq of each address as well as the add, so the matchers
stay on consecutive lines and the pair is checked to use the same
register.
- Restore the Reviewed-by on patch 1, dropped by mistake in v2.
Changes in v2:
- Add the selftest, patch 2/2 (Eduard Zingerman). It uses __jited()
rather than __xlated(): the xlated stream is identical for every
register, and the wrong prefix is only visible in the native encoding.
- No functional change to patch 1.
Vineet Gupta (2):
bpf, x86: Fix per-CPU address resolution into an extended register
selftests/bpf: Check per-CPU address resolution per register
arch/x86/net/bpf_jit_comp.c | 2 +-
.../selftests/bpf/prog_tests/verifier.c | 2 +
.../bpf/progs/verifier_percpu_addr.c | 72 +++++++++++++++++++
3 files changed, 75 insertions(+), 1 deletion(-)
create mode 100644 tools/testing/selftests/bpf/progs/verifier_percpu_addr.c
--
2.53.0-Meta
next reply other threads:[~2026-08-14 22:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 22:02 Vineet Gupta [this message]
2026-08-14 22:02 ` [PATCH bpf v3 1/2] bpf, x86: Fix per-CPU address resolution into an extended register Vineet Gupta
2026-08-14 22:02 ` [PATCH bpf v3 2/2] selftests/bpf: Check per-CPU address resolution per register Vineet Gupta
2026-08-14 22:26 ` sashiko-bot
2026-08-14 22:39 ` Vineet Gupta
2026-08-14 22:39 ` bot+bpf-ci
2026-08-14 23:55 ` Vineet Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260814220254.3797467-1-vineet.gupta@linux.dev \
--to=vineet.gupta@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=stable@vger.kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.