netdev - Re: [PATCH bpf-next v2 1/3] bpf, sockmap: avoid using sk

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] [day] [month] [year] [list]

Message-ID: <fe664471a8933c894ac98029bd704ccfb010eae3@linux.dev>
Date: Mon, 10 Mar 2025 14:13:02 +0000
From: "Jiayuan Chen" <jiayuan.chen@...ux.dev>
To: "Michal Luczaj" <mhal@...x.co>, xiyou.wangcong@...il.com,
 john.fastabend@...il.com, jakub@...udflare.com, martin.lau@...ux.dev
Cc: davem@...emloft.net, edumazet@...gle.com, kuba@...nel.org,
 pabeni@...hat.com, horms@...nel.org, andrii@...nel.org,
 eddyz87@...il.com, mykolal@...com, ast@...nel.org, daniel@...earbox.net,
 song@...nel.org, yonghong.song@...ux.dev, kpsingh@...nel.org,
 sdf@...ichev.me, haoluo@...gle.com, jolsa@...nel.org, shuah@...nel.org,
 sgarzare@...hat.com, netdev@...r.kernel.org, bpf@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-kselftest@...r.kernel.org,
 mrpre@....com, cong.wang@...edance.com,
 syzbot+dd90a702f518e0eac072@...kaller.appspotmail.com
Subject: Re: [PATCH bpf-next v2 1/3] bpf, sockmap: avoid using sk_socket
 after free

March 10, 2025 at 9:08 PM, "Michal Luczaj" <mhal@...x.co> wrote:



> 
> On 3/10/25 12:36, Jiayuan Chen wrote:
> 
> > 
> > March 7, 2025 at 5:45 PM, "Michal Luczaj" <mhal@...x.co> wrote:
> > 
> >  ...
> > 
> > > 
> > > BTW, lockdep (CONFIG_LOCKDEP=y) complains about calling AF_UNIX's
> > > 
> > >  read_skb() under RCU read lock.
> > > 
> > 
> >  My environment also has LOCKDEP enabled, but I didn't see similar
> > 
> >  warnings.
> > 
> >  Moreover, RCU assertions are typically written as:
> > 
> >  
> > 
> >  WARN_ON_ONCE(!rcu_read_lock_held())
> > 
> >  
> > 
> >  And when LOCKDEP is not enabled, rcu_read_lock_held() defaults to
> > 
> >  returning 1. So, it's unlikely to trigger a warning due to an RCU lock
> > 
> >  being held.
> > 
> >  
> > 
> >  Could you provide more of the call stack?
> > 
> 
> Sure, bpf-next with this series applied, test_progs -t sockmap_basic:
> 
> =============================
> 
> [ BUG: Invalid wait context ]
> 
> 6.14.0-rc3+ #111 Tainted: G OE
> 
> -----------------------------
> 
> test_progs/37755 is trying to lock:
> 
> ffff88810d9bc3c0 (&u->iolock){+.+.}-{4:4}, at: unix_stream_read_skb+0x30/0x120
> 
> other info that might help us debug this:
> 
> context-{5:5}
> 
> 1 lock held by test_progs/37755:
> 
>  #0: ffffffff833700e0 (rcu_read_lock){....}-{1:3}, at: sk_psock_verdict_data_ready+0x3e/0x2a0
> 
> stack backtrace:
> 
> CPU: 13 UID: 0 PID: 37755 Comm: test_progs Tainted: G OE 6.14.0-rc3+ #111
> 
> Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
> 
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
> 
> Call Trace:
> 
>  dump_stack_lvl+0x68/0x90
> 
>  lock_acquire+0xcf/0x2e0
> 
>  __mutex_lock+0x9c/0xcc0
> 
>  unix_stream_read_skb+0x30/0x120
> 
>  sk_psock_verdict_data_ready+0x8d/0x2a0
> 
>  unix_stream_sendmsg+0x232/0x640
> 
>  __sys_sendto+0x1cd/0x1e0
> 
>  __x64_sys_sendto+0x20/0x30
> 
>  do_syscall_64+0x93/0x180
> 
>  entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
Thanks, I got this stack too after enabling CONFIG_PROVE_LOCKING.
It seems that we can't call sleepable lock such as mutex_lock under rcu-locked context.
I'm working on it.