linux-kernel - Re: BUG: WARNING in free

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e50f9da1-521d-46ae-9e12-d82c4c093223@lucifer.local>
Date: Thu, 29 Aug 2024 12:30:40 +0100
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Xingyu Li <xli399@....edu>
Cc: akpm@...ux-foundation.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Yu Hao <yhao016@....edu>,
        Liam Howlett <liam.howlett@...cle.com>
Subject: Re: BUG: WARNING in free_pgtables

On Wed, Aug 28, 2024 at 02:37:04PM GMT, Xingyu Li wrote:
> Hi,
>
> We found a bug in Linux 6.10 using syzkaller. It is possibly a  logic bug.

These lines are actually a bit offset for 6.10..

> The reprodcuer is
> https://gist.github.com/freexxxyyy/5f0c95e95e1bc0fb681e504114b61de8

Again, this doesn't repro for me. And the call stack suggests this doesn't
occur in the repro but on a process exit.

>
> The bug report is:
>
> WARNING: CPU: 0 PID: 8053 at include/linux/rwsem.h:203

This is:

	lockdep_assert_held_write(sem);

So presumably lockdep is on here (be good to get .config, full dmesg).

> mmap_assert_write_locked include/linux/mmap_lock.h:70 [inline]

This is:

rwsem_assert_held_write(&mm->mmap_lock);

> WARNING: CPU: 0 PID: 8053 at include/linux/rwsem.h:203
> __is_vma_write_locked include/linux/mm.h:714 [inline]

Should be 715? Guess inlined, but problematic line seems to be:

mmap_assert_write_locked(vma->vm_mm);

> WARNING: CPU: 0 PID: 8053 at include/linux/rwsem.h:203 vma_start_write
> include/linux/mm.h:733 [inline]
> WARNING: CPU: 0 PID: 8053 at include/linux/rwsem.h:203
> free_pgtables+0x4df/0xbb0 mm/memory.c:403
> Modules linked in:
> CPU: 0 PID: 8053 Comm: syz-executor107 Not tainted 6.10.0 #13
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
> RIP: 0010:rwsem_assert_held_write include/linux/rwsem.h:203 [inline]
> RIP: 0010:mmap_assert_write_locked include/linux/mmap_lock.h:70 [inline]
> RIP: 0010:__is_vma_write_locked include/linux/mm.h:714 [inline]
> RIP: 0010:vma_start_write include/linux/mm.h:733 [inline]
> RIP: 0010:free_pgtables+0x4df/0xbb0 mm/memory.c:403
> Code: 04 00 4d 85 e4 0f 84 86 03 00 00 e8 3b 46 b6 ff 4d 89 ee 4d 89
> e5 49 bc 00 00 00 00 00 fc ff df e9 86 fd ff ff e8 21 46 b6 ff <0f> 0b
> e9 b8 fe ff ff 48 c7 c1 6c 91 24 8f 80 e1 07 80 c1 03 38 c1
> RSP: 0018:ffffc9000ac7f748 EFLAGS: 00010293
> RAX: ffffffff81db0b3f RBX: ffff88801d8cbe98 RCX: ffff888021fa1e00
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
> RBP: 0000000000000000 R08: ffffffff81db09ea R09: ffffffff8aed5df0
> R10: 0000000000000004 R11: ffff888021fa1e00 R12: ffff88802ce66ba0
> R13: ffff88801d8cbe88 R14: ffff88802ce66aa8 R15: 1ffff11003b197d1
> FS:  0000000000000000(0000) GS:ffff888063a00000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00007ff0448ce6b0 CR3: 00000000244bc000 CR4: 0000000000350ef0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> Call Trace:
>  <TASK>
>  exit_mmap+0x435/0xa20 mm/mmap.c:3352

This is

	free_pgtables(&tlb, &vmi.mas, vma, FIRST_USER_ADDRESS,
		      USER_PGTABLES_CEILING, true);

But on line 3349 we have:

	mmap_write_lock(mm);

None of the calls before free_pgtables() unlock this lock so that's super
weird. I'm not sure how this could possibly happen?

>  __mmput+0x114/0x3b0 kernel/fork.c:1346
>  exit_mm+0x207/0x2e0 kernel/exit.c:567
>  do_exit+0x996/0x2560 kernel/exit.c:863
>  do_group_exit+0x1fd/0x2b0 kernel/exit.c:1025
>  get_signal+0x1697/0x1730 kernel/signal.c:2909
>  arch_do_signal_or_restart+0x92/0x7f0 arch/x86/kernel/signal.c:310

OK so this is exit on a signal... so not the repro? Or when the repro was
killed?

>  exit_to_user_mode_loop kernel/entry/common.c:111 [inline]
>  exit_to_user_mode_prepare include/linux/entry-common.h:328 [inline]
>  __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]
>  syscall_exit_to_user_mode+0x95/0x280 kernel/entry/common.c:218
>  do_syscall_64+0x8a/0x150 arch/x86/entry/common.c:89
>  entry_SYSCALL_64_after_hwframe+0x67/0x6f
> RIP: 0033:0x7fb06353406d
> Code: Unable to access opcode bytes at 0x7fb063534043.
> RSP: 002b:00007fb0634d10c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
> RAX: 0000000000000002 RBX: 00007fb0635c92e8 RCX: 00007fb06353406d
> RDX: 0000000020000080 RSI: 0000000000000001 RDI: 0000000000000004
> RBP: 00007fb0635c92e0 R08: 00007fb0634d1640 R09: 0000000000000000
> R10: 00007fb0634d1640 R11: 0000000000000246 R12: 00007fb0635c92ec
> R13: 0000000000000000 R14: 00007fb0634f67c0 R15: 00007fb0634b1000
>  </TASK>
>
>
> --
> Yours sincerely,
> Xingyu