Did a little more work.
Where it dies
Faulting IP: kmem_cache_alloc+0xce → exact symbolized site is
kmem_cache_alloc+206 (xor (%rax),%rbx) — the hardened-freelist decode of the
“next” pointer.
Evidence: sym 0xffffffff8be680de → kmem_cache_alloc+206; dis -l
0xffffffff8be680de 32 shows:
(some perl)
add %rdi,%rax ; rax = head + s->offset
xor (%rax),%rbx ; fault here: read encoded "next" from head+offset
bswap %rcx
xor %rcx,%rbx
cmpxchg16b %gs:(%rsi) ; would be the fast cmpxchg path, not deactivate_slab
So we fault before cmpxchg16b, in the freelist decode.
Registers at fault (from crash backtrace)
RIP = ffffffff8be680de (kmem_cache_alloc+206)
RDI = 0x7db1e063bbff01b3 ← c->freelist (head)
RAX = 0x7db1e063bbff01e3 ← head + offset (offset is 0x30)
RBX = 0x3faeeb682cd28284 ← cache->random
R12 = 0xffff9e1ec02b0d00 ← kmem_cache (buffer_head)*
This exactly matches SLUB’s hardening math: load head, compute head +
s->offset, then XOR the encoded word at [head+offset] with random and
swab(head) to decode next. The deref of [head+offset] faults because
head isn’t a valid kernel address.
Cache / object info (from vmcore)
Cache: buffer_head, object_size=104 (0x68), size=104, offset=0x30,
random=0x3faeeb682cd28284.
Evidence: struct kmem_cache 0xffff9e1ec02b0d00, plus p of fields.
Per-CPU vs slab state (inconsistent)
kmem_cache_cpu @ 0xffff9e222fc3dc60:
freelist = 0x7db1e063bbff01b3, slab = 0xffffe28e400dde80.
slab @ 0xffffe28e400dde80:
freelist=0x0, inuse=39, objects=39, frozen=1 (i.e. full and frozen).
→ Contradiction: per-CPU says there’s a freelist head (and it’s a non-kernel
address), while the slab it points to is full/frozen with no freelist.
Call path / workload
Process: PID 15336 "JTS-uscryptoLis".
Stack tail: alloc_buffer_head → folio_alloc_buffers →
create_empty_buffers → ext4_block_write_begin → ext4_da_write_begin →
vfs_write.
System activity right before: very frequent drm_atomic_* flips from
virtio_gpu/virgl (as noted in logs).
Conclusion so far
Looks like a per-CPU freelist corruption for the buffer_head cache:
c->freelist itself held a bogus, non-canonical pointer (0x7db1...),
leading to a fault when decoding next from [head + 0x30].
It’s not the deactivate_slab path and not a benign race: the cmpxchg
region isn’t reached; IRQs are controlled around the fastpath; and
c->slab is full/frozen while c->freelist is non-NULL and not a valid
kernel address.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-hwe-6.8 in Ubuntu.
https://bugs.launchpad.net/bugs/2122445
Title:
Jammy HWE 6.8.0-79 in KVM/QEMU guest (virtio_gpu/virgl): kernel oops
“Bad pagetable: 000d” in do_user_addr_fault while running Java
AWT/JavaFX GUI
Status in linux-hwe-6.8 package in Ubuntu:
New
Bug description:
A KVM/QEMU guest on Ubuntu 22.04 (Jammy, HWE kernel 6.8.0-79-generic)
hits a kernel oops with “Bad pagetable: 000d” while a Java GUI
(AWT/JavaFX) is active. Kdump triggers and captures a vmcore. First
noticed after updating to 6.8.0-79; comparison with 6.8.0-78 is
pending (I will test -78 next and report back).
Environment
- Guest OS: Ubuntu 22.04.4 (Jammy) with HWE kernel 6.8.0-79-generic
- Virtualization: KVM/QEMU, machine type Q35
- Guest GPU: virtio GPU [1af4:1050] (virgl, 3D accel forced to drive
5120x1440 monitor)
- Mesa stack in guest: 23.2.1-1ubuntu3.1~22.04.3
- glxinfo -B shows: vendor Mesa; renderer “virgl (AMD Radeon Graphics
(radeonsi, raphael_mendocino, …))”
- lspci: “00:01.0 VGA compatible controller: Red Hat, Inc. Virtio GPU
[1af4:1050]”
- Kernel cmdline (guest):
workqueue.default_to_unbound=1 console=ttyS0,115200n8 console=tty0 panic=10
loglevel=7 systemd.show_status=1 drm.debug=0x1e crashkernel=512M-:192M
Symptom / oops signature
- Console shows:
- “AWT-EventQueue-: Corrupted page table at address 8038358c”
- “Bad pagetable: 000d [#1] PREEMPT SMP NOPTI”
- Oops path from vmcore (crash(8)):
pgtable_bad → do_user_addr_fault → exc_page_fault → asm_exc_page_fault →
crash_kexec
- Example PTE that triggered:
PTE 0x8000000299d39867 → PHYS 0x299d39000 FLAGS:
PRESENT|RW|USER|ACCESSED|DIRTY|NX
- Task at oops time:
PID 11858, COMM "AWT-EventQueue-" (JVM GUI thread)
- Hardware banner in oops:
“QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2”
Frequency / workload
- Reproduced under interactive GUI load in the VM (Java AWT/JavaFX
application). Prior lines in dmesg show frequent DRM atomic FB flips from
virtio_gpu while the desktop/app is active.
What I collected
- kdump vmcore + dmesg from crash (vmcore:
/var/crash/202509090957/dump.202509090957; dmesg saved)
- guest serial console log and QMP event log from the host during the incident
- full kernel command line and module list, Mesa/GLx info, and lspci output
What I’m about to try
- Boot the same guest with 6.8.0-78-generic (vmlinuz.old/initrd.img.old) to
determine if this is a 6.8.0-79 regression or not; I will update the bug with
results.
- If requested, I can also try a -proposed HWE build for confirmation.
Questions for triage
- Does this look like a kernel-side virtio_gpu/DRM/MM issue vs. a userspace
virglrenderer trigger?
- Any known fixes in later 6.8 HWE updates that match this signature?
Tags (suggested): jammy hwe kernel oops kdump kvm qemu virtio-gpu drm virgl
mesa
Attachments available on request:
- vmcore + dmesg from kdump
- guest journal/dmesg around the oops
- serial console log and QMP events from host
- `glxinfo -B`, `lspci -nnk`, `/proc/cmdline`
ProblemType: Bug
DistroRelease: Ubuntu 22.04
Package: linux-image-6.8.0-79-generic 6.8.0-79.79~22.04.1
ProcVersionSignature: Ubuntu 6.8.0-79.79~22.04.1-generic 6.8.12
Uname: Linux 6.8.0-79-generic x86_64
ApportVersion: 2.20.11-0ubuntu82.10
Architecture: amd64
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: joes 1455 F.... pulseaudio
CRDA: N/A
CasperMD5CheckResult: pass
CurrentDesktop: ubuntu:GNOME
Date: Tue Sep 9 13:25:08 2025
InstallationDate: Installed on 2025-07-21 (49 days ago)
InstallationMedia: Ubuntu 22.04.5 LTS "Jammy Jellyfish" - Release amd64
(20240911)
IwConfig:
lo no wireless extensions.
enp1s0 no wireless extensions.
Lsusb:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Lsusb-t:
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M
|__ Port 1: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid,
480M
MachineType: QEMU Standard PC (Q35 + ICH9, 2009)
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcFB: 0 virtio_gpudrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-79-generic
root=UUID=e7a3ebd8-b568-463d-96c4-cf8270ba34d3 ro
workqueue.default_to_unbound=1 console=ttyS0,115200n8 console=tty0 panic=10
loglevel=7 systemd.show_status=1 drm.debug=0x1e crashkernel=512M-:192M
RelatedPackageVersions:
linux-restricted-modules-6.8.0-79-generic N/A
linux-backports-modules-6.8.0-79-generic N/A
linux-firmware 20220329.git681281e4-0ubuntu3.39
RfKill:
SourcePackage: linux-hwe-6.8
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/01/2014
dmi.bios.release: 0.0
dmi.bios.vendor: SeaBIOS
dmi.bios.version: 1.16.3-debian-1.16.3-2
dmi.chassis.type: 1
dmi.chassis.vendor: QEMU
dmi.chassis.version: pc-q35-8.2
dmi.modalias:
dmi:bvnSeaBIOS:bvr1.16.3-debian-1.16.3-2:bd04/01/2014:br0.0:svnQEMU:pnStandardPC(Q35+ICH9,2009):pvrpc-q35-8.2:cvnQEMU:ct1:cvrpc-q35-8.2:sku:
dmi.product.name: Standard PC (Q35 + ICH9, 2009)
dmi.product.version: pc-q35-8.2
dmi.sys.vendor: QEMU
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-hwe-6.8/+bug/2122445/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
