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

[Jacob Keller <jacob.e.keller@intel.com>]

[-- Attachment #1.1: Type: text/plain, Size: 1677 bytes --]



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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]