netdev - Re: CVE-2019-11683

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: <f81bad23-97d5-1b2b-20a1-f29cfc63ff79@thelounge.net>
Date:   Sat, 4 May 2019 18:13:56 +0200
From:   Reindl Harald <h.reindl@...lounge.net>
To:     Eric Dumazet <eric.dumazet@...il.com>, netdev@...r.kernel.org
Subject: Re: CVE-2019-11683



Am 04.05.19 um 18:06 schrieb Eric Dumazet:
>> ----------------------
>>
>> https://www.openwall.com/lists/oss-security/2019/05/02/1
>>
>> syzbot has reported a remotely triggerable memory corruption in the
>> Linux kernel. It's been introduced quite recently in e20cf8d3f1f7
>> ("udp: implement GRO for plain UDP sockets.") and only affects the 5.0
>> (stable) release (so the name is a bit overhyped :).
>>
>> CVE-2019-11683 description:
>>
>> udp_gro_receive_segment in net/ipv4/udp_offload.c in the Linux kernel
>> 5.x through 5.0.11 allows remote attackers to cause a denial of
>> service (slab-out-of-bounds memory corruption) or possibly have
>> unspecified other impact via UDP packets with a 0 payload, because of
>> mishandling of padded packets, aka the "GRO packet of death" issue.
>>
>> Fix (not yet upstream):
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=4dd2b82d5adfbe0b1587ccad7a8f76d826120f37
>>
>> ----------------------
>>
>> https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.0.11
>> https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.0.12
>>
> 
> The missing part in this CVE is that this is not remotely triggerable as-is.
> 
> UDP receiver has to opt-in for GRO, and I doubt any application does this currently

ok, so the answer is no

what's the point then release every 2 days a new "stable" kernel?
even distributions like Fedora are not able to cope with that