## Update: Bug 2151273 - `path_is_under()` crash is NOT Docker-specific ### Summary
After further vmcore analysis and additional crash observations, this bug is **not specific to Docker or overlayfs**. The root cause appears to be in the VFS mount tree traversal layer, triggered by mount namespace operations that leave the mount tree in a corrupted state. ### Additional Crash Observations Two additional crash scenarios have been identified with **identical call stacks** (`path_is_under+0x50` → `complete_walk` → `do_open` → `path_openat`): #### Crash #1: `python` process (Docker-related) - **Time:** ~980s after boot - **PID:** 40380 - **RAX:** `f04180000041fce0` (corrupted mount pointer) - **Trigger:** Docker container operations #### Crash #2: `fc-cache` process (early boot) - **Time:** ~24s after boot - **PID:** 8019 - **RAX:** `d9154c20ffffd404` (different corrupted value) - **Trigger:** `fc-cache` font cache update during system startup **Key:** Both crashes occurred at `path_is_under+0x50` while traversing the mount chain. The corrupted RAX values differ, indicating a **use- after-free or memory corruption** in `struct mount` rather than a deterministic NULL pointer. ### Critical Pre-crash Event (fc-cache crash) Immediately before the fc-cache crash: ``` [ 23.950898] snap-update-ns.desktop-security-center: mount bind DENIED (apparmor) [ 24.838372] fc-cache: Oops path_is_under+0x50 ``` **This is significant:** The snap `mount` operation was **denied by apparmor**, yet the mount tree appears to have been left in an inconsistent state. The subsequent `fc-cache` `openat()` traversed this corrupted mount chain and crashed. ### Root Cause Hypothesis (Updated) 1. **Mount namespace operations** (bind mounts, overlayfs setup, etc.) partially modify the mount tree 2. If the operation is interrupted or denied (e.g., by apparmor), the mount tree cleanup/rollback may be incomplete 3. A dangling or corrupted `struct mount` node remains in the mount tree 4. Any subsequent `open()`/`openat()` syscall that triggers `path_is_under()` will traverse the mount chain and hit the corrupted node 5. The specific process that crashes is arbitrary — it can be `python`, `git`, `fc-cache`, or any other process doing file operations ### Implications - **Docker is not the root cause** — it is merely one of many ways to create complex mount trees - **Switching Docker storage drivers (overlay2 → vfs) will NOT fix this** - **The bug affects all filesystem operations** once the mount tree is corrupted, including normal ext4 file access - The trigger is likely in the **mount namespace setup/teardown logic** or its interaction with **apparmor mount mediation** ### Recommended Investigation Direction Upstream should investigate: 1. Mount tree consistency during failed/aborted mount operations 2. Apparmor mount denial paths that may leave partial mount state 3. `struct mount` reference counting in mount namespace clone/ teardown paths 4. Whether `mnt->mnt_parent` pointers are validated before traversal in `path_is_under()` ### Vmcore Analysis Details Full vmcore analysis performed with `crash` utility on kernel `7.0.0-15-generic` debug symbols. Key findings: - `nd->path.mnt` contains a non-canonical address when passed to `path_is_under()` - `search -k` of corrupted addresses finds only kdump-saved `pt_regs` structures, confirming the corruption is localized to the stack `struct nameidata` - The `struct mount` at `RAX` is not in any slab cache, suggesting it may have been freed or never properly initialized -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2151273 Title: Kernel panic in path_is_under() at fs/namespace.c when running Docker containers on Ubuntu 26.04 with kernel 7.0.0 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2151273/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
