After upgrading the linux-image-amd64 meta-package from 6.12.107-1 to
6.12.111-1 on four Debian 13 (trixie) KVM hosts, kswapd0/kswapd1 crashes
with a NULL pointer dereference at address 0000000000000008 during the
reclaim path, under memory pressure during nightly cron workloads
(AIDE + rsync backups).

The crash is reproducible within 4-18 hours after kernel boot. Three of
four hosts with identical hardware crash; the fourth runs stable on the
same kernel and same workload pattern (linuxhost2 - Atom C3858 with
lighter VM footprint).

CRASH SIGNATURE (identical across all three crash hosts):

BUG: kernel NULL pointer dereference, address: 0000000000000008
Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 18 UID: 0 PID: 403 Comm: kswapd1
Tainted: G OE 6.12.111+deb13-amd64 #1 Debian 6.12.111-1
kswapd+0x1f1/0x380
? __pfx_kswapd+0x10/0x10
note: kswapd1[403] exited with irqs disabled
note: kswapd1[403] exited with preempt_count 3
rewind_stack_and_make_dead+0x16/0x20

Escalation follows: within 20-60 seconds after the initial Oops, the
Tainted flags escalate G OE -> G D OE -> G D W OE -> G D W OEL, and
soft-lockups begin on most CPUs (RCU grace periods, migration threads,
KVM vCPU threads all stuck). The system becomes completely unresponsive
to non-BMC traffic. Only hardware reset recovers.

HARDWARE CONFIGURATION:

Host A: Supermicro X12DPL-NT6, BIOS 2.5, 2x Xeon Silver 4310 (48 CPUs,
NUMA), 256 GB RAM, NVIDIA RTX 5060 Ti (nvidia 595.99.02)
Host B: Supermicro X12DPL-NT6, BIOS 2.5, 2x Xeon Silver 4310, 256 GB RAM,
NVIDIA RTX 5060 Ti
Host C: Supermicro A2SDV-12C+-TLN5F, BIOS 2.0, Atom C3858 (12 CPUs,
single-socket), 64 GB RAM, no GPU/NVIDIA module
Host D: Supermicro A2SDV-12C+-TLN5F, BIOS 2.0, Atom C3858, 64 GB RAM,
no GPU/NVIDIA module

Note: Host C (Atom C3858, no NVIDIA module) also crashes, which
refutes "Tainted: G OE (NVIDIA out-of-tree module)" as the cause.
The crash is a kernel bug, not a driver issue.

WORKLOAD TRIGGER:

- Daily 02:00: AIDE --update (file integrity scan)
- Daily 02:00-03:00: rsync backups via GlusterFS to NAS
- Daily 03:00: apt autoremove purge of removed packages
- Weekly 03:10 (Sundays): xfs_scrub_all
- Ongoing: 5-11 qemu-system-x86 VMs per host (libvirt/qemu-kvm),
several VMs under memory pressure (Galera/MariaDB VMs,
Kubernetes nodes, mail VMs, etc.)

REGRESSION CONFIRMED:

Pinning all four hosts to linux-image-6.12.107+deb13-amd64 via
apt-mark hold makes the system stable indefinitely. linuxhost1 (Host C,
Atom C3858) crashed on 6.12.111 within 4 hours of boot, but has been
stable on 6.12.107 for 20+ hours at the time of this report.

DIAGNOSTIC NOTES:

- The crash address (0x8) is consistent across all three crash hosts,
different CPUs, different NUMA nodes, and different hardware
platforms (Xeon and Atom). This strongly suggests a software race
in the reclaim path, not a hardware defect.
- No MCE/EDAC errors in /var/log/mcelog or dmesg at the time of the
crash - confirmed hardware is not the cause.
- Pre-crash on one host: 10+ 'task:worker state:D stack:0' messages
from TGID 4799 (likely glusterfsd worker), indicating IO-stall
precedes the crash by ~4 hours. This suggests the bug is triggered
when reclaim attempts to free inodes whose backing IO is stalled.

LIKELY AFFECTED CODE PATH (subject to maintainer review):

shrink_inactive_list -> shrink_inode_list -> inode_lru_isolate
-> pagevec_lookup_range_tag -> pagevec_release -> BUG

CONFIGURATION:

- intel-microcode 3.20251111.1~deb13u1
- Standard Debian 13 qemu-kvm/libvirt setup
- GlusterFS 11 with 8 volumes distributed across all 4 hosts

ATTACHMENTS:

- BMC iKVM console capture showing the Oops with
RIP in kswapd+0x1f1/0x380 and rewind_stack_and_make_dead
- journal output showing pre-crash D-State workers and the Oops
- journal output of post-downgrade reboot (no Oops, clean boot)
- Tainted-flag escalation timeline observed in journal

CONTACT:

Michael Schefczyk <michael@schefczyk.net>
Debian 13 (trixie) administrator, small private infrastructure with
four KVM hosts running production services.

Reporter does NOT have kdump configured; reproduction with kdump
requires re-enabling 6.12.111 on a non-critical host.

REQUEST:

Please confirm whether this is reproducible against vanilla 6.12.111
without Debian patches, and consider pinning 6.12.107 in trixie until
a fix is backported.