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