GHSA-9H35-HQFF-9V3W
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-09-08 09:35In the Linux kernel, the following vulnerability has been resolved:
fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
A SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in send_sigio() and send_sigurg() when a process group receives a signal.
When FASYNC is configured for a process group (PIDTYPE_PGID), both functions use read_lock(&tasklist_lock) to traverse the task list. However, they are frequently called from softirq context: - send_sigio() via input_inject_event -> kill_fasync - send_sigurg() via tcp_check_urg -> sk_send_sigurg (NET_RX_SOFTIRQ)
The deadlock is caused by the rwlock writer fairness mechanism: 1. CPU 0 (process context) holds read_lock(&tasklist_lock) in do_wait(). 2. CPU 1 (process context) attempts write_lock(&tasklist_lock) in fork() or exit() and spins, which blocks all new readers. 3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception). 4. The softirq calls send_sigurg() and attempts to acquire read_lock(&tasklist_lock), deadlocking because CPU 1 is waiting.
Since PID hashing and do_each_pid_task() traversals are already RCU-protected, the read_lock on tasklist_lock is no longer strictly required for safe traversal. Fix this by replacing tasklist_lock with rcu_read_lock(), aligning the process group signaling path with the single-PID path. This also mitigates a potential remote denial of service vector via TCP URG packets.
Lockdep splat:
WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected [...] Chain exists of: &dev->event_lock --> &f_owner->lock --> tasklist_lock
Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(tasklist_lock); local_irq_disable(); lock(&dev->event_lock); lock(&f_owner->lock); lock(&dev->event_lock);
*** DEADLOCK ***
{
"affected": [],
"aliases": [
"CVE-2026-52946"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:04Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling\n\nA SOFTIRQ-safe to SOFTIRQ-unsafe lock order deadlock can occur in\nsend_sigio() and send_sigurg() when a process group receives a signal.\n\nWhen FASYNC is configured for a process group (PIDTYPE_PGID), both\nfunctions use read_lock(\u0026tasklist_lock) to traverse the task list.\nHowever, they are frequently called from softirq context:\n- send_sigio() via input_inject_event -\u003e kill_fasync\n- send_sigurg() via tcp_check_urg -\u003e sk_send_sigurg (NET_RX_SOFTIRQ)\n\nThe deadlock is caused by the rwlock writer fairness mechanism:\n1. CPU 0 (process context) holds read_lock(\u0026tasklist_lock) in do_wait().\n2. CPU 1 (process context) attempts write_lock(\u0026tasklist_lock) in\n fork() or exit() and spins, which blocks all new readers.\n3. CPU 0 is interrupted by a softirq (e.g., TCP URG packet reception).\n4. The softirq calls send_sigurg() and attempts to acquire\n read_lock(\u0026tasklist_lock), deadlocking because CPU 1 is waiting.\n\nSince PID hashing and do_each_pid_task() traversals are already\nRCU-protected, the read_lock on tasklist_lock is no longer strictly\nrequired for safe traversal. Fix this by replacing tasklist_lock with\nrcu_read_lock(), aligning the process group signaling path with the\nsingle-PID path. This also mitigates a potential remote denial of\nservice vector via TCP URG packets.\n\nLockdep splat:\n=====================================================\nWARNING: SOFTIRQ-safe -\u003e SOFTIRQ-unsafe lock order detected\n[...]\nChain exists of:\n \u0026dev-\u003eevent_lock --\u003e \u0026f_owner-\u003elock --\u003e tasklist_lock\n\nPossible interrupt unsafe locking scenario:\n CPU0 CPU1\n ---- ----\n lock(tasklist_lock);\n local_irq_disable();\n lock(\u0026dev-\u003eevent_lock);\n lock(\u0026f_owner-\u003elock);\n \u003cInterrupt\u003e\n lock(\u0026dev-\u003eevent_lock);\n\n*** DEADLOCK ***",
"id": "GHSA-9h35-hqff-9v3w",
"modified": "2026-09-08T09:35:32Z",
"published": "2026-06-24T18:32:41Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52946"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/00633c4683828acd5256fa8d5163f440d74bbe71"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1bee417678f1135e35b25a37734db46aa94258d2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/20a93e397abe850c49b6fa0e8cc827b5f634a8f5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/32dbd5ce4be3a3ed7e00f8af18795cc84fc50a33"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/36c1b57b2ecf3c61ac93f5f07bd29b6f21e226ed"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/54626335ea4174ab2d9a183b511d825f6765e47b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/897d6a7247739fb1528f98c575df4f2e5de7f994"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5fa9e32fb6718f70c986ee14dd5d01b4846f331"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bfcc8e8d8a495bb34cae9e620adfb75fb13a3954"
}
],
"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.