linux-kernel - Re: WARNING in get_pat

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <f02a96a2-9f3a-4bed-90a5-b3309eb91d94@intel.com>
Date: Tue, 15 Oct 2024 13:04:19 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Marius Fleischer <fleischermarius@...il.com>,
 Dave Hansen <dave.hansen@...ux.intel.com>, Andy Lutomirski
 <luto@...nel.org>, Peter Zijlstra <peterz@...radead.org>,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, linux-kernel@...r.kernel.org
Cc: syzkaller@...glegroups.com, harrisonmichaelgreen@...il.com,
 Jens Axboe <axboe@...nel.dk>, Pavel Begunkov <asml.silence@...il.com>,
 io-uring@...r.kernel.org
Subject: Re: WARNING in get_pat_info

On 10/15/24 11:55, Marius Fleischer wrote:
> Hope you are doing well!
> 
> Quick update from our side: The reproducer from the previous email
> still triggers a WARNING on v5.15 (commit hash
> 3a5928702e7120f83f703fd566082bfb59f1a57e). Happy to also test on
> other kernel versions if that helps.
> 
> Please let us know if there is any other helpful information we can provide.

I don't know for sure, but I suspect that io_uring is triggering this.
The reproducer is:

	syz_io_uring_setup(0x6f7e, &(0x7f0000000080), 0x0, 0x0)
	syz_clone(0x24080, 0x0, 0x0, 0x0, 0x0, 0x0) (fail_nth: 40)

and the stack trace shows:

 untrack_pfn+0xdc/0x240 arch/x86/mm/pat/memtype.c:1122
 ...
 __mmput+0x122/0x4b0 kernel/fork.c:1126
 ...
 __do_sys_clone+0xc8/0x110 kernel/fork.c:2721

So whatever is happening is going on with a VM_PFNMAP VMA.  Those aren't
super common except when you're mmap()'ing something from a device
driver.  I would randomly guess that io_uring_setup() is setting up a
VM_PFNMAP VMA and untrack_pfn() is getting called when that VMA is
getting torn down.

The other goofiness is that the copy_mm() path is ending up in
exit_mmap().  I think the only way to end up doing that is in the
failure path of dup_mm().

So I *think* what happens is that a io_uring VMA gets created in
dup_mmap(), but never gets any pages faulted in.  Some later setup fails
and the new mm needs to be torn down.  *Something* about the io_uring
VMA screws up the untrack_pfn() code.

I'm hoping that this rings a bell with the io_uring folks and this is a
bug they've found and fixed in mainline that just got missed backporting
to stable.