Just ${Subject} since it's a fix for a potential security footgun/DOS, whereever commit 378979e94e95 ("tcp: remove 64 KByte limit for initial tp->rcv_wnd value") has been queued up.
Thanks! Holger
On Tue, Jun 04, 2024 at 04:56:24PM +0200, Holger Hoffstätte wrote:
Just ${Subject} since it's a fix for a potential security footgun/DOS, whereever commit 378979e94e95 ("tcp: remove 64 KByte limit for initial tp->rcv_wnd value") has been queued up.
Only applies to 6.9.y, have backports for older kernels?
thanks,
greg k-h
On 2024-06-04 17:44, Greg KH wrote:
On Tue, Jun 04, 2024 at 04:56:24PM +0200, Holger Hoffstätte wrote:
Just ${Subject} since it's a fix for a potential security footgun/DOS, whereever commit 378979e94e95 ("tcp: remove 64 KByte limit for initial tp->rcv_wnd value") has been queued up.
Only applies to 6.9.y, have backports for older kernels?
No, sorry - I'm just the messenger here and moved everything to 6.9 already. Cc'ing Jakub and Eric.
My understanding is that the previous commit was a performance enhancement, so if this turns out to be too difficult then maybe 378979e94e95 ("tcp: remove 64 KByte limit for initial tp->rcv_wnd value") should just not be merged either. I have both patches on 6.9 but really cannot say whether they should go to older releases.
Let's wait for Jakub or Eric.
cheers Holger
On Tue, Jun 4, 2024 at 6:26 PM Holger Hoffstätte holger@applied-asynchrony.com wrote:
On 2024-06-04 17:44, Greg KH wrote:
On Tue, Jun 04, 2024 at 04:56:24PM +0200, Holger Hoffstätte wrote:
Just ${Subject} since it's a fix for a potential security footgun/DOS, whereever commit 378979e94e95 ("tcp: remove 64 KByte limit for initial tp->rcv_wnd value") has been queued up.
Only applies to 6.9.y, have backports for older kernels?
No, sorry - I'm just the messenger here and moved everything to 6.9 already. Cc'ing Jakub and Eric.
My understanding is that the previous commit was a performance enhancement, so if this turns out to be too difficult then maybe 378979e94e95 ("tcp: remove 64 KByte limit for initial tp->rcv_wnd value") should just not be merged either. I have both patches on 6.9 but really cannot say whether they should go to older releases.
Sorry I am missing the prior emails, 378979e94e95 does not seem security related to me, only one small TCP change.
What is the problem ?
On Tue, Jun 4, 2024 at 6:32 PM Eric Dumazet edumazet@google.com wrote:
On Tue, Jun 4, 2024 at 6:26 PM Holger Hoffstätte holger@applied-asynchrony.com wrote:
On 2024-06-04 17:44, Greg KH wrote:
On Tue, Jun 04, 2024 at 04:56:24PM +0200, Holger Hoffstätte wrote:
Just ${Subject} since it's a fix for a potential security footgun/DOS, whereever commit 378979e94e95 ("tcp: remove 64 KByte limit for initial tp->rcv_wnd value") has been queued up.
Only applies to 6.9.y, have backports for older kernels?
No, sorry - I'm just the messenger here and moved everything to 6.9 already. Cc'ing Jakub and Eric.
My understanding is that the previous commit was a performance enhancement, so if this turns out to be too difficult then maybe 378979e94e95 ("tcp: remove 64 KByte limit for initial tp->rcv_wnd value") should just not be merged either. I have both patches on 6.9 but really cannot say whether they should go to older releases.
Sorry I am missing the prior emails, 378979e94e95 does not seem security related to me, only one small TCP change.
What is the problem ?
Ah, I guess you are referring to
commit f4dca95fc0f6350918f2e6727e35b41f7f86fcce Author: Eric Dumazet edumazet@google.com Date: Thu May 23 13:05:27 2024 +0000
tcp: reduce accepted window in NEW_SYN_RECV state
Sure, If a stable kernel got 378979e94e95, it also needs commit f4dca95fc0f6350918
On 2024-06-04 18:35, Eric Dumazet wrote:
On Tue, Jun 4, 2024 at 6:32 PM Eric Dumazet edumazet@google.com wrote:
On Tue, Jun 4, 2024 at 6:26 PM Holger Hoffstätte holger@applied-asynchrony.com wrote:
On 2024-06-04 17:44, Greg KH wrote:
On Tue, Jun 04, 2024 at 04:56:24PM +0200, Holger Hoffstätte wrote:
Just ${Subject} since it's a fix for a potential security footgun/DOS, whereever commit 378979e94e95 ("tcp: remove 64 KByte limit for initial tp->rcv_wnd value") has been queued up.
Only applies to 6.9.y, have backports for older kernels?
No, sorry - I'm just the messenger here and moved everything to 6.9 already. Cc'ing Jakub and Eric.
My understanding is that the previous commit was a performance enhancement, so if this turns out to be too difficult then maybe 378979e94e95 ("tcp: remove 64 KByte limit for initial tp->rcv_wnd value") should just not be merged either. I have both patches on 6.9 but really cannot say whether they should go to older releases.
Sorry I am missing the prior emails, 378979e94e95 does not seem security related to me, only one small TCP change.
What is the problem ?
Ah, I guess you are referring to
commit f4dca95fc0f6350918f2e6727e35b41f7f86fcce Author: Eric Dumazet edumazet@google.com Date: Thu May 23 13:05:27 2024 +0000
tcp: reduce accepted window in NEW_SYN_RECV stateSure, If a stable kernel got 378979e94e95, it also needs commit f4dca95fc0f6350918
So I guess then it's probaby best to just drop them both from everwhere and be done with it.
thanks, Holger
On 2024-06-04 18:32, Eric Dumazet wrote:
On Tue, Jun 4, 2024 at 6:26 PM Holger Hoffstätte holger@applied-asynchrony.com wrote:
On 2024-06-04 17:44, Greg KH wrote:
On Tue, Jun 04, 2024 at 04:56:24PM +0200, Holger Hoffstätte wrote:
Just ${Subject} since it's a fix for a potential security footgun/DOS, whereever commit 378979e94e95 ("tcp: remove 64 KByte limit for initial tp->rcv_wnd value") has been queued up.
Only applies to 6.9.y, have backports for older kernels?
No, sorry - I'm just the messenger here and moved everything to 6.9 already. Cc'ing Jakub and Eric.
My understanding is that the previous commit was a performance enhancement, so if this turns out to be too difficult then maybe 378979e94e95 ("tcp: remove 64 KByte limit for initial tp->rcv_wnd value") should just not be merged either. I have both patches on 6.9 but really cannot say whether they should go to older releases.
Sorry I am missing the prior emails, 378979e94e95 does not seem security related to me, only one small TCP change.
What is the problem ?
I noticed that 378979e94e95 was queued up for the next -stable releases (autobot?) and notified Greg that the followup fix f4dca95fc0f6 would be a good idea as well (since *that* one seemed quite security related to me?). But it does not apply cleanly on older releases and I don't really feel qualified to do backports. So the question was whether only the first patch is OK by itself or neither should go into older releases at all.
Hope that explains it?
Thanks! Holger
linux-stable-mirror@lists.linaro.org
-
Eric Dumazet -
Greg KH -
Holger Hoffstätte