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

On Mon Aug 3, 2026 at 9:00 PM CEST, Daniel Borkmann wrote:
> 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 =3D bpf_link_get_from_fd(id_or_fd);
>>                                            BPF_LINK_UPDATE on relative l=
ink
>>                                            ...
>>                                            old_prog =3D xchg(&link->link=
.prog, new_prog);
>>                                            bpf_prog_put(old_prog);
>>    if (type && link->prog->type !=3D 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 =3D=3D 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/f87b53c0-8f00-45a6-82db-8242fa9b143f@h=
uaweicloud.com [0]
>>
>> v3: https://lore.kernel.org/bpf/20260722072326.1545677-3-pulehui@huaweic=
loud.com
>> - BPF_F_LINK flag set means the relative id_or_fd is a link, not the obj=
ect being
>>    attached. We can not get the link while attach a bare prog with relat=
ive link.
>>    So passing expected link type from callers of bpf_mprog_attach/detach=
. (Sashiko)
>> - Add comment to explain that why ptype =3D=3D UNSPEC. (Emil)
>>
>> v2: https://lore.kernel.org/bpf/20260721041048.1394085-3-pulehui@huaweic=
loud.com
>> - Improve commit msg for patch 2. (Amery)
>>
>> v1: https://lore.kernel.org/bpf/20260720134547.1289964-3-pulehui@huaweic=
loud.com
>>
>>   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 =3D ERR_PTR(-EINVAL);
>>   	bool id =3D flags & BPF_F_ID;
>> +	bool type_mismatch =3D false;
>> +	struct bpf_prog *prog;
>>
>>   	if (id)
>>   		link =3D bpf_link_by_id(id_or_fd);
>> @@ -17,13 +19,20 @@ static int bpf_mprog_link(struct bpf_tuple *tuple,
>>   		link =3D bpf_link_get_from_fd(id_or_fd);
>>   	if (IS_ERR(link))
>>   		return PTR_ERR(link);
>> -	if (type && link->prog->type !=3D type) {
>> +
>> +	rcu_read_lock();
>> +	prog =3D READ_ONCE(link->prog);
>> +	if (!prog || (type && prog->type !=3D type))
>> +		type_mismatch =3D 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?
>

I think Pu's implication was that an RCU tasks trace GP would imply RCU gp,=
 thus
using RCU read lock for protection in both cases would be sufficient for th=
e
link's free path to wait for this reader. More context is available in [0].=
 I do
think this merits a comment for clarity, even in [0] I explicitly commented
about it everywhere even when it felt unnecessary.

I didn't closely follow this set of fixes (those in addition to this) yet b=
ut in
general, we also need to be careful about tracepoint BPF links. Those will =
only
wait for SRCU gp, which is not implied for rcu_read_lock() etc., so will ne=
ed
their own distinct critical section. The fix pertaining to that was in [1].

  [0]: https://lore.kernel.org/bpf/[email protected]
  [1]: https://lore.kernel.org/bpf/[email protected]=
m

>> +	if (type_mismatch) {
>>   		bpf_link_put(link);
>>   		return -EINVAL;
>>   	}
>>
>>   	tuple->link =3D link;
>> -	tuple->prog =3D link->prog;
>> +	tuple->prog =3D prog;
>>   	return 0;
>>   }
>>
>> @@ -343,8 +352,8 @@ int bpf_mprog_detach(struct bpf_mprog_entry *entry,
>>   	if (!bpf_mprog_total(entry))
>>   		return -ENOENT;
>>   	ret =3D 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) {