Re: [External] : Re: Potential BPF Arena Security Vulnerability, Possible Memory Access and Overflow Issues

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

On 7/7/25 4:06 PM, Alexei Starovoitov wrote:
> On Mon, Jul 7, 2025 at 2:43 PM Yifei Liu <yifei.l.liu@oracle.com> wrote:
>>
>>
>>> On Jul 7, 2025, at 2:19 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>>>
>>> On Mon, Jul 7, 2025 at 1:44 PM Yifei Liu <yifei.l.liu@oracle.com> 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