[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <iehdn772fdww4zj3cknkijb5zyfj44qvpec33zyc6h4jm6qyeh@ivak4n6ekjr4>
Date: Tue, 22 Apr 2025 21:03:35 +0800
From: Jiayuan Chen <mrpre@....com>
To: syzbot <syzbot+c21c23281290bfafe8d5@...kaller.appspotmail.com>
Cc: andrii@...nel.org, ast@...nel.org, bpf@...r.kernel.org,
daniel@...earbox.net, davem@...emloft.net, edumazet@...gle.com, horms@...nel.org,
jakub@...udflare.com, john.fastabend@...il.com, kuba@...nel.org,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org, pabeni@...hat.com,
syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [net?] [bpf?] KASAN: slab-use-after-free Read in
sk_psock_verdict_data_ready (3)
On Tue, Apr 22, 2025 at 03:12:27AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit: 8582d9ab3efd libbpf: Verify section type in btf_find_elf_s..
> git tree: bpf-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=13baba3f980000
> kernel config: https://syzkaller.appspot.com/x/.config?x=3b209dc5439043d2
> dashboard link: https://syzkaller.appspot.com/bug?extid=c21c23281290bfafe8d5
> compiler: Debian clang version 15.0.6, Debian LLD 15.0.6
>
> Unfortunately, I don't have any reproducer for this issue yet.
>
> Downloadable assets:
> disk image: https://storage.googleapis.com/syzbot-assets/ee77ac023e33/disk-8582d9ab.raw.xz
> vmlinux: https://storage.googleapis.com/syzbot-assets/ebe52a30453e/vmlinux-8582d9ab.xz
> kernel image: https://storage.googleapis.com/syzbot-assets/6868f9db2e2e/bzImage-8582d9ab.xz
>
> IMPORTANT: if you fix the issue, please add the following tag to the commit:
> Reported-by: syzbot+c21c23281290bfafe8d5@...kaller.appspotmail.com
>
> ==================================================================
> BUG: KASAN: slab-use-after-free in sk_psock_verdict_data_ready+0x6d/0x390 net/core/skmsg.c:1239
> Read of size 8 at addr ffff888078595a20 by task syz.2.24/6005
>
Same as the obsoleted one:
https://syzkaller.appspot.com/bug?extid=dd90a702f518e0eac072
I'd like to create the discussion here, so that others can find it and
contribute to the topic.
Sorry to forget replying this patch:
https://lore.kernel.org/all/20250408073033.60377-1-jiayuan.chen@linux.dev/T/
That patch obtains the ops from sk->sk_socket with RCU locked, preventing
sk_socket from being freed by RCU. Since 'ops' is a const type data that's
never freed, I can still use it even after sk_socket is freed.
It's a trick way but lightweight.
I also had a discussion with Michal Luczaj about fixing this issue using
file references:
https://lore.kernel.org/all/20250317092257.68760-1-jiayuan.chen@linux.dev/T/
Welcome any better suggestions.
Powered by blists - more mailing lists