GHSA-CQWH-R98H-2279
Vulnerability from github – Published: 2026-04-24 15:32 – Updated: 2026-06-01 18:31In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix possible deadlock between unlink and dio_end_io_write
ocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem, while in ocfs2_dio_end_io_write, it acquires these locks in reverse order. This creates an ABBA lock ordering violation on lock classes ocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and ocfs2_file_ip_alloc_sem_key.
Lock Chain #0 (orphan dir inode_lock -> ip_alloc_sem): ocfs2_unlink ocfs2_prepare_orphan_dir ocfs2_lookup_lock_orphan_dir inode_lock(orphan_dir_inode) <- lock A __ocfs2_prepare_orphan_dir ocfs2_prepare_dir_for_insert ocfs2_extend_dir ocfs2_expand_inline_dir down_write(&oi->ip_alloc_sem) <- Lock B
Lock Chain #1 (ip_alloc_sem -> orphan dir inode_lock): ocfs2_dio_end_io_write down_write(&oi->ip_alloc_sem) <- Lock B ocfs2_del_inode_from_orphan() inode_lock(orphan_dir_inode) <- Lock A
Deadlock Scenario: CPU0 (unlink) CPU1 (dio_end_io_write) ------ ------ inode_lock(orphan_dir_inode) down_write(ip_alloc_sem) down_write(ip_alloc_sem) inode_lock(orphan_dir_inode)
Since ip_alloc_sem is to protect allocation changes, which is unrelated with operations in ocfs2_del_inode_from_orphan. So move ocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.
{
"affected": [],
"aliases": [
"CVE-2026-31598"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-24T15:16:37Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix possible deadlock between unlink and dio_end_io_write\n\nocfs2_unlink takes orphan dir inode_lock first and then ip_alloc_sem,\nwhile in ocfs2_dio_end_io_write, it acquires these locks in reverse order.\nThis creates an ABBA lock ordering violation on lock classes\nocfs2_sysfile_lock_key[ORPHAN_DIR_SYSTEM_INODE] and\nocfs2_file_ip_alloc_sem_key.\n\nLock Chain #0 (orphan dir inode_lock -\u003e ip_alloc_sem):\nocfs2_unlink\n ocfs2_prepare_orphan_dir\n ocfs2_lookup_lock_orphan_dir\n inode_lock(orphan_dir_inode) \u003c- lock A\n __ocfs2_prepare_orphan_dir\n ocfs2_prepare_dir_for_insert\n ocfs2_extend_dir\n\t ocfs2_expand_inline_dir\n\t down_write(\u0026oi-\u003eip_alloc_sem) \u003c- Lock B\n\nLock Chain #1 (ip_alloc_sem -\u003e orphan dir inode_lock):\nocfs2_dio_end_io_write\n down_write(\u0026oi-\u003eip_alloc_sem) \u003c- Lock B\n ocfs2_del_inode_from_orphan()\n inode_lock(orphan_dir_inode) \u003c- Lock A\n\nDeadlock Scenario:\n CPU0 (unlink) CPU1 (dio_end_io_write)\n ------ ------\n inode_lock(orphan_dir_inode)\n down_write(ip_alloc_sem)\n down_write(ip_alloc_sem)\n inode_lock(orphan_dir_inode)\n\nSince ip_alloc_sem is to protect allocation changes, which is unrelated\nwith operations in ocfs2_del_inode_from_orphan. So move\nocfs2_del_inode_from_orphan out of ip_alloc_sem to fix the deadlock.",
"id": "GHSA-cqwh-r98h-2279",
"modified": "2026-06-01T18:31:27Z",
"published": "2026-04-24T15:32:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31598"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/297d8d7bb6a2bf133d3a3636edbdf94101cbd719"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2b884d52273c60c298bd570163e8053657bbaff6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/32630dee18c6bb2175c8a865a474749492eaf19c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4b80b5a838a32437f2cae0662578bac216a2c51a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/93f35419eb84d58820040642cb6e7528fe4aba7a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b02da26a992db0c0e2559acbda0fc48d4a2fd337"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bc0fb5c7d54c78be43a536df0e20dee32adb27d3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e049f7a9bd80b7319590789ea5e1c523d6339d91"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f9fb1a7b635849322e1d7b7b6b26389778ec8e82"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
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.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.