netdev - Re: skb_under_panic in ip_tunnel

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+HUmGiVexacGwDeRU8k2adFuDZPpOgcJ8PokOGT6HukDc6+Vw@mail.gmail.com>
Date:	Wed, 2 Mar 2016 10:56:52 -0800
From:	Francesco Ruggeri <fruggeri@...sta.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	Francesco Ruggeri <fruggeri@...stanetworks.com>,
	netdev <netdev@...r.kernel.org>
Subject: Re: skb_under_panic in ip_tunnel_xmit

> I am not sure we want to support ~64K of headers.
>
> Is this something real, or just another root-exploit
> linux-bug-of-the-day trick ?
>
> When I want to reboot my host I usually type 'reboot', as it looks nicer
> to me ;)
>

Thanks Eric.
My point was that an accidental route misconfiguration, say by a buggy
protocol daemon (that is how we stumbled into this ... :( ) may leave
tunnel interfaces in an invalid state (namely with a very large or too
small needed_headroom) even after the misconfiguration is addressed.
The only fix at that point is to reinitialize the affected tunnel
interfaces, but it would not be obvious which tunnel interfaces were
affected or easy to debug a resulting crash.
The script itself is obviously not a realistic scenario, but in it I
was just trying to isolate a couple of points, namely that in the
presence of a bad routing configuration needed_headroom in tunnel
interfaces may become invalid and even result in a crash, and that
depending on the routing one may not even get a "Dead loop" warning
from dev_queue_xmit.
But I am ok if the consensus is that protocol daemons should just not do this.

Thanks,
Francesco