{
  "affected": [
    {
      "ecosystem_specific": {
        "urgency": "not yet assigned"
      },
      "package": {
        "ecosystem": "Debian:14",
        "name": "linux"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "details": "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 \u003e /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 \\ \t\t--htlb /tmp/htlb/ublk_buf | \t   awk -F '[ :]' '/dev id/ {print $3}')    echo 1 \u003e /sys/kernel/slab/radix_tree_node/failslab   echo Y \u003e /sys/kernel/debug/failslab/cache-filter   echo Y \u003e /sys/kernel/debug/failslab/ignore-gfp-wait   echo 1 \u003e /sys/kernel/debug/failslab/interval   echo -1 \u003e /sys/kernel/debug/failslab/times   echo 100 \u003e /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.",
  "id": "DEBIAN-CVE-2026-90181",
  "modified": "2026-09-18T04:47:35.943532184Z",
  "published": "2026-09-17T17:17:12.287Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://security-tracker.debian.org/tracker/CVE-2026-90181"
    }
  ],
  "upstream": [
    "CVE-2026-90181"
  ]
}