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: <CANn89iKA9O1jsTjm+vOQqN7ufBJFod7oySUC=2G7wcV2cGTkSw@mail.gmail.com>
Date: Tue, 29 Jul 2025 09:43:23 -0700
From: Eric Dumazet <edumazet@...gle.com>
To: 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

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 ?