610.43.03 + Linux 7.1 Wayland/Chromium video triggers folio_mark_dirty kernel Oops

610.43.03 + Linux 7.1 Wayland/Zen video triggers page/PTE corruption Oops

Summary

On Arch Linux, using Zen Browser (Firefox/Gecko-based) to watch YouTube on GNOME Wayland with the NVIDIA open kernel modules caused a complete system hang repeatedly. The kernel oops is in the Linux MM subsystem, not in an NVIDIA symbol, but NVIDIA UVM/HMM and DRM were active in this workload.

Hardware and software

• Lenovo Legion R9000P ARX8 (82WM)
• NVIDIA GeForce RTX 4060 Laptop GPU / AD107M, PCI ID 10de:28e0, subsystem 17aa:3c51
• External PDA F27U5 over HDMI; internal eDP also connected
• Arch Linux; GNOME 50.3 / Mutter 50.3; Wayland
• Zen Browser 1.21.6b (zen-bin, Firefox/Gecko-based); Gecko/WebRender GPU acceleration; YouTube video
• Kernel 7.1.3-zen1-3-zen, PREEMPT(full)
• nvidia-open-dkms 610.43.03-3, nvidia-utils 610.43.03-3
• Modules loaded: nvidia, nvidia-modeset, nvidia-drm, nvidia-uvm

The kernel is tainted G OE because NVIDIA is out of tree.

Kernel failure

The first boot produced this at 2026-07-15 22:52:47:

BUG: unable to handle page fault for address: ffffcd6002dcc5e0
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
CPU: 0 UID: 1000 PID: 83455 Comm: Compositor
RIP: 0010:folio_mark_dirty+0x25/0x60
Call Trace:
  zap_present_ptes.constprop.0+0x46a
  __zap_vma_range+0x734/0x13e0
  unmap_vmas+0xb2/0x1a0
  vms_complete_munmap_vmas
  do_vmi_munmap
  __x64_sys_munmap

About 39 seconds later, another task (Timer) hit the same fault pattern and the kernel reported Fixing recursive fault but reboot is needed!.

The second boot produced the same failure at 2026-07-15 23:11:33:

BUG: unable to handle page fault for address: ffffcb2706d1c5e0
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
CPU: 0 PID: 8769 Comm: Compositor
RIP: 0010:folio_mark_dirty+0x25/0x60
Call Trace:
  zap_present_ptes.constprop.0+0x46a
  __zap_vma_range+0x734/0x13e0
  unmap_vmas+0xb2/0x1a0
  vms_complete_munmap_vmas
  do_vmi_munmap
  __x64_sys_munmap

At 23:12:17, MediaPD~der #14 hit the same fault through exit_mmap -> mmput -> do_exit, followed by RCU stalls. Both failures required a reboot.

Additional reproduction on 2026-07-16

At 08:50:35, a Zen content process first crashed in userspace:

Isolated Web Co[42979]: segfault ... in libxul.so
Process 42979 (Isolated Web Co) ... dumped core
Command line: /opt/zen-browser-bin/zen-bin -contentproc ...

Three seconds later, Zen's Compositor thread (PID 38393) triggered another kernel fault during munmap():

BUG: unable to handle page fault for address: fffffb06d3aba848
RIP: zap_present_ptes.constprop.0+0x46/0xb20
CR2: fffffb06d3aba848
RAX: fffffb06d3aba840
note: Compositor[38393] exited with irqs disabled

The local 7.1.3-zen disassembly at this offset is:

call vm_normal_page
mov 0x8(%rax), %r8

Here CR2 = RAX + 0x8, so this occurrence is earlier in the same MM path: vm_normal_page() returned an invalid/stale struct page * (or the PTE decoded to one), before the later folio_mark_dirty() manifestation seen in the prior crashes.

There were no MCE/EDAC, PCIe AER, NVMe/Btrfs/I/O, or NVIDIA Xid errors in the journal.

Source-level analysis

I inspected the local 7.1.3-zen vmlinux and disassembly. At folio_mark_dirty+0x25, the faulting instruction is:

call folio_mapping
mov 0x68(%rax), %rdx

For the second crash:

• CR2 = ffffcb2706d1c5e0
• RAX = ffffcb2706d1c578
• CR2 = RAX + 0x68

Thus folio_mapping(folio) returned an invalid/stale struct address_space *, and the first invalid access was reading a field from that object. The caller is the dirty-PTE path in zap_present_ptes().

The relevant Linux source is:

• https://github.com/zen-kernel/zen-kernel/blob/v7.1.3-zen2/mm/memory.c
• https://github.com/zen-kernel/zen-kernel/blob/v7.1.3-zen2/mm/page-writeback.c

This looks like a stale/corrupted folio mapping or a page-lifetime violation (use-after-free/memory corruption), rather than a normal browser crash.

NVIDIA-specific context

The failure was preceded/repeated by:

nvidia-modeset: WARNING: GPU:0: HDMI FRL link training failed.
nvidia-modeset: WARNING: GPU:0: Unable to read EDID for display device PDA F27U5 (HDMI-0)

At 23:12:20, Zen/Gecko reported:

GPU process launch failed: error_code=1002
GPU process isn't usable. Goodbye.

The local 610.43.03 source and module parameters show that UVM HMM is enabled:

/sys/module/nvidia_uvm/parameters/uvm_disable_hmm=N
/sys/module/nvidia_uvm/parameters/uvm_enable_va_space_mm=1

The UVM source registers mmu_interval_notifier callbacks and uses migrate_vma_setup(), migrate_vma_pages(), and migrate_vma_finalize() while handling MMU invalidation/unmap events. The oops does not prove that UVM caused the corruption, but this is the relevant NVIDIA-to-Linux-MM boundary for this workload.

Regression/correlation

The kernel and NVIDIA packages were upgraded on 2026-07-14:

• linux-zen 7.1.3.zen1-2 -> 7.1.3.zen1-3
• nvidia-open-dkms 610.43.03-2 -> 610.43.03-3
• nvidia-utils 610.43.03-2 -> 610.43.03-3

Both hard failures occurred on the new combination on 2026-07-15. I did not see this folio_mark_dirty oops in preceding boots using linux-zen 7.1.3.zen1-2, although this is only a correlation because both kernel and driver packages changed.

Questions

1. Is there a known 610.43.03 UVM/HMM or NVIDIA DRM issue with Linux 7.1, PREEMPT(full), and Gecko/WebRender/Wayland video workloads that can corrupt a page/PTE lifetime?
2. Could the HDMI FRL link-training / EDID failures be related to the memory corruption or are they a separate display-link problem?
3. Which NVIDIA module parameters or debug builds would help distinguish UVM/HMM from nvidia-drm/nvidia-modeset?
4. Would NVIDIA like a complete nvidia-bug-report.sh output or a KASAN/debug-kernel reproducer?

Start with mm/memory.c and mm/page-writeback.c at zap_present_ptes() and folio_mark_dirty(), then compare the reported call traces with the Linux 7.1.3-zen source. Reproduce the Wayland/Gecko video workload while collecting the mentioned NVIDIA UVM/HMM, DRM, and kernel diagnostics. Done means identifying a confirmed corruption source or a reliable reproducer that distinguishes the suspected NVIDIA-MM boundary.