Re: [PATCH bpf-next v3 1/1] bpf: Refactor dynptr mutability tracking

Kumar Kartikeya Dwivedi
2026-04-18T21:00:02Z

On Tue, 14 Apr 2026 at 20:10, Amery Hung <ameryhung@gmail.com> wrote:
>
> Redefine dynptr mutability and fix inconsistency in the verifier and
> kfunc signatures. Dynptr mutability is at two levels. The first is
> the bpf_dynptr structure and the second is the memory the dynptr points
> to. The verifer currently tracks the mutability of the bpf_dynptr struct
> through helper and kfunc prototypes, where "const struct bpf_dynptr *"
> means the structure itself is immutable. The second level is tracked
> in upper bit of bpf_dynptr->size in runtime and is not changed in this
> patch.
>
> There are two type of inconsistency in the verfier regarding the
> mutability of the bpf_dynptr struct. First, there are many existing
> kfuncs whose prototypes are wrong. For example, bpf_dynptr_adjust()
> mutates a dynptr's start and offset but marks the argument as a const
> pointer. At the same time many other kfuncs that does not mutate the
> dynptr but mark themselves as mutable. Second, the verifier currently
> does not honor the const qualifier in kfunc prototypes as it determines
> whether tagging the arg_type with MEM_RDONLY or not based on the register
> state.
>
> Since all the verifier care is to prevent CONST_PTR_TO_DYNPTR from
> being destroyed in callback and global subprogram, redefine the
> mutability at the bpf_dynptr level to just bpf_dynptr_kern->data. Then,
> explicitly prohibit passing CONST_PTR_TO_DYNPTR to an argument tagged
> with MEM_UNINIT or OBJ_RELEASE. The mutability of a dynptr's view is not
> really interesting so drop MEM_RDONLY annotation for dynptr from the
> helpers and kfuncs. Plus, if the mutability of the entire bpf_dynptr
> were to be done correctly, it would kill the bpf_dynptr_adjust() usage
> in callback and global subporgram.
>
> Implementation wise
>
> - First, make sure all kfunc arg are correctly tagged: Tag the dynptr
> argument of bpf_dynptr_file_discard() with OBJ_RELEASE.
> - Then, in process_dynptr_func(), make sure CONST_PTR_TO_DYNPTR cannot
> be passed to argument tagged with MEM_UNINIT or OBJ_RELEASE. For
> MEM_UNINIT, it is already checked by is_dynptr_reg_valid_uninit().
> For OBJ_RELEASE, check against OBJ_RELEASE instead of MEM_RDONLY and
> drop a now identical check in unmark_stack_slots_dynptr().
> - Remove the mutual exclusive check between MEM_UNINIT and MEM_RDONLY,
> but don't add a MEM_UNINIT and OBJ_RELEASE version as it is obviously
> wrong.
>
> Note that while this patch stops following the C semantic for the
> mutability of bpf_dynptr, the prototype of kfuncs are still fixed to
> maintain the correct C semantics in the implementation. Adding or
> removing the const qualifier does not break backward compatibility.
> In addition, fix kfuncs dropping the const qualifier when casting the
> opaque bpf_dynptr to bpf_dynptr_kern.
>
> In test_kfunc_dynptr_param.c, initialize dynptr to 0 to avoid
> -Wuninitialized-const-pointer warning.
>
> Signed-off-by: Amery Hung <ameryhung@gmail.com>
>
> ---

Acked-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>