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. Sincerely, Noah Feldt
