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
