Re: [PATCH bpf v4] bpf: Fix UAF when reading prog type in bpf_mprog_link

On 7/28/26 9:42 AM, Pu Lehui wrote:
> From: Pu Lehui <[email protected]>
> 
> In bpf_mprog_link, the code currently allows a user to pass an abnormal
> non-netkit or non-tcx link via relative_fd. If a concurrent
> BPF_LINK_UPDATE is performed on this abnormal link before dereferencing
> link->prog->type in bpf_mprog_link(), it can trigger a UAF issue.
> 
> CPU0                                      CPU1
> netkit_link_prog_attach
> bpf_mprog_attach
> bpf_mprog_tuple_relative
> bpf_mprog_link
>    /* non-netkit or non-tcx link */
>    link = bpf_link_get_from_fd(id_or_fd);
>                                            BPF_LINK_UPDATE on relative link
>                                            ...
>                                            old_prog = xchg(&link->link.prog, new_prog);
>                                            bpf_prog_put(old_prog);
>    if (type && link->prog->type != type) <-- trigger UAF
> 
> The reason for the UAF is that each subsystem provides its own
> protection for link->prog. Since there is no cross subsystem protection
> (if not considering the RCU of prog tear down), dereferencing the prog
> of an anchor link that does not belong to the current subsystem is not
> safe: it may have been freed.
> 
> To resolve this, we access link->prog under RCU protection to safely
> fetch the pointer and guarantee its lifetime during the type check.
> Meanwhile, add a comment explaining that when ptype == UNSPEC in
> bpf_mprog_detach, it acts as a wildcard.
> 
> Fixes: 053c8e1f235d ("bpf: Add generic attach/detach/query API for multi-progs")
> Reported-by: Sashiko <[email protected]>
> Reviewed-by: Emil Tsalapatis <[email protected]>
> Signed-off-by: Pu Lehui <[email protected]>
> ---
> v4:
> - Access prog->type under rcu protection to simplify the repair logic,
>    and let unconditional detachment make sense when the bare prog or
>    link->prog being detached is NULL.
> - Add Reviewed-by tag by Emil.
> - Separate from patchset [0]. (Andrii)
> 
> Link: https://lore.kernel.org/bpf/[email protected] [0]
> 
> v3: https://lore.kernel.org/bpf/[email protected]
> - BPF_F_LINK flag set means the relative id_or_fd is a link, not the object being
>    attached. We can not get the link while attach a bare prog with relative link.
>    So passing expected link type from callers of bpf_mprog_attach/detach. (Sashiko)
> - Add comment to explain that why ptype == UNSPEC. (Emil)
> 
> v2: https://lore.kernel.org/bpf/[email protected]
> - Improve commit msg for patch 2. (Amery)
> 
> v1: https://lore.kernel.org/bpf/[email protected]
> 
>   kernel/bpf/mprog.c | 17 +++++++++++++----
>   1 file changed, 13 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/bpf/mprog.c b/kernel/bpf/mprog.c
> index 1394168062e8..af3e6c1c6a1f 100644
> --- a/kernel/bpf/mprog.c
> +++ b/kernel/bpf/mprog.c
> @@ -10,6 +10,8 @@ static int bpf_mprog_link(struct bpf_tuple *tuple,
>   {
>   	struct bpf_link *link = ERR_PTR(-EINVAL);
>   	bool id = flags & BPF_F_ID;
> +	bool type_mismatch = false;
> +	struct bpf_prog *prog;
>   
>   	if (id)
>   		link = bpf_link_by_id(id_or_fd);
> @@ -17,13 +19,20 @@ static int bpf_mprog_link(struct bpf_tuple *tuple,
>   		link = bpf_link_get_from_fd(id_or_fd);
>   	if (IS_ERR(link))
>   		return PTR_ERR(link);
> -	if (type && link->prog->type != type) {
> +
> +	rcu_read_lock();
> +	prog = READ_ONCE(link->prog);
> +	if (!prog || (type && prog->type != type))
> +		type_mismatch = true;
> +	rcu_read_unlock();

Hm, what about progs under rcu_read_lock_trace cases, wouldn't the UAF
still be there?

Even though the diff is smaller, I'd kind of lean towards link->type
testing since this addresses the underlying issue and avoids touching
the prog completely.. do you want me to look into it and also add a
BPF selftest to it as patch 2/2?

> +	if (type_mismatch) {
>   		bpf_link_put(link);
>   		return -EINVAL;
>   	}
>   
>   	tuple->link = link;
> -	tuple->prog = link->prog;
> +	tuple->prog = prog;
>   	return 0;
>   }
>   
> @@ -343,8 +352,8 @@ int bpf_mprog_detach(struct bpf_mprog_entry *entry,
>   	if (!bpf_mprog_total(entry))
>   		return -ENOENT;
>   	ret = bpf_mprog_tuple_relative(&rtuple, id_or_fd, flags,
> -				       prog ? prog->type :
> -				       BPF_PROG_TYPE_UNSPEC);
> +				       /* Use UNSPEC as wildcard when prog is NULL */
> +				       prog ? prog->type : BPF_PROG_TYPE_UNSPEC);
>   	if (ret)
>   		return ret;
>   	if (dtuple.prog) {