From: sashiko-bot@kernel.org
To: "George Hu" <integral@archlinux.org>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH] bpf, x86: use 32-bit zero idiom for shorter encoding
Date: Thu, 24 Sep 2026 16:14:48 +0000 [thread overview]
Message-ID: <20260924161449.04CD11F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260924160154.12807-1-integral@archlinux.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] bpf: prologue size reduction truncates stack pointer in tail calls
--
commit b074cc264a81306406896f5f166974e4a1d9467f
Author: George Hu <integral@archlinux.org>
bpf, x86: use 32-bit zero idiom for shorter encoding
This commit reduces the BPF prologue size by changing "xor rax, rax"
to "xor eax, eax", saving one byte in the generated instructions.
> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
> index de7515ea1beae..a62317b78df1e 100644
> --- a/arch/x86/net/bpf_jit_comp.c
> +++ b/arch/x86/net/bpf_jit_comp.c
> @@ -551,8 +551,11 @@ static void emit_prologue(u8 **pprog, u8 *ip, u32 stack_depth, bool ebpf_from_cb
> if (tail_call_reachable && !is_subprog)
> /* When it's the entry of the whole tailcall context,
> * zeroing rax means initialising tail_call_cnt.
> + *
> + * xor eax, eax
> + * equivalent to 'xor rax, rax', but one byte less
> */
> - EMIT3(0x48, 0x31, 0xC0); /* xor rax, rax */
> + EMIT2(0x31, 0xC0);
[Severity: Critical]
Does this 1-byte reduction break the hardcoded tail call offset assumption?
X86_TAIL_CALL_OFFSET is defined as (12 + ENDBR_INSN_SIZE) elsewhere in this
file. By reducing the prologue instruction size from 3 bytes to 2 bytes,
the 12-byte layout expected by the tail call jump logic appears to be broken.
During a tail call jump, this 1-byte mismatch will cause the jump to land past
the intended destination, skipping the 0x48 REX.W prefix of the subsequent
instruction:
EMIT3_off32(0x48, 0x81, 0xEC, round_up(stack_depth, 8));
The CPU would then decode the remainder as a 32-bit sub esp instruction,
which zeroes the upper 32 bits of the stack pointer (rsp). This points the
stack into unprivileged user-space memory, potentially allowing local
privilege escalation.
> else
> /* Keep the same instruction layout. */
> emit_nops(&prog, 3); /* nop3 */
[Severity: Critical]
Should this fallback branch also be updated to 2 bytes?
Since the tail-call reachable path above was changed to emit 2 bytes, leaving
this as a 3-byte NOP destroys the consistent instruction layout between
tail-call-reachable and non-tail-call-reachable programs.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260924160154.12807-1-integral@archlinux.org?part=1
next prev parent reply other threads:[~2026-09-24 16:14 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-24 16:01 [PATCH] bpf, x86: use 32-bit zero idiom for shorter encoding George Hu
2026-09-24 16:14 ` sashiko-bot [this message]
2026-09-24 16:23 ` Alexei Starovoitov
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=20260924161449.04CD11F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=integral@archlinux.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.