mshv: Fix race in mshv_irqfd_deassign
In the Linux kernel, the following vulnerability has been resolved: mshv: Fix race in mshv_irqfd_deassign mshv_irqfd_deactivate() and the hlist traversal of pt_irqfds_list require pt->pt_irqfds_lock to be held, but mshv_irqfd_deassign() omits it. This races with the EPOLLHUP path in mshv_irqfd_wakeup(), which does take the lock before calling mshv_irqfd_deactivate(). Additionally, mshv_irqfd_deactivate() uses hlist_del() which poisons the node pointers rather than resetting them. Since mshv_irqfd_is_active() relies on hlist_unhashed() (checks pprev == NULL), a poisoned node still appears active. If a concurrent path calls mshv_irqfd_deactivate() again on the same irqfd, the guard fails to prevent a double hlist_del() on poisoned pointers. Fix both issues: - Add the missing spin_lock_irq/spin_unlock_irq around the list traversal in mshv_irqfd_deassign(), matching mshv_irqfd_release(). - Use hlist_del_init() instead of hlist_del() so the node is properly marked as unhashed after removal, making the is_active guard reliable.
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.18.44, 7.1.8
- CVEs
- CVE-2026-80896
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 2 Nov 2026, 19:40 UTC · Revision 1
Source evidence
In the Linux kernel, the following vulnerability has been resolved: mshv: Fix race in mshv_irqfd_deassign mshv_irqfd_deactivate() and the hlist traversal of pt_irqfds_list require pt->pt_irqfds_lock to be held, but mshv_irqfd_deassign() omits it. This races with the EPOLLHUP path in mshv_irqfd_wakeup(), which does take the lock before calling mshv_irqfd_deactivate(). Additionally, mshv_irqfd_deactivate() uses hlist_del() which poisons the node pointers rather than resetting them. Since mshv_irqfd_is_active() relies on hlist_unhashed() (checks pprev == NULL), a poisoned node still appears active. If a concurrent path calls mshv_irqfd_deactivate() again on the same irqfd, the guard fails to prevent a double hlist_del() on poisoned pointers. Fix both issues: - Add the missing spin_lock_irq/spin_unlock_irq around the list traversal in mshv_irqfd_deassign(), matching mshv_irqfd_release(). - Use hlist_del_init() instead of hlist_del() so the node is properly marked as unhashed after removal, making the is_active guard reliable.
osv:CVE-2026-80896
Kernel
Fixed versions: 6.18.44, 7.1.8
Complete source record
{
"id": "1919db906452b24640e968454675e4e344afb928dbaa834e9a1eff20c22934e7",
"url": "https://osv.dev/vulnerability/CVE-2026-80896",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "mshv: Fix race in mshv_irqfd_deassign",
"summary": "In the Linux kernel, the following vulnerability has been resolved: mshv: Fix race in mshv_irqfd_deassign mshv_irqfd_deactivate() and the hlist traversal of pt_irqfds_list require pt->pt_irqfds_lock to be held, but mshv_irqfd_deassign() omits it. This races with the EPOLLHUP path in mshv_irqfd_wakeup(), which does take the lock before calling mshv_irqfd_deactivate(). Additionally, mshv_irqfd_deactivate() uses hlist_del() which poisons the node pointers rather than resetting them. Since mshv_irqfd_is_active() relies on hlist_unhashed() (checks pprev == NULL), a poisoned node still appears active. If a concurrent path calls mshv_irqfd_deactivate() again on the same irqfd, the guard fails to prevent a double hlist_del() on poisoned pointers. Fix both issues: - Add the missing spin_lock_irq/spin_unlock_irq around the list traversal in mshv_irqfd_deassign(), matching mshv_irqfd_release(). - Use hlist_del_init() instead of hlist_del() so the node is properly marked as unhashed after removal, making the is_active guard reliable.",
"evidence": "osv:CVE-2026-80896",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.18.44",
"evidence": "/affected/1/ranges"
},
{
"value": "7.1.8",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "unknown",
"structured": {
"id": "CVE-2026-80896",
"aliases": [
"CVE-2026-80896"
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "621191d709b14882270dfd8ea5d7d6cdfebe2c35"
},
{
"fixed": "72a90ce4918b5a2d4820fe20677ba9af780d8826"
},
{
"fixed": "4529a41a675b96e0f876eef1cc93a31a57cb4d18"
},
{
"fixed": "0762262ac3e70f65b3bb843fe892f8bac1562d08"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-80896.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.15.0"
},
{
"fixed": "6.18.44"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.1.8"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-80896.json"
}
}
],
"modified": "2026-10-28T02:30:22.697277451Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/0762262ac3e70f65b3bb843fe892f8bac1562d08",
"https://git.kernel.org/stable/c/4529a41a675b96e0f876eef1cc93a31a57cb4d18",
"https://git.kernel.org/stable/c/72a90ce4918b5a2d4820fe20677ba9af780d8826",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80896.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-80896",
"https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git"
],
"provider_metadata": {
"cna_assigner": "Linux",
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/80xxx/CVE-2026-80896.json"
}
},
"related_cves": [
{
"value": "CVE-2026-80896",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": null
},
"source_id": "core-osv",
"document_id": 489226,
"published_at": "2026-09-04T17:11:11.689+00:00"
}