[SRU][J][PATCH 0/1] CVE-2024-39496

[Vinicius Peixoto]

[Impact]

While loading a zone's info during creation of a block group, we can race
with a device replace operation and then trigger a use-after-free on the
device that was just replaced (source device of the replace operation).

This happens because at btrfs_load_zone_info() we extract a device from
the chunk map into a local variable and then use the device while not
under the protection of the device replace rwsem. So if there's a device
replace operation happening when we extract the device and that device
is the source of the replace operation, we will trigger a use-after-free
if before we finish using the device the replace operation finishes and
frees the device.

Fix this by enlarging the critical section under the protection of the
device replace rwsem so that all uses of the device are done inside the
critical section.

[Fix]
Noble: pending release (6.8.0-43.43)
Jammy: backported
Focal: not affected
Bionic: not affected
Xenial: not affected

Jammy is missing upstream commit 09a46725cc84 ("btrfs: zoned: factor out
per-zone logic from btrfs_load_block_group_zone_info"). The fix commit
had to be adapted to account for the missing refactor (but the critical
section affected by the fix commit is very similar before and after the
upstream change).

[Test]
Compile/boot tested, then created an emulated/in-memory zoned block
device according to the instructions in the btrfs documentation [1]
and ran a few basic tests to ensure basic filesystem functionality
wasn't compromised.

[Where problems could occur]
This could impact systems running btrfs in zoned mode, and problems
could present themselves to affected users as a hang when performing a
btrfs device replace operation.

[1] https://btrfs.readthedocs.io/en/latest/Zoned-mode.html

Vinicius Peixoto (1):
  btrfs: zoned: fix use-after-free due to race with dev replace

 fs/btrfs/zoned.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

-- 
2.43.0