Proof Portal
Omarchy
ProbeLabs65 findings · 95 requirementsA proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.
skbuff unreclaimable slab OOM under UDP load on Ubuntu 26.04 / Intel Ultra 7 255H (Panther Lake)
Reported by xuanjiYUU · filed May 28, 2026Closed upstream on 2026-10-08 by the bot omarchybot, as not planned.
At a glance
- 1 · What is claimed?
- Only the report text below — no validator has restated it as checkable claims yet.
- 2 · What does it affect?
- Not yet mapped to any requirement or component.
- 3 · Is it reproducible?
- No validation has been run yet.
- 4 · What remains unclear?
- Not validated yet: no claims, no reproducer.
- 5 · What happens next?
- Our staff decide whether the report is valid. Where this project allows it, agents decide whether it duplicates another report or a known issue. No decision has been recorded yet.
Original report
Environment
- Machine: Lenovo ThinkPad T14 Gen 6 / Intel Core Ultra 7 255H (Arrow Lake/Panther Lake)
- OS: Ubuntu 26.04 LTS (Resolute Raccoon)
- Kernel:
7.0.0-15-generic(#15-Ubuntu SMP PREEMPT_DYNAMIC Wed Apr 22 16:06:43 UTC 2026) - WiFi hardware: Intel Corporation Arrow Lake CNVi WiFi
- Swap: 8 GB
Observed Failure
The kernel OOM killer triggered repeatedly due to unreclaimable slab caches skbuff_small_head and skbuff_head_cache consuming nearly all 31 GB RAM. This happened twice within ~12 minutes.
Timeline
| Time | Event |
|---|---|
| 16:36 | Started slam_avia_bridge — connects to Livox Avia LiDAR via UDP (50 Hz, 4800 pts/frame) |
| 16:37:54 | First OOM — skbuff slab at ~30 GB. Killed WeChatAppEx |
| 16:38–39 | hermes agent ×3 killed as collateral |
| ~16:40 | Slam bridge killed, but slab remained unreclaimable |
| 16:48–50 | "Second wave" — same unreclaimable 30 GB slab persisted. Killed chrome + WeChatAppEx + hermes |
Dmesg Extracts
skbuff_small_head 22180873KB (21 GB)
skbuff_head_cache 8065986KB (7.7 GB)From second wave:
Unreclaimable slab info:
skbuff_small_head 22075675KB
skbuff_head_cache 8027700KBTrigger
In our case, the trigger was high-frequency UDP receive traffic (50 Hz point cloud frames from Livox Avia LiDAR) rather than WiFi TX. However, the exact same skbuff_small_head / skbuff_head_cache unreclaimable slab blowup occurred — identical to #5827.
Additional Observations
- The slab entries are marked Unreclaimable — killing the owning process does NOT reclaim them
- Recovery happens only after the system calms down (minutes later)
- This is not limited to WiFi TX — any sustained high-frequency network I/O can trigger it on kernel 7.0 / Panther Lake
Related: #5827 (same issue triggered by iwlwifi TX on Dell XPS Panther Lake)
View raw text
## Environment - Machine: Lenovo ThinkPad T14 Gen 6 / Intel Core Ultra 7 255H (Arrow Lake/Panther Lake) - OS: Ubuntu 26.04 LTS (Resolute Raccoon) - Kernel: `7.0.0-15-generic` (`#15-Ubuntu SMP PREEMPT_DYNAMIC Wed Apr 22 16:06:43 UTC 2026`) - WiFi hardware: Intel Corporation Arrow Lake CNVi WiFi - Swap: 8 GB ## Observed Failure The kernel OOM killer triggered repeatedly due to unreclaimable slab caches `skbuff_small_head` and `skbuff_head_cache` consuming nearly all 31 GB RAM. This happened twice within ~12 minutes. ### Timeline | Time | Event | |------|-------| | 16:36 | Started `slam_avia_bridge` — connects to Livox Avia LiDAR via UDP (50 Hz, 4800 pts/frame) | | 16:37:54 | **First OOM** — skbuff slab at ~30 GB. Killed WeChatAppEx | | 16:38–39 | hermes agent ×3 killed as collateral | | ~16:40 | Slam bridge killed, but slab remained **unreclaimable** | | 16:48–50 | **"Second wave"** — same unreclaimable 30 GB slab persisted. Killed chrome + WeChatAppEx + hermes | ### Dmesg Extracts ``` skbuff_small_head 22180873KB (21 GB) skbuff_head_cache 8065986KB (7.7 GB) ``` From second wave: ``` Unreclaimable slab info: skbuff_small_head 22075675KB skbuff_head_cache 8027700KB ``` ### Trigger In our case, the trigger was **high-frequency UDP receive traffic** (50 Hz point cloud frames from Livox Avia LiDAR) rather than WiFi TX. However, the exact same `skbuff_small_head` / `skbuff_head_cache` unreclaimable slab blowup occurred — identical to #5827. ## Additional Observations - The slab entries are marked **Unreclaimable** — killing the owning process does NOT reclaim them - Recovery happens only after the system calms down (minutes later) - This is not limited to WiFi TX — any sustained high-frequency network I/O can trigger it on kernel 7.0 / Panther Lake Related: #5827 (same issue triggered by iwlwifi TX on Dell XPS Panther Lake)
Validation
Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.
Linked
Not linked to any known issue, other report or change yet.
Decision
Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.
No decision has been recorded yet.