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 <[email protected]> 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
