test case btrfs/164 reported UAF.. [ 6712.084324] general protection fault: 0000 [#1] PREEMPT SMP :: [ 6712.195423] btrfs_update_commit_device_size+0x75/0xf0 [btrfs] [ 6712.201424] btrfs_commit_transaction+0x57d/0xa90 [btrfs] [ 6712.206999] btrfs_rm_device+0x627/0x850 [btrfs] [ 6712.211800] btrfs_ioctl+0x2b03/0x3120 [btrfs] ::
reason for this is that btrfs_shrink_device() adds the device resized to the fs_devices::resized_devices after it has called the last commit transaction. So the list fs_devices::resized_devices is not empty when btrfs_shrink_device() returns. Now the parent function btrfs_rm_device() calls btrfs_close_bdev(device); call_rcu(&device->rcu, free_device_rcu); and then does the commit transaction. The commit transaction goes through the fs_devices::resized_devices in btrfs_update_commit_device_size() and leads to UAF. Fix this by making sure btrfs_shrink_device() calls the last needed btrfs_commit_transaction() before the return. Signed-off-by: Anand Jain <anand.j...@oracle.com> --- I am bit skeptical about the condition when btrfs_commit_transaction() fails, can you pls be wary about it when reviewing. Thanks. Lu/David, As this issues isn't reproducible at my end, can you pls test this patch on top of the patch btrfs: fix missing superblock update in the device delete commit transaction Thanks. fs/btrfs/volumes.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 418843b8f8e8..344083cc811c 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -4464,7 +4464,10 @@ int btrfs_shrink_device(struct btrfs_device *device, u64 new_size) /* Now btrfs_update_device() will change the on-disk size. */ ret = btrfs_update_device(trans, device); - btrfs_end_transaction(trans); + if (ret) + btrfs_end_transaction(trans); + else + ret = btrfs_commit_transaction(trans); done: btrfs_free_path(path); if (ret) { -- 2.7.0 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html