Re: [syzbot] [mm?] kernel BUG in sanity_check_pinned_pages

[David Hildenbrand <david@redhat.com>]

On 03.06.25 19:20, Jens Axboe wrote:
> 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@syzkaller.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@kernel.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.

Yeah, that does not really look problematic.

Interestingly, this was found in

	git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci

Hm.

Let me dig a bit, but if it's some corner case race, it's weird that we didn't
find it earlier.

-- 
Cheers,

David / dhildenb