On 28.11.24 12:42, Hillf Danton wrote:
On Thu, 28 Nov 2024 11:52:42 +0100 David Hildenbrand <david@xxxxxxxxxx>
On 23.11.24 08:31, syzbot wrote:
Hello,
syzbot found the following issue on:
HEAD commit: 9fb2cfa4635a Merge tag 'pull-ufs' of git://git.kernel.org/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10042930580000
kernel config: https://syzkaller.appspot.com/x/.config?x=c4515f1b6a4e50b7
dashboard link: https://syzkaller.appspot.com/bug?extid=9f9a7f73fb079b2387a6
compiler: gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=105ff2e8580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/7c0c61a15f60/disk-9fb2cfa4.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/3363d84eeb74/vmlinux-9fb2cfa4.xz
kernel image: https://storage.googleapis.com/syzbot-assets/2b1a270af550/bzImage-9fb2cfa4.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+9f9a7f73fb079b2387a6@xxxxxxxxxxxxxxxxxxxxxxxxx
Staring at the console output:
[ 520.222112][ T7269] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x1403 pfn:0x125be
->mapping is cleared for a order9 page
> >> [ 520.362213][ T7269] head: order:9 mapcount:0 entire_mapcount:0
nr_pages_mapped:0 pincount:0
[ 520.411963][ T7269] memcg:ffff88807c73c000
[ 520.492069][ T7269] flags: 0xfff00000000040(head|node=0|zone=1|lastcpupid=0x7ff)
[ 520.499844][ T7269] raw: 00fff00000000000 ffffea0000490001 dead000000000122 dead000000000400
[ 520.551982][ T7269] raw: 00000000000014d0 0000000000000000 00000000ffffffff 0000000000000000
[ 520.560912][ T7269] head: 00fff00000000040 0000000000000000 dead000000000122 0000000000000000
[ 520.672020][ T7269] head: 0000000000001245 0000000000000000 00000001ffffffff ffff88807c73c000
[ 520.735699][ T7269] head: 00fff00000000209 ffffea0000490001 ffffffffffffffff 0000000000000000
[ 520.901989][ T7269] head: 0000000000000200 0000000000000000 00000000ffffffff 0000000000000000
[ 520.991952][ T7269] page dumped because: VM_BUG_ON_PAGE(PageTail(page))
[ 521.086487][ T7269] page_owner tracks the page as allocated
[ 521.132208][ T7269] page last allocated via order 0, migratetype Movable, gfp_mask 0x3d24ca(GFP_TRANSHUGE|__GFP_NORETRY|
^order 0 looks wrong, but let;s not get distracted.
__GFP_THISNODE), pid 7321, tgid 7321 (syz.1.194), ts 520201520231, free_ts 520193076092
[ 521.272012][ T7269] post_alloc_hook+0x2d1/0x350
[ 521.276977][ T7269] __alloc_pages_direct_compact+0x20e/0x590
[ 521.314428][ T7269] __alloc_pages_noprof+0x182b/0x25a0
[ 521.319975][ T7269] alloc_pages_mpol_noprof+0x282/0x610
[ 521.420092][ T7269] folio_alloc_mpol_noprof+0x36/0xd0
[ 521.483167][ T7269] vma_alloc_folio_noprof+0xee/0x1b0
[ 521.539677][ T7269] do_huge_pmd_anonymous_page+0x258/0x2ae0
...
[ 521.851719][ T7269] page last free pid 7323 tgid 7321 stack trace:
[ 521.972611][ T7269] free_unref_folios+0xa87/0x14f0
[ 521.977735][ T7269] folios_put_refs+0x587/0x7b0
[ 522.072508][ T7269] folio_batch_move_lru+0x2c4/0x3b0
[ 522.077794][ T7269] __folio_batch_add_and_move+0x35b/0xc60
[ 522.191992][ T7269] reclaim_folio_list+0x205/0x3a0
[ 522.197131][ T7269] reclaim_pages+0x481/0x650
[ 522.201760][ T7269] madvise_cold_or_pageout_pte_range+0x163b/0x20d0
...
So we allocated a order-9 anonymous folio, but suddenly find it via shmem in the pagecache?
Is this some crazy use-after-free / double-free, where we end up freeing a shmem folio
that is still in the pagecache? Once freed, it gets merged in the buddy, and we then re-allocate
it as part of a PMD THP; but shmem still finds it in the pagecache, and as the it's now suddenly
It is not in the pagecache.
next_uptodate_folio() finds it there? Which is .. via the pagecache
xas_next_entry()?
But good point on the mapping. If we would have freed a folio while
still in the pagecache (before truncation), we'd likely have gotten an
error from free_page_is_bad().
Well, unless check_pages_enabled() is false.
--
Cheers,
David / dhildenb
