On 11/5/2025 3:12 PM, Nate Karstens wrote:
Thanks, Jake!
So, without the ssize_t, I guess everything switches back to unsigned here when subtracting skb->len..
That's right. In C, if there is a mix of signed an unsigned, then signed are converted to unsigned and unsigned arithmetic is used.
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?
Here is a summary of the types for the variables involved:
len => ssize_t (signed) (ssize_t)head->len => unsigned int cast to ssize_t skb->len => unsigned int, causes the whole comparison to use unsigned arithmetic stm->strp.offset => int (see struct strp_msg)
Ah, right so if we don't cast skb->len then the entire thing uses unsigned arithmetic which results in the bad outcome for certain values of input.
Casting would fix this. Another alternative would be to re-write the checks so that they don't fail when using unsigned arithmetic.
Given that we already cast one to ssize_t, it does seem reasonable to just add the other cast as your patch did.
If we don't actually use the strparser code anywhere then it could be dropped
It is still used elsewhere, and ktls still uses some of the data structures.
Right. Fixing it makes the most sense, so that other users don't accidentally behave unexpectedly.
Cheers,
Nate