CWE-667
Allowed-with-ReviewImproper Locking
Abstraction: Class · Status: Draft
The product does not properly acquire or release a lock on a resource, leading to unexpected resource state changes and behaviors.
713 vulnerabilities reference this CWE, most recent first.
GHSA-H67M-XG8F-FXCF
Vulnerability from github – Published: 2021-11-10 18:59 – Updated: 2024-11-07 22:17Impact
The code behind tf.function API can be made to deadlock when two tf.function decorated Python functions are mutually recursive:
import tensorflow as tf
@tf.function()
def fun1(num):
if num == 1:
return
print(num)
fun2(num-1)
@tf.function()
def fun2(num):
if num == 0:
return
print(num)
fun1(num-1)
fun1(9)
This occurs due to using a non-reentrant Lock Python object.
Loading any model which contains mutually recursive functions is vulnerable. An attacker can cause denial of service by causing users to load such models and calling a recursive tf.function, although this is not a frequent scenario.
Patches
We have patched the issue in GitHub commit afac8158d43691661ad083f6dd9e56f327c1dcb7.
The fix will be included in TensorFlow 2.7.0. We will also cherrypick this commit on TensorFlow 2.6.1, TensorFlow 2.5.2, and TensorFlow 2.4.4, as these are also affected and still in supported range.
For more information
Please consult our security guide for more information regarding the security model and how to contact us with issues and questions.
Attribution
This vulnerability has been reported by members of the Aivul Team from Qihoo 360.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.6.0"
},
{
"fixed": "2.6.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "2.5.0"
},
{
"fixed": "2.5.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.6.0"
},
{
"fixed": "2.6.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.5.0"
},
{
"fixed": "2.5.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-cpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.6.0"
},
{
"fixed": "2.6.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "2.5.0"
},
{
"fixed": "2.5.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "PyPI",
"name": "tensorflow-gpu"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.4.4"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2021-41213"
],
"database_specific": {
"cwe_ids": [
"CWE-662",
"CWE-667"
],
"github_reviewed": true,
"github_reviewed_at": "2021-11-08T22:25:35Z",
"nvd_published_at": "2021-11-05T23:15:00Z",
"severity": "MODERATE"
},
"details": "### Impact\nThe [code behind `tf.function` API](https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/python/eager/def_function.py#L542) can be made to deadlock when two `tf.function` decorated Python functions are mutually recursive:\n\n```python \nimport tensorflow as tf\n\n@tf.function() \ndef fun1(num):\n if num == 1:\n return\n print(num)\n fun2(num-1)\n\n@tf.function()\ndef fun2(num):\n if num == 0:\n return\n print(num)\n fun1(num-1)\n\nfun1(9)\n```\n\nThis occurs due to using a non-reentrant `Lock` Python object.\n\nLoading any model which contains mutually recursive functions is vulnerable. An attacker can cause denial of service by causing users to load such models and calling a recursive `tf.function`, although this is not a frequent scenario.\n\n### Patches\nWe have patched the issue in GitHub commit [afac8158d43691661ad083f6dd9e56f327c1dcb7](https://github.com/tensorflow/tensorflow/commit/afac8158d43691661ad083f6dd9e56f327c1dcb7).\n\nThe fix will be included in TensorFlow 2.7.0. We will also cherrypick this commit on TensorFlow 2.6.1, TensorFlow 2.5.2, and TensorFlow 2.4.4, as these are also affected and still in supported range.\n\n### For more information\nPlease consult [our security guide](https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.\n\n### Attribution\nThis vulnerability has been reported by members of the Aivul Team from Qihoo 360.",
"id": "GHSA-h67m-xg8f-fxcf",
"modified": "2024-11-07T22:17:51Z",
"published": "2021-11-10T18:59:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/security/advisories/GHSA-h67m-xg8f-fxcf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41213"
},
{
"type": "WEB",
"url": "https://github.com/tensorflow/tensorflow/commit/afac8158d43691661ad083f6dd9e56f327c1dcb7"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-cpu/PYSEC-2021-622.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow-gpu/PYSEC-2021-820.yaml"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/tensorflow/PYSEC-2021-405.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/tensorflow/tensorflow"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Deadlock in mutually recursive `tf.function` objects"
}
GHSA-H72J-469C-C787
Vulnerability from github – Published: 2024-10-21 18:30 – Updated: 2024-10-31 15:30In the Linux kernel, the following vulnerability has been resolved:
vrf: revert "vrf: Remove unnecessary RCU-bh critical section"
This reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853.
dev_queue_xmit_nit is expected to be called with BH disabled. __dev_queue_xmit has the following:
/* Disable soft irqs for various locks below. Also
* stops preemption for RCU.
*/
rcu_read_lock_bh();
VRF must follow this invariant. The referenced commit removed this protection. Which triggered a lockdep warning:
================================
WARNING: inconsistent lock state
6.11.0 #1 Tainted: G W
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
btserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes:
ffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30
{IN-SOFTIRQ-W} state was registered at:
lock_acquire+0x19a/0x4f0
_raw_spin_lock+0x27/0x40
packet_rcv+0xa33/0x1320
__netif_receive_skb_core.constprop.0+0xcb0/0x3a90
__netif_receive_skb_list_core+0x2c9/0x890
netif_receive_skb_list_internal+0x610/0xcc0
[...]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(rlock-AF_PACKET);
<Interrupt>
lock(rlock-AF_PACKET);
*** DEADLOCK ***
Call Trace:
<TASK>
dump_stack_lvl+0x73/0xa0
mark_lock+0x102e/0x16b0
__lock_acquire+0x9ae/0x6170
lock_acquire+0x19a/0x4f0
_raw_spin_lock+0x27/0x40
tpacket_rcv+0x863/0x3b30
dev_queue_xmit_nit+0x709/0xa40
vrf_finish_direct+0x26e/0x340 [vrf]
vrf_l3_out+0x5f4/0xe80 [vrf]
__ip_local_out+0x51e/0x7a0
[...]
{
"affected": [],
"aliases": [
"CVE-2024-49980"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-21T18:15:18Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvrf: revert \"vrf: Remove unnecessary RCU-bh critical section\"\n\nThis reverts commit 504fc6f4f7f681d2a03aa5f68aad549d90eab853.\n\ndev_queue_xmit_nit is expected to be called with BH disabled.\n__dev_queue_xmit has the following:\n\n /* Disable soft irqs for various locks below. Also\n * stops preemption for RCU.\n */\n rcu_read_lock_bh();\n\nVRF must follow this invariant. The referenced commit removed this\nprotection. Which triggered a lockdep warning:\n\n\t================================\n\tWARNING: inconsistent lock state\n\t6.11.0 #1 Tainted: G W\n\t--------------------------------\n\tinconsistent {IN-SOFTIRQ-W} -\u003e {SOFTIRQ-ON-W} usage.\n\tbtserver/134819 [HC0[0]:SC0[0]:HE1:SE1] takes:\n\tffff8882da30c118 (rlock-AF_PACKET){+.?.}-{2:2}, at: tpacket_rcv+0x863/0x3b30\n\t{IN-SOFTIRQ-W} state was registered at:\n\t lock_acquire+0x19a/0x4f0\n\t _raw_spin_lock+0x27/0x40\n\t packet_rcv+0xa33/0x1320\n\t __netif_receive_skb_core.constprop.0+0xcb0/0x3a90\n\t __netif_receive_skb_list_core+0x2c9/0x890\n\t netif_receive_skb_list_internal+0x610/0xcc0\n [...]\n\n\tother info that might help us debug this:\n\t Possible unsafe locking scenario:\n\n\t CPU0\n\t ----\n\t lock(rlock-AF_PACKET);\n\t \u003cInterrupt\u003e\n\t lock(rlock-AF_PACKET);\n\n\t *** DEADLOCK ***\n\n\tCall Trace:\n\t \u003cTASK\u003e\n\t dump_stack_lvl+0x73/0xa0\n\t mark_lock+0x102e/0x16b0\n\t __lock_acquire+0x9ae/0x6170\n\t lock_acquire+0x19a/0x4f0\n\t _raw_spin_lock+0x27/0x40\n\t tpacket_rcv+0x863/0x3b30\n\t dev_queue_xmit_nit+0x709/0xa40\n\t vrf_finish_direct+0x26e/0x340 [vrf]\n\t vrf_l3_out+0x5f4/0xe80 [vrf]\n\t __ip_local_out+0x51e/0x7a0\n [...]",
"id": "GHSA-h72j-469c-c787",
"modified": "2024-10-31T15:30:58Z",
"published": "2024-10-21T18:30:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49980"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/718a752bd746b3f4dd62516bb437baf73d548415"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8c9381b3138246d46536db93ed696832abd70204"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b04c4d9eb4f25b950b33218e33b04c94e7445e51"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e61f8c4d179b2ffc0d3b7f821c3734be738643d0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H7WR-QV5C-937X
Vulnerability from github – Published: 2026-03-25 12:30 – Updated: 2026-05-26 15:32In the Linux kernel, the following vulnerability has been resolved:
perf/core: Fix invalid wait context in ctx_sched_in()
Lockdep found a bug in the event scheduling when a pinned event was failed and wakes up the threads in the ring buffer like below.
It seems it should not grab a wait-queue lock under perf-context lock. Let's do it with irq_work.
[ 39.913691] ============================= [ 39.914157] [ BUG: Invalid wait context ] [ 39.914623] 6.15.0-next-20250530-next-2025053 #1 Not tainted [ 39.915271] ----------------------------- [ 39.915731] repro/837 is trying to lock: [ 39.916191] ffff88801acfabd8 (&event->waitq){....}-{3:3}, at: __wake_up+0x26/0x60 [ 39.917182] other info that might help us debug this: [ 39.917761] context-{5:5} [ 39.918079] 4 locks held by repro/837: [ 39.918530] #0: ffffffff8725cd00 (rcu_read_lock){....}-{1:3}, at: __perf_event_task_sched_in+0xd1/0xbc0 [ 39.919612] #1: ffff88806ca3c6f8 (&cpuctx_lock){....}-{2:2}, at: __perf_event_task_sched_in+0x1a7/0xbc0 [ 39.920748] #2: ffff88800d91fc18 (&ctx->lock){....}-{2:2}, at: __perf_event_task_sched_in+0x1f9/0xbc0 [ 39.921819] #3: ffffffff8725cd00 (rcu_read_lock){....}-{1:3}, at: perf_event_wakeup+0x6c/0x470
{
"affected": [],
"aliases": [
"CVE-2026-23311"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-25T11:16:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Fix invalid wait context in ctx_sched_in()\n\nLockdep found a bug in the event scheduling when a pinned event was\nfailed and wakes up the threads in the ring buffer like below.\n\nIt seems it should not grab a wait-queue lock under perf-context lock.\nLet\u0027s do it with irq_work.\n\n [ 39.913691] =============================\n [ 39.914157] [ BUG: Invalid wait context ]\n [ 39.914623] 6.15.0-next-20250530-next-2025053 #1 Not tainted\n [ 39.915271] -----------------------------\n [ 39.915731] repro/837 is trying to lock:\n [ 39.916191] ffff88801acfabd8 (\u0026event-\u003ewaitq){....}-{3:3}, at: __wake_up+0x26/0x60\n [ 39.917182] other info that might help us debug this:\n [ 39.917761] context-{5:5}\n [ 39.918079] 4 locks held by repro/837:\n [ 39.918530] #0: ffffffff8725cd00 (rcu_read_lock){....}-{1:3}, at: __perf_event_task_sched_in+0xd1/0xbc0\n [ 39.919612] #1: ffff88806ca3c6f8 (\u0026cpuctx_lock){....}-{2:2}, at: __perf_event_task_sched_in+0x1a7/0xbc0\n [ 39.920748] #2: ffff88800d91fc18 (\u0026ctx-\u003elock){....}-{2:2}, at: __perf_event_task_sched_in+0x1f9/0xbc0\n [ 39.921819] #3: ffffffff8725cd00 (rcu_read_lock){....}-{1:3}, at: perf_event_wakeup+0x6c/0x470",
"id": "GHSA-h7wr-qv5c-937x",
"modified": "2026-05-26T15:32:06Z",
"published": "2026-03-25T12:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23311"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/486ff5ad49bc50315bcaf6d45f04a33ef0a45ced"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/825f218ca70ef394c2b8546b313711d867b24584"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c67ab059953e3b66cb17ddd6524c23f9e1f6526d"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H97W-34CR-4PXX
Vulnerability from github – Published: 2025-02-27 03:34 – Updated: 2026-05-12 15:30In the Linux kernel, the following vulnerability has been resolved:
clocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context
The following bug report happened with a PREEMPT_RT kernel:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog preempt_count: 1, expected: 0 RCU nest depth: 0, expected: 0 get_random_u32+0x4f/0x110 clocksource_verify_choose_cpus+0xab/0x1a0 clocksource_verify_percpu.part.0+0x6b/0x330 clocksource_watchdog_kthread+0x193/0x1a0
It is due to the fact that clocksource_verify_choose_cpus() is invoked with preemption disabled. This function invokes get_random_u32() to obtain random numbers for choosing CPUs. The batched_entropy_32 local lock and/or the base_crng.lock spinlock in driver/char/random.c will be acquired during the call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot be acquired in atomic context.
Fix this problem by using migrate_disable() to allow smp_processor_id() to be reliably used without introducing atomic context. preempt_disable() is then called after clocksource_verify_choose_cpus() but before the clocksource measurement is being run to avoid introducing unexpected latency.
{
"affected": [],
"aliases": [
"CVE-2025-21767"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-27T03:15:17Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nclocksource: Use migrate_disable() to avoid calling get_random_u32() in atomic context\n\nThe following bug report happened with a PREEMPT_RT kernel:\n\n BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2012, name: kwatchdog\n preempt_count: 1, expected: 0\n RCU nest depth: 0, expected: 0\n get_random_u32+0x4f/0x110\n clocksource_verify_choose_cpus+0xab/0x1a0\n clocksource_verify_percpu.part.0+0x6b/0x330\n clocksource_watchdog_kthread+0x193/0x1a0\n\nIt is due to the fact that clocksource_verify_choose_cpus() is invoked with\npreemption disabled. This function invokes get_random_u32() to obtain\nrandom numbers for choosing CPUs. The batched_entropy_32 local lock and/or\nthe base_crng.lock spinlock in driver/char/random.c will be acquired during\nthe call. In PREEMPT_RT kernel, they are both sleeping locks and so cannot\nbe acquired in atomic context.\n\nFix this problem by using migrate_disable() to allow smp_processor_id() to\nbe reliably used without introducing atomic context. preempt_disable() is\nthen called after clocksource_verify_choose_cpus() but before the\nclocksource measurement is being run to avoid introducing unexpected\nlatency.",
"id": "GHSA-h97w-34cr-4pxx",
"modified": "2026-05-12T15:30:48Z",
"published": "2025-02-27T03:34:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21767"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0fb534187d2355f6c8f995321e76d1ccd1262ac1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60f54f0d4ea530950549a8263e6fdd70a40490a4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6bb05a33337b2c842373857b63de5c9bf1ae2a09"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/852805b6cbdb69c298a8fc9fbe79994c95106e04"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8783ceeee797d9aa9cfe150690fb9d0bac8cc459"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cc3d79e7c806cb57d71c28a4a35e7d7fb3265faa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d9c217fadfcff7a8df58567517d1e4253f3fd243"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00028.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-H99J-GM55-RRCW
Vulnerability from github – Published: 2026-06-24 18:32 – Updated: 2026-06-28 09:31In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER
When protocol sets HCI_PROTO_DEFER, hci_conn_request_evt() calls hci_connect_cfm(conn) without hdev->lock. Generally hci_connect_cfm() assumes it is held, and if conn is deleted concurrently -> UAF.
Only SCO and ISO set HCI_PROTO_DEFER and only for defer setup listen, and HCI_EV_CONN_REQUEST is not generated for ISO. In the non-deferred listening socket code paths, hci_connect_cfm(conn) is called with hdev->lock held.
Fix by holding the lock.
{
"affected": [],
"aliases": [
"CVE-2026-53072"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-24T17:17:21Z",
"severity": "HIGH"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: fix locking in hci_conn_request_evt() with HCI_PROTO_DEFER\n\nWhen protocol sets HCI_PROTO_DEFER, hci_conn_request_evt() calls\nhci_connect_cfm(conn) without hdev-\u003elock. Generally hci_connect_cfm()\nassumes it is held, and if conn is deleted concurrently -\u003e UAF.\n\nOnly SCO and ISO set HCI_PROTO_DEFER and only for defer setup listen,\nand HCI_EV_CONN_REQUEST is not generated for ISO. In the non-deferred\nlistening socket code paths, hci_connect_cfm(conn) is called with\nhdev-\u003elock held.\n\nFix by holding the lock.",
"id": "GHSA-h99j-gm55-rrcw",
"modified": "2026-06-28T09:31:40Z",
"published": "2026-06-24T18:32:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53072"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/385b2d0468a0871fc716c549fa3b0c257c7dbcb3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/541d5bf9b5afaf41090b2a3aa7b47f2db2ff801f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5c7209a341ff2ac338b2b0375c34a307b37c9ac2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/60e3f4ff02d1f2d55bfbf2ca32a97285a9771ee4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b4d226d01ab7da0d2027a2a1e3a6079152e5065"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9d4a6c0f43fc5e4d4f062e8e450e5483eb74176e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c27224daf0b08efbb2b24ed64b6139b294f5473a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c7777f534a8018ae4bb1c80d8925af4df588a314"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HC84-56CX-WR29
Vulnerability from github – Published: 2025-03-12 12:30 – Updated: 2025-03-13 18:32In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix softlockup in arena_map_free on 64k page kernel
On an aarch64 kernel with CONFIG_PAGE_SIZE_64KB=y, arena_htab tests cause a segmentation fault and soft lockup. The same failure is not observed with 4k pages on aarch64.
It turns out arena_map_free() is calling apply_to_existing_page_range() with the address returned by bpf_arena_get_kern_vm_start(). If this address is not page-aligned the code ends up calling apply_to_pte_range() with that unaligned address causing soft lockup.
Fix it by round up GUARD_SZ to PAGE_SIZE << 1 so that the division by 2 in bpf_arena_get_kern_vm_start() returns a page-aligned value.
{
"affected": [],
"aliases": [
"CVE-2025-21851"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-03-12T10:15:17Z",
"severity": "LOW"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix softlockup in arena_map_free on 64k page kernel\n\nOn an aarch64 kernel with CONFIG_PAGE_SIZE_64KB=y,\narena_htab tests cause a segmentation fault and soft lockup.\nThe same failure is not observed with 4k pages on aarch64.\n\nIt turns out arena_map_free() is calling\napply_to_existing_page_range() with the address returned by\nbpf_arena_get_kern_vm_start(). If this address is not page-aligned\nthe code ends up calling apply_to_pte_range() with that unaligned\naddress causing soft lockup.\n\nFix it by round up GUARD_SZ to PAGE_SIZE \u003c\u003c 1 so that the\ndivision by 2 in bpf_arena_get_kern_vm_start() returns\na page-aligned value.",
"id": "GHSA-hc84-56cx-wr29",
"modified": "2025-03-13T18:32:21Z",
"published": "2025-03-12T12:30:58Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-21851"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/517e8a7835e8cfb398a0aeb0133de50e31cae32b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/787d556a3de447e70964a4bdeba9196f62a62b1e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c1f3f3892d4526f18aaeffdb6068ce861e793ee3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-HC99-RGJ6-64QJ
Vulnerability from github – Published: 2025-03-14 00:30 – Updated: 2025-03-14 00:30In the Linux kernel, the following vulnerability has been resolved:
bcache: avoid journal no-space deadlock by reserving 1 journal bucket
The journal no-space deadlock was reported time to time. Such deadlock can happen in the following situation.
When all journal buckets are fully filled by active jset with heavy write I/O load, the cache set registration (after a reboot) will load all active jsets and inserting them into the btree again (which is called journal replay). If a journaled bkey is inserted into a btree node and results btree node split, new journal request might be triggered. For example, the btree grows one more level after the node split, then the root node record in cache device super block will be upgrade by bch_journal_meta() from bch_btree_set_root(). But there is no space in journal buckets, the journal replay has to wait for new journal bucket to be reclaimed after at least one journal bucket replayed. This is one example that how the journal no-space deadlock happens.
The solution to avoid the deadlock is to reserve 1 journal bucket in run time, and only permit the reserved journal bucket to be used during cache set registration procedure for things like journal replay. Then the journal space will never be fully filled, there is no chance for journal no-space deadlock to happen anymore.
This patch adds a new member "bool do_reserve" in struct journal, it is inititalized to 0 (false) when struct journal is allocated, and set to 1 (true) by bch_journal_space_reserve() when all initialization done in run_cache_set(). In the run time when journal_reclaim() tries to allocate a new journal bucket, free_journal_buckets() is called to check whether there are enough free journal buckets to use. If there is only 1 free journal bucket and journal->do_reserve is 1 (true), the last bucket is reserved and free_journal_buckets() will return 0 to indicate no free journal bucket. Then journal_reclaim() will give up, and try next time to see whetheer there is free journal bucket to allocate. By this method, there is always 1 jouranl bucket reserved in run time.
During the cache set registration, journal->do_reserve is 0 (false), so the reserved journal bucket can be used to avoid the no-space deadlock.
{
"affected": [],
"aliases": [
"CVE-2022-49327"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T07:01:09Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbcache: avoid journal no-space deadlock by reserving 1 journal bucket\n\nThe journal no-space deadlock was reported time to time. Such deadlock\ncan happen in the following situation.\n\nWhen all journal buckets are fully filled by active jset with heavy\nwrite I/O load, the cache set registration (after a reboot) will load\nall active jsets and inserting them into the btree again (which is\ncalled journal replay). If a journaled bkey is inserted into a btree\nnode and results btree node split, new journal request might be\ntriggered. For example, the btree grows one more level after the node\nsplit, then the root node record in cache device super block will be\nupgrade by bch_journal_meta() from bch_btree_set_root(). But there is no\nspace in journal buckets, the journal replay has to wait for new journal\nbucket to be reclaimed after at least one journal bucket replayed. This\nis one example that how the journal no-space deadlock happens.\n\nThe solution to avoid the deadlock is to reserve 1 journal bucket in\nrun time, and only permit the reserved journal bucket to be used during\ncache set registration procedure for things like journal replay. Then\nthe journal space will never be fully filled, there is no chance for\njournal no-space deadlock to happen anymore.\n\nThis patch adds a new member \"bool do_reserve\" in struct journal, it is\ninititalized to 0 (false) when struct journal is allocated, and set to\n1 (true) by bch_journal_space_reserve() when all initialization done in\nrun_cache_set(). In the run time when journal_reclaim() tries to\nallocate a new journal bucket, free_journal_buckets() is called to check\nwhether there are enough free journal buckets to use. If there is only\n1 free journal bucket and journal-\u003edo_reserve is 1 (true), the last\nbucket is reserved and free_journal_buckets() will return 0 to indicate\nno free journal bucket. Then journal_reclaim() will give up, and try\nnext time to see whetheer there is free journal bucket to allocate. By\nthis method, there is always 1 jouranl bucket reserved in run time.\n\nDuring the cache set registration, journal-\u003edo_reserve is 0 (false), so\nthe reserved journal bucket can be used to avoid the no-space deadlock.",
"id": "GHSA-hc99-rgj6-64qj",
"modified": "2025-03-14T00:30:51Z",
"published": "2025-03-14T00:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-49327"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1dda32aed6f62c163f38ff947ef5b3360e329159"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/32feee36c30ea06e38ccb8ae6e5c44c6eec790a6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5607652823ac65e2c6885e73bd46d5a4f9a20363"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/59afd4f287900c8187e968a4153ed35e6b48efce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6332ea3e35efa12dc08f0cbf5faea5e6e8eb0497"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HFFQ-87G8-8R3X
Vulnerability from github – Published: 2025-09-18 15:30 – Updated: 2025-12-11 18:30In the Linux kernel, the following vulnerability has been resolved:
padata: Always leave BHs disabled when running ->parallel()
A deadlock can happen when an overloaded system runs ->parallel() in the context of the current task:
padata_do_parallel
->parallel()
pcrypt_aead_enc/dec
padata_do_serial
spin_lock(&reorder->lock) // BHs still enabled
<interrupt>
...
__do_softirq
...
padata_do_serial
spin_lock(&reorder->lock)
It's a bug for BHs to be on in _do_serial as Steffen points out, so ensure they're off in the "current task" case like they are in padata_parallel_worker to avoid this situation.
{
"affected": [],
"aliases": [
"CVE-2022-50382"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-18T14:15:36Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npadata: Always leave BHs disabled when running -\u003eparallel()\n\nA deadlock can happen when an overloaded system runs -\u003eparallel() in the\ncontext of the current task:\n\n padata_do_parallel\n -\u003eparallel()\n pcrypt_aead_enc/dec\n padata_do_serial\n spin_lock(\u0026reorder-\u003elock) // BHs still enabled\n \u003cinterrupt\u003e\n ...\n __do_softirq\n ...\n padata_do_serial\n spin_lock(\u0026reorder-\u003elock)\n\nIt\u0027s a bug for BHs to be on in _do_serial as Steffen points out, so\nensure they\u0027re off in the \"current task\" case like they are in\npadata_parallel_worker to avoid this situation.",
"id": "GHSA-hffq-87g8-8r3x",
"modified": "2025-12-11T18:30:33Z",
"published": "2025-09-18T15:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-50382"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/17afa98bccec4f52203508b3f49b5f948c6fd6ac"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/34c3a47d20ae55b3600fed733bf96eafe9c500d5"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6cfa9e60c0f88fdec6368e081ab968411cc706b1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7337adb20fcc0aebb50eaff2bc5a8dd9a7c6743d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8e0681dd4eee029eb1d533d06993f7cb091efb73"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HFJ6-RQ3W-F48R
Vulnerability from github – Published: 2022-02-11 00:01 – Updated: 2023-08-08 15:31Improper locking in the Power Management Controller (PMC) for some Intel Chipset firmware before versions pmc_fw_lbg_c1-21ww02a and pmc_fw_lbg_b0-21ww02a may allow a privileged user to potentially enable denial of service via local access.
{
"affected": [],
"aliases": [
"CVE-2021-0147"
],
"database_specific": {
"cwe_ids": [
"CWE-662",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-09T23:15:00Z",
"severity": "MODERATE"
},
"details": "Improper locking in the Power Management Controller (PMC) for some Intel Chipset firmware before versions pmc_fw_lbg_c1-21ww02a and pmc_fw_lbg_b0-21ww02a may allow a privileged user to potentially enable denial of service via local access.",
"id": "GHSA-hfj6-rq3w-f48r",
"modified": "2023-08-08T15:31:43Z",
"published": "2022-02-11T00:01:00Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-0147"
},
{
"type": "WEB",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00470.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HFM8-Q4MR-MF9F
Vulnerability from github – Published: 2025-08-16 12:30 – Updated: 2025-11-18 18:32In the Linux kernel, the following vulnerability has been resolved:
virtio-net: fix recursived rtnl_lock() during probe()
The deadlock appears in a stack trace like:
virtnet_probe() rtnl_lock() virtio_config_changed_work() netdev_notify_peers() rtnl_lock()
It happens if the VMM sends a VIRTIO_NET_S_ANNOUNCE request while the virtio-net driver is still probing.
The config_work in probe() will get scheduled until virtnet_open() enables the config change notification via virtio_config_driver_enable().
{
"affected": [],
"aliases": [
"CVE-2025-38551"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-16T12:15:31Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio-net: fix recursived rtnl_lock() during probe()\n\nThe deadlock appears in a stack trace like:\n\n virtnet_probe()\n rtnl_lock()\n virtio_config_changed_work()\n netdev_notify_peers()\n rtnl_lock()\n\nIt happens if the VMM sends a VIRTIO_NET_S_ANNOUNCE request while the\nvirtio-net driver is still probing.\n\nThe config_work in probe() will get scheduled until virtnet_open() enables\nthe config change notification via virtio_config_driver_enable().",
"id": "GHSA-hfm8-q4mr-mf9f",
"modified": "2025-11-18T18:32:49Z",
"published": "2025-08-16T12:30:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-38551"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3859f137b3c1fa1f0031d54263234566bdcdd7aa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4e7c46362550b229354aeb52038f414e231b0037"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/be5dcaed694e4255dc02dd0acfe036708c535def"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
Mitigation
Strategy: Libraries or Frameworks
Use industry standard APIs to implement locking mechanism.
CAPEC-25: Forced Deadlock
The adversary triggers and exploits a deadlock condition in the target software to cause a denial of service. A deadlock can occur when two or more competing actions are waiting for each other to finish, and thus neither ever does. Deadlock conditions can be difficult to detect.
CAPEC-26: Leveraging Race Conditions
The adversary targets a race condition occurring when multiple processes access and manipulate the same resource concurrently, and the outcome of the execution depends on the particular order in which the access takes place. The adversary can leverage a race condition by "running the race", modifying the resource and modifying the normal execution flow. For instance, a race condition can occur while accessing a file: the adversary can trick the system by replacing the original file with their version and cause the system to read the malicious file.
CAPEC-27: Leveraging Race Conditions via Symbolic Links
This attack leverages the use of symbolic links (Symlinks) in order to write to sensitive files. An attacker can create a Symlink link to a target file not otherwise accessible to them. When the privileged program tries to create a temporary file with the same name as the Symlink link, it will actually write to the target file pointed to by the attackers' Symlink link. If the attacker can insert malicious content in the temporary file they will be writing to the sensitive file by using the Symlink. The race occurs because the system checks if the temporary file exists, then creates the file. The attacker would typically create the Symlink during the interval between the check and the creation of the temporary file.