On Sunday 2009-09-06 02:36, Michal Soltys wrote: >But with current xt_u32.c code this is impossible due to subsequent >sanity checks: > > if (at + val < at) > return false; > at += val; > pos = number; > if (at + 4 < at || skb->len < at + 4 (#3) || > pos > skb->len - at - 4 (#4) ) > return false; > > if (skb_copy_bits(skb, at + pos, &n, > sizeof(n)) < 0) > >In particular, condition (#3) will make the function return false, if >'at' is at / near the end of packet, regardless of the 'pos' value used. >Furthermore, (#4) would inhibit any "negative" 'pos' value anyway. > >If I haven't missed anything, The code stems from Patrick's comments [to my original u32 submission] about overflow checks. It seems you are basically throwing these out of the window. > at += val; This can overflow. Or if @val is signed, it may even underflow, and surely give funny results when @at is unsigned at the same time. Then there is also the question on what should happen when you deal with values that are - in their respective context as defined in an RFC or something - uint32_ts. Though probably a little unlikely in the real world at this time, I would not count on never hitting a jumbo frame size field of, say, 2147483656 bytes. > if (at + number + 4 < 4 || skb->len < at + number + 4) at+number can overflow, so can at+number+4. The check is insufficient too, because let at+number+4 may yield, through overflows, a value that is still greater than 4. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
