CVE-2026-64378

What it actually does

This is a Linux kernel race condition in the writeback/cgroup writeback path during filesystem unmount and inode writeback ownership switching. A local actor who can cause container teardown, cgroup writeback activity, and filesystem unmount timing can trigger a window where an inode is retained past superblock shutdown. The kernel may then hit a BUG_ON condition for busy inodes after unmount or later access destroyed per-CPU accounting structures, creating a use-after-free condition. Practical impact is primarily local kernel crash/denial of service, with potential for kernel memory corruption and privilege escalation depending on kernel configuration, allocator behavior, and exploit reliability.

Why it matters to the business

Systems running affected Linux kernels may be vulnerable to local attacks that crash the host kernel or potentially allow a local user or containerized workload to gain elevated privileges. The operational risk is highest for multi-tenant container hosts, CI/CD runners, Kubernetes nodes, build systems, and platforms where untrusted or semi-trusted workloads can create I/O pressure and trigger container or mount teardown. Although EPSS is currently low and there is no known CISA KEV listing or public exploit maturity indicated, kernel race flaws can become more serious if reliable exploit techniques are later published.

How an attack unfolds

An attacker first needs local code execution, such as access to a shell, a compromised service account, or the ability to run a container workload. The attacker then creates conditions that exercise cgroup writeback and inode writeback switching while a filesystem or container-associated mount is being unmounted. By repeatedly racing container exit or mount teardown against writeback activity, the attacker attempts to hit the timing window between inode_prepare_wbs_switch() and wb_queue_isw(). If successful, unmount processing may conclude that there are no pending writeback switch operations and proceed to evict inodes and destroy superblock resources while a referenced inode is still in flight. This can trigger a kernel BUG with busy inodes after unmount, causing a system crash, or later result in use-after-free behavior when delayed writeback switch work releases the inode and touches freed accounting structures.

How to fix it

Apply vendor kernel updates that include the upstream fix for the writeback race between cgroup_writeback_umount() and inode_switch_wbs()/cleanup_offline_cgwb(). The fix extends the RCU read-side critical section around inode writeback switch queuing and adds synchronize_rcu() during cgroup writeback unmount handling so queued work is visible before the workqueue is flushed. No exact fixed package versions were provided in the input, so use distribution advisories for the deployed kernel branch and update to the first fixed kernel or later. Where immediate patching is not possible, reduce exposure by limiting local shell access, restricting untrusted container execution, enforcing least-privilege container profiles, avoiding privileged containers, and scheduling restarts of high-risk multi-tenant nodes after patching. Mitigations should be treated as temporary because the vulnerable code is in the kernel and cannot be reliably neutralized from user space.

How to confirm the fix worked

Confirm the running kernel has been updated to a vendor build that contains the fix for this race. Validate by checking the distribution kernel changelog, security advisory, or source package for references to the writeback/cgroup_writeback_umount race fix, synchronize_rcu() in cgroup_writeback_umount(), or expanded rcu_read_lock() coverage in inode_switch_wbs() and cleanup_offline_cgwb(). After patching and rebooting, verify the active kernel version with standard OS tooling and ensure no hosts remain booted into an older vulnerable kernel. For exposure assessment, identify Linux systems that run containers, use cgroups, and allow local or workload-level code execution. Stability validation can include monitoring for absence of recurring kernel BUG/Oops messages involving generic_shutdown_super, cgroup_writeback_umount, inode_switch_wbs, and busy inodes after unmount during container stop/start stress testing.

Typical attack path

1. Obtain local execution on a Linux system, commonly through an unprivileged account, compromised service, or container workload.
2. Generate filesystem writeback activity tied to cgroups or containers, such as repeated file writes and dirty-page pressure.
3. Repeatedly start and stop containers or otherwise trigger cgroup cleanup and filesystem unmount paths.
4. Race cgroup_writeback_umount() against inode_switch_wbs() or cleanup_offline_cgwb() so that inode writeback switching is in flight during unmount.
5. Cause the kernel to retain an inode reference past superblock shutdown, triggering a BUG_ON crash or a later use-after-free condition.
6. Leverage the result for denial of service, or, if a reliable memory-corruption exploit is developed, attempt kernel privilege escalation.

How to detect it

Look for evidence of kernel crashes or memory-safety faults around container shutdown, cgroup cleanup, filesystem unmount, and writeback activity. Primary log sources include kernel ring buffer output, /var/log/kern.log, /var/log/messages, systemd journal kernel facility logs, crash dump metadata, vmcore analysis, container runtime logs, Kubernetes node events, and hypervisor or cloud serial console logs. Search for BUG/Oops traces containing generic_shutdown_super, cgroup_writeback_umount, inode_switch_wbs, cleanup_offline_cgwb, wb_queue_isw, inode_switch_wbs_work_fn, process_inode_switch_wbs, ext4_kill_sb, or messages about busy inodes after unmount. Also review unexplained node reboots, kernel panics, containerd-shim involvement near the time of the crash, and repeated workload patterns that rapidly create dirty files and terminate containers. A single matching crash may be accidental because the bug is a race, but repeated crashes correlated with a specific local user, container image, job, or workload should be investigated as possible exploitation or exploit testing.

• VFS: Busy inodes after unmount
• kernel BUG at fs/super.c:695
• generic_shutdown_super
• cgroup_writeback_umount
• inode_switch_wbs
• cleanup_offline_cgwb
• inode_prepare_wbs_switch
• wb_queue_isw
• inode_switch_wbs_work_fn
• process_inode_switch_wbs
• percpu_counter_dec
• ext4_kill_sb
• kill_block_super
• deactivate_locked_super
• cleanup_mnt
• containerd-shim
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• KASAN: use-after-free
• Kernel panic - not syncing

What your security team should do

• Prioritize patching container hosts, Kubernetes nodes, CI runners, build workers, shared development hosts, and any Linux systems that run untrusted or semi-trusted local workloads.
• Track vendor advisories for the deployed Linux distribution and kernel branch, then upgrade to a fixed kernel and reboot to activate it.
• Search historical kernel logs, persistent journal data, hypervisor console logs, and crash dumps for BUG/Oops traces matching this flaw.
• Temporarily reduce risk by limiting who can run containers or local workloads, disabling privileged containers where possible, and enforcing seccomp, AppArmor, SELinux, and container runtime hardening profiles.
• Increase monitoring for kernel crashes, node reboots, containerd-shim-related crashes, and repeated container teardown activity combined with filesystem write pressure.
• If matching crash signatures are found on shared or multi-tenant hosts, treat them as potentially suspicious and preserve logs, vmcore dumps, container runtime metadata, and workload provenance for investigation.
• Because there is no KEV listing, no ransomware association, and no public exploit maturity indicated, handle as important but not currently internet-scale urgent unless local multi-tenant exposure is high.