netdev - Re: [RFC PATCH net] tc: Return an error if filters try to attach too many actions

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: <lbwm7wpxlrvjv7rsrjz3ztuuq57lxutlsptskyyt7rg7axqdsj@cfbkhkwmp2ys>
Date: Mon, 7 Apr 2025 14:05:04 +0200
From: Jiri Pirko <jiri@...nulli.us>
To: Toke Høiland-Jørgensen <toke@...hat.com>
Cc: Jamal Hadi Salim <jhs@...atatu.com>, 
	Cong Wang <xiyou.wangcong@...il.com>, Ilya Maximets <i.maximets@...hat.com>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, 
	netdev@...r.kernel.org
Subject: Re: [RFC PATCH net] tc: Return an error if filters try to attach too
 many actions

Mon, Apr 07, 2025 at 01:29:23PM +0200, toke@...hat.com wrote:
>While developing the fix for the buffer sizing issue in [0], I noticed
>that the kernel will happily accept a long list of actions for a filter,
>and then just silently truncate that list down to a maximum of 32
>actions.
>
>That seems less than ideal, so this patch changes the action parsing to
>return an error message and refuse to create the filter in this case.
>This results in an error like:
>
> # ip link add type veth
> # tc qdisc replace dev veth0 root handle 1: fq_codel
> # tc -echo filter add dev veth0 parent 1: u32 match u32 0 0 $(for i in $(seq 33); do echo action pedit munge ip dport set 22; done)
>Error: Only 32 actions supported per filter.
>We have an error talking to the kernel
>
>Instead of just creating a filter with 32 actions and dropping the last
>one.
>
>Sending as an RFC as this is obviously a change in UAPI. But seeing as
>creating more than 32 filters has never actually *worked*, it could be
>argued that the change is not likely to break any existing workflows.
>But, well, OTOH: https://xkcd.com/1172/
>
>So what do people think? Worth the risk for saner behaviour?

I vote "yes".