CVE-2026-90181: ublk: avoid teardown retry loop on xarray allocation failure
In the Linux kernel, the following vulnerability has been resolved:
ublk: avoid teardown retry loop on xarray allocation failure
ublkshmemremoveranges() 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 xastore(..., GFPATOMIC). If the store fails before maserase(), the current range is left in the tree and the helper returns false. The outer ublkshmemremoveranges() 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 radixtreenode failslab injection after a SHMEMZC buffer has already been registered:
# Kernel config: # CONFIGBLKDEVUBLK=y # CONFIGDEBUGFS=y # CONFIGFAULTINJECTION=y # CONFIGFAULTINJECTIONDEBUGFS=y # CONFIGFAILSLAB=y
echo 10 > /proc/sys/vm/nrhugepages mkdir -p /tmp/htlb mount -t hugetlbfs none /tmp/htlb fallocate -l 4M /tmp/htlb/ublkbuf
devid=$(kublk add -t null --shmemzc \ --htlb /tmp/htlb/ublkbuf | awk -F '[ :]' '/dev id/ {print $3}')
echo 1 > /sys/kernel/slab/radixtreenode/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 "$devid"
On the unfixed kernel the delete command was still running after 3 seconds. Disabling failslab made it return. The fault-injection stack showed:
shouldfailslab kmemcachealloclrunoprof xasnomem xastore xastore ublkshmemremoveranges ublkcdevrel ublkctrldeldev
Remove the allocation from the teardown loop. Keep the existing batch limit, but collect {basepfn, nrpages} 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 GFPATOMIC allocation.
With the same failslab settings, the fixed kernel completed "kublk del -n $devid" successfully in about 45 ms.
Affected Software
Event History
Frequently Asked Questions
Which systems are exposed to this teardown hang?
Systems using the Linux kernel ublk driver with a SHMEM_ZC buffer registered are relevant. The described reproduction also uses hugetlbfs-backed memory; the issue occurs during removal of the registered shared-memory ranges.
What conditions are required to trigger the issue?
An xarray allocation performed with GFP_ATOMIC must fail while the teardown code is collecting ranges to remove. The provided reproduction uses radix_tree_node failslab injection after registering a SHMEM_ZC buffer, so deliberate fault injection can trigger the condition.
What happens when the allocation failure occurs?
The current range remains in the maple tree, and the outer teardown loop retries that same range without making progress. Continued atomic allocation failures can therefore cause the teardown path to loop indefinitely.