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 Ubuntu
Bugs, which is subscribed to 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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-hwe-6.8/+bug/2122445/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
