On 5/4/19 11:49 AM, Reindl Harald wrote:
> is this fixed in 5.0.12 and just not visible in the changelog?
>
> because if not there's no poiunt to reboot a over a long time randomly
> crahsing firewall setup which *appears* stable now after replace "LOG"
> with "NFLOG" and remove --reap from the xt_recent rules
>
> ----------------------
>
> 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.
