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]
Date: Wed, 14 Feb 2024 17:10:37 +0100
From: Davide Caratti <dcaratti@...hat.com>
To: Jamal Hadi Salim <jhs@...atatu.com>
Cc: Jakub Kicinski <kuba@...nel.org>, davem@...emloft.net,
	netdev@...r.kernel.org, edumazet@...gle.com, pabeni@...hat.com,
	Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
	xiyou.wangcong@...il.com, jiri@...nulli.us,
	shmulik.ladkani@...il.com
Subject: Re: [PATCH net] net/sched: act_mirred: use the backlog for mirred
 ingress

On Wed, Feb 14, 2024 at 10:28:27AM -0500, Jamal Hadi Salim wrote:
> On Wed, Feb 14, 2024 at 10:11 AM Jamal Hadi Salim <jhs@...atatu.com> wrote:
> >
> > On Fri, Feb 9, 2024 at 6:54 PM Jakub Kicinski <kuba@...nel.org> wrote:
> > >
> > > The test Davide added in commit ca22da2fbd69 ("act_mirred: use the backlog
> > > for nested calls to mirred ingress") hangs our testing VMs every 10 or so
> > > runs, with the familiar tcp_v4_rcv -> tcp_v4_rcv deadlock reported by
> > > lockdep.

[...]

> > Doing a quick test of this and other patch i saw..
> 
> 
> So tests pass - but on the list i only see one patch and the other is
> on lore, not sure how to ACK something that is not on email, but FWIW:
> Acked-by: Jamal Hadi Salim <jhs@...atatu.com>
> 
> The second patch avoids the recursion issue (which was the root cause)
> and the first patch is really undoing ca22da2fbd693

If I well read, Jakub's patch [1] uses the backlog for egress->ingress
regardless of the "nest level": no more calls to netif_receive_skb():
It's the same as my initial proposal for fixing the OVS soft-lockup [2],
the code is different because now we have tcf_mirred_to_dev().

I'm ok with this solution, and maybe we need to re-think if it's
really a problem to loose the statistics for action subsequent to a
mirred redirect egress->ingress. IMHO it's not a problem to loose them:
if RPS or RX timestamping is enabled on the RX target device, we would
loose this information anyways (maybe this answers to Jiri's question
above in the thread).

The other patch [3] fixes the reported UAF, but if the Fixes: tag is
correct it will probably need some special care if it propagates to
stable branches.

thanks,
-- 
davide

[1] https://lore.kernel.org/netdev/20240209235413.3717039-1-kuba@kernel.org/
[2] https://lore.kernel.org/netdev/33dc43f587ec1388ba456b4915c75f02a8aae226.1663945716.git.dcaratti@redhat.com/ 
[3] https://lore.kernel.org/netdev/20240214033848.981211-2-kuba@kernel.org/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ