Bug 205705 - Linux Kernel 5.3.10 - perf_trace_lock_acquire use-after-free
Summary: Linux Kernel 5.3.10 - perf_trace_lock_acquire use-after-free
Status: NEW
Alias: None
Product: Process Management
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: process_other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-29 17:03 UTC by Tristan Madani
Modified: 2020-03-30 10:04 UTC (History)
5 users (show)

See Also:
Kernel Version: 5.3.10
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Tristan Madani 2019-11-29 17:03:45 UTC
LINUX KERNEL 5.3.10 - perf_trace_lock_acquire use-after-free

0x01 - Introduction
===

# Product: Linux Kernel 
# Version: 5.3.10 (and probably other versions)
# Bug: UAF (Read)
# Tested on: GNU/Linux Debian 9 x86_64


0x02 - Crash report
===

BUG: KASAN: use-after-free in perf_trace_lock_acquire+0x443/0x630 include/trace/events/lock.h:13
Read of size 8 at addr ffff88802245cc18 by task syz-executor.1/10285

CPU: 1 PID: 10285 Comm: syz-executor.1 Not tainted 5.3.10 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
Call Trace:											// <--- call trace that reach it
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xca/0x13e lib/dump_stack.c:113
 print_address_description+0x67/0x360 mm/kasan/report.c:351
 __kasan_report.cold.7+0x1a/0x3b mm/kasan/report.c:482
 kasan_report+0xe/0x12 mm/kasan/common.c:618
 perf_trace_lock_acquire+0x443/0x630 include/trace/events/lock.h:13
 trace_lock_acquire include/trace/events/lock.h:13 [inline]
 lock_acquire+0x234/0x330 kernel/locking/lockdep.c:4411
 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
 _raw_spin_lock_irqsave+0x30/0x40 kernel/locking/spinlock.c:159
 __wake_up_common_lock+0xa8/0x120 kernel/sched/wait.c:122
 __locks_wake_up_blocks+0x18e/0x240 fs/locks.c:741
 locks_delete_block+0x7f/0x240 fs/locks.c:772
 flock_lock_inode_wait fs/locks.c:2081 [inline]
 locks_lock_inode_wait+0x14c/0x3b0 fs/locks.c:2100
 locks_lock_file_wait include/linux/fs.h:1310 [inline]
 __do_sys_flock fs/locks.c:2163 [inline]
 __se_sys_flock fs/locks.c:2126 [inline]
 __x64_sys_flock+0x2fb/0x350 fs/locks.c:2126
 do_syscall_64+0xbc/0x560 arch/x86/entry/common.c:296
 entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x465b89
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f5adacefc68 EFLAGS: 00000246 ORIG_RAX: 0000000000000049
RAX: ffffffffffffffda RBX: 000000000051bfa8 RCX: 0000000000465b89
RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000005
RBP: 00000000ffffffff R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004a6427
R13: 00000000004e4650 R14: 00000000004a6f99 R15: 00007f5adacf06bc

Allocated by task 10290:								// <--- where is it allocated
 save_stack+0x19/0x80 mm/kasan/common.c:69
 set_track mm/kasan/common.c:77 [inline]
 __kasan_kmalloc mm/kasan/common.c:493 [inline]
 __kasan_kmalloc.constprop.7+0xc1/0xd0 mm/kasan/common.c:466
 slab_post_alloc_hook mm/slab.h:520 [inline]
 slab_alloc_node mm/slub.c:2770 [inline]
 slab_alloc mm/slub.c:2778 [inline]
 kmem_cache_alloc+0xd9/0x2f0 mm/slub.c:2783
 kmem_cache_zalloc include/linux/slab.h:738 [inline]
 locks_alloc_lock+0x18/0x1c0 fs/locks.c:345
 flock_make_lock+0x245/0x2b0 fs/locks.c:486
 __do_sys_flock fs/locks.c:2145 [inline]
 __se_sys_flock fs/locks.c:2126 [inline]
 __x64_sys_flock+0x122/0x350 fs/locks.c:2126
 do_syscall_64+0xbc/0x560 arch/x86/entry/common.c:296
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

Freed by task 10290:								// <--- where it has been freed
 save_stack+0x19/0x80 mm/kasan/common.c:69
 set_track mm/kasan/common.c:77 [inline]
 __kasan_slab_free+0x12e/0x180 mm/kasan/common.c:455
 slab_free_hook mm/slub.c:1423 [inline]
 slab_free_freelist_hook+0x56/0x160 mm/slub.c:1474
 slab_free mm/slub.c:3016 [inline]
 kmem_cache_free+0xa0/0x330 mm/slub.c:3032
 locks_free_lock fs/locks.c:382 [inline]
 __do_sys_flock fs/locks.c:2166 [inline]
 __se_sys_flock fs/locks.c:2126 [inline]
 __x64_sys_flock+0x290/0x350 fs/locks.c:2126
 do_syscall_64+0xbc/0x560 arch/x86/entry/common.c:296
 entry_SYSCALL_64_after_hwframe+0x49/0xbe

The buggy address belongs to the object at ffff88802245cb88
 which belongs to the cache file_lock_cache of size 264			// <--- the object's cache
The buggy address is located 144 bytes inside of
 264-byte region [ffff88802245cb88, ffff88802245cc90)
The buggy address belongs to the page:
page:ffffea0000891700 refcount:1 mapcount:0 mapping:ffff88802e50ca00 index:0x0
flags: 0x100000000000200(slab)
raw: 0100000000000200 ffffea00008e4ec0 0000000300000003 ffff88802e50ca00
raw: 0000000000000000 00000000000c000c 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88802245cb00: fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc
 ffff88802245cb80: fc fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff88802245cc00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                            ^
 ffff88802245cc80: fb fb fc fc fc fc fc fc fc fc fb fb fb fb fb fb
 ffff88802245cd00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Comment 1 Tony Jones 2020-02-05 20:38:33 UTC
Do you have any of the reproducer info per https://github.com/google/syzkaller/blob/master/docs/reproducing_crashes.md
Comment 2 Dmitry Vyukov 2020-03-30 08:33:16 UTC
This also happened on Android 5.4 kernel:
https://syzkaller.appspot.com/bug?id=780a5854ef31fca357e4d176ae87446e44459523
And there is a C reproducer in that bug.
Comment 3 Jeff Layton 2020-03-30 10:04:28 UTC
I think this is likely fixed by these commits in mainline kernel:

6d390e4b5d48ec03bb87e63cf0a2bff5f4e116da
dcf23ac3e846ca0cf626c155a0e3fcbbcf4fae8a

Could you test those and let me know whether they fix the issue?

Note You need to log in before you can comment on or make changes to this bug.