Re: [RFC bpf PATCH 0/2] bpf: Fix memory access tags in helper prototypes
From: Zesen Liu
Date: Mon Dec 22 2025 - 22:16:16 EST
Apologies for the resend due to an incorrect configuration in my mail client.
Thanks for your comment!
> On Dec 23, 2025, at 03:29, Amery Hung <ameryhung@xxxxxxxxx> wrote:
>
> Perhaps you are conflating one of your proposals here? This is fine
> currently. ARG_PTR_TO_MEM without any annotation is viewed as BPF_READ
> so passing a read-only buffer should work.
Actually, that is not the case. I tested this again, and ARG_PTR_TO_MEM
without MEM_RDONLY does reject read-only buffers. You can reproduce this
behavior with test_d_path_check_rdonly_mem in selftests by removing its
arg2’s MEM_WRITE tag.
> I think it is better to make the MEM_WRITE, MEM_RDONLY annotation
> explicit and check it in the verifier.
>
> Flipping the default MEM_RDONLY semantic to MEM_WRITE does not prevent
> a similar bug in the future when we have helpers/optimizations/checks
> rely on an implicit semantic.
The current default semantic is in an inconsistent state: it implies
neither MEM_RDONLY nor MEM_WRITE. A naked ARG_PTR_TO_MEM rejects
read-only buffers, yet tells the verifier that the helper does not modify the memory.
I see two ways to resolve this ambiguity:
1) Enforce explicit memory access tags (disallow naked ARG_PTR_TO_MEM) as I
proposed eariler; or
2) Change ARG_PTR_TO_MEM semantics to behave exactly like
ARG_PTR_TO_MEM | MEM_RDONLY.
I would appreciate your thoughts on this. :)
Thanks,
Zesen Liu