[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2025042223-departed-aids-add9@gregkh>
Date: Tue, 22 Apr 2025 12:43:35 +0200
From: Greg KH <gregkh@...uxfoundation.org>
To: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc: stable@...r.kernel.org, netdev@...r.kernel.org, bpf@...r.kernel.org,
Ricardo Cañuelo Navarro <rcn@...lia.com>,
Alexei Starovoitov <ast@...nel.org>,
Andrii Nakryiko <andrii@...nel.org>,
Daniel Borkmann <daniel@...earbox.net>,
"David S. Miller" <davem@...emloft.net>,
Jakub Kicinski <kuba@...nel.org>,
Jesper Dangaard Brouer <hawk@...nel.org>,
John Fastabend <john.fastabend@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Toke Høiland-Jørgensen <toke@...nel.org>
Subject: Re: [PATCH stable] xdp: Reset bpf_redirect_info before running a
xdp's BPF prog.
On Mon, Apr 14, 2025 at 06:21:20PM +0200, Sebastian Andrzej Siewior wrote:
> Ricardo reported a KASAN discovered use after free in v6.6-stable.
>
> 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 output in
> bpf_warn_invalid_xdp_action() appears once.
> Then the TUN driver runs another BPF program (on the same CPU) which
> returns XDP_REDIRECT without setting ri->tgt_value first. It invokes
> bpf_trace_printk() to print four characters and obtain the required
> return value. This is enough to get xdp_do_redirect() invoked which
> then accesses the pointer in tgt_value which might have been already
> deallocated.
>
> This problem does not affect upstream because since commit
> 401cb7dae8130 ("net: Reference bpf_redirect_info via task_struct on PREEMPT_RT.")
>
> the per-CPU variable is referenced via task's task_struct and exists on
> the stack during NAPI callback. Therefore it is cleared once before the
> first invocation and remains valid within the RCU section of the NAPI
> callback.
>
> Instead of performing the huge backport of the commit (plus its fix ups)
> here is an alternative version which only resets the variable in
> question prior invoking the BPF program.
>
> Acked-by: Toke Høiland-Jørgensen <toke@...nel.org>
> Reported-by: Ricardo Cañuelo Navarro <rcn@...lia.com>
> Closes: https://lore.kernel.org/all/20250226-20250204-kasan-slab-use-after-free-read-in-dev_map_enqueue__submit-v3-0-360efec441ba@igalia.com/
> Fixes: 97f91a7cf04ff ("bpf: add bpf_redirect_map helper routine")
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@...utronix.de>
> ---
>
> I discussed this with Toke, thread starts at
> https://lore.kernel.org/all/20250313183911.SPAmGLyw@linutronix.de/
>
> The commit, which this by accident, is part of v6.11-rc1.
> I added the commit introducing map redirects as the origin of the
> problem which is v4.14-rc1. The code is a bit different there but it
> seems to work similar.
> Affected kernels would be from v4.14 to v6.10.
Does not apply to any tree other than 6.6.y :(
Powered by blists - more mailing lists