CVE-2019-11683

CVE-2019-11683

[Reindl Harald]

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

Re: CVE-2019-11683

[Eric Dumazet]

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.

Re: CVE-2019-11683

[Reindl Harald]

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

Re: CVE-2019-11683

[Eric Dumazet]

On 5/4/19 12:13 PM, Reindl Harald wrote:
> 
> 
> 
> 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

That is a question for distros, not for netdev@ ?

Re: CVE-2019-11683

[Reindl Harald]

Am 04.05.19 um 18:32 schrieb Eric Dumazet:
> On 5/4/19 12:13 PM, Reindl Harald wrote:
>>
>> 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
> 
> That is a question for distros, not for netdev@ ?

maybe, but the point is that we go in a direction where you have every 2
or 3 days a "stable" update up to days where at 9:00 AM a "stable" point
release appears at kernel.org and one hour later the next one from Linus
himself to fix a regression in the release an hour ago

release-realy-release-often is fine, but that smells like rush and
nobody downstream be it a sysadmin or a distribution can cope with that
when you are in a testing stage a while start deploy there are 2 new
releases with a long changelog

just because you never know if what you intended to deploy now better
should be skipped or joust go ahead because the next one a few days
later brings a regression and which ones are the regressions adn which
ones are the fixes which for me personally now leads to just randomly
update every few weaks

Re: CVE-2019-11683

[Stephen Hemminger]

On Sat, 4 May 2019 18:39:15 +0200
Reindl Harald <h.reindl@thelounge.net> wrote:

> Am 04.05.19 um 18:32 schrieb Eric Dumazet:
> > On 5/4/19 12:13 PM, Reindl Harald wrote:  
> >>
> >> 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  
> > 
> > That is a question for distros, not for netdev@ ?  
> 
> maybe, but the point is that we go in a direction where you have every 2
> or 3 days a "stable" update up to days where at 9:00 AM a "stable" point
> release appears at kernel.org and one hour later the next one from Linus
> himself to fix a regression in the release an hour ago
> 
> release-realy-release-often is fine, but that smells like rush and
> nobody downstream be it a sysadmin or a distribution can cope with that
> when you are in a testing stage a while start deploy there are 2 new
> releases with a long changelog
> 
> just because you never know if what you intended to deploy now better
> should be skipped or joust go ahead because the next one a few days
> later brings a regression and which ones are the regressions adn which
> ones are the fixes which for me personally now leads to just randomly
> update every few weaks

The point of stable kernel releases is to feed the distribution pipeline.
Sitting on updates or doing value judgments as developers does not aide that
process. End users who can not handle continual change are not the target audience.

Re: CVE-2019-11683

[Eric Dumazet]

On 5/4/19 12:39 PM, Reindl Harald wrote:
> 
> 
> Am 04.05.19 um 18:32 schrieb Eric Dumazet:
>> On 5/4/19 12:13 PM, Reindl Harald wrote:
>>>
>>> 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
>>
>> That is a question for distros, not for netdev@ ?
> 
> maybe, but the point is that we go in a direction where you have every 2
> or 3 days a "stable" update up to days where at 9:00 AM a "stable" point
> release appears at kernel.org and one hour later the next one from Linus
> himself to fix a regression in the release an hour ago
> 
> release-realy-release-often is fine, but that smells like rush and
> nobody downstream be it a sysadmin or a distribution can cope with that
> when you are in a testing stage a while start deploy there are 2 new
> releases with a long changelog
> 
> just because you never know if what you intended to deploy now better
> should be skipped or joust go ahead because the next one a few days
> later brings a regression and which ones are the regressions adn which
> ones are the fixes which for me personally now leads to just randomly
> update every few weaks
> 

In any case, this discussion has nothing to do with netdev@

Are you suggesting that we should not fix bugs at given period of times,
just because a 'release of some stable kernel' happened one day before ?

How you do your updates does not really concern us, sorry !

Re: CVE-2019-11683

[Reindl Harald]

Am 04.05.19 um 18:43 schrieb Eric Dumazet:
> In any case, this discussion has nothing to do with netdev@
> 
> Are you suggesting that we should not fix bugs at given period of times,
> just because a 'release of some stable kernel' happened one day before?

sorry to get cynical but that's likely the reason the fix for conncount
panics (https://bugzilla.kernel.org/show_bug.cgi?id=202065) took from
2018-12-28 to 2019-01-29 making it in any release while every kernel
from 4.19.0 to 4.20.4 was just fucked up terrible