cgroup user-after-free

[Lixiong Liu (刘利雄)]

Hi,

We meet cgroup use-after-free happened in T SW version with 

kernel-5.15.
 
Root cause: 
cgroup_migrate_finish free cset’s cgroup,

but cgroup_sk_alloc use the freed cgroup,

then use-after-free happened.



Detail:
[name:report&]BUG: KASAN: use-after-free in cgroup_sk_alloc

[name:report&]Read of size 8 at addr ffffff80d6d2a048 by task

ChromiumNet/5259
Call trace:
dump_backtrace
show_stack
dump_stack_lvl
print_address_description
__kasan_report
kasan_report
__asan_report_load8_noabort
cgroup_sk_alloc
sk_alloc
unix_create1
unix_create
__sock_create
__sys_socket
__arm64_sys_socket
invoke_syscall
el0_svc_common
do_el0_svc
el0_svc
el0t_64_sync_handler
el0t_64_sync

[name:report&]Allocated by task 1380:
____kasan_kmalloc
__kasan_kmalloc
kmem_cache_alloc_trace
find_css_set
cgroup_migrate_prepare_dst
cgroup_attach_task
__cgroup1_procs_write
cgroup1_procs_write
cgroup_file_write
kernfs_fop_write_iter
vfs_write
ksys_write
__arm64_sys_write
invoke_syscall
el0_svc_common
do_el0_svc
el0_svc
el0t_64_sync_handler
el0t_64_sync

[name:report&]Freed by task 4530:
kasan_set_track
kasan_set_free_info
____kasan_slab_free
__kasan_slab_free
slab_free_freelist_hook
kmem_cache_free_bulk
kfree_rcu_work
process_one_work
worker_thread
kthread
ret_from_fork

[name:report&]Last potentially related work creation:
kasan_save_stack
__kasan_record_aux_stack
kasan_record_aux_stack_noalloc
kvfree_call_rcu
put_css_set_locked
cgroup_migrate_finish
cgroup_attach_task
__cgroup1_procs_write
cgroup1_procs_write
cgroup_file_write
kernfs_fop_write_iter
vfs_write
ksys_write
__arm64_sys_write
invoke_syscall
el0_svc_common
do_el0_svc
el0_svc
el0t_64_sync_handle
el0t_64_sync

[name:report&]The buggy address belongs to the object at
ffffff80d6d2a000 which belongs to the cache kmalloc-512 of size 512

[name:report&]The buggy address is located 72 bytes inside of
512-byte region

[name:debug&]page dumped because: kasan: bad access detected

"cgroup_sk_alloc", kernel-5.15/kernel/cgroup/cgroup.c"
 cset = task_css_set(current);
 if (likely(cgroup_tryget(cset->dfl_cgrp))) {
        cgroup = cset->dfl_cgrp;
 }
 
(gdb) p/x &((struct css_set *)0)->dfl_cgrp
$2 = 0x48
 
Do you have any suggestion for this issue? 

Can we workaround this issue just by hold 

css_set_lock before access cset->dfl_cgrp 

in cgroup_sk_alloc?

Thanks!

Best regards,
Lixiong Liu