[Bug 1707] iptables-extensions man page misleading for --to

[bugzilla-daemon at netfilter.org]

https://bugzilla.netfilter.org/show_bug.cgi?id=1707

--- Comment #6 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to Phil Sutter from comment #5)
> (In reply to Pablo Neira Ayuso from comment #4)
> > (In reply to Phil Sutter from comment #3)
> > > (In reply to Pablo Neira Ayuso from comment #2)
> > > > (In reply to Phil Sutter from comment #1)
> > > > > Pablo, am I on the right track? Could you please review?
> > > > 
> > > > According to the code:
> > > > 
> > > [...]
> > > >         ret = textsearch_find(config, &state);                              
> > > >         return (ret <= to - from ? ret : UINT_MAX);                         
> > > [...]
> > > > commit f72b948dcbb8558d639214536c2ace1b0760f41d
> > > > Author: Phil Oester <kernel at linuxace.com>
> > > > Date:   Mon Jun 26 00:00:57 2006 -0700
> > > > 
> > > >     [NET]: skb_find_text ignores to argument
> > > 
> > > Ah, thanks for digging this up! IIUC, it merely asserts the start of the
> > > matching string lies within the given boundaries, it may still extend to past
> > > the end.
> > > 
> > > Is my interpretation about skb_seq_read() right though and specifying a too
> > > narrow range could lead to a false negative? In other words, does 'from - to'
> > > have to include the pattern's length?
> > 
> > By false negative you mean, pattern goes over the 'to' boundary?
> 
> I meant not finding the string in the packet even though it's present. IIUC,
> skb_seq_read() deals with fragments. Assume I search for 'www.netfilter.org'
> at
> offset 40 to 45 (obviously too small). Fragment 1 contains data until offset
> 50, fragment 2 data from 50 on. The pattern is there, so the end of fragment
> 1
> has "www.netfil" and fragment 2 starts with "ter.org". My small range should
> cause skb_seq_read() to return just the first fragment data, not the second
> one
> and thus the match should fail although the string is present. An
> appropriately
> large --to value (17 in this case) would cause skb_seq_read() to return the
> next fragment's data in a consecutive call and thus the string is found.

Because of how skb_seq_read() works, that means even with KMP it will not find
a matching in such case.

I think your reason in correct, would you make a proof of concept with and
without fragments?

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20230928/a88003fb/attachment.html>