| 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
| ||
|
Message-ID: <0859bb24-2d98-4420-b0bc-e5a60ba0dedd@redhat.com> Date: Tue, 3 Jun 2025 19:25:11 +0200 From: David Hildenbrand <david@...hat.com> To: Jens Axboe <axboe@...nel.dk>, 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, Catalin Marinas <catalin.marinas@....com> Subject: Re: [syzbot] [mm?] kernel BUG in sanity_check_pinned_pages 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@...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. 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
Powered by blists - more mailing lists