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

[Waiman Long <llong@redhat.com>]

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@qq.com> 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@qq.com>,    xingwei lee <xrivendell7@gmail.com>,Penglei Jiang <superman.xpt@gmail.com>
>>> 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.
>