Two more distinct signatures on the same host, and this time one of them
produced a complete dump.
Host unchanged: MECHREVO M5 / H45, BIOS J002NS4 (2023-08-23), Ubuntu 22.04.5,
`linux-image-6.8.0-138-generic` (6.8.0-138.138~22.04.1, upstream base 6.8.12),
16 GB non-ECC.
MGLRU remains disabled, as in the original report.
## 1. New signature A — `Bad page state`, non-oops, taint only
2026-10-27 13:50:35 CST, `comm=Hermes` (Electron main process), 4 h 57 m
of uptime:
```
BUG: Bad page state in process Hermes pfn:2f9b5c
page: refcount:0 mapcount:131072 mapping:0000000000000000 index:0x34c403cff
pfn:0x2f9b5c
page_type: 0x1ffff()
page dumped because: nonzero mapcount
Call Trace:
bad_page -> free_page_is_bad_report -> free_unref_page_prepare ->
free_unref_page_list
? __mem_cgroup_uncharge_list
release_pages -> free_pages_and_swap_cache -> tlb_batch_pages_flush ->
tlb_finish_mmu
unmap_region -> do_vmi_align_munmap -> do_vmi_munmap -> __mmap_region ->
mmap_region
do_mmap -> vm_mmap_pgoff -> ksys_mmap_pgoff -> __x64_sys_mmap
```
Free path, `refcount:0` but `mapcount:0x20000`, `page_type:0x1ffff`, with
`__mem_cgroup_uncharge_list` on the same stack, coming out of an ordinary
`munmap` inside `mmap`.
Kernel only taints (`TAINT_BAD_PAGE`) and keeps running — no oops, so no dump
for this one.
Full log attached (`bad-page-state-20261027.log`).
## 2. New signature B — NULL dereference in `__lruvec_stat_mod_folio`,
with a full stack
2026-10-27 19:03:09.63 CST, 4 h 38 m of uptime, process exit path:
```
BUG: kernel NULL pointer dereference, address: 0000000000000610
#PF: supervisor read access in kernel mode #PF: error_code(0x0000) -
not-present page
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 2 PID: 45798 Comm: ThreadPoolForeg Not tainted 6.8.0-138-generic
#138~22.04.1-Ubuntu
RIP: 0010:__lruvec_stat_mod_folio+0x57/0xc0
RAX: ffff8e8f94038000 RBX: fffff84d0be68f80 RDX: 0000000000000000
RDI: 0000000000000000 RSI: 0000000000000011 R14: ffff8e92ffbd5000
Call Trace:
folio_remove_rmap_ptes+0x78/0xe0
zap_pte_range+0x245/0xc30
zap_pmd_range.isra.0+0x120/0x280
unmap_page_range+0x287/0x500
unmap_single_vma -> unmap_vmas -> exit_mmap -> __mmput -> mmput -> exit_mm
-> do_exit -> do_group_exit -> get_signal
Kernel panic - not syncing: Fatal exception
```
`panic_on_oops=1` / `panic=10` are set on this host, so this one was written to
EFI pstore
(12 records, decoded digest attached as `panic-1903-pstore-digest.log`). The
2026-10-20 crash
already came with a pstore dump (attached earlier); this is the first dump for
this particular
signature, the `__lruvec_stat_mod_folio` / rmap-removal face of it. Note event
3 in the original
report was the same RIP with a garbage `R14`; here the same site resolves to
NULL instead.
Reading it against `mm/memcontrol.c` (v6.8.12) — the function is out-of-line,
so this is a real
frame, not an inlined site:
```c
void __lruvec_stat_mod_folio(struct folio *folio, enum node_stat_item idx, int
val)
{
pg_data_t *pgdat = folio_pgdat(folio);
...
memcg = folio_memcg(folio);
/* Untracked pages have no memcg, no lruvec. Update only the node */
if (!memcg) {
rcu_read_unlock();
__mod_node_page_state(pgdat, idx, val);
return;
}
lruvec = mem_cgroup_lruvec(memcg, pgdat);
__mod_lruvec_state(lruvec, idx, val);
rcu_read_unlock();
}
```
Two facts follow from that and the registers:
- The `!memcg` case returns early and never touches a lruvec. We are past it,
so **`folio_memcg()`
was non-NULL** — the folio did carry a `memcg_data` pointer, and it was the
wrong kind of pointer.
- The faulting instruction is `mov 0x610(%rdi),%r14` with `RDI = 0`, and R14 is
the value compared
immediately after, i.e. the `pgdat` in `if (unlikely(lruvec->pgdat !=
pgdat))` inside
`mem_cgroup_lruvec()`. So the lruvec used by that access was derived from a
NULL per-node
structure for the memcg that `memcg_data` pointed at, on a folio that still
had rmap entries
(we are removing them). I don't have the `-dbgsym` build here to confirm the
struct offsets from
the disassembly, so treat the mapping as my reading rather than established —
the register dump
is what matters.
Two details that may matter:
- `Not tainted`, and no `Bad page state` anywhere earlier in that boot: 4 h 38
m clean, then this.
So in this shape there is **no precursor in dmesg at all** — the accounting
is already broken
by the time anything is printed.
- `RAX = ffff8e8f94038000` is the pointer taken from the folio, i.e. it is not
a NULL
`memcg_data`; it is a `memcg_data` that does not lead to a usable per-node
structure.
## 3. What this adds up to on this host
These two bring it to five manifests, all in mm page accounting, all reached
from ordinary
user-space paths (`munmap` inside `mmap`, process exit / mm teardown):
| # | Signature | Path | Outcome |
|---|---|---|---|
| 1–2 (original report) | GPF in `uncharge_folio`; `lru_size` underflow |
process exit, reclaim | oops / cosmetic |
| 3 (original report) | GPF on LIST_POISON in `rmqueue_bulk`; garbage in
`__lruvec_stat_mod_folio` | PCP list, rmap stat | oops |
| 4 (this comment, §1) | `Bad page state`, nonzero mapcount | free path during
`munmap` | taint only |
| 5 (this comment, §2) | NULL in `__lruvec_stat_mod_folio` | `exit_mmap` → rmap
removal | panic |
## Questions
1. A non-NULL `memcg_data` that does not lead to a usable per-node structure
(`node_id == 0`,
single node here) — is that something you'd expect from a stale/dangling
memcg pointer, or is
there a legitimate window where it can happen?
2. I can A/B a mitigation on this host and report the result either way: boot
with
`cgroup_disable=memory` (does the failure disappear when the memory
controller is off?) versus
`6.8.0-136-generic` (is this a -138 regression?). Say if you'd rather I not
change the kernel
cmdline mid-triage.
3. If you want the same treatment (armed probes + pstore dump) for the
`uncharge_folio` GPF face,
I can capture the next occurrence; currently I only have the 2026-10-20
pstore dump for it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2171572
Title:
mm/memcg: repeated general protection fault in uncharge_folio +
lru_size underflow on 6.8.0-138 (jammy HWE), independent of MGLRU
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2171572/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
