On Fri, Aug 3, 2018 at 12:33 PM Josh Hunt <joshhun...@gmail.com> wrote:
>
> On Thu, Aug 2, 2018 at 4:34 PM, Peter Oskolkov <p...@google.com> wrote:
>>
>> This patchset
>>  * changes IPv4 defrag behavior to match that of IPv6: overlapping
>>    fragments now cause the whole IP datagram to be discarded (suggested
>>    by David Miller): there are no legitimate use cases for overlapping
>>    fragments;
>>  * changes IPv4 defrag queue from a list to a rb tree (suggested
>>    by Eric Dumazet): this change removes a potential attach vector.
>>
>> Upcoming patches will contain similar changes for IPv6 frag queue,
>> as well as a comprehensive IP defrag self-test (temporarily delayed).
>>
>> Peter Oskolkov (3):
>>   ip: discard IPv4 datagrams with overlapping segments.
>>   net: modify skb_rbtree_purge to return the truesize of all purged
>>     skbs.
>>   ip: use rb trees for IP frag queue.
>>
>>  include/linux/skbuff.h                  |  11 +-
>>  include/net/inet_frag.h                 |   3 +-
>>  include/uapi/linux/snmp.h               |   1 +
>>  net/core/skbuff.c                       |   6 +-
>>  net/ipv4/inet_fragment.c                |  16 +-
>>  net/ipv4/ip_fragment.c                  | 239 +++++++++++-------------
>>  net/ipv4/proc.c                         |   1 +
>>  net/ipv6/netfilter/nf_conntrack_reasm.c |   1 +
>>  net/ipv6/reassembly.c                   |   1 +
>>  9 files changed, 139 insertions(+), 140 deletions(-)
>>
>> --
>> 2.18.0.597.ga71716f1ad-goog
>>
>
> Peter
>
> I just tested your patches along with Florian's on top of net-next. Things 
> look much better wrt this type of attack. Thanks for doing this. I'm 
> wondering if we want to put an optional mechanism in place to limit the size 
> of the tree in terms of skbs it can hold? Otherwise an attacker can send 
> ~1400 8 byte frags and consume all frag memory (default high thresh is 4M) 
> pretty easily and I believe also evict other frags which may have been 
> pending? I am guessing this is what Florian's min MTU patches are trying to 
> help with.
>
> --
> Josh

Hi Josh,

It will be really easy to limit the size of the queue/tree (e.g. based
on a sysctl parameter). I can send a follow-up patch if there is a
consensus that this behavior is needed/useful.

Thanks,
Peter

Reply via email to