CVE-2026-23198 (GCVE-0-2026-23198)
Vulnerability from cvelistv5 – Published: 2026-02-14 16:27 – Updated: 2026-02-14 16:27
VLAI?
Title
KVM: Don't clobber irqfd routing type when deassigning irqfd
Summary
In the Linux kernel, the following vulnerability has been resolved:
KVM: Don't clobber irqfd routing type when deassigning irqfd
When deassigning a KVM_IRQFD, don't clobber the irqfd's copy of the IRQ's
routing entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86
and arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to
handle a concurrent routing update, verify that the irqfd is still active
before consuming the routing information. As evidenced by the x86 and
arm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below),
clobbering the entry type without notifying arch code is surprising and
error prone.
As a bonus, checking that the irqfd is active provides a convenient
location for documenting _why_ KVM must not consume the routing entry for
an irqfd that is in the process of being deassigned: once the irqfd is
deleted from the list (which happens *before* the eventfd is detached), it
will no longer receive updates via kvm_irq_routing_update(), and so KVM
could deliver an event using stale routing information (relative to
KVM_SET_GSI_ROUTING returning to userspace).
As an even better bonus, explicitly checking for the irqfd being active
fixes a similar bug to the one the clobbering is trying to prevent: if an
irqfd is deactivated, and then its routing is changed,
kvm_irq_routing_update() won't invoke kvm_arch_update_irqfd_routing()
(because the irqfd isn't in the list). And so if the irqfd is in bypass
mode, IRQs will continue to be posted using the old routing information.
As for kvm_arch_irq_bypass_del_producer(), clobbering the routing type
results in KVM incorrectly keeping the IRQ in bypass mode, which is
especially problematic on AMD as KVM tracks IRQs that are being posted to
a vCPU in a list whose lifetime is tied to the irqfd.
Without the help of KASAN to detect use-after-free, the most common
sympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to
the memory for irqfd structure being re-allocated and zeroed, resulting
in irqfd->irq_bypass_data being NULL when read by
avic_update_iommu_vcpu_affinity():
BUG: kernel NULL pointer dereference, address: 0000000000000018
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0
Oops: Oops: 0000 [#1] SMP
CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test
Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE
Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE
Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025
RIP: 0010:amd_iommu_update_ga+0x19/0xe0
Call Trace:
<TASK>
avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd]
__avic_vcpu_load+0xf4/0x130 [kvm_amd]
kvm_arch_vcpu_load+0x89/0x210 [kvm]
vcpu_load+0x30/0x40 [kvm]
kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm]
kvm_vcpu_ioctl+0x571/0x6a0 [kvm]
__se_sys_ioctl+0x6d/0xb0
do_syscall_64+0x6f/0x9d0
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x46893b
</TASK>
---[ end trace 0000000000000000 ]---
If AVIC is inhibited when the irfd is deassigned, the bug will manifest as
list corruption, e.g. on the next irqfd assignment.
list_add corruption. next->prev should be prev (ffff8d474d5cd588),
but was 0000000000000000. (next=ffff8d8658f86530).
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:31!
Oops: invalid opcode: 0000 [#1] SMP
CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test
Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE
Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE
Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025
RIP: 0010:__list_add_valid_or_report+0x97/0xc0
Call Trace:
<TASK>
avic_pi_update_irte+0x28e/0x2b0 [kvm_amd]
kvm_pi_update_irte+0xbf/0x190 [kvm]
kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm]
irq_bypass_register_consumer+0xcd/0x170 [irqbypa
---truncated---
Severity ?
No CVSS data available.
Assigner
References
Impacted products
| Vendor | Product | Version | |||||||
|---|---|---|---|---|---|---|---|---|---|
| Linux | Linux |
Affected:
f70c20aaf141adb715a2d750c55154073b02a9c3 , < 959a063e7f12524bc1871ad1f519787967bbcd45
(git)
Affected: f70c20aaf141adb715a2d750c55154073b02a9c3 , < 2284bc168b148a17b5ca3b37b3d95c411f18a08d (git) Affected: f70c20aaf141adb715a2d750c55154073b02a9c3 , < 6d14ba1e144e796b5fc81044f08cfba9024ca195 (git) Affected: f70c20aaf141adb715a2d750c55154073b02a9c3 , < b61f9b2fcf181451d0a319889478cc53c001123e (git) Affected: f70c20aaf141adb715a2d750c55154073b02a9c3 , < ff48c9312d042bfbe826ca675e98acc6c623211c (git) Affected: f70c20aaf141adb715a2d750c55154073b02a9c3 , < 4385b2f2843549bfb932e0dcf76bf4b065543a3c (git) Affected: f70c20aaf141adb715a2d750c55154073b02a9c3 , < b4d37cdb77a0015f51fee083598fa227cc07aaf1 (git) |
|||||||
|
|||||||||
{
"containers": {
"cna": {
"affected": [
{
"defaultStatus": "unaffected",
"product": "Linux",
"programFiles": [
"virt/kvm/eventfd.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"lessThan": "959a063e7f12524bc1871ad1f519787967bbcd45",
"status": "affected",
"version": "f70c20aaf141adb715a2d750c55154073b02a9c3",
"versionType": "git"
},
{
"lessThan": "2284bc168b148a17b5ca3b37b3d95c411f18a08d",
"status": "affected",
"version": "f70c20aaf141adb715a2d750c55154073b02a9c3",
"versionType": "git"
},
{
"lessThan": "6d14ba1e144e796b5fc81044f08cfba9024ca195",
"status": "affected",
"version": "f70c20aaf141adb715a2d750c55154073b02a9c3",
"versionType": "git"
},
{
"lessThan": "b61f9b2fcf181451d0a319889478cc53c001123e",
"status": "affected",
"version": "f70c20aaf141adb715a2d750c55154073b02a9c3",
"versionType": "git"
},
{
"lessThan": "ff48c9312d042bfbe826ca675e98acc6c623211c",
"status": "affected",
"version": "f70c20aaf141adb715a2d750c55154073b02a9c3",
"versionType": "git"
},
{
"lessThan": "4385b2f2843549bfb932e0dcf76bf4b065543a3c",
"status": "affected",
"version": "f70c20aaf141adb715a2d750c55154073b02a9c3",
"versionType": "git"
},
{
"lessThan": "b4d37cdb77a0015f51fee083598fa227cc07aaf1",
"status": "affected",
"version": "f70c20aaf141adb715a2d750c55154073b02a9c3",
"versionType": "git"
}
]
},
{
"defaultStatus": "affected",
"product": "Linux",
"programFiles": [
"virt/kvm/eventfd.c"
],
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"vendor": "Linux",
"versions": [
{
"status": "affected",
"version": "4.4"
},
{
"lessThan": "4.4",
"status": "unaffected",
"version": "0",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.10.*",
"status": "unaffected",
"version": "5.10.250",
"versionType": "semver"
},
{
"lessThanOrEqual": "5.15.*",
"status": "unaffected",
"version": "5.15.200",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.1.*",
"status": "unaffected",
"version": "6.1.163",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.6.*",
"status": "unaffected",
"version": "6.6.124",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.12.*",
"status": "unaffected",
"version": "6.12.70",
"versionType": "semver"
},
{
"lessThanOrEqual": "6.18.*",
"status": "unaffected",
"version": "6.18.10",
"versionType": "semver"
},
{
"lessThanOrEqual": "*",
"status": "unaffected",
"version": "6.19",
"versionType": "original_commit_for_fix"
}
]
}
],
"cpeApplicability": [
{
"nodes": [
{
"cpeMatch": [
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.10.250",
"versionStartIncluding": "4.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "5.15.200",
"versionStartIncluding": "4.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.1.163",
"versionStartIncluding": "4.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.6.124",
"versionStartIncluding": "4.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.12.70",
"versionStartIncluding": "4.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.18.10",
"versionStartIncluding": "4.4",
"vulnerable": true
},
{
"criteria": "cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*",
"versionEndExcluding": "6.19",
"versionStartIncluding": "4.4",
"vulnerable": true
}
],
"negate": false,
"operator": "OR"
}
]
}
],
"descriptions": [
{
"lang": "en",
"value": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Don\u0027t clobber irqfd routing type when deassigning irqfd\n\nWhen deassigning a KVM_IRQFD, don\u0027t clobber the irqfd\u0027s copy of the IRQ\u0027s\nrouting entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86\nand arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to\nhandle a concurrent routing update, verify that the irqfd is still active\nbefore consuming the routing information. As evidenced by the x86 and\narm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below),\nclobbering the entry type without notifying arch code is surprising and\nerror prone.\n\nAs a bonus, checking that the irqfd is active provides a convenient\nlocation for documenting _why_ KVM must not consume the routing entry for\nan irqfd that is in the process of being deassigned: once the irqfd is\ndeleted from the list (which happens *before* the eventfd is detached), it\nwill no longer receive updates via kvm_irq_routing_update(), and so KVM\ncould deliver an event using stale routing information (relative to\nKVM_SET_GSI_ROUTING returning to userspace).\n\nAs an even better bonus, explicitly checking for the irqfd being active\nfixes a similar bug to the one the clobbering is trying to prevent: if an\nirqfd is deactivated, and then its routing is changed,\nkvm_irq_routing_update() won\u0027t invoke kvm_arch_update_irqfd_routing()\n(because the irqfd isn\u0027t in the list). And so if the irqfd is in bypass\nmode, IRQs will continue to be posted using the old routing information.\n\nAs for kvm_arch_irq_bypass_del_producer(), clobbering the routing type\nresults in KVM incorrectly keeping the IRQ in bypass mode, which is\nespecially problematic on AMD as KVM tracks IRQs that are being posted to\na vCPU in a list whose lifetime is tied to the irqfd.\n\nWithout the help of KASAN to detect use-after-free, the most common\nsympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to\nthe memory for irqfd structure being re-allocated and zeroed, resulting\nin irqfd-\u003eirq_bypass_data being NULL when read by\navic_update_iommu_vcpu_affinity():\n\n BUG: kernel NULL pointer dereference, address: 0000000000000018\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0\n Oops: Oops: 0000 [#1] SMP\n CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test\n Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE\n Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025\n RIP: 0010:amd_iommu_update_ga+0x19/0xe0\n Call Trace:\n \u003cTASK\u003e\n avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd]\n __avic_vcpu_load+0xf4/0x130 [kvm_amd]\n kvm_arch_vcpu_load+0x89/0x210 [kvm]\n vcpu_load+0x30/0x40 [kvm]\n kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm]\n kvm_vcpu_ioctl+0x571/0x6a0 [kvm]\n __se_sys_ioctl+0x6d/0xb0\n do_syscall_64+0x6f/0x9d0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n RIP: 0033:0x46893b\n \u003c/TASK\u003e\n ---[ end trace 0000000000000000 ]---\n\nIf AVIC is inhibited when the irfd is deassigned, the bug will manifest as\nlist corruption, e.g. on the next irqfd assignment.\n\n list_add corruption. next-\u003eprev should be prev (ffff8d474d5cd588),\n but was 0000000000000000. (next=ffff8d8658f86530).\n ------------[ cut here ]------------\n kernel BUG at lib/list_debug.c:31!\n Oops: invalid opcode: 0000 [#1] SMP\n CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test\n Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE\n Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025\n RIP: 0010:__list_add_valid_or_report+0x97/0xc0\n Call Trace:\n \u003cTASK\u003e\n avic_pi_update_irte+0x28e/0x2b0 [kvm_amd]\n kvm_pi_update_irte+0xbf/0x190 [kvm]\n kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm]\n irq_bypass_register_consumer+0xcd/0x170 [irqbypa\n---truncated---"
}
],
"providerMetadata": {
"dateUpdated": "2026-02-14T16:27:23.621Z",
"orgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"shortName": "Linux"
},
"references": [
{
"url": "https://git.kernel.org/stable/c/959a063e7f12524bc1871ad1f519787967bbcd45"
},
{
"url": "https://git.kernel.org/stable/c/2284bc168b148a17b5ca3b37b3d95c411f18a08d"
},
{
"url": "https://git.kernel.org/stable/c/6d14ba1e144e796b5fc81044f08cfba9024ca195"
},
{
"url": "https://git.kernel.org/stable/c/b61f9b2fcf181451d0a319889478cc53c001123e"
},
{
"url": "https://git.kernel.org/stable/c/ff48c9312d042bfbe826ca675e98acc6c623211c"
},
{
"url": "https://git.kernel.org/stable/c/4385b2f2843549bfb932e0dcf76bf4b065543a3c"
},
{
"url": "https://git.kernel.org/stable/c/b4d37cdb77a0015f51fee083598fa227cc07aaf1"
}
],
"title": "KVM: Don\u0027t clobber irqfd routing type when deassigning irqfd",
"x_generator": {
"engine": "bippy-1.2.0"
}
}
},
"cveMetadata": {
"assignerOrgId": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
"assignerShortName": "Linux",
"cveId": "CVE-2026-23198",
"datePublished": "2026-02-14T16:27:23.621Z",
"dateReserved": "2026-01-13T15:37:45.985Z",
"dateUpdated": "2026-02-14T16:27:23.621Z",
"state": "PUBLISHED"
},
"dataType": "CVE_RECORD",
"dataVersion": "5.2",
"vulnerability-lookup:meta": {
"nvd": "{\"cve\":{\"id\":\"CVE-2026-23198\",\"sourceIdentifier\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\",\"published\":\"2026-02-14T17:15:57.640\",\"lastModified\":\"2026-02-18T17:52:22.253\",\"vulnStatus\":\"Awaiting Analysis\",\"cveTags\":[],\"descriptions\":[{\"lang\":\"en\",\"value\":\"In the Linux kernel, the following vulnerability has been resolved:\\n\\nKVM: Don\u0027t clobber irqfd routing type when deassigning irqfd\\n\\nWhen deassigning a KVM_IRQFD, don\u0027t clobber the irqfd\u0027s copy of the IRQ\u0027s\\nrouting entry as doing so breaks kvm_arch_irq_bypass_del_producer() on x86\\nand arm64, which explicitly look for KVM_IRQ_ROUTING_MSI. Instead, to\\nhandle a concurrent routing update, verify that the irqfd is still active\\nbefore consuming the routing information. As evidenced by the x86 and\\narm64 bugs, and another bug in kvm_arch_update_irqfd_routing() (see below),\\nclobbering the entry type without notifying arch code is surprising and\\nerror prone.\\n\\nAs a bonus, checking that the irqfd is active provides a convenient\\nlocation for documenting _why_ KVM must not consume the routing entry for\\nan irqfd that is in the process of being deassigned: once the irqfd is\\ndeleted from the list (which happens *before* the eventfd is detached), it\\nwill no longer receive updates via kvm_irq_routing_update(), and so KVM\\ncould deliver an event using stale routing information (relative to\\nKVM_SET_GSI_ROUTING returning to userspace).\\n\\nAs an even better bonus, explicitly checking for the irqfd being active\\nfixes a similar bug to the one the clobbering is trying to prevent: if an\\nirqfd is deactivated, and then its routing is changed,\\nkvm_irq_routing_update() won\u0027t invoke kvm_arch_update_irqfd_routing()\\n(because the irqfd isn\u0027t in the list). And so if the irqfd is in bypass\\nmode, IRQs will continue to be posted using the old routing information.\\n\\nAs for kvm_arch_irq_bypass_del_producer(), clobbering the routing type\\nresults in KVM incorrectly keeping the IRQ in bypass mode, which is\\nespecially problematic on AMD as KVM tracks IRQs that are being posted to\\na vCPU in a list whose lifetime is tied to the irqfd.\\n\\nWithout the help of KASAN to detect use-after-free, the most common\\nsympton on AMD is a NULL pointer deref in amd_iommu_update_ga() due to\\nthe memory for irqfd structure being re-allocated and zeroed, resulting\\nin irqfd-\u003eirq_bypass_data being NULL when read by\\navic_update_iommu_vcpu_affinity():\\n\\n BUG: kernel NULL pointer dereference, address: 0000000000000018\\n #PF: supervisor read access in kernel mode\\n #PF: error_code(0x0000) - not-present page\\n PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0\\n Oops: Oops: 0000 [#1] SMP\\n CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test\\n Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE\\n Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE\\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025\\n RIP: 0010:amd_iommu_update_ga+0x19/0xe0\\n Call Trace:\\n \u003cTASK\u003e\\n avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd]\\n __avic_vcpu_load+0xf4/0x130 [kvm_amd]\\n kvm_arch_vcpu_load+0x89/0x210 [kvm]\\n vcpu_load+0x30/0x40 [kvm]\\n kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm]\\n kvm_vcpu_ioctl+0x571/0x6a0 [kvm]\\n __se_sys_ioctl+0x6d/0xb0\\n do_syscall_64+0x6f/0x9d0\\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\\n RIP: 0033:0x46893b\\n \u003c/TASK\u003e\\n ---[ end trace 0000000000000000 ]---\\n\\nIf AVIC is inhibited when the irfd is deassigned, the bug will manifest as\\nlist corruption, e.g. on the next irqfd assignment.\\n\\n list_add corruption. next-\u003eprev should be prev (ffff8d474d5cd588),\\n but was 0000000000000000. (next=ffff8d8658f86530).\\n ------------[ cut here ]------------\\n kernel BUG at lib/list_debug.c:31!\\n Oops: invalid opcode: 0000 [#1] SMP\\n CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test\\n Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE\\n Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE\\n Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025\\n RIP: 0010:__list_add_valid_or_report+0x97/0xc0\\n Call Trace:\\n \u003cTASK\u003e\\n avic_pi_update_irte+0x28e/0x2b0 [kvm_amd]\\n kvm_pi_update_irte+0xbf/0x190 [kvm]\\n kvm_arch_irq_bypass_add_producer+0x72/0x90 [kvm]\\n irq_bypass_register_consumer+0xcd/0x170 [irqbypa\\n---truncated---\"},{\"lang\":\"es\",\"value\":\"En el kernel de Linux, la siguiente vulnerabilidad ha sido resuelta: KVM: No sobrescribir el tipo de enrutamiento de irqfd al desasignar irqfd Al desasignar un KVM_IRQFD, no sobrescribir la copia del irqfd de la entrada de enrutamiento de la IRQ, ya que hacerlo rompe kvm_arch_irq_bypass_del_producer() en x86 y arm64, que buscan expl\u00edcitamente KVM_IRQ_ROUTING_MSI. En su lugar, para manejar una actualizaci\u00f3n de enrutamiento concurrente, verificar que el irqfd sigue activo antes de consumir la informaci\u00f3n de enrutamiento. Como lo demuestran los errores de x86 y arm64, y otro error en kvm_arch_update_irqfd_routing() (ver abajo), sobrescribir el tipo de entrada sin notificar al c\u00f3digo de arquitectura es sorprendente y propenso a errores. Como ventaja adicional, verificar que el irqfd est\u00e1 activo proporciona una ubicaci\u00f3n conveniente para documentar _por qu\u00e9_ KVM no debe consumir la entrada de enrutamiento para un irqfd que est\u00e1 en proceso de ser desasignado: una vez que el irqfd se elimina de la lista (lo que ocurre *antes* de que el eventfd se desvincule), ya no recibir\u00e1 actualizaciones a trav\u00e9s de kvm_irq_routing_update(), y as\u00ed KVM podr\u00eda entregar un evento utilizando informaci\u00f3n de enrutamiento obsoleta (en relaci\u00f3n con KVM_SET_GSI_ROUTING que regresa al espacio de usuario). Como una ventaja a\u00fan mejor, verificar expl\u00edcitamente que el irqfd est\u00e1 activo corrige un error similar al que el sobrescrito intenta prevenir: si un irqfd se desactiva y luego se cambia su enrutamiento, kvm_irq_routing_update() no invocar\u00e1 a kvm_arch_update_irqfd_routing() (porque el irqfd no est\u00e1 en la lista). Y as\u00ed, si el irqfd est\u00e1 en modo de bypass, las IRQ seguir\u00e1n siendo publicadas utilizando la informaci\u00f3n de enrutamiento antigua. En cuanto a kvm_arch_irq_bypass_del_producer(), sobrescribir el tipo de enrutamiento resulta en que KVM mantiene incorrectamente la IRQ en modo de bypass, lo cual es especialmente problem\u00e1tico en AMD, ya que KVM rastrea las IRQ que se est\u00e1n publicando a una vCPU en una lista cuya vida \u00fatil est\u00e1 ligada al irqfd. Sin la ayuda de KASAN para detectar el uso despu\u00e9s de liberaci\u00f3n, el s\u00edntoma m\u00e1s com\u00fan en AMD es una desreferencia de puntero NULL en amd_iommu_update_ga() debido a que la memoria para la estructura irqfd se reasigna y se pone a cero, lo que resulta en que irqfd-\u0026gt;irq_bypass_data sea NULL cuando es le\u00eddo por avic_update_iommu_vcpu_affinity(): BUG: desreferencia de puntero NULL del kernel, direcci\u00f3n: 0000000000000018 #PF: acceso de lectura de supervisor en modo kernel #PF: error_code(0x0000) - p\u00e1gina no presente PGD 40cf2b9067 P4D 40cf2b9067 PUD 408362a067 PMD 0 Oops: Oops: 0000 [#1] SMP CPU: 6 UID: 0 PID: 40383 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--5dddc257e6b2-irqfd #31 NONE Tainted: [U]=USER, [W]=WARN, [O]=OOT_MODULE Nombre de hardware: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.78.2-0 09/05/2025 RIP: 0010:amd_iommu_update_ga+0x19/0xe0 Traza de Llamada: avic_update_iommu_vcpu_affinity+0x3d/0x90 [kvm_amd] __avic_vcpu_load+0xf4/0x130 [kvm_amd] kvm_arch_vcpu_load+0x89/0x210 [kvm] vcpu_load+0x30/0x40 [kvm] kvm_arch_vcpu_ioctl_run+0x45/0x620 [kvm] kvm_vcpu_ioctl+0x571/0x6a0 [kvm] __se_sys_ioctl+0x6d/0xb0 do_syscall_64+0x6f/0x9d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 RIP: 0033:0x46893b ---[ fin de la traza 0000000000000000 ]--- Si AVIC se inhibe cuando el irqfd es desasignado, el error se manifestar\u00e1 como corrupci\u00f3n de lista, por ejemplo, en la siguiente asignaci\u00f3n de irqfd. Corrupci\u00f3n de list_add. next-\u0026gt;prev deber\u00eda ser prev (ffff8d474d5cd588), pero era 0000000000000000. (next=ffff8d8658f86530). ------------[ cortar aqu\u00ed ]------------ BUG del kernel en lib/list_debug.c:31! Oops: c\u00f3digo de operaci\u00f3n inv\u00e1lido: 0000 [#1] SMP CPU: 128 UID: 0 PID: 80818 Comm: vfio_irq_test Tainted: G U W O 6.19.0-smp--f19dc4d680ba-irqfd #28 NONE---truncado---\"}],\"metrics\":{},\"references\":[{\"url\":\"https://git.kernel.org/stable/c/2284bc168b148a17b5ca3b37b3d95c411f18a08d\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/4385b2f2843549bfb932e0dcf76bf4b065543a3c\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/6d14ba1e144e796b5fc81044f08cfba9024ca195\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/959a063e7f12524bc1871ad1f519787967bbcd45\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/b4d37cdb77a0015f51fee083598fa227cc07aaf1\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/b61f9b2fcf181451d0a319889478cc53c001123e\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"},{\"url\":\"https://git.kernel.org/stable/c/ff48c9312d042bfbe826ca675e98acc6c623211c\",\"source\":\"416baaa9-dc9f-4396-8d5f-8c081fb06d67\"}]}}"
}
}
Loading…
Loading…
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Loading…
Loading…