Hi,
On Sat, Aug 15, 2026 at 07:43:32PM +0200, Salvatore Bonaccorso wrote:
> Hi,
>
> On Sat, Aug 15, 2026 at 12:59:39PM +0000, Noah Elias Feldt wrote:
> > On Fri, 14 Aug 2026 21:36:27 +0200 Salvatore Bonaccorso
> > <[email protected]<mailto:[email protected]>> wrote:
> > > Hi Noah,
> > >
> > > On Thu, Aug 13, 2026 at 02:38:34PM +0000, Noah Elias Feldt wrote:
> > > > Subject: linux-binary-7.1.3+deb13-amd64: unprivileged user-triggerable
> > > > use-after-free host panic
> > > > Package: src:linux
> > > > X-Debbugs-Cc: [email protected]<mailto:[email protected]>
> > > > Version: 7.1.3-1~bpo13+1
> > > > Severity: important
> > > >
> > > > Dear Maintainer,
> > > >
> > > > An unprivileged local user can panic the entire host. Reading a cgroup's
> > > > world-readable cgroup.procs triggers a use-after-free of struct
> > > > task_struct in
> > > > css_task_iter_next(), ending in "Kernel panic - not syncing: Fatal
> > > > exception in
> > > > interrupt".
> > > > Nodes hard-panic and reboot organically under normal load on
> > > > the affected kernel. It also reproduces deterministically within
> > > > seconds with
> > > > the attached PoC as an ordinary user (no root, no capabilities, no
> > > > namespaces).
> > > >
> > > > *** Reporter, please consider answering these questions, where
> > > > appropriate ***
> > > >
> > > > * What led up to the situation?
> > > > An unprivileged process reads its own world-readable cgroup.procs
> > > > while,
> > > > on the same CPU, thread-group leaders in that cgroup exit and are
> > > > mass-reaped (attached poc.c). Not only synthetic: several of our
> > > > production
> > > > nodes have already panicked this way organically under normal
> > > > container
> > > > workload (Kubernetes / cri-o) on the affected kernel.
> > > >
> > > > * What exactly did you do?
> > > > Ran the reproducer as an ordinary user on an Debian 13 KVM guest
> > > > (trixie-backports kernel)
> > > >
> > > > * What was the outcome?
> > > > In ~12-70 s: "refcount_t: addition on 0" in css_task_iter_next()
> > > > (get_task_struct on usage==0) -> premature free -> NULL
> > > > rcu_head.func in
> > > > rcu_do_batch (RIP:0x0) -> "Kernel panic - not syncing". Host dead
> > > > -- same
> > > > signature as the organic production panics. Full trace attached
> > > > (dmesg.log).
> > > >
> > > > * What outcome did you expect instead?
> > > > Reading cgroup.procs must never crash the host.
> > >
> > > I can reproduce the issue up to the current kernel version
> > > 7.2~rc7-1~exp1 in experimental. Are you able to narrow down more the
> > > range and would you be able to bisect the issue?
> > >
> > > I will see if I can otherwise poin point it as well and if there are
> > > already upstream issues reported about this.
> > >
> > > Regards,
> > > Salvatore
> > >
> > >
> >
> > Thanks for reproducing it. We haven't run a full bisect, but
> > narrowed it by source inspection: the deferred-unlink rework
> > (cgroup_task_free called from __put_task_struct, i.e. after
> > usage==0) is absent in v6.18.44 and present in v6.19.13, so safe
> > ≤6.18 (incl. stable 6.12.x), first affected v6.19, matching commit
> > d245698d727a. (Just a hypothesis)
> >
> > We also fully reproduced it on our production system with a second,
> > more targeted reproducer: inside an unprivileged container on a
> > stock 7.0.13 node, the bare-metal host panicked within seconds. I
> > didn't attach it since I think, it shouldn't be public yet. I can
> > send it to you privately.
>
> Thanks for sharing that, I initially wrongly guessed to be a
> regression from 7.0 to 7.1-rc1 but it looks it is just bit harder to
> trigger on older versions.
>
> I think we can next forward this to upstream.
I did bisect and it did lead for me to 260fbcb92bbe ("cgroup: Move
dying_tasks cleanup from cgroup_task_release() to
cgroup_task_free()"). But it is nearby to the commit you are spotting.
I will forward the issue upstream.
Regards,
Salvatore
