From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: mail.toke.dk; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=ASikToQH; arc=none (Message is not ARC signed); dmarc=pass (Used From Domain Record) header.from=kernel.org policy.dmarc=quarantine Received: from sea.source.kernel.org (sea.source.kernel.org [172.234.252.31]) by mail.toke.dk (Postfix) with ESMTPS id 7CE2713E42B9 for ; Wed, 29 Jul 2026 00:51:15 +0200 (CEST) Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by sea.source.kernel.org (Postfix) with ESMTP id 09018408DD; Tue, 28 Jul 2026 22:51:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7808C1F000E9; Tue, 28 Jul 2026 22:51:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785279072; bh=CZ0KRWqMI03pyEwTO5s36gWT9C8Ll9NZtTC3eQ17wbk=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=ASikToQHro7rHTB4zeIWRMHmeJ8DLQS0kMVIMkvL15Q8+OLSDc0GmNOg96nPKI2vq d7Pp/q5nv9p2heikrvHRipT2S0LnfDgaKkAbrk57QyXl/QsF/qelOnyQo6wwkmliJi z8nwvezgaxJs2U+WgjkdXPeLxTjdh/HdWsX+zu5oXu8nZubqMFlXa5fhLZcfy4N3b0 Fe4xq9SaDqgyQhkYfOFrb+Qo21YVZGWWGU2cIBSa9/+jnSGNgf20aOVTxMpMzmHi+/ yAyEyO6PbEqrX9CMvqTaKWT9s6k/GmLlwPzIRjc8HArLegcL3IIzSx/bOkmYBaDByl JoczH4hgmILAw== Date: Tue, 28 Jul 2026 15:51:11 -0700 From: Jakub Kicinski To: Toke =?UTF-8?B?SMO4aWxhbmQtSsO4cmdlbnNlbg==?= Cc: Ren Wei , cake@lists.bufferbloat.net, netdev@vger.kernel.org, jhs@mojatatu.com, jiri@resnulli.us, davem@davemloft.net, edumazet@google.com, pabeni@redhat.com, horms@kernel.org, vega@nebusec.ai, zhilinz@nebusec.ai Message-ID: <20260728155111.3463ac49@kernel.org> In-Reply-To: <875x1zwfzz.fsf@toke.dk> References: <502a543e7f04d14a15a0f6cecab30dbdf77033d1.1784855599.git.zhilinz@nebusec.ai> <875x1zwfzz.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: UPGATIIERSUEZZGQNMKI7FFHRMYZMRIP X-Message-ID-Hash: UPGATIIERSUEZZGQNMKI7FFHRMYZMRIP X-MailFrom: kuba@kernel.org 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: On Tue, 28 Jul 2026 12:44:16 +0200 Toke H=C3=B8iland-J=C3=B8rgensen wrote: > > 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. =20 >=20 > Hmm, I seem to recall a policy that says we don't care about > panic_on_warn-induced crashes? What say the maintainers? Maybe in cases were it's triggered by root doing something stupid. But packet triggered WARN will definitely cause eyebrows to shift upwards. > 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. >=20 > So rather than add all these new checks, how about we just get rid of > the WARN_ON? =F0=9F=91=8D=EF=B8=8F