BUG: KASAN: use-after-free in scatterwalk_copychunks followed by Bad page map error and multiple general protection faults
Issue
- Running rhel8.10.z kernel-debug for testing revealed the existence of UAF bug in scatterwalk_copychunks() followed by a Bad page map error and multiple general protection faults:
==================================================================
BUG: KASAN: use-after-free in scatterwalk_copychunks+0x1f4/0x7b0
Write of size 8 at addr ffff888193e80000 by task mkdir/173837
CPU: 2 PID: 173837 Comm: mkdir Kdump: loaded Not tainted 4.18.0-553.16.1.el8_10.x86_64+debug #1
Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS 090008 12/07/2018
Call Trace:
dump_stack+0x5c/0x80
print_address_description.constprop.6+0x1a/0x150
? scatterwalk_copychunks+0x1f4/0x7b0
? scatterwalk_copychunks+0x1f4/0x7b0
kasan_report.cold.11+0x7f/0x118
? scatterwalk_copychunks+0x1f4/0x7b0
kasan_check_range+0x1a0/0x210
memcpy+0x38/0x60
scatterwalk_copychunks+0x1f4/0x7b0
scatterwalk_map_and_copy+0x110/0x170
? scatterwalk_copychunks+0x7b0/0x7b0
? srso_alias_return_thunk+0x5/0xfce2a
? crypto_ccm_init_crypt+0x310/0x990 [ccm]
? simd_skcipher_encrypt+0x258/0x300
crypto_ccm_encrypt+0x3ff/0x630 [ccm]
? srso_alias_return_thunk+0x5/0xfce2a
crypt_message+0x1067/0x1900 [cifs]
? find_held_lock+0x3a/0x1d0
? hlock_class+0x4e/0x120
? srso_alias_return_thunk+0x5/0xfce2a
? cpumask_test_cpu.constprop.29+0x70/0x70 [cifs]
? srso_alias_return_thunk+0x5/0xfce2a
? mark_held_locks+0xb7/0x120
? memset+0x1f/0x40
? _get_random_bytes+0x164/0x390
? smb3_init_transform_rq+0x75f/0x9e0 [cifs]
? entry_SYSCALL_64_after_hwframe+0x6b/0xe0
? urandom_read+0x530/0x530
? lock_is_held_type+0xdc/0x110
? __kmalloc+0x3b/0x290
? srso_alias_return_thunk+0x5/0xfce2a
? sched_clock_cpu+0x18/0x1e0
? srso_alias_return_thunk+0x5/0xfce2a
? find_held_lock+0x3a/0x1d0
smb3_init_transform_rq+0x78e/0x9e0 [cifs]
? smb3_free_compound_rqst+0x2d0/0x2d0 [cifs]
? srso_alias_return_thunk+0x5/0xfce2a
? __kasan_kmalloc+0x82/0xa0
? srso_alias_return_thunk+0x5/0xfce2a
? kmem_cache_alloc_trace+0x188/0x2b0
smb_send_rqst+0x1df/0x320 [cifs]
? __smb_send_rqst+0x1170/0x1170 [cifs]
? hlock_class+0x4e/0x120
? srso_alias_return_thunk+0x5/0xfce2a
? smb2_setup_request+0x3d1/0x8e0 [cifs]
compound_send_recv+0x985/0x2bc0 [cifs]
? lock_downgrade+0x710/0x710
? srso_alias_return_thunk+0x5/0xfce2a
? srso_alias_return_thunk+0x5/0xfce2a
? cifs_pick_channel+0x290/0x290 [cifs]
? do_raw_spin_unlock+0x14b/0x230
? srso_alias_return_thunk+0x5/0xfce2a
? do_raw_spin_unlock+0x14b/0x230
? __smb2_plain_req_init+0x697/0xcf0 [cifs]
? srso_alias_return_thunk+0x5/0xfce2a
? SMB2_close_init+0xb0/0x2f0 [cifs]
? SMB2_set_compression+0x1d0/0x1d0 [cifs]
? lock_is_held_type+0xdc/0x110
? rcu_read_lock_sched_held+0xb3/0xe0
? rcu_read_lock_bh_held+0xd0/0xd0
smb2_compound_op+0x290d/0x5b30 [cifs]
? cpumask_test_cpu.constprop.2+0x70/0x70 [cifs]
? mark_held_locks+0xb7/0x120
? srso_alias_return_thunk+0x5/0xfce2a
? mark_held_locks+0xb7/0x120
? srso_alias_return_thunk+0x5/0xfce2a
? lockdep_hardirqs_on_prepare+0x298/0x3f0
? kasan_quarantine_put+0x100/0x190
? srso_alias_return_thunk+0x5/0xfce2a
? lock_is_held_type+0xdc/0x110
? cifs_get_readable_path+0x15c/0x340 [cifs]
? srso_alias_return_thunk+0x5/0xfce2a
? rcu_read_lock_sched_held+0xb3/0xe0
? rcu_read_lock_bh_held+0xd0/0xd0
? srso_alias_return_thunk+0x5/0xfce2a
? slab_free_freelist_hook+0xc6/0x1a0
? cifs_get_readable_path+0x15c/0x340 [cifs]
? srso_alias_return_thunk+0x5/0xfce2a
? kmem_cache_free+0x23a/0x370
smb2_query_path_info+0x1c9/0x470 [cifs]
? move_smb2_info_to_cifs+0x310/0x310 [cifs]
? srso_alias_return_thunk+0x5/0xfce2a
? __kasan_kmalloc+0x82/0xa0
? srso_alias_return_thunk+0x5/0xfce2a
? kmem_cache_alloc_trace+0x188/0x2b0
cifs_get_inode_info+0xabe/0x1d00 [cifs]
? cifs_get_inode_info_unix+0x5b0/0x5b0 [cifs]
? srso_alias_return_thunk+0x5/0xfce2a
? slab_free_freelist_hook+0xc6/0x1a0
? smb2_compound_op+0xf7b/0x5b30 [cifs]
? srso_alias_return_thunk+0x5/0xfce2a
? kfree+0xe8/0x2d0
? srso_alias_return_thunk+0x5/0xfce2a
? smb2_compound_op+0xf7b/0x5b30 [cifs]
? __dentry_path+0x498/0x570
? srso_alias_return_thunk+0x5/0xfce2a
? srso_alias_return_thunk+0x5/0xfce2a
? __dentry_path+0x41d/0x570
cifs_mkdir_qinfo+0x153/0xa70 [cifs]
? lock_is_held_type+0xdc/0x110
? smb311_posix_get_inode_info+0xe50/0xe50 [cifs]
? rcu_read_lock_sched_held+0xb3/0xe0
? rcu_read_lock_bh_held+0xd0/0xd0
cifs_mkdir+0xca4/0x1250 [cifs]
? srso_alias_return_thunk+0x5/0xfce2a
? security_inode_mkdir+0x86/0xe0
vfs_mkdir+0x3ca/0x630
? srso_alias_return_thunk+0x5/0xfce2a
? security_path_mkdir+0xcb/0x140
do_mkdirat+0x1a7/0x200
? __ia32_sys_mknod+0xb0/0xb0
? srso_alias_return_thunk+0x5/0xfce2a
? lockdep_hardirqs_on_prepare+0x298/0x3f0
? do_syscall_64+0x22/0x450
do_syscall_64+0xa5/0x450
entry_SYSCALL_64_after_hwframe+0x6b/0xe0
RIP: 0033:0x7f4d27b5fd4b
Code: 73 01 c3 48 8b 0d 3d 71 39 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 53 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 0d 71 39 00 f7 d8 64 89 01 48
RSP: 002b:00007fff4fe90f48 EFLAGS: 00000246 ORIG_RAX: 0000000000000053
RAX: ffffffffffffffda RBX: 00007fff4fe91ee2 RCX: 00007f4d27b5fd4b
RDX: 0000000000000000 RSI: 00000000000001ff RDI: 00007fff4fe91f0d
RBP: 00007fff4fe91f0d R08: 00000000000001ff R09: 000055772642f270
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000000001ff
R13: 000055772642f290 R14: 00007fff4fe910c0 R15: 00007fff4fe91258
Allocated by task 1:
kasan_save_stack+0x1c/0x50
__kasan_slab_alloc+0x60/0x80
slab_post_alloc_hook+0x45/0x3b0
kmem_cache_alloc+0x155/0x360
getname_flags+0xba/0x510
do_sys_openat2+0x228/0x4b0
do_sys_open+0x8a/0xd0
do_syscall_64+0xa5/0x450
entry_SYSCALL_64_after_hwframe+0x6b/0xe0
Freed by task 1:
kasan_save_stack+0x1c/0x50
kasan_set_track+0x21/0x30
kasan_set_free_info+0x20/0x40
__kasan_slab_free+0xdf/0x110
slab_free_freelist_hook+0xc6/0x1a0
kmem_cache_free+0x109/0x370
do_sys_openat2+0x264/0x4b0
do_sys_open+0x8a/0xd0
do_syscall_64+0xa5/0x450
entry_SYSCALL_64_after_hwframe+0x6b/0xe0
The buggy address belongs to the object at ffff888193e80000
which belongs to the cache names_cache of size 4096
The buggy address is located 0 bytes inside of
4096-byte region [ffff888193e80000, ffff888193e81000)
The buggy address belongs to the page:
page:ffffea00064fa000 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 head:ffffea00064fa000 order:3 compound_mapcount:0 compound_pincount:0
flags: 0x17ffffc0008100(slab|head|node=0|zone=2|lastcpupid=0x1fffff)
raw: 0017ffffc0008100 dead000000000100 dead000000000200 ffff8881001b3180
raw: 0000000000000000 0000000000070007 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888193e7ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff888193e7ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff888193e80000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888193e80080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888193e80100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Disabling lock debugging due to kernel taint
Environment
- Red Hat Enterprise Linux 8.10.z - 4.18.0-553.16.1.el8_10
- Red Hat Enterprise Linux 8.10.z kernels older than 4.18.0-553.27.1.el8_10
Subscriber exclusive content
A Red Hat subscription provides unlimited access to our knowledgebase, tools, and much more.