In the Linux kernel, the following vulnerability has been resolved: writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs()… (CVE-2026-64378)
In the Linux kernel, the following vulnerability has been resolved: writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs() When a container exits, the following BUG_ON() is occasionally triggered: ================================================================== VFS: Busy inodes after unmount of sdb (ext4) ------------[ cut here ]------------ kernel BUG at fs/super.c:695! CPU: 3 PID: 6 Comm: containerd-shim Tainted: G OE K 6.6 #1 pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : generic_shutdown_super+0xf0/0x100 lr : generic_shutdown_super+0xf0/0x100 Call trace: generic_shutdown_super+0xf0/0x100 kill_block_super+0x20/0x48 ext4_kill_sb+0x28/0x60 deactivate_locked_super+0x54/0x130 deactivate_super+0x84/0xa0 cleanup_mnt+0xa4/0x140 __cleanup_mnt+0x18/0x28 task_work_run+0x78/0xe0 do_notify_resume+0x204/0x240 ================================================================== The root cause is a race between cgroup_writeback_umount() and inode_switch_wbs()/cleanup_offline_cgwb(). There is a window between inode_prepare_wbs_switch() returning true and the subsequent wb_queue_isw() call. Following is the process that triggers the issue: CPU A (umount) | CPU B (writeback) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ inode_switch_wbs/cleanup_offline_cgwb atomic_inc(&isw_nr_in_flight) inode_prepare_wbs_switch -> passes SB_ACTIVE check __iget(inode) generic_shutdown_super sb->s_flags &= ~SB_ACTIVE cgroup_writeback_umount(sb) smp_mb() atomic_read(&isw_nr_in_flight) rcu_barrier() -> no pending RCU callbacks flush_workqueue(isw_wq) -> nothing queued, returns evict_inodes(sb) -> Inode skipped as isw still holds a ref. sop->put_super(sb) /* destroys percpu counters */ -> VFS: Busy inodes after unmount! wb_queue_isw() queue_work(isw_wq, ...) /* later in work function */ inode_switch_wbs_work_fn process_inode_switch_wbs iput() -> evict percpu_counter_dec() // UAF! Fix this by extending the RCU read-side critical section in inode_switch_wbs() and cleanup_offline_cgwb() to cover from inode_prepare_wbs_switch() through wb_queue_isw(). Since there is no sleep in this window, rcu_read_lock() can be used. Then add a synchronize_rcu() in cgroup_writeback_umount() before the existing rcu_barrier(), so that all in-flight switchers that have passed the SB_ACTIVE check have completed queue_work() before flush_workqueue() is called. The existing rcu_barrier() is intentionally retained so this fix can be backported unchanged to stable kernels (5.10.y, 6.6.y, ...) that still queue switches via queue_rcu_work(). It is a no-op on current mainline (since commit e1b849cfa6b6 ("writeback: Avoid contention on wb->list_lock when switching inodes")) and is removed in a follow-up patch.
AI Analysis
Technical Summary
This vulnerability in the Linux kernel involves a race condition between cgroup_writeback_umount() and inode_switch_wbs()/cleanup_offline_cgwb() functions. When a container exits, a kernel BUG_ON() may be triggered due to busy inodes after unmounting an ext4 filesystem. The race occurs because there is a window between inode_prepare_wbs_switch() returning true and the subsequent wb_queue_isw() call, leading to a use-after-free scenario during inode reference counting and eviction. The fix involves extending the RCU read-side critical section to cover the entire window and adding a synchronize_rcu() call in cgroup_writeback_umount() to ensure all in-flight switchers complete before flush_workqueue() is called. This fix is designed to be backported to stable kernels and removes the race condition without impacting normal operation.
Potential Impact
The vulnerability can cause kernel crashes (BUG_ON) due to busy inodes after unmount, which may lead to system instability or denial of service. The root cause is a race condition that can result in use-after-free during inode reference handling in the writeback subsystem. There is no indication of privilege escalation or data corruption beyond system instability. No known exploits in the wild have been reported.
Mitigation Recommendations
A fix for this race condition has been implemented in the Linux kernel by extending RCU critical sections and adding synchronization calls to ensure proper ordering during unmount operations. Users should apply the official kernel updates that include this fix. Since no affected versions or patch links are provided, check the vendor or Linux kernel mailing lists for the relevant stable kernel updates (including 5.10.y, 6.6.y, and later). Patch status is not yet confirmed — check the vendor advisory for current remediation guidance.
In the Linux kernel, the following vulnerability has been resolved: writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs()… (CVE-2026-64378)
Description
In the Linux kernel, the following vulnerability has been resolved: writeback: fix race between cgroup_writeback_umount() and inode_switch_wbs() When a container exits, the following BUG_ON() is occasionally triggered: ================================================================== VFS: Busy inodes after unmount of sdb (ext4) ------------[ cut here ]------------ kernel BUG at fs/super.c:695! CPU: 3 PID: 6 Comm: containerd-shim Tainted: G OE K 6.6 #1 pstate: 63400009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : generic_shutdown_super+0xf0/0x100 lr : generic_shutdown_super+0xf0/0x100 Call trace: generic_shutdown_super+0xf0/0x100 kill_block_super+0x20/0x48 ext4_kill_sb+0x28/0x60 deactivate_locked_super+0x54/0x130 deactivate_super+0x84/0xa0 cleanup_mnt+0xa4/0x140 __cleanup_mnt+0x18/0x28 task_work_run+0x78/0xe0 do_notify_resume+0x204/0x240 ================================================================== The root cause is a race between cgroup_writeback_umount() and inode_switch_wbs()/cleanup_offline_cgwb(). There is a window between inode_prepare_wbs_switch() returning true and the subsequent wb_queue_isw() call. Following is the process that triggers the issue: CPU A (umount) | CPU B (writeback) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ inode_switch_wbs/cleanup_offline_cgwb atomic_inc(&isw_nr_in_flight) inode_prepare_wbs_switch -> passes SB_ACTIVE check __iget(inode) generic_shutdown_super sb->s_flags &= ~SB_ACTIVE cgroup_writeback_umount(sb) smp_mb() atomic_read(&isw_nr_in_flight) rcu_barrier() -> no pending RCU callbacks flush_workqueue(isw_wq) -> nothing queued, returns evict_inodes(sb) -> Inode skipped as isw still holds a ref. sop->put_super(sb) /* destroys percpu counters */ -> VFS: Busy inodes after unmount! wb_queue_isw() queue_work(isw_wq, ...) /* later in work function */ inode_switch_wbs_work_fn process_inode_switch_wbs iput() -> evict percpu_counter_dec() // UAF! Fix this by extending the RCU read-side critical section in inode_switch_wbs() and cleanup_offline_cgwb() to cover from inode_prepare_wbs_switch() through wb_queue_isw(). Since there is no sleep in this window, rcu_read_lock() can be used. Then add a synchronize_rcu() in cgroup_writeback_umount() before the existing rcu_barrier(), so that all in-flight switchers that have passed the SB_ACTIVE check have completed queue_work() before flush_workqueue() is called. The existing rcu_barrier() is intentionally retained so this fix can be backported unchanged to stable kernels (5.10.y, 6.6.y, ...) that still queue switches via queue_rcu_work(). It is a no-op on current mainline (since commit e1b849cfa6b6 ("writeback: Avoid contention on wb->list_lock when switching inodes")) and is removed in a follow-up patch.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
This vulnerability in the Linux kernel involves a race condition between cgroup_writeback_umount() and inode_switch_wbs()/cleanup_offline_cgwb() functions. When a container exits, a kernel BUG_ON() may be triggered due to busy inodes after unmounting an ext4 filesystem. The race occurs because there is a window between inode_prepare_wbs_switch() returning true and the subsequent wb_queue_isw() call, leading to a use-after-free scenario during inode reference counting and eviction. The fix involves extending the RCU read-side critical section to cover the entire window and adding a synchronize_rcu() call in cgroup_writeback_umount() to ensure all in-flight switchers complete before flush_workqueue() is called. This fix is designed to be backported to stable kernels and removes the race condition without impacting normal operation.
Potential Impact
The vulnerability can cause kernel crashes (BUG_ON) due to busy inodes after unmount, which may lead to system instability or denial of service. The root cause is a race condition that can result in use-after-free during inode reference handling in the writeback subsystem. There is no indication of privilege escalation or data corruption beyond system instability. No known exploits in the wild have been reported.
Mitigation Recommendations
A fix for this race condition has been implemented in the Linux kernel by extending RCU critical sections and adding synchronization calls to ensure proper ordering during unmount operations. Users should apply the official kernel updates that include this fix. Since no affected versions or patch links are provided, check the vendor or Linux kernel mailing lists for the relevant stable kernel updates (including 5.10.y, 6.6.y, and later). Patch status is not yet confirmed — check the vendor advisory for current remediation guidance.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-325c-m2q7-75hg
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-64378"]
- Ecosystems
- []
- Database Specific Severity
- null
- Cvss Version
- null
Threat ID: 6a65420b9c2644c7f8084d27
Added to database: 07/25/2026, 23:08:59 UTC
Last enriched: 07/25/2026, 23:30:32 UTC
Last updated: 09/08/2026, 22:52:14 UTC
Views: 60
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.