linux-kernel - Re: [PATCH] strparser: Fix signed/unsigned mismatch bug

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: <1097ef25-d36e-4cbb-96cb-7516c1f640e7@intel.com>
Date: Wed, 5 Nov 2025 14:29:24 -0800
From: Jacob Keller <jacob.e.keller@...el.com>
To: Nate Karstens <nate.karstens@...min.com>
CC: <davem@...emloft.net>, <edumazet@...gle.com>, <horms@...nel.org>,
	<john.fastabend@...il.com>, <kuba@...nel.org>,
	<linux-kernel@...r.kernel.org>, <linux@...blig.org>, <mrpre@....com>,
	<nate.karstens@...il.com>, <netdev@...r.kernel.org>, <pabeni@...hat.com>,
	<stable@...r.kernel.org>, <tom@...ntonium.net>
Subject: Re: [PATCH] strparser: Fix signed/unsigned mismatch bug



On 11/5/2025 9:34 AM, Nate Karstens wrote:
> All right, one more time using `git send-email` (plainly I don't do this every day)...
> 
> Sabrina,
> 
> Thanks for looking at this!
> 
> I'm seeing this on kernel version 5.10.244. I know that ktls on the mainline kernel has moved away from strparser, but I think the change would be useful for anyone still using strparser (both for ktls on old kernels and other users as well). It seems that, because head->len was cast to ssize_t, it was an oversight that skb->len wasn't as well (if the intention was to use unsigned arithmetic, then there would be no need to cast head-> len).
>

Right.
> Here is an example of the values involved with the test I'm running:
> 
> len = 16406
> head->len = 1448
> skb->len = 1448
> stm->strp.offset = 478
> (ssize_t)head->len - skb->len - stm.strp.offset = 4294966818

So, without the ssize_t, I guess everything switches back to unsigned
here when subtracting skb->len..

I don't quite recall the signed vs unsigned rules for this. Is
stm.strp.offset also unsigned? which means that after head->len -
skb->len resolves to unsigned 0 then we underflow?
> (ssize_t)head->len - (ssize_t)skb->len - stm.strp.offset = -478

Where as here, it resolves to signed 0, so we go ultimately resolve to a
signed result?

> 
> I'm happy to update the patch, how much of this information would be useful to include in the commit message?
> 

If we don't actually use the strparser code anywhere then it could be
dropped? But otherwise I agree with Nate that we shouldn't leave this
mistake in place, even if its not actually used by kTLS anymore.

Thanks,
Jake



Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (237 bytes)