netdev - Re: [PATCH stable] xdp: Reset bpf_redirect_info before running a xdp's BPF prog.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2025031733-collide-dad-203a@gregkh>
Date: Mon, 17 Mar 2025 14:44:53 +0100
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, Mar 17, 2025 at 02:38:13PM +0100, 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 it seems
> to work similar.

What stable tree(s) is this for?  Just 6.6.y?  Why not older ones?

> Greg, feel free to decide if this is worth a CVE.

That's not how CVEs are assigned :)

If you want one, please read the in-tree documentation we have for that.

thanks,

greg k-h