CVE-2026-98083: btrfs: fix transaction use-after-free in raid stripe insertion
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix transaction use-after-free in raid stripe insertion
If allocation of a RAID stripe extent fails, btrfsinsertoneraidextent() aborts and ends the transaction before returning -ENOMEM.
btrfsfinishoneordered(), the production caller through btrfsinsertraidextent(), still owns the transaction handle. It handles the error by aborting the transaction and then reaches the common exit path, which ends the transaction again.
The premature end can free the handle and drop its transaction reference. Transaction cleanup can then free the transaction before the caller's second abort accesses the handle and transaction, resulting in use-after-free.
Keep the abort at the failure site, but let the caller's common exit path end the transaction once, after it has finished using both objects.
Affected Software
Event History
Frequently Asked Questions
Under what conditions can this bug be triggered?
The failure path requires allocation of a RAID stripe extent to fail in Btrfs. The affected path is reached while finishing ordered work through btrfs_finish_one_ordered(), after btrfs_insert_one_raid_extent() returns -ENOMEM.
What is the practical impact of the faulty error handling?
A failed RAID stripe extent allocation can cause the transaction handle to be ended prematurely. Later cleanup may free the transaction before the caller performs its second abort, causing that abort to access freed transaction-handle and transaction objects.
Is an out-of-memory condition involved in exploitation or detection?
Yes. The described trigger is btrfs_insert_one_raid_extent() returning -ENOMEM because RAID stripe extent allocation failed. Systems experiencing allocation failures during this Btrfs ordered-work path are the relevant population for investigation.
What code behavior distinguishes the corrected implementation?
The failure site still aborts the transaction, but does not end it before returning. The caller's common exit path ends the transaction once, only after it has finished using the transaction handle and transaction objects.