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

[Jens Axboe]

On 6/3/25 11:25 AM, David Hildenbrand wrote:
> 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@xxxxxxxxxxxxxxxxxxxxxxxxx
>>>>
>>>> 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@xxxxxxxxx>
>> 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.

Yep, pulled that into 6.15 as released, and got a few mm/ changes in there.
So perhaps related?

-- 
Jens Axboe