CVE-2026-68347
Estado: RecibidaSin puntuar—
In the Linux kernel, the following vulnerability has been resolved:
iommu/amd: Fix IRQ unsafe locking in gdom allocation
Lockdep complains:
Since amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the flush, switch the allocation side in gdom_info_load_or_alloc_locked() to HARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue, so switch that path to HARDIRQ-safe locking as well.
Detalles técnicos trazas, registros y código del informe original
[ 259.410489] =====================================================
[ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected
[ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted
[ 259.429718] -----------------------------------------------------
[ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
[ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0
[ 259.454485]
and this task is already holding:
[ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60
[ 259.470408] which would create a new lock dependency:
[ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3}
[ 259.483615]
but this new dependency connects a HARDIRQ-irq-safe lock:
[ 259.492447] (&domain->lock){-.-.}-{3:3}
[ 259.492449]
... which became HARDIRQ-irq-safe at:
[ 259.503705] lock_acquire+0xb6/0x2e0
[ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60
[ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50
[ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0
[ 259.523534] __iommu_dma_unmap+0xc2/0x140
[ 259.528100] iommu_dma_unmap_phys+0x55/0xc0
[ 259.532863] dma_unmap_phys+0x274/0x2e0
[ 259.537238] dma_unmap_page_attrs+0x17/0x30
[ 259.542000] nvme_unmap_data+0x13e/0x280
[ 259.546473] nvme_pci_complete_batch+0x45/0x70
[ 259.551524] nvme_irq+0x83/0x90
[ 259.555123] __handle_irq_event_percpu+0x92/0x360
[ 259.560466] handle_irq_event+0x39/0x80
[ 259.564841] handle_edge_irq+0xb2/0x1a0
[ 259.569214] __common_interrupt+0x4e/0x130
[ 259.573882] common_interrupt+0x88/0xa0
[ 259.578256] asm_common_interrupt+0x27/0x40
[ 259.583019] cpuidle_enter_state+0x119/0x5d0
[ 259.587877] cpuidle_enter+0x2e/0x50
[ 259.591962] do_idle+0x153/0x2c0
[ 259.595657] cpu_startup_entry+0x29/0x30
[ 259.600128] start_secondary+0x118/0x150
[ 259.604601] common_startup_64+0x13e/0x141
[ 259.609266]
to a HARDIRQ-irq-unsafe lock:
[ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3}
[ 259.615386]
... which became HARDIRQ-irq-unsafe at:
[ 259.627039] ...
[ 259.627039] lock_acquire+0xb6/0x2e0
[ 259.633071] _raw_spin_lock+0x2f/0x50
[ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0
[ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd]
[ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd]
[ 259.654547] __x64_sys_ioctl+0x9d/0xf0
...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.20%
- Percentil entre todas las CVEs puntuadas: 9
- 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-68347",
"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": "757d2b1fdf5b7d6eead5963a49b5780617987ab8",
"lessThan": "e0c78cdf35af3ada05f9309f4641e9f83c945dbd",
"versionType": "git"
},
{
"status": "affected",
"version": "757d2b1fdf5b7d6eead5963a49b5780617987ab8",
"lessThan": "0db3a430d9681fdb29890bef6934cd89cd1745d0",
"versionType": "git"
}
],
"programFiles": [
"drivers/iommu/amd/nested.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.0"
},
{
"status": "unaffected",
"version": "0",
"lessThan": "7.0",
"versionType": "semver"
},
{
"status": "unaffected",
"version": "7.1.6",
"versionType": "semver",
"lessThanOrEqual": "7.1.*"
},
{
"status": "unaffected",
"version": "7.2",
"versionType": "original_commit_for_fix",
"lessThanOrEqual": "*"
}
],
"programFiles": [
"drivers/iommu/amd/nested.c"
],
"defaultStatus": "affected"
}
]
}
],
"published": "2026-08-10T13:20:26.553",
"references": [
{
"url": "https://git.kernel.org/stable/c/0db3a430d9681fdb29890bef6934cd89cd1745d0",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
},
{
"url": "https://git.kernel.org/stable/c/e0c78cdf35af3ada05f9309f4641e9f83c945dbd",
"source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}
],
"vulnStatus": "Received",
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Fix IRQ unsafe locking in gdom allocation\n\nLockdep complains:\n\n [ 259.410489] =====================================================\n [ 259.417287] WARNING: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected\n [ 259.424667] 7.0.0-g51db1d8d2113 #54 Not tainted\n [ 259.429718] -----------------------------------------------------\n [ 259.436516] qemu-system-x86/10143 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:\n [ 259.444670] ff3b2b1c60305170 (&xa->xa_lock#25){+.+.}-{3:3}, at: __domain_flush_pages+0x17c/0x4b0\n [ 259.454485]\n and this task is already holding:\n [ 259.460991] ff3b2b1c98504cc0 (&domain->lock){-.-.}-{3:3}, at: amd_iommu_iotlb_sync+0x25/0x60\n [ 259.470408] which would create a new lock dependency:\n [ 259.476041] (&domain->lock){-.-.}-{3:3} -> (&xa->xa_lock#25){+.+.}-{3:3}\n [ 259.483615]\n but this new dependency connects a HARDIRQ-irq-safe lock:\n [ 259.492447] (&domain->lock){-.-.}-{3:3}\n [ 259.492449]\n ... which became HARDIRQ-irq-safe at:\n [ 259.503705] lock_acquire+0xb6/0x2e0\n [ 259.507790] _raw_spin_lock_irqsave+0x3e/0x60\n [ 259.512748] amd_iommu_flush_iotlb_all+0x20/0x50\n [ 259.517996] iommu_dma_free_iova.isra.0+0x1b8/0x1e0\n [ 259.523534] __iommu_dma_unmap+0xc2/0x140\n [ 259.528100] iommu_dma_unmap_phys+0x55/0xc0\n [ 259.532863] dma_unmap_phys+0x274/0x2e0\n [ 259.537238] dma_unmap_page_attrs+0x17/0x30\n [ 259.542000] nvme_unmap_data+0x13e/0x280\n [ 259.546473] nvme_pci_complete_batch+0x45/0x70\n [ 259.551524] nvme_irq+0x83/0x90\n [ 259.555123] __handle_irq_event_percpu+0x92/0x360\n [ 259.560466] handle_irq_event+0x39/0x80\n [ 259.564841] handle_edge_irq+0xb2/0x1a0\n [ 259.569214] __common_interrupt+0x4e/0x130\n [ 259.573882] common_interrupt+0x88/0xa0\n [ 259.578256] asm_common_interrupt+0x27/0x40\n [ 259.583019] cpuidle_enter_state+0x119/0x5d0\n [ 259.587877] cpuidle_enter+0x2e/0x50\n [ 259.591962] do_idle+0x153/0x2c0\n [ 259.595657] cpu_startup_entry+0x29/0x30\n [ 259.600128] start_secondary+0x118/0x150\n [ 259.604601] common_startup_64+0x13e/0x141\n [ 259.609266]\n to a HARDIRQ-irq-unsafe lock:\n [ 259.615384] (&xa->xa_lock#25){+.+.}-{3:3}\n [ 259.615386]\n ... which became HARDIRQ-irq-unsafe at:\n [ 259.627039] ...\n [ 259.627039] lock_acquire+0xb6/0x2e0\n [ 259.633071] _raw_spin_lock+0x2f/0x50\n [ 259.637250] amd_iommu_alloc_domain_nested+0x140/0x3c0\n [ 259.643078] iommufd_hwpt_alloc+0x272/0x800 [iommufd]\n [ 259.648813] iommufd_fops_ioctl+0x14e/0x200 [iommufd]\n [ 259.654547] __x64_sys_ioctl+0x9d/0xf0\n ...\n\nSince amd_iommu_domain_flush_pages() necessarily holds domain->lock to do the\nflush, switch the allocation side in gdom_info_load_or_alloc_locked() to\nHARDIRQ-safe allocation. The IOMMU_DESTROY->free path has the same issue,\nso switch that path to HARDIRQ-safe locking as well."
}
],
"lastModified": "2026-08-17T06:17:42.917",
"sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67"
}