[stable request] ROSE memory-safety fixes for 7.0.y and earlier (merged out-of-tree in linux-netdev/mod-orphan)

[stable request] ROSE memory-safety fixes for 7.0.y and earlier (merged out-of-tree in linux-netdev/mod-orphan)

[Bernard Pidoux]

Hello Jakub, Greg, and stable maintainers,

(Resending in plain text; the previous copy was rejected by the lists
because it carried an HTML part.)

I am Bernard Pidoux, F6BVP, an old-timer ham radio user of the Linux
ROSE implementation. ROSE and AX.25 no longer have an official kernel
maintainer; I am one of the people still running this code on real
nodes and fixing it when it breaks.

Over the past weeks a series of fifteen memory-safety fixes for
net/rose that I wrote was reviewed and merged by Jakub Kicinski into
linux-netdev/mod-orphan. They fix real, reproducible kernel bugs that
affect any node running AX.25 networking over the ROSE protocol:

- several use-after-free conditions in the ROSE teardown paths
(neighbour timers fired after free, socket freed under an open fd,
sockets reaped from the heartbeat while still owned by userspace);
- a rose_neigh refcount underflow in rose_kill_by_device();
- netdev reference double-holds in rose_make_new() and
rose_rx_call_request();
- dev_put()/neighbour reference leaks in the loopback timer path;
- a notifier unregistered too early in rose_exit().

These are crash bugs (use-after-free writes, refcount underflow) that a
remote peer or normal session teardown can trigger. They have been
soak-tested on production ROSE nodes and confirmed to remove the
crashes and the kmemleak reports.

The problem is the path to the stable trees. ROSE was removed from
mainline in 7.1 and is now unmaintained, so these fixes were merged
into the out-of-tree mod-orphan repository rather than into Linus'
tree, and therefore have no mainline commit ID. The normal
"cherry-pick from upstream SHA" stable procedure cannot apply.

However the affected code is still present and still buggy in every
stable series that predates the removal: 7.0.y first of all (the last
line that ships net/rose), and the older long-term branches that carry
essentially the same ROSE code. Distributions tracking those kernels
currently ship the crashes with no official way to receive the fix.

My request: would you accept these as stable-only patches applied to
7.0.y and to the earlier stable series that still contain net/rose, so
that distributions pick them up? If a stable-only submission is the
right vehicle, I will send the series rebased per target branch, each
patch with a proper changelog and the bug it fixes; if you would rather
route them another way, please tell me and I will prepare whatever form
you need.

I can attach the patches in git-format-patch form for any branch you
name.

Thank you for considering this. ROSE is a small and quiet corner of the
kernel, but the nodes that run it are real, and these fixes matter to
them.

73,
Bernard Pidoux, F6BVP
bernard.f6bvp@gmail.com

Re: [stable request] ROSE memory-safety fixes for 7.0.y and earlier (merged out-of-tree in linux-netdev/mod-orphan)

[Greg KH]

On Mon, Jun 15, 2026 at 07:21:21PM +0200, Bernard Pidoux wrote:
> Hello Jakub, Greg, and stable maintainers,
> 
> (Resending in plain text; the previous copy was rejected by the lists
> because it carried an HTML part.)
> 
> I am Bernard Pidoux, F6BVP, an old-timer ham radio user of the Linux
> ROSE implementation. ROSE and AX.25 no longer have an official kernel
> maintainer; I am one of the people still running this code on real
> nodes and fixing it when it breaks.
> 
> Over the past weeks a series of fifteen memory-safety fixes for
> net/rose that I wrote was reviewed and merged by Jakub Kicinski into
> linux-netdev/mod-orphan. They fix real, reproducible kernel bugs that
> affect any node running AX.25 networking over the ROSE protocol:
> 
> - several use-after-free conditions in the ROSE teardown paths
> (neighbour timers fired after free, socket freed under an open fd,
> sockets reaped from the heartbeat while still owned by userspace);
> - a rose_neigh refcount underflow in rose_kill_by_device();
> - netdev reference double-holds in rose_make_new() and
> rose_rx_call_request();
> - dev_put()/neighbour reference leaks in the loopback timer path;
> - a notifier unregistered too early in rose_exit().
> 
> These are crash bugs (use-after-free writes, refcount underflow) that a
> remote peer or normal session teardown can trigger. They have been
> soak-tested on production ROSE nodes and confirmed to remove the
> crashes and the kmemleak reports.
> 
> The problem is the path to the stable trees. ROSE was removed from
> mainline in 7.1 and is now unmaintained, so these fixes were merged
> into the out-of-tree mod-orphan repository rather than into Linus'
> tree, and therefore have no mainline commit ID. The normal
> "cherry-pick from upstream SHA" stable procedure cannot apply.
> 
> However the affected code is still present and still buggy in every
> stable series that predates the removal: 7.0.y first of all (the last
> line that ships net/rose), and the older long-term branches that carry
> essentially the same ROSE code. Distributions tracking those kernels
> currently ship the crashes with no official way to receive the fix.
> 
> My request: would you accept these as stable-only patches applied to
> 7.0.y and to the earlier stable series that still contain net/rose, so
> that distributions pick them up? If a stable-only submission is the
> right vehicle, I will send the series rebased per target branch, each
> patch with a proper changelog and the bug it fixes; if you would rather
> route them another way, please tell me and I will prepare whatever form
> you need.

Great questions, I was waiting for something like this to eventually
happen :)

Ideally, we would just backport the "delete the code" changes, and then
distros can use your external module for their older systems, if they
care/want to, BUT that will increase the load on you to support older
kernel versions, which isn't very fair for you as in the end, you will
be getting bizarre requests from dead^Wenterprise distros asking you to
support 10+ year old kernels...

So let's try the other way, yes, I'll gladly take patches that you have
applied to your tree to fix issues in older kernels.  One request,
please use the same git id that you use in your repo as the "backported
from" git id that is in the stable message, so that we can track them
properly across different stable releases (the ecosystem has lots of
tools that rely on this.)

As for the format, whatever works for you is fine for us.  Ideally a
mbox full of patches, but we can take anything as long as we can
eventually turn it into a patch that we can apply.  How about trying one
set of backports first so we can see how well the process works to
smooth out the details?

Oh, and of course, thanks for stepping up and offering to do this work,
it's much appreciated.

greg k-h

Re: [stable request] ROSE memory-safety fixes for 7.0.y and earlier (merged out-of-tree in linux-netdev/mod-orphan)

[Bernard Pidoux]

[-- Attachment #1: Type: text/plain, Size: 1666 bytes --]

Hi Greg, all,

Sorry about that -- my mail client dropped the list and Jakub from the
recipients on the previous message; I did not intend to take it off-list.
Resending the same note to everyone, with the mbox attached again.

I have prepared a first set, attached as an mbox: 15 ROSE fixes for the
7.0.y stable tree (7.0.y is the last stable line that still ships ROSE,
since it was removed in 7.1). They are the use-after-free, refcount and
teardown-race fixes I developed and merged in the linux-netdev/mod-orphan
tree, where ROSE now lives.

As Greg asked, every patch carries a

(cherry picked from commit <id>)

trailer pointing at the exact git id in mod-orphan it was taken from, so
they can be tracked across releases.

The whole series applies cleanly with "git am" on top of v7.0.13 (no
conflicts, no fuzz). The 15 fixes form one coherent set -- the three
core UAF fixes build on the earlier refactors in the same series, so they
cannot be cherry-picked in isolation; this is why I send the full set as
the first batch.

Please let me know if you would prefer a different format (individual
mails via git send-email, extra trailers, etc.) and I will adjust. I am
happy to follow up once this batch has gone through.

Thanks again,
Bernard, F6BVP


Le sam. 20 juin 2026 à 12:27, Greg KH <gregkh@linuxfoundation.org> a écrit :
>
> On Sat, Jun 20, 2026 at 12:24:55PM +0200, Bernard Pidoux wrote:
> > Hi Greg,
>
> <snip>
>
> For some reason you sent this only to me, which is a bit rude to
> everyone else on the mailing list.  I'll be glad to respond if you
> resend it to everyone.
>
> thanks,
>
> greg k-h

[-- Attachment #2: rose-7.0.13-backport.mbox --]
[-- Type: application/mbox, Size: 36226 bytes --]

Re: [stable request] ROSE memory-safety fixes for 7.0.y and earlier (merged out-of-tree in linux-netdev/mod-orphan)

[Greg KH]

On Sat, Jun 20, 2026 at 12:37:16PM +0200, Bernard Pidoux wrote:
> Hi Greg, all,
> 
> Sorry about that -- my mail client dropped the list and Jakub from the
> recipients on the previous message; I did not intend to take it off-list.
> Resending the same note to everyone, with the mbox attached again.
> 
> I have prepared a first set, attached as an mbox: 15 ROSE fixes for the
> 7.0.y stable tree (7.0.y is the last stable line that still ships ROSE,
> since it was removed in 7.1). They are the use-after-free, refcount and
> teardown-race fixes I developed and merged in the linux-netdev/mod-orphan
> tree, where ROSE now lives.
> 
> As Greg asked, every patch carries a
> 
> (cherry picked from commit <id>)
> 
> trailer pointing at the exact git id in mod-orphan it was taken from, so
> they can be tracked across releases.
> 
> The whole series applies cleanly with "git am" on top of v7.0.13 (no
> conflicts, no fuzz). The 15 fixes form one coherent set -- the three
> core UAF fixes build on the earlier refactors in the same series, so they
> cannot be cherry-picked in isolation; this is why I send the full set as
> the first batch.
> 
> Please let me know if you would prefer a different format (individual
> mails via git send-email, extra trailers, etc.) and I will adjust. I am
> happy to follow up once this batch has gone through.

Great, does this series also apply to 6.18.y and/or any older trees?  Or
should I just worry about this branch for now while we work out the
workflow?

And at first glance, this looks great.  I'll try to apply these on
Monday and let you know how it goes.

thanks,

greg k-h

Re: [stable request] ROSE memory-safety fixes for 7.0.y and earlier (merged out-of-tree in linux-netdev/mod-orphan)

[Bernard Pidoux]

Hi Greg,

Thanks, much appreciated.

Short answer: yes, the same series applies to 6.18.y, and the same bugs
exist in the older trees too -- but only 7.0.y and 6.18.y take the series
as-is. ROSE was removed in 7.1, so every stable line up to and including
7.0.y still carries this code and is affected.

I just test-applied this exact mbox with "git am" against the current
ROSE files of each tree:

v7.0.13 : clean, 15/15 (what I sent you)
linux-6.18.y : clean, 15/15, no conflicts -- the teardown code is
identical to 7.0.13
linux-6.12.y : applies up to patch 3, then conflicts in
rose_loopback.c (the loopback/timer code predates one
of the refactors the series builds on)
linux-6.6.y / 6.1.y / 5.15.y : same, conflict at the same patch

So for 6.18.y I can send an identical batch right away. For 6.12.y and
the older LTS lines the fixes are still needed, but they need a rebased
backport rather than a straight cherry-pick; I'm happy to prepare those
per-tree once the format is settled.

My suggestion, matching what you said: let's land this 7.0.y batch first
to work out the workflow. As soon as it's in I'll send the (identical)
6.18.y batch, and then the rebased older-tree batches one line at a time.
Whatever order is easiest on your side works for me.

Thanks again,
Bernard, F6BVP


Le sam. 20 juin 2026 à 12:52, Greg KH <gregkh@linuxfoundation.org> a écrit :
>
> On Sat, Jun 20, 2026 at 12:37:16PM +0200, Bernard Pidoux wrote:
> > Hi Greg, all,
> >
> > Sorry about that -- my mail client dropped the list and Jakub from the
> > recipients on the previous message; I did not intend to take it off-list.
> > Resending the same note to everyone, with the mbox attached again.
> >
> > I have prepared a first set, attached as an mbox: 15 ROSE fixes for the
> > 7.0.y stable tree (7.0.y is the last stable line that still ships ROSE,
> > since it was removed in 7.1). They are the use-after-free, refcount and
> > teardown-race fixes I developed and merged in the linux-netdev/mod-orphan
> > tree, where ROSE now lives.
> >
> > As Greg asked, every patch carries a
> >
> > (cherry picked from commit <id>)
> >
> > trailer pointing at the exact git id in mod-orphan it was taken from, so
> > they can be tracked across releases.
> >
> > The whole series applies cleanly with "git am" on top of v7.0.13 (no
> > conflicts, no fuzz). The 15 fixes form one coherent set -- the three
> > core UAF fixes build on the earlier refactors in the same series, so they
> > cannot be cherry-picked in isolation; this is why I send the full set as
> > the first batch.
> >
> > Please let me know if you would prefer a different format (individual
> > mails via git send-email, extra trailers, etc.) and I will adjust. I am
> > happy to follow up once this batch has gone through.
>
> Great, does this series also apply to 6.18.y and/or any older trees?  Or
> should I just worry about this branch for now while we work out the
> workflow?
>
> And at first glance, this looks great.  I'll try to apply these on
> Monday and let you know how it goes.
>
> thanks,
>
> greg k-h

Re: [stable request] ROSE memory-safety fixes for 7.0.y and earlier (merged out-of-tree in linux-netdev/mod-orphan)

[Sasha Levin]

> I have prepared a first set, attached as an mbox: 15 ROSE fixes for the
> 7.0.y stable tree [...] The whole series applies cleanly with "git am"
> on top of v7.0.13 [...] The 15 fixes form one coherent set [...] this is
> why I send the full set as the first batch.

Thanks Bernard. No objection from me on the series. Since Greg has said
he'll apply the 7.0.y batch himself (and these come straight from the
mod-orphan tree rather than from a mainline SHA), I'll leave him to drive
landing 7.0.y first and then the identical 6.18.y batch, and I'll pick up
the rebased older-tree batches once you send them per-tree.

Thanks,
Sasha