In the Linux kernel, the following vulnerability has been resolved: ublk: avoid teardown retry loop on xarray allocation failure __ublk_sh

In the Linux kernel, the following vulnerability has been resolved:

ublk: avoid teardown retry loop on xarray allocation failure

__ublk_shmem_remove_ranges() removes matching maple tree ranges in
batches, but first stores each range into a temporary xarray so that the
pages can be unpinned after dropping the maple tree lock.

That temporary xarray is filled under the maple tree lock with
xa_store(..., GFP_ATOMIC). If the store fails before mas_erase(), the
current range is left in the tree and the helper returns false. The
outer ublk_shmem_remove_ranges() loop then immediately retries the same
range. While the atomic allocation keeps failing, the teardown path has
no forward progress.

The issue can be reproduced with radix_tree_node failslab injection after
a SHMEM_ZC buffer has already been registered:

Kernel config:

CONFIG_BLK_DEV_UBLK=y

CONFIG_DEBUG_FS=y

CONFIG_FAULT_INJECTION=y

CONFIG_FAULT_INJECTION_DEBUG_FS=y

CONFIG_FAILSLAB=y

echo 10 > /proc/sys/vm/nr_hugepages
mkdir -p /tmp/htlb
mount -t hugetlbfs none /tmp/htlb
fallocate -l 4M /tmp/htlb/ublk_buf

dev_id=$(kublk add -t null --shmem_zc
--htlb /tmp/htlb/ublk_buf |
awk -F '[ :]' '/dev id/ {print $3}')

echo 1 > /sys/kernel/slab/radix_tree_node/failslab
echo Y > /sys/kernel/debug/failslab/cache-filter
echo Y > /sys/kernel/debug/failslab/ignore-gfp-wait
echo 1 > /sys/kernel/debug/failslab/interval
echo -1 > /sys/kernel/debug/failslab/times
echo 100 > /sys/kernel/debug/failslab/probability

kublk del -n "$dev_id"

On the unfixed kernel the delete command was still running after 3
seconds. Disabling failslab made it return. The fault-injection stack
showed:

should_failslab
kmem_cache_alloc_lru_noprof
__xas_nomem
__xa_store
xa_store
__ublk_shmem_remove_ranges
ublk_cdev_rel
ublk_ctrl_del_dev

Remove the allocation from the teardown loop. Keep the existing batch
limit, but collect {base_pfn, nr_pages} pairs in a fixed-size stack array.
Once a matching range is found, the range is erased from the maple tree
before dropping the lock, so each successful scan makes progress without
depending on any GFP_ATOMIC allocation.

With the same failslab settings, the fixed kernel completed
"kublk del -n $dev_id" successfully in about 45 ms.