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.
Leer descripción completaMostrar menos
The issue can be reproduced with radix_tree_node failslab injection after a SHMEM_ZC buffer has already been registered:
dev_id=$(kublk add -t null --shmem_zc \ --htlb /tmp/htlb/ublk_buf | awk -F '[ :]' '/dev id/ {print $3}')
On the unfixed kernel the delete command was still running after 3 seconds. Disabling failslab made it return. The fault-injection stack showed:
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.
Detalles técnicos trazas, registros y código del informe original
# 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 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" should_failslab kmem_cache_alloc_lru_noprof __xas_nomem __xa_store xa_store __ublk_shmem_remove_ranges ublk_cdev_rel ublk_ctrl_del_dev
CVSS
NVD no ha asignado puntuación CVSS a esta CVE (habitual desde el cambio de política de abril de 2026).
Probabilidad de explotación (EPSS)
- Probabilidad de explotación en los próximos 30 días: 0.21%
- Percentil entre todas las CVEs puntuadas: 11
- Fecha de la puntuación: 6/10/2026
EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).
Tecnologías afectadas (1)
⚠ Inferidas por IA a partir de la descripción — NVD aún no ha analizado esta CVE; no son CPE verificados.
Referencias
JSON original (NVD)
Mostrar
{
"id": "CVE-2026-90181",
"cveTags": [],
"metrics": {},
"affected": [
{
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"affectedData": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "309e02dccf64e1b7bd2067abedc270e33b0aadf3",
"lessThan": "b9cc6cc74daf6fef533dbe65d8cee779fea69600",
"versionType": "git"
},
{
"status": "affected",
"version": "309e02dccf64e1b7bd2067abedc270e33b0aadf3",
"lessThan": "4fd66a7f829f3f38f92a79081f0f2688aed644f0",
"versionType": "git"
}
],
"programFiles": [
"drivers/block/ublk_drv.c"
],
"defaultStatus": "unaffected"
},
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"product": "Linux",
"versions": [
{
"status": "affected",
"version": "7.1"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "7.1",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "7.2.6",
"versionType": "semver",
"lessThanOrEqual": "7.2.*"
},
{
"status": "unaffected",
"version": "7.3-rc1",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"drivers/block/ublk_drv.c"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-09-17T17:17:12.287",
"references": [
{
"url": "https://git.kernel.org/stable/c/4fd66a7f829f3f38f92a79081f0f2688aed644f0",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/b9cc6cc74daf6fef533dbe65d8cee779fea69600",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Received",
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nublk: avoid teardown retry loop on xarray allocation failure\n\n__ublk_shmem_remove_ranges() removes matching maple tree ranges in\nbatches, but first stores each range into a temporary xarray so that the\npages can be unpinned after dropping the maple tree lock.\n\nThat temporary xarray is filled under the maple tree lock with\nxa_store(..., GFP_ATOMIC). If the store fails before mas_erase(), the\ncurrent range is left in the tree and the helper returns false. The\nouter ublk_shmem_remove_ranges() loop then immediately retries the same\nrange. While the atomic allocation keeps failing, the teardown path has\nno forward progress.\n\nThe issue can be reproduced with radix_tree_node failslab injection after\na SHMEM_ZC buffer has already been registered:\n\n # Kernel config:\n # CONFIG_BLK_DEV_UBLK=y\n # CONFIG_DEBUG_FS=y\n # CONFIG_FAULT_INJECTION=y\n # CONFIG_FAULT_INJECTION_DEBUG_FS=y\n # CONFIG_FAILSLAB=y\n\n echo 10 > /proc/sys/vm/nr_hugepages\n mkdir -p /tmp/htlb\n mount -t hugetlbfs none /tmp/htlb\n fallocate -l 4M /tmp/htlb/ublk_buf\n\n dev_id=$(kublk add -t null --shmem_zc \\\n\t\t--htlb /tmp/htlb/ublk_buf |\n\t awk -F '[ :]' '/dev id/ {print $3}')\n\n echo 1 > /sys/kernel/slab/radix_tree_node/failslab\n echo Y > /sys/kernel/debug/failslab/cache-filter\n echo Y > /sys/kernel/debug/failslab/ignore-gfp-wait\n echo 1 > /sys/kernel/debug/failslab/interval\n echo -1 > /sys/kernel/debug/failslab/times\n echo 100 > /sys/kernel/debug/failslab/probability\n\n kublk del -n \"$dev_id\"\n\nOn the unfixed kernel the delete command was still running after 3\nseconds. Disabling failslab made it return. The fault-injection stack\nshowed:\n\n should_failslab\n kmem_cache_alloc_lru_noprof\n __xas_nomem\n __xa_store\n xa_store\n __ublk_shmem_remove_ranges\n ublk_cdev_rel\n ublk_ctrl_del_dev\n\nRemove the allocation from the teardown loop. Keep the existing batch\nlimit, but collect {base_pfn, nr_pages} pairs in a fixed-size stack array.\nOnce a matching range is found, the range is erased from the maple tree\nbefore dropping the lock, so each successful scan makes progress without\ndepending on any GFP_ATOMIC allocation.\n\nWith the same failslab settings, the fixed kernel completed\n\"kublk del -n $dev_id\" successfully in about 45 ms."
}
],
"lastModified": "2026-09-17T17:17:12.287",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}