Re: [RFC] Use after free in BPF/ XDP during XDP_REDIRECT

["Toke Høiland-Jørgensen" <toke@kernel.org>]

Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes:

> On 2025-03-13 20:28:06 [+0100], Toke Høiland-Jørgensen wrote:
>> Sebastian Andrzej Siewior <bigeasy@linutronix.de> writes:
>> 
>> > Hi,
>> >
>> > Ricardo reported a KASAN related use after free
>> > 	https://lore.kernel.org/all/20250226-20250204-kasan-slab-use-after-free-read-in-dev_map_enqueue__submit-v3-0-360efec441ba@igalia.com/
>> >
>> > in v6.6 stable and suggest a backport of commits
>> > 	401cb7dae8130 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.")
>> > 	fecef4cd42c68 ("tun: Assign missing bpf_net_context.")
>> > 	9da49aa80d686 ("tun: Add missing bpf_net_ctx_clear() in do_xdp_generic()")
>> >
>> > as a fix. In the meantime I have the syz reproducer+config and was able
>> > to investigate.
>> > It looks as if the syzbot starts a BPF program via xdp_test_run_batch()
>> > which assigns ri->tgt_value via dev_hash_map_redirect() and the return code
>> > isn't XDP_REDIRECT it looks like nonsense. So the print in
>> > bpf_warn_invalid_xdp_action() appears once. Everything goes as planned.
>> > Then the TUN driver runs another BPF program which returns XDP_REDIRECT
>> > without setting ri->tgt_value. This appears to be a trick because it
>> > invoked bpf_trace_printk() which printed four characters. Anyway, this
>> > is enough to get xdp_do_redirect() going.
>> >
>> > The commits in questions do fix it because the bpf_redirect_info becomes
>> > not only per-task but gets invalidated after the XDP context is left.
>> >
>> > Now that I understand it I would suggest something smaller instead as a
>> > stable fix, (instead the proposed patches). Any objections to the
>> > following:
>> >
>> > diff --git a/net/core/filter.c b/net/core/filter.c
>> > index be313928d272..1d906b7a541d 100644
>> > --- a/net/core/filter.c
>> > +++ b/net/core/filter.c
>> > @@ -9000,8 +9000,12 @@ static bool xdp_is_valid_access(int off, int size,
>> >  
>> >  void bpf_warn_invalid_xdp_action(struct net_device *dev, struct bpf_prog *prog, u32 act)
>> >  {
>> > +	struct bpf_redirect_info *ri = this_cpu_ptr(&bpf_redirect_info);
>> >  	const u32 act_max = XDP_REDIRECT;
>> >  
>> > +	ri->map_id = INT_MAX;
>> > +	ri->map_type = BPF_MAP_TYPE_UNSPEC;
>> > +
>> >  	pr_warn_once("%s XDP return value %u on prog %s (id %d) dev %s, expect packet loss!\n",
>> >  		     act > act_max ? "Illegal" : "Driver unsupported",
>> >  		     act, prog->aux->name, prog->aux->id, dev ? dev->name : "N/A");
>> 
>> From your description above, this will fix the particular error
>> encountered, but what happens if the initial return code is not in fact
>> nonsense (so the warn_invalid_action) is not triggered?
>> 
>> I.e.,
>> 
>> bpf_redirect_map(...);
>> return XDP_DROP;
>> 
>> would still leave ri->map_id and ri->map_type set for the later tun
>> driver invocation, no?
>
> Right. So if it returns XDP_PASS or XDP_DROP instead of nonsense then
> the buffer remains set. And another driver could use it.
> But this would mean we would have to tackle each bpf_prog_run_xdp()
> invocation and reset it afterwards… So maybe the backport instead? We
> have
> | $ git grep bpf_prog_run_xdp | wc -l
> | 55
>
> call sites.

Hmm, how about putting the reset (essentially the changes you have
above) into bpf_prog_run_xdp() itself, before executing the BPF program?

-Toke