Re: [PATCH] net: fix search limit handling in skb_find_text()

From: David Miller
Date: Thu Jun 18 2015 - 05:57:35 EST


From: Roman I Khimov <khimov@xxxxxxxxx>
Date: Mon, 15 Jun 2015 12:11:58 +0300

> Suppose that we're trying to use an xt_string netfilter module to match a
> string in a specially crafted packet that has "a nice string" starting at
> offset 28.
>
> It could be done in iptables like this:
>
> -A some_chain -m string --string "a nice string" --algo bm --from 28 --to 38 -j DROP
>
> And it would work as expected. Now changing that to
>
> -A some_chain -m string --string "a nice string" --algo bm --from 29 --to 38 -j DROP
>
> breaks the match, as expected. But, if we try to make
>
> -A some_chain -m string --string "a nice string" --algo bm --from 20 --to 28 -j DROP
>
> then it suddenly works again! So the 'to' parameter seems to be inclusive, not
> working as an offset after which no search should be done. OK, now if we try:
>
> -A some_chain -m string --string "a nice string" --algo bm --from 28 --to 28 -j DROP
>
> it doesn't work. So, for the case of equal 'from' and 'to' it's treated in a
> different way.
>
> The first behaviour (matching at 'to' offset) comes from skb_find_text()
> comparison. The second one (not matching if 'from' and 'to' are equal) comes
> from skb_seq_read() check for (abs_offset >= st->upper_offset).
>
> I think that the way skb_find_text() handles 'to' is wrong and should be fixed
> so that we always have predictable behaviour -- only match before 'to' offset.
>
> There are currently only five usages of skb_find_text() in the kernel and it
> looks to me that none of them expect to match something at the 'to' offset,
> so probably this change is safe.
>
> Reported-by: Edward Makarov <makarov@xxxxxxxxx>
> Tested-by: Edward Makarov <makarov@xxxxxxxxx>
> Signed-off-by: Roman I Khimov <khimov@xxxxxxxxx>

Unfortunately any aspect of this exposed to userspace is pretty much locked
in place, and we can't change it without potentially breaking someone's
setup. This has been this way for a long time, so the risk of breaking
things is very real.

I'm not applying this, sorry.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/