Re: [BUG] alloc_tag: GPF in __pgalloc_tag_sub() during hibernation snapshot, page tag ref points into .orc_unwind_ip

[Hao Ge <hao.ge@linux.dev>]

Hi Konstantin

On 2026/11/9 16:45, Konstantin Yagola wrote:
> Hi,
>
> my laptop sometimes fails to hibernate: the screen goes dark, the fans
> keep spinning and only a forced power-off helps. It happened twice this
> week on 7.3. Both times pstore caught the same crash: a GPF in
> __pgalloc_tag_sub() while hibernate_preallocate_memory() reclaims
> memory for the image. Both times it was the second or third hibernation
> of the same boot, after successful S4 resumes. It is not every time:
> one boot went through six hibernate/resume cycles without a problem.
>
> Taint first, honestly: P (nvidia), O (openrazer) and S (CPU undervolt
> via MSR). I know S makes any report suspicious, so here is why I think
> this is a software bug and not random corruption:
>
>  - RCX is fe20d545fe20d545 in BOTH crashes, byte for byte, across two
>    different boots with different KASLR offsets;
>  - RDX (the codetag pointer taken from the page) minus the KASLR
>    offset is the same in both crashes: 0xffffffff835ac1f0;
>  - in vmlinux of this build that address is inside .orc_unwind_ip,
>    not an alloc_tag. The faulting code is
>
>        mov  rcx, [rdx+0x20]    ; tag->counters
>        add  gs:[rcx], rax      ; <-- GPF
>
>    so "counters" is just ORC table bytes read as a percpu pointer.
>
> So a page's tag reference ends up as a valid, KASLR-adjusted kernel
> pointer to the wrong place. My guess is that page tag refs get out of
> sync with the tags across a hibernate/resume cycle, but I have not
> verified that.
>
> Setup: Razer Blade 16 (RZ09-0483, BIOS 2.03), i9-13950HX, 32 GB RAM,
> NixOS, kernel 7.3.0 (nixpkgs build, CONFIG_MEM_ALLOC_PROFILING=y,
> ..._ENABLED_BY_DEFAULT=y, not compressed, no _DEBUG), hibernation to a
> 48 GB swapfile on btrfs inside dm-crypt, /sys/power/disk = platform.

Thanks for the excellent report and especially for the disassembly work;
Sorry for the delayed reply.

Based on your configuration, we are using page_ext mode: the codetag pointer
is stored in page_ext. page_ext is allocated via the page allocator as well.

From your disassembly analysis above, we can see the issue is triggered because
the address stored in a page_ext has been overwritten.

Where those 8 bytes live page_ext (normal pages from the buddy, GFP_ZERO'd at early
boot, before any driver loads),  layout as below:

+---------------+---------------+-------------+-------------+
|     ref(pfn1)  | ref(pfn2)      |       ...          | ref(pfn k)  |
+---------------+---------------+-------------+-------------+
|   &tag_a        | &tag_b         |                     |  &tag_k     |
+---------------+---------------+-------------+-------------+

I'm wondering whether an out-of-bounds write from an adjacent page might have clobbered it.
Are there any other clues available? Could you share where I can get the matching vmlinux,
kernel config and dmesg?

Thanks
Best Regards
Hao

>
> Workaround: sysctl.vm.mem_profiling=never on the command line. I cannot
> reproduce this on an untainted kernel: it happens about once a week,
> and with the workaround I will not see it at all. If there is something
> cheaper to collect (a debug option, a printk, a check right after
> resume), I am happy to run it.
>
> Crash 1 (2026-11-09), assembled from pstore:
>
> Oops: general protection fault, probably for non-canonical address
> 0xfe20646ff042c545: 0000 [#1] SMP NOPTI
> CPU: 3 UID: 0 PID: 458460 Comm: systemd-sleep Tainted: P S         O
>     7.3.0 #1-NixOS PREEMPT(lazy)
> Tainted: [P]=PROPRIETARY_MODULE, [S]=CPU_OUT_OF_SPEC, [O]=OOT_MODULE
> Hardware name: Razer Blade 16 - RZ09-0483/SO690, BIOS 2.03 06/04/2024
> RIP: 0010:__pgalloc_tag_sub+0xcc/0x170
> Code: e8 79 f4 08 00 48 85 c0 74 eb 48 03 05 9d 09 d2 01 48 8b 10 48
> 89 c3 48 85 d2 74 1b 44 89 f0 48 8b 4a 20 48 c1 e0 0c 48 f7 d8 <65> 48
> 01 01 48 8b 42 20 65 48 ff 48 08 48 c7 c7 00 19 c3 ac e8 fb
> RSP: 0018:ffffcfcdc517b4d8 EFLAGS: 00010287
> RAX: fffffffffffff000 RBX: ffff8f220292fbc0 RCX: fe20d545fe20d545
> RDX: ffffffffac3ac1f0 RSI: 0000000000000001 RDI: 0000000002bafbc0
> RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
> R10: ffff8f299ed9d260 R11: 0000000000000000 R12: fffff39ed5d7de00
> R13: 0000000000000000 R14: 0000000000000001 R15: ffffcfcdc517b5e8
> Call Trace:
> <TASK>
> free_unref_folios+0x18f/0x830
> shrink_folio_list+0x63e/0x1090
> evict_folios+0x154/0x5f0
> try_to_shrink_lruvec+0x132/0x260
> shrink_one+0xc0/0x1a0
> shrink_node+0xb9e/0xdd0
> do_try_to_free_pages+0xbf/0x480
> try_to_free_pages+0xf6/0x1f0
> __alloc_frozen_pages_noprof+0xa00/0x18d0
> alloc_pages_mpol+0xbc/0x180
> alloc_pages_noprof+0x3b/0x90
> alloc_image_page+0x2d/0xb0
> preallocate_image_memory+0x30/0x64
> hibernate_preallocate_memory+0x257/0x391
> hibernation_snapshot+0x9c/0x4c0
> hibernate.cold+0x10d/0x495
> state_store+0xc3/0xd0
> kernfs_fop_write_iter+0x18a/0x230
> vfs_write+0x25d/0x470
> ksys_write+0x73/0xf0
> do_syscall_64+0x114/0x5c0
> entry_SYSCALL_64_after_hwframe+0x77/0x7f
> </TASK>
> Kernel panic - not syncing: Fatal exception
> Kernel Offset: 0x28e00000 from 0xffffffff81000000
>
> Earlier in that boot: "ACPI: PM: Waking up from system sleep state S4"
> at 28492 s, crash at 83620 s.
>
> Crash 2 (2026-11-07): same RIP, same RCX, RDX ffffffffbc1ac1f0 with
> Kernel Offset 0x38c00000 (same address after subtracting it), but this
> time in kswapd0, 7 s after "PM: hibernation: hibernation entry". Two
> successful S4 resumes earlier in that boot (121257 s, 192472 s).
>
> Full pstore dumps and the vmlinux of this build are available if
> useful.
>
> Thanks, KY.