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: Mon, 18 Dec 2023 09:49:27 +0100
From: Davide Caratti <dcaratti@...hat.com>
To: Victor Nogueira <victor@...atatu.com>
Cc: jhs@...atatu.com, davem@...emloft.net, edumazet@...gle.com,
	kuba@...nel.org, pabeni@...hat.com, xiyou.wangcong@...il.com,
	jiri@...nulli.us, mleitner@...hat.com, pctammela@...atatu.com,
	netdev@...r.kernel.org, kernel@...atatu.com
Subject: Re: [PATCH RFC net-next] net: sched: act_mirred: Extend the cpu
 mirred nest guard with an explicit loop ttl

hello Victor, thanks for the patch!

On Fri, Dec 15, 2023 at 03:08:27PM -0300, Victor Nogueira wrote:
> As pointed out by Jamal in:
> https://lore.kernel.org/netdev/CAM0EoMn4C-zwrTCGzKzuRYukxoqBa8tyHyFDwUSZYwkMOUJ4Lw@mail.gmail.com/
> 
> Mirred is allowing for infinite loops in certain use cases, such as the
> following:
> 
> ----
> sudo ip netns add p4node
> sudo ip link add p4port0 address 10:00:00:01:AA:BB type veth peer \
>    port0 address 10:00:00:02:AA:BB
> 
> sudo ip link set dev port0 netns p4node
> sudo ip a add 10.0.0.1/24 dev p4port0
> sudo ip neigh add 10.0.0.2 dev p4port0 lladdr 10:00:00:02:aa:bb
> sudo ip netns exec p4node ip a add 10.0.0.2/24 dev port0
> sudo ip netns exec p4node ip l set dev port0 up
> sudo ip l set dev p4port0 up
> sudo ip netns exec p4node tc qdisc add dev port0 clsact
> sudo ip netns exec p4node tc filter add dev port0 ingress protocol ip \
>    prio 10 matchall action mirred ingress redirect dev port0
> 
> ping -I p4port0 10.0.0.2 -c 1
> -----
> 
> To solve this, we reintroduced a ttl variable attached to the skb (in
> struct tc_skb_cb) which will prevent infinite loops for use cases such as
> the one described above.
> 
> The nest per cpu variable (tcf_mirred_nest_level) is now only used for
> detecting whether we should call netif_rx or netif_receive_skb when
> sending the packet to ingress.

looks good to me. Do you think it's worth setting an initial value (0, AFAIU)
for tc_skb_cb(skb)->ttl inside tc_run() ?

other than this,

Acked-by: Davide Caratti <dcaratti@...hat.com>


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ