Message-ID: <f031d35b-13e3-4dec-a89c-f221331be735@kernel.dk>
Date: Tue, 3 Jun 2025 11:20:23 -0600
From: Jens Axboe <axboe@...nel.dk>
To: David Hildenbrand <david@...hat.com>,
 syzbot <syzbot+1d335893772467199ab6@...kaller.appspotmail.com>,
 akpm@...ux-foundation.org, jgg@...pe.ca, jhubbard@...dia.com,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org, peterx@...hat.com,
 syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [mm?] kernel BUG in sanity_check_pinned_pages

On 6/3/25 10:22 AM, David Hildenbrand wrote:
> On 03.06.25 17:31, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit:    d7fa1af5b33e Merge branch 'for-next/core' into for-kernelci
>> git tree:       git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1457d80c580000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=89c13de706fbf07a
>> dashboard link: https://syzkaller.appspot.com/bug?extid=1d335893772467199ab6
>> compiler:       Debian clang version 20.1.6 (++20250514063057+1e4d39e07757-1~exp1~20250514183223.118), Debian LLD 20.1.6
>> userspace arch: arm64
>>
>> Unfortunately, I don't have any reproducer for this issue yet.
>>
>> Downloadable assets:
>> disk image: https://storage.googleapis.com/syzbot-assets/da97ad659b2c/disk-d7fa1af5.raw.xz
>> vmlinux: https://storage.googleapis.com/syzbot-assets/659e123552a8/vmlinux-d7fa1af5.xz
>> kernel image: https://storage.googleapis.com/syzbot-assets/6ec5dbf4643e/Image-d7fa1af5.gz.xz
>>
>> IMPORTANT: if you fix the issue, please add the following tag to the commit:
>> Reported-by: syzbot+1d335893772467199ab6@...kaller.appspotmail.com
>>
>> head: ffffffff000001fe 0000000000000028 0000000000000000 0000000000000200
>> page dumped because: VM_BUG_ON_PAGE(!PageAnonExclusive(&folio->page) && !PageAnonExclusive(page))
>> ------------[ cut here ]------------
>> kernel BUG at mm/gup.c:70!
>> Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP
>> Modules linked in:
>>
>> CPU: 1 UID: 0 PID: 115 Comm: kworker/u8:4 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025
>> Workqueue: iou_exit io_ring_exit_work
>> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> pc : sanity_check_pinned_pages+0x7cc/0x7d0 mm/gup.c:69
>> lr : sanity_check_pinned_pages+0x7cc/0x7d0 mm/gup.c:69
>> sp : ffff800097f17640
>> x29: ffff800097f17660 x28: dfff800000000000 x27: 1fffffbff87da000
>> x26: 05ffc0000002107c x25: 05ffc0000002107c x24: fffffdffc3ed0000
>> x23: fffffdffc3ed0000 x22: ffff800097f176e0 x21: 05ffc0000002107c
>> x20: 0000000000000000 x19: ffff800097f176e0 x18: 1fffe0003386f276
>> x17: 703e2d6f696c6f66 x16: ffff80008adbe9e4 x15: 0000000000000001
>> x14: 1fffe0003386f2e2 x13: 0000000000000000 x12: 0000000000000000
>> x11: ffff60003386f2e3 x10: 0000000000ff0100 x9 : c8ccd30be98f3f00
>> x8 : c8ccd30be98f3f00 x7 : 0000000000000001 x6 : 0000000000000001
>> x5 : ffff800097f16d58 x4 : ffff80008f415ba0 x3 : ffff8000807b4b68
>> x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000061
>> Call trace:
>>   sanity_check_pinned_pages+0x7cc/0x7d0 mm/gup.c:69 (P)
>>   unpin_user_page+0x80/0x10c mm/gup.c:191
>>   io_release_ubuf+0x84/0xf8 io_uring/rsrc.c:113
>>   io_buffer_unmap io_uring/rsrc.c:140 [inline]
>>   io_free_rsrc_node+0x250/0x57c io_uring/rsrc.c:513
>>   io_put_rsrc_node io_uring/rsrc.h:103 [inline]
>>   io_rsrc_data_free+0x148/0x298 io_uring/rsrc.c:197
>>   io_sqe_buffers_unregister+0x84/0xa0 io_uring/rsrc.c:607
>>   io_ring_ctx_free+0x48/0x430 io_uring/io_uring.c:2723
>>   io_ring_exit_work+0x6c4/0x73c io_uring/io_uring.c:2962
>>   process_one_work+0x7e8/0x156c kernel/workqueue.c:3238
>>   process_scheduled_works kernel/workqueue.c:3319 [inline]
>>   worker_thread+0x958/0xed8 kernel/workqueue.c:3400
>>   kthread+0x5fc/0x75c kernel/kthread.c:464
>>   ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:847
>> Code: 900523a1 910e0021 aa1703e0 97fff8a9 (d4210000)
>> ---[ end trace 0000000000000000 ]---
> 
> So we lost a PAE bit for a pinned folio.
> 
> [   97.640225][  T115] page: refcount:512 mapcount:0 mapping:0000000000000000 index:0x20000 pfn:0x13b400
> [   97.640378][  T115] head: order:9 mapcount:511 entire_mapcount:0 nr_pages_mapped:511 pincount:1
> 
> The folio is indeed pinned, and it is PTE-mapped (511 PTEs are mapped).
> 
> The page we are using for unpinning is not mapped (mapcount:0).
> 
> pfn:0x13b400 indicates that the page we are provided is actually the head page (folio->page).
> 
> 
> [   97.640414][  T115] memcg:ffff0000f36b6000
> [   97.640435][  T115] anon flags: 0x5ffc0000002107c(referenced|uptodate|dirty|lru|arch_1|head|swapbacked|node=0|zone=2|lastcpupid=0x7ff)
> [   97.640468][  T115] raw: 05ffc0000002107c fffffdffc37be1c8 fffffdffc3d75f08 ffff0000d50c0ee1
> [   97.640490][  T115] raw: 0000000000020000 0000000000000000 00000200ffffffff ffff0000f36b6000
> [   97.640514][  T115] head: 05ffc0000002107c fffffdffc37be1c8 fffffdffc3d75f08 ffff0000d50c0ee1
> [   97.640536][  T115] head: 0000000000020000 0000000000000000 00000200ffffffff ffff0000f36b6000
> [   97.640559][  T115] head: 05ffc00000010a09 fffffdffc3ed0001 000001ff000001fe 00000001ffffffff
> [   97.640581][  T115] head: ffffffff000001fe 0000000000000028 0000000000000000 0000000000000200
> [   97.640600][  T115] page dumped because: VM_BUG_ON_PAGE(!PageAnonExclusive(&folio->page) && !PageAnonExclusive(page))
> 
> So we effectively only test the head page. Here we don't have the bit
> set for that page.
> 
> 
> In gup_fast() we perform a similar sanity check, which didn't trigger
> at the time we pinned the folio. io_uring ends up calling
> io_pin_pages() where we call pin_user_pages_fast(), so GUP-fast might
> indeed trigger.
> 
> 
> What could trigger this (in weird scenarios, though) is if we used
> pin_user_page() to obtain a page, then did folio = page_folio(page)
> and called unpin_user_page(&folio->page) instead of using
> unpin_folio(). Or using any other page that we didn't pin. It would be
> a corner case, though.
> 
> Staring at io_release_ubuf(), that's also not immediately what's
> happening.
> 
> There is this coalescing code in
> io_sqe_buffer_register()->io_check_coalesce_buffer(), maybe ...
> something is going wrong there?
> 
> 
> 
> Otherwise, I could only envision (a) some random memory overwrite
> clearing the bit or (b) some weird race between GUP-fast and PAE
> clearing that we didn't run into so far. But these sanity checks have
> been around for a loooong time at this point.
> 
> Unfortunately, no reproducer :(

Too bad there's no reproducer... Since this looks recent, I'd suspect
the recent changes there. Most notably:

commit f446c6311e86618a1f81eb576b56a6266307238f
Author: Jens Axboe <axboe@...nel.dk>
Date:   Mon May 12 09:06:06 2025 -0600

    io_uring/memmap: don't use page_address() on a highmem page

which seems a bit odd, as this is arm64 and there'd be no highmem. This
went into the 6.15 kernel release. Let's hope a reproducer is
forthcoming.

-- 
Jens Axboe

Powered by blists - more mailing lists