Re: KASAN: slab-use-after-free Read in cgroup_rstat_flush

[Waiman Long]

On 4/14/25 1:42 PM, tj wrote:
> On Mon, Apr 14, 2025 at 07:40:04PM +0200, Michal Koutný wrote:
> > Hello.
> >
> > On Mon, Apr 07, 2025 at 07:59:58AM -0400, ffhgfv <xnxc22xnxc22@xxxxxx> wrote:
> > > Hello, I found a bug titled "   KASAN: slab-use-after-free Read in cgroup_rstat_flush " with modified syzkaller in the Linux6.14.
> > > If you fix this issue, please add the following tag to the commit:  Reported-by: Jianzhou Zhao <xnxc22xnxc22@xxxxxx>,    xingwei lee <xrivendell7@xxxxxxxxx>,Penglei Jiang <superman.xpt@xxxxxxxxx>
> > > I use the same kernel as syzbot instance upstream: f6e0150b2003fb2b9265028a618aa1732b3edc8f
> > > kernel config: https://syzkaller.appspot.com/text?tag=KernelConfig&amp;x=da4b04ae798b7ef6
> > > compiler: gcc version 11.4.0
> > >
> > > Unfortunately, we do not have a repro.
> > Thanks for sharing the report.
> >
> > > ------------[ cut here ]-----------------------------------------
> > >   TITLE:  KASAN: slab-use-after-free Read in cgroup_rstat_flush
> > > ==================================================================
> > > bridge_slave_0: left allmulticast mode
> > > bridge_slave_0: left promiscuous mode
> > > bridge0: port 1(bridge_slave_0) entered disabled state
> > > ==================================================================
> > > BUG: KASAN: slab-use-after-free in cgroup_rstat_cpu kernel/cgroup/rstat.c:19 [inline]
> > > BUG: KASAN: slab-use-after-free in cgroup_base_stat_flush kernel/cgroup/rstat.c:422 [inline]
> > > BUG: KASAN: slab-use-after-free in cgroup_rstat_flush+0x16ce/0x2180 kernel/cgroup/rstat.c:328
> > I read this like the struct cgroup is gone when the code try flushing
> > its respective stats (its ->rstat_cpu more precisely).
> >
> > Namely,
> > 	__mem_cgroup_flush_stats
> > 		cgroup_rstat_flush(memcg->css.cgroup);
> > this reference is taken at cgroup creation in init_and_link_css()
> > and released only in css_free_rwork_fn().
> Maybe another casualty of the bug fixed by a22b3d54de94 ("cgroup/cpuset: Fix
> race between newly created partition and dying one")?

You mean the rcu_read_lock isn't held for the entire flushing operation 
so that the cgroup structure itself may have been freed near the end. Right?

Cheers,
Longman

> Thanks.