Re: [PATCH v1 net-next 0/2] net: Disallow buggy TCP transitions and IPV6_ADDRFORM.

Re: [PATCH v1 net-next 0/2] net: Disallow buggy TCP transitions and IPV6_ADDRFORM.

[Jakub Kicinski]

On Sat, 19 Sep 2026 07:35:05 +0900 Hyunwoo Kim wrote:
> >   Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")  
> 
> Hi netdev maintainers,
> 
> What is the plan for stable backports here? Does the uapi change rule
> this series out for stable?

Not super well defined to be completely honest.
My gut feeling is that we should wait for it to reach Linus, and ~rc3
then pull it to LTS. Which would mean 2 months from now (mid Nov).

That said, I am personally pretty unbothered about local exploits.
There's too many of them. And because of the serious exploits
(remote, VM escape etc) I think people are not deploying stable
much more rapidly and with less testing. I don't want to inject 
a de-feature under such condition.

Adding Greg and stable in case they have a stronger stomach.

Also FWIW I believe that Eric D is AFK at the moment, and he's the only
netdev maintainer subscribed to security@, AFAIU, so y'all may be aware
of more things than I am...

Re: [PATCH v1 net-next 0/2] net: Disallow buggy TCP transitions and IPV6_ADDRFORM.

[Greg Kroah-Hartman]

On Sat, Sep 19, 2026 at 02:20:35PM -0700, Jakub Kicinski wrote:
> On Sat, 19 Sep 2026 07:35:05 +0900 Hyunwoo Kim wrote:
> > >   Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")  
> > 
> > Hi netdev maintainers,
> > 
> > What is the plan for stable backports here? Does the uapi change rule
> > this series out for stable?
> 
> Not super well defined to be completely honest.
> My gut feeling is that we should wait for it to reach Linus, and ~rc3
> then pull it to LTS. Which would mean 2 months from now (mid Nov).

Once it's in a released -rc, why not have it backported then?  Why wait?  :)

> That said, I am personally pretty unbothered about local exploits.
> There's too many of them. And because of the serious exploits
> (remote, VM escape etc) I think people are not deploying stable
> much more rapidly and with less testing. I don't want to inject 
> a de-feature under such condition.
> 
> Adding Greg and stable in case they have a stronger stomach.

I like to see the stable trees match Linus's whenever possible,
especially when we have known bugfixes.

> Also FWIW I believe that Eric D is AFK at the moment, and he's the only
> netdev maintainer subscribed to security@, AFAIU, so y'all may be aware
> of more things than I am...

Not any more aware of anything other than the normal flood of crud...

thanks,

greg k-h

Re: [PATCH v1 net-next 0/2] net: Disallow buggy TCP transitions and IPV6_ADDRFORM.

[Jakub Kicinski]

On Sun, 20 Sep 2026 09:45:14 +0200 Greg Kroah-Hartman wrote:
> On Sat, Sep 19, 2026 at 02:20:35PM -0700, Jakub Kicinski wrote:
> > On Sat, 19 Sep 2026 07:35:05 +0900 Hyunwoo Kim wrote:  
> > > What is the plan for stable backports here? Does the uapi change rule
> > > this series out for stable?  
> > 
> > Not super well defined to be completely honest.
> > My gut feeling is that we should wait for it to reach Linus, and ~rc3
> > then pull it to LTS. Which would mean 2 months from now (mid Nov).  
> 
> Once it's in a released -rc, why not have it backported then?  Why wait?  :)

To be clear - it's in -next right now.

> > That said, I am personally pretty unbothered about local exploits.
> > There's too many of them. And because of the serious exploits
> > (remote, VM escape etc) I think people are not deploying stable
> > much more rapidly and with less testing. I don't want to inject 
> > a de-feature under such condition.
> > 
> > Adding Greg and stable in case they have a stronger stomach.  
> 
> I like to see the stable trees match Linus's whenever possible,
> especially when we have known bugfixes.
> 
> > Also FWIW I believe that Eric D is AFK at the moment, and he's the only
> > netdev maintainer subscribed to security@, AFAIU, so y'all may be aware
> > of more things than I am...  
> 
> Not any more aware of anything other than the normal flood of crud...

Okay then, I think we should just wait for the merge window,
and reevaluate if^w as new bugs show up.

Hyunwoo, if you have bugs in the queue that are solved in -next
I'd hold off on sending the fixes unless they can be triggered
remotely or from a VM.

Re: [PATCH v1 net-next 0/2] net: Disallow buggy TCP transitions and IPV6_ADDRFORM.

[Hyunwoo Kim]

On Mon, Sep 21, 2026 at 10:23:10AM -0700, Jakub Kicinski wrote:
> On Sun, 20 Sep 2026 09:45:14 +0200 Greg Kroah-Hartman wrote:
> > On Sat, Sep 19, 2026 at 02:20:35PM -0700, Jakub Kicinski wrote:
> > > On Sat, 19 Sep 2026 07:35:05 +0900 Hyunwoo Kim wrote:  
> > > > What is the plan for stable backports here? Does the uapi change rule
> > > > this series out for stable?  
> > > 
> > > Not super well defined to be completely honest.
> > > My gut feeling is that we should wait for it to reach Linus, and ~rc3
> > > then pull it to LTS. Which would mean 2 months from now (mid Nov).  
> > 
> > Once it's in a released -rc, why not have it backported then?  Why wait?  :)
> 
> To be clear - it's in -next right now.
> 
> > > That said, I am personally pretty unbothered about local exploits.
> > > There's too many of them. And because of the serious exploits
> > > (remote, VM escape etc) I think people are not deploying stable
> > > much more rapidly and with less testing. I don't want to inject 
> > > a de-feature under such condition.
> > > 
> > > Adding Greg and stable in case they have a stronger stomach.  
> > 
> > I like to see the stable trees match Linus's whenever possible,
> > especially when we have known bugfixes.
> > 
> > > Also FWIW I believe that Eric D is AFK at the moment, and he's the only
> > > netdev maintainer subscribed to security@, AFAIU, so y'all may be aware
> > > of more things than I am...  
> > 
> > Not any more aware of anything other than the normal flood of crud...
> 
> Okay then, I think we should just wait for the merge window,
> and reevaluate if^w as new bugs show up.
> 
> Hyunwoo, if you have bugs in the queue that are solved in -next
> I'd hold off on sending the fixes unless they can be triggered
> remotely or from a VM.

OK, will do.


Best regards,
Hyunwoo Kim