CVE-2025-40303
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-12-08

Last updated on: 2025-12-08

Assigner: kernel.org

Description
In the Linux kernel, the following vulnerability has been resolved: btrfs: ensure no dirty metadata is written back for an fs with errors [BUG] During development of a minor feature (make sure all btrfs_bio::end_io() is called in task context), I noticed a crash in generic/388, where metadata writes triggered new works after btrfs_stop_all_workers(). It turns out that it can even happen without any code modification, just using RAID5 for metadata and the same workload from generic/388 is going to trigger the use-after-free. [CAUSE] If btrfs hits an error, the fs is marked as error, no new transaction is allowed thus metadata is in a frozen state. But there are some metadata modifications before that error, and they are still in the btree inode page cache. Since there will be no real transaction commit, all those dirty folios are just kept as is in the page cache, and they can not be invalidated by invalidate_inode_pages2() call inside close_ctree(), because they are dirty. And finally after btrfs_stop_all_workers(), we call iput() on btree inode, which triggers writeback of those dirty metadata. And if the fs is using RAID56 metadata, this will trigger RMW and queue new works into rmw_workers, which is already stopped, causing warning from queue_work() and use-after-free. [FIX] Add a special handling for write_one_eb(), that if the fs is already in an error state, immediately mark the bbio as failure, instead of really submitting them. Then during close_ctree(), iput() will just discard all those dirty tree blocks without really writing them back, thus no more new jobs for already stopped-and-freed workqueues. The extra discard in write_one_eb() also acts as an extra safenet. E.g. the transaction abort is triggered by some extent/free space tree corruptions, and since extent/free space tree is already corrupted some tree blocks may be allocated where they shouldn't be (overwriting existing tree blocks). In that case writing them back will further corrupting the fs.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-12-08
Last Modified
2025-12-08
Generated
2026-05-07
AI Q&A
2025-12-08
EPSS Evaluated
2026-05-05
NVD
CVE-2025-40303
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
linux linux_kernel *
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-UNKNOWN
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability occurs in the Linux kernel's btrfs filesystem when it encounters errors. If the filesystem is marked as having errors, no new transactions are allowed, leaving some metadata modifications dirty in the page cache without being properly written back or invalidated. When the system attempts to write back this dirty metadata, especially on RAID5 or RAID6 metadata configurations, it triggers read-modify-write operations on workqueues that have already been stopped, causing use-after-free issues and potential crashes. The fix involves marking such write attempts as failures immediately to avoid submitting them, preventing further corruption and crashes.


How can this vulnerability impact me? :

This vulnerability can cause system crashes or instability due to use-after-free errors when the btrfs filesystem is used with RAID5 or RAID6 metadata and encounters errors. It may also lead to further filesystem corruption if corrupted tree blocks are written back improperly, potentially resulting in data loss or degraded system reliability.


What immediate steps should I take to mitigate this vulnerability?

The vulnerability is fixed by adding special handling in the Linux kernel's btrfs code to avoid writing back dirty metadata when the filesystem is in an error state. To mitigate this vulnerability immediately, you should update your Linux kernel to a version that includes this fix. This prevents use-after-free conditions and further filesystem corruption by discarding dirty metadata instead of writing it back when errors occur.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart