From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; dkim=none; arc=none (Message is not ARC signed); dmarc=fail (Used From Domain Record) header.from=toke.dk policy.dmarc=none From: Toke =?utf-8?Q?H=C3=B8iland-J=C3=B8rgensen?= To: Ren Wei , cake@lists.bufferbloat.net, netdev@vger.kernel.org Cc: jhs@mojatatu.com, jiri@resnulli.us, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, horms@kernel.org, vega@nebusec.ai, zhilinz@nebusec.ai, enjou1224z@gmail.com In-Reply-To: <502a543e7f04d14a15a0f6cecab30dbdf77033d1.1784855599.git.zhilinz@nebusec.ai> References: <502a543e7f04d14a15a0f6cecab30dbdf77033d1.1784855599.git.zhilinz@nebusec.ai> Date: Tue, 28 Jul 2026 12:44:16 +0200 X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <875x1zwfzz.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain Message-ID-Hash: UF2YV5JVK3F4PEDM3BNKJZLQA34EPWZB X-Message-ID-Hash: UF2YV5JVK3F4PEDM3BNKJZLQA34EPWZB X-MailFrom: toke@toke.dk X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; emergency; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.10 Precedence: list Subject: [Cake] Re: [PATCH net 1/1] net/sched: sch_cake: validate 6in4 inner headers List-Id: Cake - FQ_codel the next generation Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: > A malformed packet can therefore use an inner header with a non-IPv6 > version while still setting the byte used as nexthdr to TCP. When two > packets from the same queued flow reach cake_ack_filter(), the version > dispatch can fall through to WARN_ON(1), which becomes a denial of > service on kernels with panic_on_warn enabled. Hmm, I seem to recall a policy that says we don't care about panic_on_warn-induced crashes? What say the maintainers? That being said, I am not sure an unconditional WARN_ON really serves any purpose here? As you've shown, this will most likely just be caused by malformed packets. So rather than add all these new checks, how about we just get rid of the WARN_ON? -Toke