CVE-2026-90181

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.