On 7/7/25 4:06 PM, Alexei Starovoitov wrote:
On Mon, Jul 7, 2025 at 2:43 PM Yifei Liu <yifei.l.liu@xxxxxxxxxx> wrote:
On Jul 7, 2025, at 2:19 PM, Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote:
On Mon, Jul 7, 2025 at 1:44 PM Yifei Liu <yifei.l.liu@xxxxxxxxxx> wrote:
Hi Alexei,
I recently noticed that the verifier_arena_large selftest would fail on the overflow and underflow section for 64k page size kernels. After a deeper investigation, the similar issue is also reproducible on 4k page size over both x86 and aarch64 platforms.
The root reason of this failure looks to be a failed or missing check of the pointer upper 32-bit from the user space. User space could access the arena space value even the pointer is not in the assigned user space pointer range. For example, if the user_vm_start is 7f7d26200000 and arena size is 4G (end upper bound is 7f7e26200000), when I set *(7f7e26200000 - 65536) = 20, I could also get the value of (7f7d26200000 - 65536) as 20. It should be 0 if that is out of the range.
Could you please take a look at this issue? Or could you please point me where is the place doing the address translation and I could try to provide a patch for this?
Thank you very much.
Yifei
Methods on reproduce:
1. Use a 64k page size arm based kernel and run verifier_arena_large selftest, it would failed on return 12 and 13. Or
Are you sure you're running the latest kernel ?
This sounds like issue fixed in commit 517e8a7835e8 ("bpf: Fix
softlockup in arena_map_free on 64k page kernel”)
Thanks for the reply. I do check this fix and it is not related to the one I mentioned above. It just fix the guard
range so that it would not set the start address without page alignment.
In general this is not a security vulnerability in any way.
32-bit wraparound is there by design.
If we do not check the upper 32-bit value, it would be wide open for user-space to access the arena space.
And maybe even the user-space process cannot access the memory outside the 4G area because it would
try to translate all the pointers to that area.
No idea what you're trying to say.
Plus, it would consistently fail the verifier_arena_large selftest for 64k page size kernels. Maybe we want to
skip some of the overflow/underflow tests if the page size is 64k?
I tried on my aarch64 machine which has 64K page size. The verifier_arena_large works fine for
me with either gcc11 or clang21. Could you give more details (traces) about the failure you observed?
Skip without full understanding is not a good idea.
This test does:
if (*(page1 + PAGE_SIZE) != 0)
return 11;
if (*(page1 - PAGE_SIZE) != 0)
return 12;
if (*(page2 + PAGE_SIZE) != 0)
return 13;
if (*(page2 - PAGE_SIZE) != 0)
which gets compiled into bpf insns with positive and negative 16-bit offsets.
When PAGE_SIZE is 64k the code is compiled into some other form,
since constant doesn't fit into 'off' field.
So the code is not checking what it is supposed to.
One way is to use inline asm. Another is to replace PAGE_SIZE
with an actual 4k constant in big_alloc1() test.
We are fine here. The selection dag knows the imm range and can
generate correct registers. Below is the actually generated code:
; if (*(page1 + PAGE_SIZE) != 0)
75: bf 81 00 00 00 00 00 00 r1 = r8
76: 07 01 00 00 00 00 01 00 r1 += 0x10000
77: 71 11 00 00 00 00 00 00 w1 = *(u8 *)(r1 + 0x0)
78: 56 01 0e 00 00 00 00 00 if w1 != 0x0 goto +0xe <big_alloc1+0x2e8>
79: b4 07 00 00 0c 00 00 00 w7 = 0xc
; if (*(page1 - PAGE_SIZE) != 0)
80: 07 08 00 00 00 00 ff ff r8 += -0x10000
81: 71 81 00 00 00 00 00 00 w1 = *(u8 *)(r8 + 0x0)
82: 56 01 0a 00 00 00 00 00 if w1 != 0x0 goto +0xa <big_alloc1+0x2e8>
83: b4 07 00 00 0d 00 00 00 w7 = 0xd
; if (*(page2 + PAGE_SIZE) != 0)
84: bf 91 00 00 00 00 00 00 r1 = r9
85: 07 01 00 00 00 00 01 00 r1 += 0x10000
86: 71 11 00 00 00 00 00 00 w1 = *(u8 *)(r1 + 0x0)
87: 56 01 05 00 00 00 00 00 if w1 != 0x0 goto +0x5 <big_alloc1+0x2e8>
; if (*(page2 - PAGE_SIZE) != 0)
88: 07 09 00 00 00 00 ff ff r9 += -0x10000
89: 71 91 00 00 00 00 00 00 w1 = *(u8 *)(r9 + 0x0)
90: b4 07 00 00 00 00 00 00 w7 = 0x0
91: 16 01 01 00 00 00 00 00 if w1 == 0x0 goto +0x1 <big_alloc1+0x2e8>
92: b4 07 00 00 0e 00 00 00 w7 = 0xe
