ocfs2: o2hb: quiesce negotiate handlers and timeout work
In the Linux kernel, the following vulnerability has been resolved: ocfs2: o2hb: quiesce negotiate handlers and timeout work Heartbeat regions publish struct o2hb_region as the private data for the NEGO_TIMEOUT and NEGO_APPROVE o2net handlers as soon as make_item() creates the configfs region. The approve handler can call o2hb_arm_timeout(), so a peer can touch the region timeout work before dev_store() has finished building the heartbeat runtime, or after teardown has started to shut that runtime back down. The final configfs put also has to keep reg alive until the last in-flight o2net callback drops its handler reference. o2net_unregister_handler_list() blocks future handler lookups, but it does not wait for sc_rx_work that already passed o2net_handler_get(). That drain needs to cover local listener teardown as well, where the o2net ordered workqueue may already be inside destroy_workqueue(). Fix the lifetime rule in both directions. Initialize the region delayed works before publishing reg through the o2net handler table, keep new or stopping regions non-armable with hr_stopping, and quiesce both delayed works on failed-start and teardown paths even when no heartbeat thread is left to call o2hb_disarm_timeout(). Then unregister handlers before tearing down handler-visible region state and make the drain wait for the active or destroying o2net ordered workqueue before release frees reg. The buggy scenario involves two paths, with each column showing the order within that p
- Products
- Kernel
- Affected versions
- Not specified
- Fixed versions
- 6.1.191, 6.12.114, 6.18.57, 6.6.160, 7.2.6
- CVEs
- CVE-2026-90301
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 5 Nov 2026, 03:54 UTC · Revision 1
Source evidence
ocfs2: o2hb: quiesce negotiate handlers and timeout work
core-osv · Original sourcePublished 17 Sept 2026, 16:08 UTC
In the Linux kernel, the following vulnerability has been resolved: ocfs2: o2hb: quiesce negotiate handlers and timeout work Heartbeat regions publish struct o2hb_region as the private data for the NEGO_TIMEOUT and NEGO_APPROVE o2net handlers as soon as make_item() creates the configfs region. The approve handler can call o2hb_arm_timeout(), so a peer can touch the region timeout work before dev_store() has finished building the heartbeat runtime, or after teardown has started to shut that runtime back down. The final configfs put also has to keep reg alive until the last in-flight o2net callback drops its handler reference. o2net_unregister_handler_list() blocks future handler lookups, but it does not wait for sc_rx_work that already passed o2net_handler_get(). That drain needs to cover local listener teardown as well, where the o2net ordered workqueue may already be inside destroy_workqueue(). Fix the lifetime rule in both directions. Initialize the region delayed works before publishing reg through the o2net handler table, keep new or stopping regions non-armable with hr_stopping, and quiesce both delayed works on failed-start and teardown paths even when no heartbeat thread is left to call o2hb_disarm_timeout(). Then unregister handlers before tearing down handler-visible region state and make the drain wait for the active or destroying o2net ordered workqueue before release frees reg. The buggy scenario involves two paths, with each column showing the order within that p
osv:CVE-2026-90301
Kernel
Fixed versions: 6.1.191, 6.6.160, 6.12.114, 6.18.57, 7.2.6
Complete source record
{
"id": "e3d1adbdefb2f034bdbf72a28a77ab6c4347659b475d23602b5a909a20a6fc78",
"url": "https://osv.dev/vulnerability/CVE-2026-90301",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "ocfs2: o2hb: quiesce negotiate handlers and timeout work",
"summary": "In the Linux kernel, the following vulnerability has been resolved: ocfs2: o2hb: quiesce negotiate handlers and timeout work Heartbeat regions publish struct o2hb_region as the private data for the NEGO_TIMEOUT and NEGO_APPROVE o2net handlers as soon as make_item() creates the configfs region. The approve handler can call o2hb_arm_timeout(), so a peer can touch the region timeout work before dev_store() has finished building the heartbeat runtime, or after teardown has started to shut that runtime back down. The final configfs put also has to keep reg alive until the last in-flight o2net callback drops its handler reference. o2net_unregister_handler_list() blocks future handler lookups, but it does not wait for sc_rx_work that already passed o2net_handler_get(). That drain needs to cover local listener teardown as well, where the o2net ordered workqueue may already be inside destroy_workqueue(). Fix the lifetime rule in both directions. Initialize the region delayed works before publishing reg through the o2net handler table, keep new or stopping regions non-armable with hr_stopping, and quiesce both delayed works on failed-start and teardown paths even when no heartbeat thread is left to call o2hb_disarm_timeout(). Then unregister handlers before tearing down handler-visible region state and make the drain wait for the active or destroying o2net ordered workqueue before release frees reg. The buggy scenario involves two paths, with each column showing the order within that p",
"evidence": "osv:CVE-2026-90301",
"products": [
{
"name": {
"value": "Kernel",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "6.1.191",
"evidence": "/affected/1/ranges"
},
{
"value": "6.6.160",
"evidence": "/affected/1/ranges"
},
{
"value": "6.12.114",
"evidence": "/affected/1/ranges"
},
{
"value": "6.18.57",
"evidence": "/affected/1/ranges"
},
{
"value": "7.2.6",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": []
}
],
"severity": "high",
"structured": {
"id": "CVE-2026-90301",
"aliases": [
"CVE-2026-90301"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H"
}
],
"affected": [
{
"ranges": [
{
"repo": "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git",
"type": "GIT",
"events": [
{
"introduced": "34069b886f95356d68bf8315fa648c4ab3193cdd"
},
{
"fixed": "ed3c9aebd6bb5aa6ccc2a9177fab7a87ae895715"
},
{
"fixed": "b672d4de13247369c8dc394ba83f2a896d9cc25c"
},
{
"fixed": "f218d70f27bb326f5e9b2f33503e253851b3bafa"
},
{
"fixed": "9d44822ba34d6035690f725f9de602744a6e1946"
},
{
"fixed": "b5a2907bdeced0949bcddc84b95ba7d4cb93841b"
},
{
"fixed": "011291b70ba4832e136b7b581825b2bc0f525bf6"
}
]
}
],
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-90301.json"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "4.7.0"
},
{
"fixed": "6.1.191"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.2.0"
},
{
"fixed": "6.6.160"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.7.0"
},
{
"fixed": "6.12.114"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.13.0"
},
{
"fixed": "6.18.57"
}
]
},
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "6.19.0"
},
{
"fixed": "7.2.6"
}
]
}
],
"package": {
"name": "Kernel",
"ecosystem": "Linux"
},
"database_specific": {
"source": "https://storage.googleapis.com/cve-osv-conversion/osv-output/CVE-2026-90301.json"
}
}
],
"modified": "2026-11-01T02:30:42.189332807Z",
"provider": "osv",
"references": [
"https://git.kernel.org/stable/c/011291b70ba4832e136b7b581825b2bc0f525bf6",
"https://git.kernel.org/stable/c/9d44822ba34d6035690f725f9de602744a6e1946",
"https://git.kernel.org/stable/c/b5a2907bdeced0949bcddc84b95ba7d4cb93841b",
"https://git.kernel.org/stable/c/b672d4de13247369c8dc394ba83f2a896d9cc25c",
"https://git.kernel.org/stable/c/ed3c9aebd6bb5aa6ccc2a9177fab7a87ae895715",
"https://git.kernel.org/stable/c/f218d70f27bb326f5e9b2f33503e253851b3bafa",
"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/90xxx/CVE-2026-90301.json",
"https://nvd.nist.gov/vuln/detail/CVE-2026-90301",
"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/90xxx/CVE-2026-90301.json"
}
},
"related_cves": [
{
"value": "CVE-2026-90301",
"evidence": "/id"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 510046,
"published_at": "2026-09-17T16:08:25.152+00:00"
}