netdev - Re: [PATCH v2] net: Add locking to protect skb->dev access in ip

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: <6888f5eb491ac_1676002946c@willemb.c.googlers.com.notmuch>
Date: Tue, 29 Jul 2025 12:25:15 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Eric Dumazet <edumazet@...gle.com>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: Sharath Chandra Vurukala <quic_sharathv@...cinc.com>, 
 davem@...emloft.net, 
 dsahern@...nel.org, 
 kuba@...nel.org, 
 pabeni@...hat.com, 
 netdev@...r.kernel.org, 
 quic_kapandey@...cinc.com, 
 quic_subashab@...cinc.com
Subject: Re: [PATCH v2] net: Add locking to protect skb->dev access in
 ip_output

Eric Dumazet wrote:
> On Tue, Jul 29, 2025 at 9:11 AM Willem de Bruijn
> <willemdebruijn.kernel@...il.com> wrote:
> >
> > Sharath Chandra Vurukala wrote:
> >
> > > >> +  rcu_read_lock();
> >
> > How do we know that all paths taken from here are safe to be run
> > inside an rcu readside critical section btw?
> 
> This is totally safe ;)

I trust that it is. It's just not immediately obvious to me why.

__dev_queue_xmit_nit calls rcu_read_lock_bh, so the safety of anything
downstream is clear.

But do all protocol stacks do this?

I see that TCP does, through __ip_queue_xmit. So that means all
code downstream of that, including all the modular netfilter code
already has to be safe indeed. That should suffice.

I started by looking at the UDP path and see no equivalent
rcu_read_lock call in that path however.