Re: [PATCH bpf-next v5 13/16] bpf,x86: Implement JIT support for stack arguments

[Yonghong Song <yonghong.song@linux.dev>]

On 4/17/26 6:20 PM, bot+bpf-ci@kernel.org wrote:
>> diff --git a/arch/x86/net/bpf_jit_comp.c b/arch/x86/net/bpf_jit_comp.c
>> index 32864dbc2c4e..25b4357de023 100644
>> --- a/arch/x86/net/bpf_jit_comp.c
>> +++ b/arch/x86/net/bpf_jit_comp.c
> [ ... ]
>
>> @@ -2129,12 +2222,26 @@ static int do_jit(struct bpf_prog *bpf_prog, int *addrs, u8 *image, u8 *rw_image
>>   				EMIT1(0xC7);
>>   			goto st;
>>   		case BPF_ST | BPF_MEM | BPF_DW:
>> +			if (dst_reg == BPF_REG_PARAMS && insn->off == -8) {
>> +				/* Arg 6: store immediate in r9 register */
>> +				emit_mov_imm64(&prog, X86_REG_R9, imm32 >> 31, (u32)imm32);
>> +				break;
>> +			}
>>   			EMIT2(add_1mod(0x48, dst_reg), 0xC7);
>>
>> -st:			if (is_imm8(insn->off))
>> -				EMIT2(add_1reg(0x40, dst_reg), insn->off);
>> +st:			insn_off = insn->off;
>> +			if (dst_reg == BPF_REG_PARAMS) {
>> +				/* Args 7+: reverse BPF negative offsets to
>> +				 * x86 positive rsp offsets.
>> +				 * BPF off=-16 → [rsp+0], off=-24 → [rsp+8], ...
>> +				 */
>> +				insn_off = outgoing_arg_base - outgoing_rsp - insn_off - 16;
>> +				dst_reg = BPF_REG_FP;
>> +			}
>> +			if (is_imm8(insn_off))
>> +				EMIT2(add_1reg(0x40, dst_reg), insn_off);
>>   			else
>> -				EMIT1_off32(add_1reg(0x80, dst_reg), insn->off);
>> +				EMIT1_off32(add_1reg(0x80, dst_reg), insn_off);
> The special case for arg 6 at offset -8 is only implemented for
> BPF_ST | BPF_MEM | BPF_DW. What happens with smaller access sizes
> (BPF_B, BPF_H, BPF_W)?
>
> Looking at the code flow, if a BPF_ST with size B/H/W targets
> dst_reg == BPF_REG_PARAMS at offset -8, execution would fall through
> to the st: label. The offset translation formula would then be applied:
>
>      insn_off = outgoing_arg_base - outgoing_rsp - (-8) - 16
>               = outgoing_arg_base - outgoing_rsp - 8
>
> For example, with outgoing_arg_base = -40 and outgoing_rsp = 0,
> this yields -32, which would attempt to write at [rbp - 32], outside
> the designated outgoing argument area at [rsp].
>
> Does this allow writing out-of-bounds below the stack pointer instead
> of updating R9?
>
> Reference: https://lore.kernel.org/bpf/20260417044443.66D37C19425@smtp.kernel.org/
>
>> @@ -2144,7 +2251,17 @@ st:			if (is_imm8(insn->off))
>>   		case BPF_STX | BPF_MEM | BPF_H:
>>   		case BPF_STX | BPF_MEM | BPF_W:
>>   		case BPF_STX | BPF_MEM | BPF_DW:
>> -			emit_stx(&prog, BPF_SIZE(insn->code), dst_reg, src_reg, insn->off);
>> +			if (dst_reg == BPF_REG_PARAMS && insn->off == -8) {
>> +				/* Arg 6: store register value in r9 */
>> +				EMIT_mov(X86_REG_R9, src_reg);
>> +				break;
>> +			}
>> +			insn_off = insn->off;
>> +			if (dst_reg == BPF_REG_PARAMS) {
>> +				insn_off = outgoing_arg_base - outgoing_rsp - insn_off - 16;
>> +				dst_reg = BPF_REG_FP;
>> +			}
> The offset translation formula subtracts the BPF offset, which reverses
> the addressing direction. While this correctly maps 8-byte aligned slot
> bases (e.g., -16 → rsp+0, -24 → rsp+8), can it handle partial writes
> within those slots?

Currently we do not support partial writes within those slots.
In llvm, all stack arguments are promoted to 64bit.

>
> For instance, if a program writes to the upper 32 bits of arg 7 at BPF
> offset -12:
>
>      insn_off = outgoing_arg_base - outgoing_rsp - (-12) - 16
>               = outgoing_arg_base - outgoing_rsp - 4
>
> With outgoing_arg_base = -40 and outgoing_rsp = 0, this computes to
> -36, mapping the access to [rbp - 36] instead of [rsp + 4].
>
> Does this formula produce out-of-bounds accesses below the stack pointer
> for partial writes?
>
> Reference: https://lore.kernel.org/bpf/20260417044443.66D37C19425@smtp.kernel.org/
>
> [ ... ]
>
>> @@ -2243,6 +2360,19 @@ st:			if (is_imm8(insn->off))
>>   		case BPF_LDX | BPF_PROBE_MEMSX | BPF_H:
>>   		case BPF_LDX | BPF_PROBE_MEMSX | BPF_W:
>>   			insn_off = insn->off;
>> +			if (src_reg == BPF_REG_PARAMS) {
>> +				if (insn_off == 8) {
>> +					/* Incoming arg 6: read from r9 */
>> +					EMIT_mov(dst_reg, X86_REG_R9);
>> +					break;
>> +				}
>> +				src_reg = BPF_REG_FP;
>> +				/*
>> +				 * Incoming args 7+: native_off == bpf_off
>> +				 * (r11+16 → [rbp+16], r11+24 → [rbp+24], ...)
>> +				 * No offset adjustment needed.
>> +				 */
>> +			}
> When reading incoming arg 6 with smaller access sizes (BPF_LDX |
> BPF_MEM | BPF_B/H/W), the code performs a full 64-bit move from R9
> to the destination register:
>
>      EMIT_mov(dst_reg, X86_REG_R9);

Again, we only support 64bit operations.

>
> For sub-64-bit arguments, are the upper bits of R9 guaranteed to be
> zero? If not, could this move garbage data into the upper bits of
> dst_reg, bypassing the verifier's strict bounds tracking which expects
> values to stay within their declared ranges (e.g., [0, 255] for
> bytes)?
>
> Reference: https://lore.kernel.org/bpf/20260417044443.66D37C19425@smtp.kernel.org/
>
> The JIT translation assumes that LDX operations target incoming
> arguments (positive offsets from r11) and STX/ST operations target
> outgoing arguments (negative offsets from r11). Is this assumption
> always valid?

Yes.

>
> Consider these scenarios:
>
> Scenario 1: A program writes to an outgoing argument slot at
> [r11 - 16] via STX, then reads it back via LDX. The JIT would:
>    - Store: apply outgoing translation → [rsp + 0]
>    - Load: apply incoming translation → [rbp + 16] (different location)

A LDX with [r11 - 16] will be rejected by verifier.

>
> The load would read from the BPF program stack area rather than the
> outgoing argument area, potentially returning uninitialized data.
>
> Scenario 2: A program attempts to modify an incoming argument at
> [r11 + 16] via STX. The JIT would apply the outgoing translation:

Again, this is illegal for STX with positive offset.

>
>      insn_off = outgoing_arg_base - outgoing_rsp - 16 - 16
>               = outgoing_arg_base - outgoing_rsp - 32
>
> With outgoing_arg_base = -40 and outgoing_rsp = 0, this yields -72,
> writing to [rbp - 72], which could be out-of-bounds below the allocated
> stack area.
>
> Does the verifier enforce a constraint that reads can only target
> positive r11 offsets and writes can only target negative r11 offsets?
>
> Reference: https://lore.kernel.org/bpf/20260417044443.66D37C19425@smtp.kernel.org/
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/24592562564