Goal Reached Thanks to every supporter — we hit 100%!

Goal: 1000 CNY · Raised: 1336 CNY

100%
Buy Us a Coffee

CVE-2026-68347— iommu/amd: Fix IRQ unsafe locking in gdom allocation

Quick assessment

Affected
Linux Linux
Exploitation
No confirmed in-the-wild exploitation; assess based on exposure
Recommended action
Check the vendor advisory and references for a fixed version. If immediate upgrade is impossible, restrict exposure and increase monitoring.

Linux kernel是美国Linux基金会开源的一个操作系统内核。 Linux kernel 7.0版本存在安全漏洞，该漏洞源于drivers/iommu/amd/nested.c文件中的gdom分配过程存在IRQ不安全锁定问题，可能导致锁顺序异常。

AI Predicted 5.5 Difficulty: Easy EPSS 0.16% · P6

Possible ATT&CK Techniques 1 AI

T1499 · Endpoint Denial of Service

Affected Version Matrix 6

VendorProduct Version RangeStatus
Linux Linux 757d2b1fdf5b7d6eead5963a49b5780617987ab8< e0c78cdf35af3ada05f9309f4641e9f83c945dbd affected
757d2b1fdf5b7d6eead5963a49b5780617987ab8< 0db3a430d9681fdb29890bef6934cd89cd1745d0 affected
7.0 affected
< 7.0 unaffected
7.1.6≤ 7.1.* unaffected
7.2≤ * unaffected
Get alerts for future matching vulnerabilities Log in to subscribe

I. Basic Information for CVE-2026-68347

Vulnerability Information
Have questions about the vulnerability? See if Shenlong's analysis helps!
View Shenlong Deep Dive ↗

Although we use advanced large model technology, its output may still contain inaccurate or outdated information.Shenlong tries to ensure data accuracy, but please verify and judge based on the actual situation.

Vulnerability Title
iommu/amd: Fix IRQ unsafe locking in gdom allocation
Source: CVE Program / CVE List V5
Vulnerability Description
In the Linux kernel, the following vulnerability has been resolved: iommu/amd: Fix IRQ unsafe locking in gdom allocation Lockdep complains: [ 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 ... 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.
Source: CVE Program / CVE List V5
CVSS Information
N/A
Source: CVE Program / CVE List V5
Vulnerability Type
N/A
Source: CVE Program / CVE List V5
Vulnerability Title
Linux kernel 安全漏洞
Source: CNNVD (China National Vulnerability Database)
Vulnerability Description
Linux kernel是美国Linux基金会开源的一个操作系统内核。 Linux kernel 7.0版本存在安全漏洞，该漏洞源于drivers/iommu/amd/nested.c文件中的gdom分配过程存在IRQ不安全锁定问题，可能导致锁顺序异常。
Source: CNNVD (China National Vulnerability Database)
CVSS Information
N/A
Source: CNNVD (China National Vulnerability Database)
Vulnerability Type
N/A
Source: CNNVD (China National Vulnerability Database)

Affected Products

Vendor Product Affected Versions CPE Subscribe
Linux Linux 757d2b1fdf5b7d6eead5963a49b5780617987ab8 ~ e0c78cdf35af3ada05f9309f4641e9f83c945dbd -
Linux Linux 7.0 -

II. Public POCs for CVE-2026-68347

# POC Description Source Link Shenlong Link
AI-Generated POC Premium

No public POC found.

Login to generate AI POC

III. Intelligence Information for CVE-2026-68347

请登录查看更多情报信息。

Patches & Fixes for CVE-2026-68347 (2)

Same Patch Batch · Linux · 2026-08-10 · 344 CVEs total

CVE-2026-68136 9.8 CRITICAL net: gro: fix double aggregation of flush-marked skbs
CVE-2026-68300 9.8 CRITICAL sctp: auth: verify auth requirement when auth_chunk is NULL
CVE-2026-68154 9.8 CRITICAL libceph: reject zero bucket types in crush_decode
CVE-2026-68156 9.8 CRITICAL libceph: refresh auth->authorizer_buf{,_len} after authorizer update
CVE-2026-68158 9.8 CRITICAL libceph: Fix multiplication overflow in decode_new_up_state_weight()
CVE-2026-68159 9.8 CRITICAL libceph: bound pg_{temp,upmap,upmap_items} length to CEPH_PG_MAX_SIZE
CVE-2026-68160 9.8 CRITICAL ceph: fix pre-auth out-of-bounds read on snaptrace in ceph_handle_caps()
CVE-2026-68161 9.8 CRITICAL sctp: close UDP tunnel sockets during netns teardown
CVE-2026-68144 9.8 CRITICAL phonet: pep: fix use-after-free in pep_get_sb()
CVE-2026-68170 9.8 CRITICAL mptcp: fix stale skb->sk reference on subflow close
CVE-2026-68302 9.8 CRITICAL amt: re-read skb header pointers after every pull
CVE-2026-68137 9.8 CRITICAL net/x25: fix use-after-free in x25_kill_by_neigh()
CVE-2026-68388 9.8 CRITICAL smb/client: handle overlapping allocated ranges in fallocate
CVE-2026-68426 9.8 CRITICAL xfrm: fix stale skb->prev after async crypto steals a GSO segment
CVE-2026-68385 9.8 CRITICAL s390/checksum: Fix csum_partial() without vector facility
CVE-2026-68127 9.8 CRITICAL ila: reload IPv6 header after pskb_may_pull in checksum adjust
CVE-2026-68117 9.8 CRITICAL tipc: clear sock->sk on the failed-insert path in tipc_sk_create()
CVE-2026-68381 9.8 CRITICAL ksmbd: pin conn during async oplock break notification
CVE-2026-68123 9.8 CRITICAL openvswitch: fix GSO userspace truncation underflow
CVE-2026-68124 9.6 CRITICAL mctp: serial: handle zero-length frames to prevent rx buffer overflow

Showing top 20 of 344 CVEs. View all on vendor page &rarr; →

IV. Related Vulnerabilities

Same product: Linux
Same vendor: Linux

V. Comments for CVE-2026-68347

No comments yet

Leave a comment