linux-kernel - Re: [syzbot] [mm?] kernel BUG in sanity_check_pinned

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b5aa34ed-d7d4-4445-b8bb-6187b4100682@redhat.com>
Date: Mon, 23 Jun 2025 11:29:24 +0200
From: David Hildenbrand <david@...hat.com>
To: syzbot <syzbot+1d335893772467199ab6@...kaller.appspotmail.com>,
 akpm@...ux-foundation.org, axboe@...nel.dk, catalin.marinas@....com,
 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 21.06.25 23:52, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
> 
> HEAD commit:    9aa9b43d689e 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=1525330c580000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=27f179c74d5c35cd
> 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
> syz repro:      https://syzkaller.appspot.com/x/repro.syz?x=16d73370580000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=160ef30c580000

There is not that much magic in there, I'm afraid.

fork() is only used to spin up guests, but before the memory region of 
interest is actually allocated, IIUC. No threading code that races.

IIUC, it triggers fairly fast on aarch64. I've left it running for a 
while on x86_64 without any luck.

So maybe this is really some aarch64-special stuff (pointer tagging?).

In particular, there is something very weird in the reproducer:

   syscall(__NR_madvise, /*addr=*/0x20a93000ul, /*len=*/0x4000ul,
           /*advice=MADV_HUGEPAGE|0x800000000*/ 0x80000000eul);

advise is supposed to be a 32bit int. What does the magical 
"0x800000000" do?

Let me try my luck reproducing in on arm.

-- 
Cheers,

David / dhildenb