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. Regards, Salvatore
