Same signature here, on 22.04 with the 6.8 HWE kernel, and I have
minute-resolution metrics through the whole event that may help with the
"no reproducible trigger" problem.
Hardware: Lenovo ideacentre 200-01IBW, RTL8821AE (rtl8821ae / rtl_pci /
rtlwifi / btcoexist), Bluetooth on the same combo chip via btusb+btrtl.
Kernel 6.8.0-138-generic, Ubuntu 22.04.
The machine had been up 8 days with node_exporter scraping /proc/meminfo
every 15s into Prometheus. On 2026-09-19 at 12:53:28 the kernel logged:
UBSAN: array-index-out-of-bounds in
.../rtlwifi/btcoexist/halbtc8821a2ant.c:3968:36
Workqueue: rtl8821ae_pci rtl_c2hcmd_wq_callback [rtlwifi]
rtl_btc_btinfo_notify+0x1d/0x40 [btcoexist]
rtl_c2h_content_parsing.isra.0+0x66/0x110 [rtlwifi]
rtl_c2hcmd_wq_callback+0x3c/0x80 [rtlwifi]
UBSAN: invalid-load in .../halbtc8821a2ant.c:1150:11
Five traces, all in the same workqueue. What follows is the part I think is
new: from that exact second, SUnreclaim begins growing without bound and
never stops.
12:50:00 SUnreclaim 172.0 MiB (flat at this value for the whole 8-day
boot)
12:51:00 SUnreclaim 172.0 MiB
12:52:00 SUnreclaim 172.0 MiB
12:53:00 SUnreclaim 172.0 MiB
12:54:00 SUnreclaim 178.4 MiB +6.4 <-- UBSAN logged at 12:53:28
12:55:00 SUnreclaim 188.7 MiB +10.3
12:56:00 SUnreclaim 200.4 MiB +11.6
12:57:00 SUnreclaim 212.1 MiB +11.8
... ~+12 MiB/min, dead linear, never plateaus
21:30:00 SUnreclaim 7438 MiB (of 7852 MiB total)
The first sample after the fault is +6.4 MiB, i.e. 53% of a full minute's
growth, which puts the onset at ~12:53:28 - the same second as the UBSAN
trap. Growth rate was constant at ~12 MiB/min for 8h37m.
Because the leak is unreclaimable *kernel slab*, the machine does not OOM,
it livelocks, which I think is why this is reported as "crashes"/"halts"
rather than as a memory leak:
- Page cache was squeezed from 4.8 GB to 45 MiB; AnonPages fell to 77 MiB.
- Swap only reached 69% and stalled - there was nothing swappable left, and
the leak itself can never be swapped.
- The kernel OOM killer never fired at all.
- systemd-oomd fired repeatedly and achieved nothing. It killed qbittorrent,
then all 26 processes of gnome-shell, then 17 IBus processes, and pressure
went UP after each one: 54.06% -> 57.03% -> 77.46% -> 77.98% -> 76.50%.
No userspace process holds this memory, so there is nothing useful to kill.
- iowait hit 75% as every page fault became a major fault (143 MB/s read).
- journald's own timestamps went out of order near the end, then logging
stopped at 21:50:21. No panic, no oops, no shutdown - the box simply
stopped responding and needed a physical power cycle, ~8h57m after the
UBSAN.
If it helps with bisection: the trigger appears to be whatever BT_INFO C2H
message content drives that index past the end of the u8[10]. There is
precedent for this code path leaking skbs - commit 8cfa272b0d32 ("rtlwifi:
Fix leak of skb when processing C2H_BT_INFO", 4.20) fixed an earlier leak in
rtl_c2hcmd_enqueue() on the rtl_c2h_fast_cmd() path. That fix is obviously
long since in 6.8, so this is a different instance, but an unfreed skb per
BT_INFO message would produce exactly the constant-rate slab growth above.
Workaround that appears to hold: I disabled the Bluetooth side of the combo
chip, which stops BT_INFO C2H messages being generated at all.
printf 'blacklist btusb\nblacklist btrtl\n' | sudo tee
/etc/modprobe.d/blacklist-bluetooth.conf
sudo systemctl disable --now bluetooth.service
sudo modprobe -r btusb
After this, hci0 is gone and rfkill lists no Bluetooth device. btcoexist
stays loaded - rtl8821ae has a hard symbol dependency on it and cannot be
unloaded while WiFi is up - but with no BT radio there is nothing for it to
parse. I cannot yet claim this is a fix; the leak only fired once in 13 days
of metrics, so it will be weeks before absence of recurrence means anything.
Posting it because the thread currently has no workaround at all.
Happy to supply the full Prometheus series, the complete journalctl for the
boot, or to run any instrumented kernel against this hardware. I have the
machine under a 5-minute SUnreclaim watchdog now, so if it recurs I will
capture slabtop output during the leak and post the exact cache name, which
should settle the mechanism.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2097693
Title:
Occasional crashes referencing btcoexist
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2097693/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
