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.
693 vulnerabilities reference this CWE, most recent first.
GHSA-HH6Q-PGH2-779F
Vulnerability from github – Published: 2024-03-06 09:30 – Updated: 2025-02-14 18:30In the Linux kernel, the following vulnerability has been resolved:
IB/ipoib: Fix mcast list locking
Releasing the priv->lock while iterating the priv->multicast_list in
ipoib_mcast_join_task() opens a window for ipoib_mcast_dev_flush() to
remove the items while in the middle of iteration. If the mcast is removed
while the lock was dropped, the for loop spins forever resulting in a hard
lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):
Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)
-----------------------------------+-----------------------------------
ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work)
spin_lock_irq(&priv->lock) | __ipoib_ib_dev_flush(priv, ...)
list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv->dev)
&priv->multicast_list, list) |
ipoib_mcast_join(dev, mcast) |
spin_unlock_irq(&priv->lock) |
| spin_lock_irqsave(&priv->lock, flags)
| list_for_each_entry_safe(mcast, tmcast,
| &priv->multicast_list, list)
| list_del(&mcast->list);
| list_add_tail(&mcast->list, &remove_list)
| spin_unlock_irqrestore(&priv->lock, flags)
spin_lock_irq(&priv->lock) |
| ipoib_mcast_remove_list(&remove_list)
(Here, mcast is no longer on the | list_for_each_entry_safe(mcast, tmcast,
priv->multicast_list and we keep | remove_list, list)
spinning on the remove_list of | >>> wait_for_completion(&mcast->done)
the other thread which is blocked |
and the list is still valid on |
it's stack.)
Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent eventual sleeps. Unfortunately we could not reproduce the lockup and confirm this fix but based on the code review I think this fix should address such lockups.
crash> bc 31 PID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: "kworker/u72:2" -- [exception RIP: ipoib_mcast_join_task+0x1b1] RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002 RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000 work (&priv->mcast_task{,.work}) RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000 &mcast->list RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000 R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00 mcast R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8 dev priv (&priv->lock) &priv->multicast_list (aka head) ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 --- --- #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib] #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967
crash> rx ff646f199a8c7e68 ff646f199a8c7e68: ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work
crash> list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000 (empty)
crash> ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000 mcast_task.work.func = 0xffffffffc0944910 , mcast_mutex.owner.counter = 0xff1c69998efec000
crash> b 8 PID: 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: "kworker/u72:0" -- #3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646 #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib] #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib] #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib] #7 [ff ---truncated---
{
"affected": [],
"aliases": [
"CVE-2023-52587"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-06T07:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/ipoib: Fix mcast list locking\n\nReleasing the `priv-\u003elock` while iterating the `priv-\u003emulticast_list` in\n`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to\nremove the items while in the middle of iteration. If the mcast is removed\nwhile the lock was dropped, the for loop spins forever resulting in a hard\nlockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):\n\n Task A (kworker/u72:2 below) | Task B (kworker/u72:0 below)\n -----------------------------------+-----------------------------------\n ipoib_mcast_join_task(work) | ipoib_ib_dev_flush_light(work)\n spin_lock_irq(\u0026priv-\u003elock) | __ipoib_ib_dev_flush(priv, ...)\n list_for_each_entry(mcast, | ipoib_mcast_dev_flush(dev = priv-\u003edev)\n \u0026priv-\u003emulticast_list, list) |\n ipoib_mcast_join(dev, mcast) |\n spin_unlock_irq(\u0026priv-\u003elock) |\n | spin_lock_irqsave(\u0026priv-\u003elock, flags)\n | list_for_each_entry_safe(mcast, tmcast,\n | \u0026priv-\u003emulticast_list, list)\n | list_del(\u0026mcast-\u003elist);\n | list_add_tail(\u0026mcast-\u003elist, \u0026remove_list)\n | spin_unlock_irqrestore(\u0026priv-\u003elock, flags)\n spin_lock_irq(\u0026priv-\u003elock) |\n | ipoib_mcast_remove_list(\u0026remove_list)\n (Here, `mcast` is no longer on the | list_for_each_entry_safe(mcast, tmcast,\n `priv-\u003emulticast_list` and we keep | remove_list, list)\n spinning on the `remove_list` of | \u003e\u003e\u003e wait_for_completion(\u0026mcast-\u003edone)\n the other thread which is blocked |\n and the list is still valid on |\n it\u0027s stack.)\n\nFix this by keeping the lock held and changing to GFP_ATOMIC to prevent\neventual sleeps.\nUnfortunately we could not reproduce the lockup and confirm this fix but\nbased on the code review I think this fix should address such lockups.\n\ncrash\u003e bc 31\nPID: 747 TASK: ff1c6a1a007e8000 CPU: 31 COMMAND: \"kworker/u72:2\"\n--\n [exception RIP: ipoib_mcast_join_task+0x1b1]\n RIP: ffffffffc0944ac1 RSP: ff646f199a8c7e00 RFLAGS: 00000002\n RAX: 0000000000000000 RBX: ff1c6a1a04dc82f8 RCX: 0000000000000000\n work (\u0026priv-\u003emcast_task{,.work})\n RDX: ff1c6a192d60ac68 RSI: 0000000000000286 RDI: ff1c6a1a04dc8000\n \u0026mcast-\u003elist\n RBP: ff646f199a8c7e90 R8: ff1c699980019420 R9: ff1c6a1920c9a000\n R10: ff646f199a8c7e00 R11: ff1c6a191a7d9800 R12: ff1c6a192d60ac00\n mcast\n R13: ff1c6a1d82200000 R14: ff1c6a1a04dc8000 R15: ff1c6a1a04dc82d8\n dev priv (\u0026priv-\u003elock) \u0026priv-\u003emulticast_list (aka head)\n ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018\n--- \u003cNMI exception stack\u003e ---\n #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib]\n #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967\n\ncrash\u003e rx ff646f199a8c7e68\nff646f199a8c7e68: ff1c6a1a04dc82f8 \u003c\u003c\u003c work = \u0026priv-\u003emcast_task.work\n\ncrash\u003e list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000\n(empty)\n\ncrash\u003e ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000\n mcast_task.work.func = 0xffffffffc0944910 \u003cipoib_mcast_join_task\u003e,\n mcast_mutex.owner.counter = 0xff1c69998efec000\n\ncrash\u003e b 8\nPID: 8 TASK: ff1c69998efec000 CPU: 33 COMMAND: \"kworker/u72:0\"\n--\n #3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646\n #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib]\n #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib]\n #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib]\n #7 [ff\n---truncated---",
"id": "GHSA-hh6q-pgh2-779f",
"modified": "2025-02-14T18:30:44Z",
"published": "2024-03-06T09:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52587"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/342258fb46d66c1b4c7e2c3717ac01e10c03cf18"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4c8922ae8eb8dcc1e4b7d1059d97a8334288d825"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4f973e211b3b1c6d36f7c6a19239d258856749f9"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5108a2dc2db5630fb6cd58b8be80a0c134bc310a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/615e3adc2042b7be4ad122a043fc9135e6342c90"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7c7bd4d561e9dc6f5b7df9e184974915f6701a89"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac2630fd3c90ffec34a0bfc4d413668538b0e8f2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ed790bd0903ed3352ebf7f650d910f49b7319b34"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00020.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-HH73-MJW2-25FW
Vulnerability from github – Published: 2024-05-22 09:31 – Updated: 2025-09-24 21:30In the Linux kernel, the following vulnerability has been resolved:
isdn: mISDN: Fix sleeping function called from invalid context
The driver can call card->isac.release() function from an atomic context.
Fix this by calling this function after releasing the lock.
The following log reveals it:
[ 44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018 [ 44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe [ 44.169574 ] INFO: lockdep is turned off. [ 44.169899 ] irq event stamp: 0 [ 44.170160 ] hardirqs last enabled at (0): [<0000000000000000>] 0x0 [ 44.170627 ] hardirqs last disabled at (0): [] copy_process+0x132d/0x3e00 [ 44.171240 ] softirqs last enabled at (0): [] copy_process+0x135a/0x3e00 [ 44.171852 ] softirqs last disabled at (0): [<0000000000000000>] 0x0 [ 44.172318 ] Preemption disabled at: [ 44.172320 ] [] nj_release+0x69/0x500 [netjet] [ 44.174441 ] Call Trace: [ 44.174630 ] dump_stack_lvl+0xa8/0xd1 [ 44.174912 ] dump_stack+0x15/0x17 [ 44.175166 ] mightsleep+0x3a2/0x510 [ 44.175459 ] ? nj_release+0x69/0x500 [netjet] [ 44.175791 ] might_sleep+0x82/0xe0 [ 44.176063 ] ? start_flush_work+0x20/0x7b0 [ 44.176375 ] start_flush_work+0x33/0x7b0 [ 44.176672 ] ? trace_irq_enable_rcuidle+0x85/0x170 [ 44.177034 ] ? kasan_quarantine_put+0xaa/0x1f0 [ 44.177372 ] ? kasan_quarantine_put+0xaa/0x1f0 [ 44.177711 ] __flush_work+0x11a/0x1a0 [ 44.177991 ] ? flush_work+0x20/0x20 [ 44.178257 ] ? lock_release+0x13c/0x8f0 [ 44.178550 ] ? __kasan_check_write+0x14/0x20 [ 44.178872 ] ? do_raw_spin_lock+0x148/0x360 [ 44.179187 ] ? read_lock_is_recursive+0x20/0x20 [ 44.179530 ] ? __kasan_check_read+0x11/0x20 [ 44.179846 ] ? do_raw_spin_unlock+0x55/0x900 [ 44.180168 ] ? ____kasan_slab_free+0x116/0x140 [ 44.180505 ] ? _raw_spin_unlock_irqrestore+0x41/0x60 [ 44.180878 ] ? skb_queue_purge+0x1a3/0x1c0 [ 44.181189 ] ? kfree+0x13e/0x290 [ 44.181438 ] flush_work+0x17/0x20 [ 44.181695 ] mISDN_freedchannel+0xe8/0x100 [ 44.182006 ] isac_release+0x210/0x260 [mISDNipac] [ 44.182366 ] nj_release+0xf6/0x500 [netjet] [ 44.182685 ] nj_remove+0x48/0x70 [netjet] [ 44.182989 ] pci_device_remove+0xa9/0x250
{
"affected": [],
"aliases": [
"CVE-2021-47468"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-22T07:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nisdn: mISDN: Fix sleeping function called from invalid context\n\nThe driver can call card-\u003eisac.release() function from an atomic\ncontext.\n\nFix this by calling this function after releasing the lock.\n\nThe following log reveals it:\n\n[ 44.168226 ] BUG: sleeping function called from invalid context at kernel/workqueue.c:3018\n[ 44.168941 ] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 5475, name: modprobe\n[ 44.169574 ] INFO: lockdep is turned off.\n[ 44.169899 ] irq event stamp: 0\n[ 44.170160 ] hardirqs last enabled at (0): [\u003c0000000000000000\u003e] 0x0\n[ 44.170627 ] hardirqs last disabled at (0): [\u003cffffffff814209ed\u003e] copy_process+0x132d/0x3e00\n[ 44.171240 ] softirqs last enabled at (0): [\u003cffffffff81420a1a\u003e] copy_process+0x135a/0x3e00\n[ 44.171852 ] softirqs last disabled at (0): [\u003c0000000000000000\u003e] 0x0\n[ 44.172318 ] Preemption disabled at:\n[ 44.172320 ] [\u003cffffffffa009b0a9\u003e] nj_release+0x69/0x500 [netjet]\n[ 44.174441 ] Call Trace:\n[ 44.174630 ] dump_stack_lvl+0xa8/0xd1\n[ 44.174912 ] dump_stack+0x15/0x17\n[ 44.175166 ] ___might_sleep+0x3a2/0x510\n[ 44.175459 ] ? nj_release+0x69/0x500 [netjet]\n[ 44.175791 ] __might_sleep+0x82/0xe0\n[ 44.176063 ] ? start_flush_work+0x20/0x7b0\n[ 44.176375 ] start_flush_work+0x33/0x7b0\n[ 44.176672 ] ? trace_irq_enable_rcuidle+0x85/0x170\n[ 44.177034 ] ? kasan_quarantine_put+0xaa/0x1f0\n[ 44.177372 ] ? kasan_quarantine_put+0xaa/0x1f0\n[ 44.177711 ] __flush_work+0x11a/0x1a0\n[ 44.177991 ] ? flush_work+0x20/0x20\n[ 44.178257 ] ? lock_release+0x13c/0x8f0\n[ 44.178550 ] ? __kasan_check_write+0x14/0x20\n[ 44.178872 ] ? do_raw_spin_lock+0x148/0x360\n[ 44.179187 ] ? read_lock_is_recursive+0x20/0x20\n[ 44.179530 ] ? __kasan_check_read+0x11/0x20\n[ 44.179846 ] ? do_raw_spin_unlock+0x55/0x900\n[ 44.180168 ] ? ____kasan_slab_free+0x116/0x140\n[ 44.180505 ] ? _raw_spin_unlock_irqrestore+0x41/0x60\n[ 44.180878 ] ? skb_queue_purge+0x1a3/0x1c0\n[ 44.181189 ] ? kfree+0x13e/0x290\n[ 44.181438 ] flush_work+0x17/0x20\n[ 44.181695 ] mISDN_freedchannel+0xe8/0x100\n[ 44.182006 ] isac_release+0x210/0x260 [mISDNipac]\n[ 44.182366 ] nj_release+0xf6/0x500 [netjet]\n[ 44.182685 ] nj_remove+0x48/0x70 [netjet]\n[ 44.182989 ] pci_device_remove+0xa9/0x250",
"id": "GHSA-hh73-mjw2-25fw",
"modified": "2025-09-24T21:30:30Z",
"published": "2024-05-22T09:31:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47468"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/37e4f57b22cc5ebb3f80cf0f74fdeb487f082367"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4054b869dc263228d30a4755800b78f0f2ba0c89"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6510e80a0b81b5d814e3aea6297ba42f5e76f73c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f95c97e0f9d6eb39c3f2cb45e8fa4268d1b372b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9f591cbdbed3d7822b2bdba89b34a6d7b434317d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a5b34409d3fc52114c828be4adbc30744fa3258b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ef269a8808cb1759245a98a7fe16fceaebad894c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f5966ba53013149bcf94e1536644a958dd00a026"
}
],
"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-HHXW-8C9W-Q5Q9
Vulnerability from github – Published: 2022-05-24 17:41 – Updated: 2022-06-29 00:00A local privilege escalation was discovered in the Linux kernel before 5.10.13. Multiple race conditions in the AF_VSOCK implementation are caused by wrong locking in net/vmw_vsock/af_vsock.c. The race conditions were implicitly introduced in the commits that added VSOCK multi-transport support.
{
"affected": [],
"aliases": [
"CVE-2021-26708"
],
"database_specific": {
"cwe_ids": [
"CWE-269",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-05T14:15:00Z",
"severity": "HIGH"
},
"details": "A local privilege escalation was discovered in the Linux kernel before 5.10.13. Multiple race conditions in the AF_VSOCK implementation are caused by wrong locking in net/vmw_vsock/af_vsock.c. The race conditions were implicitly introduced in the commits that added VSOCK multi-transport support.",
"id": "GHSA-hhxw-8c9w-q5q9",
"modified": "2022-06-29T00:00:48Z",
"published": "2022-05-24T17:41:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26708"
},
{
"type": "WEB",
"url": "https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.10.13"
},
{
"type": "WEB",
"url": "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c518adafa39f37858697ac9309c6cf1805581446"
},
{
"type": "WEB",
"url": "https://security.netapp.com/advisory/ntap-20210312-0008"
},
{
"type": "WEB",
"url": "https://www.openwall.com/lists/oss-security/2021/02/04/5"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/02/05/6"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2021/04/09/2"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/01/25/14"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-HJ3C-GWRC-6JCH
Vulnerability from github – Published: 2024-07-30 09:31 – Updated: 2026-05-12 12:32In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM to 2^31.
We had a similar issue in sch_fq, fixed with commit d9e15a273306 ("pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM")
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24] Modules linked in: irq event stamp: 131135 hardirqs last enabled at (131134): [] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline] hardirqs last enabled at (131134): [] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95 hardirqs last disabled at (131135): [] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline] hardirqs last disabled at (131135): [] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551 softirqs last enabled at (125892): [] neigh_hh_init net/core/neighbour.c:1538 [inline] softirqs last enabled at (125892): [] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553 softirqs last disabled at (125896): [] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19 CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Workqueue: mld mld_ifc_work pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __list_del include/linux/list.h:195 [inline] pc : __list_del_entry include/linux/list.h:218 [inline] pc : list_move_tail include/linux/list.h:310 [inline] pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline] pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 lr : __list_del_entry include/linux/list.h:218 [inline] lr : list_move_tail include/linux/list.h:310 [inline] lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline] lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854 sp : ffff800093d36700 x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000 x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0 x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0 x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0 x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8 x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000 x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470 Call trace: __list_del include/linux/list.h:195 [inline] __list_del_entry include/linux/list.h:218 [inline] list_move_tail include/linux/list.h:310 [inline] fq_tin_dequeue include/net/fq_impl.h:112 [inline] ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854 wake_tx_push_queue net/mac80211/util.c:294 [inline] ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315 drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline] schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline] ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664 ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966 ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062 __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338 ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547 __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563 neigh_output include/net/neighbour.h:542 [inline] ip6_fini ---truncated---
{
"affected": [],
"aliases": [
"CVE-2024-42114"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-30T08:15:03Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values\n\nsyzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM\nto 2^31.\n\nWe had a similar issue in sch_fq, fixed with commit\nd9e15a273306 (\"pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM\")\n\nwatchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]\nModules linked in:\nirq event stamp: 131135\n hardirqs last enabled at (131134): [\u003cffff80008ae8778c\u003e] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]\n hardirqs last enabled at (131134): [\u003cffff80008ae8778c\u003e] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95\n hardirqs last disabled at (131135): [\u003cffff80008ae85378\u003e] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\n hardirqs last disabled at (131135): [\u003cffff80008ae85378\u003e] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\n softirqs last enabled at (125892): [\u003cffff80008907e82c\u003e] neigh_hh_init net/core/neighbour.c:1538 [inline]\n softirqs last enabled at (125892): [\u003cffff80008907e82c\u003e] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553\n softirqs last disabled at (125896): [\u003cffff80008904166c\u003e] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19\nCPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nWorkqueue: mld mld_ifc_work\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __list_del include/linux/list.h:195 [inline]\n pc : __list_del_entry include/linux/list.h:218 [inline]\n pc : list_move_tail include/linux/list.h:310 [inline]\n pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854\n lr : __list_del_entry include/linux/list.h:218 [inline]\n lr : list_move_tail include/linux/list.h:310 [inline]\n lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854\nsp : ffff800093d36700\nx29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000\nx26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0\nx23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0\nx20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0\nx17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8\nx14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff\nx11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc\nx2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470\nCall trace:\n __list_del include/linux/list.h:195 [inline]\n __list_del_entry include/linux/list.h:218 [inline]\n list_move_tail include/linux/list.h:310 [inline]\n fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854\n wake_tx_push_queue net/mac80211/util.c:294 [inline]\n ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315\n drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]\n schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]\n ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664\n ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966\n ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062\n __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338\n ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532\n __netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n netdev_start_xmit include/linux/netdevice.h:4917 [inline]\n xmit_one net/core/dev.c:3531 [inline]\n dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547\n __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341\n dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563\n neigh_output include/net/neighbour.h:542 [inline]\n ip6_fini\n---truncated---",
"id": "GHSA-hj3c-gwrc-6jch",
"modified": "2026-05-12T12:32:03Z",
"published": "2024-07-30T09:31:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42114"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/33ac5a4eb3d4bea2146658f1b6d1fa86d62d2b22"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3fc06f6d142d2840735543216a60d0a8c345bdec"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/80ac0cc9c0bef984e29637b1efa93d7214b42f53"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8a3ac7fb36962c34698f884bd697938054ff2afa"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d1cba2ea8121e7fdbe1328cea782876b1dd80993"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e87c2f098f52aa2fe20258a5bb1738d6a74e9ed7"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/10/msg00003.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/01/msg00001.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-HJGX-24CQ-764X
Vulnerability from github – Published: 2026-02-14 18:30 – Updated: 2026-03-19 18:31In the Linux kernel, the following vulnerability has been resolved:
procfs: avoid fetching build ID while holding VMA lock
Fix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock or per-VMA lock, whichever was used to lock VMA under question, to avoid deadlock reported by syzbot:
-> #1 (&mm->mmap_lock){++++}-{4:4}: __might_fault+0xed/0x170 _copy_to_iter+0x118/0x1720 copy_page_to_iter+0x12d/0x1e0 filemap_read+0x720/0x10a0 blkdev_read_iter+0x2b5/0x4e0 vfs_read+0x7f4/0xae0 ksys_read+0x12a/0x250 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&sb->s_type->i_mutex_key#8){++++}-{4:4}: __lock_acquire+0x1509/0x26d0 lock_acquire+0x185/0x340 down_read+0x98/0x490 blkdev_read_iter+0x2a7/0x4e0 __kernel_read+0x39a/0xa90 freader_fetch+0x1d5/0xa80 __build_id_parse.isra.0+0xea/0x6a0 do_procmap_query+0xd75/0x1050 procfs_procmap_ioctl+0x7a/0xb0 __x64_sys_ioctl+0x18e/0x210 do_syscall_64+0xcb/0xf80 entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
rlock(&mm->mmap_lock); lock(&sb->s_type->i_mutex_key#8); lock(&mm->mmap_lock); rlock(&sb->s_type->i_mutex_key#8);
*** DEADLOCK ***
This seems to be exacerbated (as we haven't seen these syzbot reports before that) by the recent:
777a8560fd29 ("lib/buildid: use __kernel_read() for sleepable context")
To make this safe, we need to grab file refcount while VMA is still locked, but other than that everything is pretty straightforward. Internal build_id_parse() API assumes VMA is passed, but it only needs the underlying file reference, so just add another variant build_id_parse_file() that expects file passed directly.
[akpm@linux-foundation.org: fix up kerneldoc]
{
"affected": [],
"aliases": [
"CVE-2026-23199"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-14T17:15:57Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nprocfs: avoid fetching build ID while holding VMA lock\n\nFix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock\nor per-VMA lock, whichever was used to lock VMA under question, to avoid\ndeadlock reported by syzbot:\n\n -\u003e #1 (\u0026mm-\u003emmap_lock){++++}-{4:4}:\n __might_fault+0xed/0x170\n _copy_to_iter+0x118/0x1720\n copy_page_to_iter+0x12d/0x1e0\n filemap_read+0x720/0x10a0\n blkdev_read_iter+0x2b5/0x4e0\n vfs_read+0x7f4/0xae0\n ksys_read+0x12a/0x250\n do_syscall_64+0xcb/0xf80\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n -\u003e #0 (\u0026sb-\u003es_type-\u003ei_mutex_key#8){++++}-{4:4}:\n __lock_acquire+0x1509/0x26d0\n lock_acquire+0x185/0x340\n down_read+0x98/0x490\n blkdev_read_iter+0x2a7/0x4e0\n __kernel_read+0x39a/0xa90\n freader_fetch+0x1d5/0xa80\n __build_id_parse.isra.0+0xea/0x6a0\n do_procmap_query+0xd75/0x1050\n procfs_procmap_ioctl+0x7a/0xb0\n __x64_sys_ioctl+0x18e/0x210\n do_syscall_64+0xcb/0xf80\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n other info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n CPU0 CPU1\n ---- ----\n rlock(\u0026mm-\u003emmap_lock);\n lock(\u0026sb-\u003es_type-\u003ei_mutex_key#8);\n lock(\u0026mm-\u003emmap_lock);\n rlock(\u0026sb-\u003es_type-\u003ei_mutex_key#8);\n\n *** DEADLOCK ***\n\nThis seems to be exacerbated (as we haven\u0027t seen these syzbot reports\nbefore that) by the recent:\n\n\t777a8560fd29 (\"lib/buildid: use __kernel_read() for sleepable context\")\n\nTo make this safe, we need to grab file refcount while VMA is still locked, but\nother than that everything is pretty straightforward. Internal build_id_parse()\nAPI assumes VMA is passed, but it only needs the underlying file reference, so\njust add another variant build_id_parse_file() that expects file passed\ndirectly.\n\n[akpm@linux-foundation.org: fix up kerneldoc]",
"id": "GHSA-hjgx-24cq-764x",
"modified": "2026-03-19T18:31:14Z",
"published": "2026-02-14T18:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23199"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b5cbacd7f86f4f62b8813688c8e73be94e8e1951"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b9b97e6aeb534315f9646b2090d1a5024c6a4e82"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cbc03ce3e6ce7e21214c3f02218213574c1a2d08"
}
],
"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-HJJF-XJVR-567J
Vulnerability from github – Published: 2026-02-14 18:30 – Updated: 2026-03-19 18:31In the Linux kernel, the following vulnerability has been resolved:
net: usb: r8152: fix resume reset deadlock
rtl8152 can trigger device reset during reset which potentially can result in a deadlock:
* DPM device timeout after 10 seconds; 15 seconds until panic * Call Trace: schedule+0x483/0x1370 schedule_preempt_disabled+0x15/0x30 __mutex_lock_common+0x1fd/0x470 __rtl8152_set_mac_address+0x80/0x1f0 dev_set_mac_address+0x7f/0x150 rtl8152_post_reset+0x72/0x150 usb_reset_device+0x1d0/0x220 rtl8152_resume+0x99/0xc0 usb_resume_interface+0x3e/0xc0 usb_resume_both+0x104/0x150 usb_resume+0x22/0x110
The problem is that rtl8152 resume calls reset under tp->control mutex while reset basically re-enters rtl8152 and attempts to acquire the same tp->control lock once again.
Reset INACCESSIBLE device outside of tp->control mutex scope to avoid recursive mutex_lock() deadlock.
{
"affected": [],
"aliases": [
"CVE-2026-23188"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-14T17:15:56Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: r8152: fix resume reset deadlock\n\nrtl8152 can trigger device reset during reset which\npotentially can result in a deadlock:\n\n **** DPM device timeout after 10 seconds; 15 seconds until panic ****\n Call Trace:\n \u003cTASK\u003e\n schedule+0x483/0x1370\n schedule_preempt_disabled+0x15/0x30\n __mutex_lock_common+0x1fd/0x470\n __rtl8152_set_mac_address+0x80/0x1f0\n dev_set_mac_address+0x7f/0x150\n rtl8152_post_reset+0x72/0x150\n usb_reset_device+0x1d0/0x220\n rtl8152_resume+0x99/0xc0\n usb_resume_interface+0x3e/0xc0\n usb_resume_both+0x104/0x150\n usb_resume+0x22/0x110\n\nThe problem is that rtl8152 resume calls reset under\ntp-\u003econtrol mutex while reset basically re-enters rtl8152\nand attempts to acquire the same tp-\u003econtrol lock once\nagain.\n\nReset INACCESSIBLE device outside of tp-\u003econtrol mutex\nscope to avoid recursive mutex_lock() deadlock.",
"id": "GHSA-hjjf-xjvr-567j",
"modified": "2026-03-19T18:31:14Z",
"published": "2026-02-14T18:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23188"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/1b2efc593dca99d8e8e6f6d6c7ccd9a972679702"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/61c8091b7937f91f9bc0b7f6b578de270fe35dc7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6d06bc83a5ae8777a5f7a81c32dd75b8d9b2fe04"
}
],
"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-HMGJ-4596-MMPR
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2024-08-27 21:31In the Linux kernel, the following vulnerability has been resolved:
eth: sungem: remove .ndo_poll_controller to avoid deadlocks
Erhard reports netpoll warnings from sungem:
netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398) WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c
gem_poll_controller() disables interrupts, which may sleep. We can't sleep in netpoll, it has interrupts disabled completely. Strangely, gem_poll_controller() doesn't even poll the completions, and instead acts as if an interrupt has fired so it just schedules NAPI and exits. None of this has been necessary for years, since netpoll invokes NAPI directly.
{
"affected": [],
"aliases": [
"CVE-2024-38597"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T14:15:19Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\neth: sungem: remove .ndo_poll_controller to avoid deadlocks\n\nErhard reports netpoll warnings from sungem:\n\n netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)\n WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c\n\ngem_poll_controller() disables interrupts, which may sleep.\nWe can\u0027t sleep in netpoll, it has interrupts disabled completely.\nStrangely, gem_poll_controller() doesn\u0027t even poll the completions,\nand instead acts as if an interrupt has fired so it just schedules\nNAPI and exits. None of this has been necessary for years, since\nnetpoll invokes NAPI directly.",
"id": "GHSA-hmgj-4596-mmpr",
"modified": "2024-08-27T21:31:13Z",
"published": "2024-06-19T15:30:54Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38597"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/476adb3bbbd7886e8251d3b9ce2d3c3e680f35d6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5de5aeb98f9a000adb0db184e32765e4815d860b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6400d205fbbcbcf9b8510157e1f379c1d7e2e937"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/ac0a230f719b02432d8c7eba7615ebd691da86f4"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e22b23f5888a065d084e87db1eec639c445e677f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/faf94f1eb8a34b2c31b2042051ef36f63420ecce"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/fbeeb55dbb33d562149c57e794f06b7414e44289"
}
],
"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-HP4X-9RGH-5PGM
Vulnerability from github – Published: 2026-04-24 15:32 – Updated: 2026-07-14 15:31In the Linux kernel, the following vulnerability has been resolved:
RDMA/irdma: Fix deadlock during netdev reset with active connections
Resolve deadlock that occurs when user executes netdev reset while RDMA applications (e.g., rping) are active. The netdev reset causes ice driver to remove irdma auxiliary driver, triggering device_delete and subsequent client removal. During client removal, uverbs_client waits for QP reference count to reach zero while cma_client holds the final reference, creating circular dependency and indefinite wait in iWARP mode. Skip QP reference count wait during device reset to prevent deadlock.
{
"affected": [],
"aliases": [
"CVE-2026-31565"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-24T15:16:30Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/irdma: Fix deadlock during netdev reset with active connections\n\nResolve deadlock that occurs when user executes netdev reset while RDMA\napplications (e.g., rping) are active. The netdev reset causes ice\ndriver to remove irdma auxiliary driver, triggering device_delete and\nsubsequent client removal. During client removal, uverbs_client waits\nfor QP reference count to reach zero while cma_client holds the final\nreference, creating circular dependency and indefinite wait in iWARP\nmode. Skip QP reference count wait during device reset to prevent\ndeadlock.",
"id": "GHSA-hp4x-9rgh-5pgm",
"modified": "2026-07-14T15:31:54Z",
"published": "2026-04-24T15:32:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31565"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-019113.html"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-082556.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/009831768faeca3fb5950ce63f1b49594ec82389"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/464bbb844ba5b68e038220c34019069a0a9f1581"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6f52370970ac07d352a7af4089e55e0e6425f827"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a8a1c7621127a15a02494b96ee376406c064237b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/acb060bc2609c2eab49263968be59c7d59d497bc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/adf0de36e52a48681eb58cbd7cbf6c8d200caa2b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cd8bcec2de5e24e05c34c9391940fda6f50e79b4"
}
],
"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-HP99-HC25-26X7
Vulnerability from github – Published: 2025-12-09 18:30 – Updated: 2025-12-11 18:30A post-authentication flaw in the network two-phase commit protocol used for cross-shard transactions in MongoDB Server may lead to logical data inconsistencies under specific conditions which are not predictable and exist for a very short period of time. This error can cause the transaction coordination logic to misinterpret the transaction as committed, resulting in inconsistent state on those shards. This may lead to low integrity and availability impact.
This issue impacts MongoDB Server v8.0 versions prior to 8.0.16, MongoDB Server v7.0 versions prior to 7.0.26 and MongoDB server v8.2 versions prior to 8.2.2.
{
"affected": [],
"aliases": [
"CVE-2025-14345"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-09T16:17:41Z",
"severity": "LOW"
},
"details": "A post-authentication\u00a0flaw in the network two-phase commit protocol used for cross-shard transactions in MongoDB Server may lead to logical data inconsistencies under specific conditions which are not predictable and exist for a very short period of time. This error can cause the transaction coordination logic to misinterpret the transaction as committed, resulting in inconsistent state on those shards. This may lead to low integrity and availability impact.\n\nThis issue impacts MongoDB Server v8.0 versions prior to 8.0.16, MongoDB Server v7.0 versions prior to 7.0.26 and MongoDB server v8.2 versions prior to 8.2.2.",
"id": "GHSA-hp99-hc25-26x7",
"modified": "2025-12-11T18:30:41Z",
"published": "2025-12-09T18:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-14345"
},
{
"type": "WEB",
"url": "https://jira.mongodb.org/browse/SERVER-106075"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-HPR5-WWH9-PJHF
Vulnerability from github – Published: 2022-02-19 00:01 – Updated: 2022-10-07 18:15A locking protection bypass flaw was found in some versions of gnome-shell as shipped within CentOS Stream 8, when the "Application menu" or "Window list" GNOME extensions are enabled. This flaw allows a physical attacker who has access to a locked system to kill existing applications and start new ones as the locked user, even if the session is still locked.
{
"affected": [],
"aliases": [
"CVE-2021-20315"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-02-18T18:15:00Z",
"severity": "MODERATE"
},
"details": "A locking protection bypass flaw was found in some versions of gnome-shell as shipped within CentOS Stream 8, when the \"Application menu\" or \"Window list\" GNOME extensions are enabled. This flaw allows a physical attacker who has access to a locked system to kill existing applications and start new ones as the locked user, even if the session is still locked.",
"id": "GHSA-hpr5-wwh9-pjhf",
"modified": "2022-10-07T18:15:55Z",
"published": "2022-02-19T00:01:33Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-20315"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2006285"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:N/I:H/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.