netdev - Re: [PATCH net] net: add recursion limit to GRO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <1476148387.2974887.751853265.25F6FD56@webmail.messagingengine.com>
Date:   Tue, 11 Oct 2016 03:13:07 +0200
From:   Hannes Frederic Sowa <hannes@...essinduktion.org>
To:     Eric Dumazet <eric.dumazet@...il.com>,
        Sabrina Dubroca <sd@...asysnail.net>
Cc:     netdev@...r.kernel.org, Jiri Benc <jbenc@...hat.com>
Subject: Re: [PATCH net] net: add recursion limit to GRO

Hi,

On Mon, Oct 10, 2016, at 16:03, Eric Dumazet wrote:
> On Mon, 2016-10-10 at 15:43 +0200, Sabrina Dubroca wrote:
> > Currently, GRO can do unlimited recursion through the gro_receive
> > handlers.  This was fixed for tunneling protocols by limiting tunnel GRO
> > to one level with encap_mark, but both VLAN and TEB still have this
> > problem.  Thus, the kernel is vulnerable to a stack overflow, if we
> > receive a packet composed entirely of VLAN headers.
> > 
> > This patch adds a recursion counter to the GRO layer to prevent stack
> > overflow.  When a gro_receive function hits the recursion limit, GRO is
> > aborted for this skb and it is processed normally.
> > 
> > Thanks to Vladimír Beneš <vbenes@...hat.com> for the initial bug report.
>
> [...]
>
> Have you considered using a per cpu counter ?
> 
> It might be cheaper than using a 4-bit field in skb.
> 
> Really this counter does not need to be stored in skb. GRO already uses
> way too much space in skb->cb[]

The idea was to use some padding space and not bother with another
static per cpu allocation as long as there is space in the cb, which is
certainly more expensive in terms of memory consumption.

We can add a comment to make future users in gro_cb aware that this can
easily be moved to per cpu allocation if necessary in future?

Bye,
Hannes