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