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 for Android: free password hash cracker in your pocket

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

Message-ID: <688900eddd162_16a694294ae@willemb.c.googlers.com.notmuch>
Date: Tue, 29 Jul 2025 13:12:13 -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:25 AM Willem de Bruijn
> <willemdebruijn.kernel@...il.com> wrote:
> >
> > 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.
> 
> ip_output() can already be called from sections rcu_read_lock() protected,
> or from BH context.
> 
> The caller's context does not matter. I am unsure what you were
> looking at in the UDP stack ?

I was just looking indeed for a caller that held rcu_read_lock already.

I saw the __ip_queue_xmit caller only after I asked the question. But
indeed calling from bottom half is another obvious answer.

Might be informative to add a comment to the commit message to that
effect.