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-PH47-5XQG-MR4X
Vulnerability from github – Published: 2023-06-06 15:30 – Updated: 2024-04-04 04:35In vcu, there is a possible use after free due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07645149; Issue ID: ALPS07645167.
{
"affected": [],
"aliases": [
"CVE-2023-20737"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-06T13:15:13Z",
"severity": "MODERATE"
},
"details": "In vcu, there is a possible use after free due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07645149; Issue ID: ALPS07645167.",
"id": "GHSA-ph47-5xqg-mr4x",
"modified": "2024-04-04T04:35:26Z",
"published": "2023-06-06T15:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20737"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/June-2023"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PH55-5XQF-59R7
Vulnerability from github – Published: 2024-03-11 18:31 – Updated: 2025-01-14 15:30In the Linux kernel, the following vulnerability has been resolved:
drm: Don't unref the same fb many times by mistake due to deadlock handling
If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl() we proceed to unref the fb and then retry the whole thing from the top. But we forget to reset the fb pointer back to NULL, and so if we then get another error during the retry, before the fb lookup, we proceed the unref the same fb again without having gotten another reference. The end result is that the fb will (eventually) end up being freed while it's still in use.
Reset fb to NULL once we've unreffed it to avoid doing it again until we've done another fb lookup.
This turned out to be pretty easy to hit on a DG2 when doing async flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I saw that drm_closefb() simply got stuck in a busy loop while walking the framebuffer list. Fortunately I was able to convince it to oops instead, and from there it was easier to track down the culprit.
{
"affected": [],
"aliases": [
"CVE-2023-52486"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-11T18:15:16Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: Don\u0027t unref the same fb many times by mistake due to deadlock handling\n\nIf we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()\nwe proceed to unref the fb and then retry the whole thing from the top.\nBut we forget to reset the fb pointer back to NULL, and so if we then\nget another error during the retry, before the fb lookup, we proceed\nthe unref the same fb again without having gotten another reference.\nThe end result is that the fb will (eventually) end up being freed\nwhile it\u0027s still in use.\n\nReset fb to NULL once we\u0027ve unreffed it to avoid doing it again\nuntil we\u0027ve done another fb lookup.\n\nThis turned out to be pretty easy to hit on a DG2 when doing async\nflips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I\nsaw that drm_closefb() simply got stuck in a busy loop while walking\nthe framebuffer list. Fortunately I was able to convince it to oops\ninstead, and from there it was easier to track down the culprit.",
"id": "GHSA-ph55-5xqf-59r7",
"modified": "2025-01-14T15:30:47Z",
"published": "2024-03-11T18:31:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52486"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/376e21a9e4c2c63ee5d8d3aa74be5082c3882229"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/62f2e79cf9f4f47cc9dea9cebdf58d9f7b5695e0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/9dd334a8245011ace45e53298175c7b659edb3e7"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b4af63da9d94986c529d74499fdfe44289acd551"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bfd0feb1b109cb63b87fdcd00122603787c75a1a"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/cb4daf271302d71a6b9a7c01bd0b6d76febd8f0c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d7afdf360f4ac142832b098b4de974e867cc063c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/f55261469be87c55df13db76dc945f6bcd825105"
},
{
"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-PH5R-C8GC-XG6F
Vulnerability from github – Published: 2024-03-21 12:31 – Updated: 2026-05-12 12:31In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout
While the rhashtable set gc runs asynchronously, a race allows it to collect elements from anonymous sets with timeouts while it is being released from the commit path.
Mingi Cho originally reported this issue in a different path in 6.1.x with a pipapo set with low timeouts which is not possible upstream since 7395dfacfff6 ("netfilter: nf_tables: use timestamp to check for set element timeout").
Fix this by setting on the dead flag for anonymous sets to skip async gc in this case.
According to 08e4c8c5919f ("netfilter: nf_tables: mark newset as dead on transaction abort"), Florian plans to accelerate abort path by releasing objects via workqueue, therefore, this sets on the dead flag for abort path too.
{
"affected": [],
"aliases": [
"CVE-2024-26643"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-21T11:15:28Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: mark set as dead when unbinding anonymous set with timeout\n\nWhile the rhashtable set gc runs asynchronously, a race allows it to\ncollect elements from anonymous sets with timeouts while it is being\nreleased from the commit path.\n\nMingi Cho originally reported this issue in a different path in 6.1.x\nwith a pipapo set with low timeouts which is not possible upstream since\n7395dfacfff6 (\"netfilter: nf_tables: use timestamp to check for set\nelement timeout\").\n\nFix this by setting on the dead flag for anonymous sets to skip async gc\nin this case.\n\nAccording to 08e4c8c5919f (\"netfilter: nf_tables: mark newset as dead on\ntransaction abort\"), Florian plans to accelerate abort path by releasing\nobjects via workqueue, therefore, this sets on the dead flag for abort\npath too.",
"id": "GHSA-ph5r-c8gc-xg6f",
"modified": "2026-05-12T12:31:35Z",
"published": "2024-03-21T12:31:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-26643"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/291cca35818bd52a407bc37ab45a15816039e363"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/406b0241d0eb598a0b330ab20ae325537d8d8163"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5224afbc30c3ca9ba23e752f0f138729b2c48dd8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/552705a3650bbf46a22b1adedc1b04181490fc36"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b2d6f9a5b1cf968f1eaa71085ceeb09c2cb276b1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d75a589bb92af1abf3b779cfcd1977ca11b27033"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e2d45f467096e931044f0ab7634499879d851a5c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/edcf1a3f182ecf8b6b805f0ce90570ea98c5f6bf"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00017.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-PHJ6-5VRC-G27M
Vulnerability from github – Published: 2024-06-19 15:30 – Updated: 2024-08-27 18:31In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix deadlock in __mptcp_push_pending()
__mptcp_push_pending() may call mptcp_flush_join_list() with subflow socket lock held. If such call hits mptcp_sockopt_sync_all() then subsequently __mptcp_sockopt_sync() could try to lock the subflow socket for itself, causing a deadlock.
sysrq: Show Blocked State task:ss-server state:D stack: 0 pid: 938 ppid: 1 flags:0x00000000 Call Trace: __schedule+0x2d6/0x10c0 ? __mod_memcg_state+0x4d/0x70 ? csum_partial+0xd/0x20 ? _raw_spin_lock_irqsave+0x26/0x50 schedule+0x4e/0xc0 __lock_sock+0x69/0x90 ? do_wait_intr_irq+0xa0/0xa0 __lock_sock_fast+0x35/0x50 mptcp_sockopt_sync_all+0x38/0xc0 __mptcp_push_pending+0x105/0x200 mptcp_sendmsg+0x466/0x490 sock_sendmsg+0x57/0x60 __sys_sendto+0xf0/0x160 ? do_wait_intr_irq+0xa0/0xa0 ? fpregs_restore_userregs+0x12/0xd0 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f9ba546c2d0 RSP: 002b:00007ffdc3b762d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f9ba56c8060 RCX: 00007f9ba546c2d0 RDX: 000000000000077a RSI: 0000000000e5e180 RDI: 0000000000000234 RBP: 0000000000cc57f0 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f9ba56c8060 R13: 0000000000b6ba60 R14: 0000000000cc7840 R15: 41d8685b1d7901b8
Fix the issue by using __mptcp_flush_join_list() instead of plain mptcp_flush_join_list() inside __mptcp_push_pending(), as suggested by Florian. The sockopt sync will be deferred to the workqueue.
{
"affected": [],
"aliases": [
"CVE-2021-47590"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-06-19T15:15:53Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: fix deadlock in __mptcp_push_pending()\n\n__mptcp_push_pending() may call mptcp_flush_join_list() with subflow\nsocket lock held. If such call hits mptcp_sockopt_sync_all() then\nsubsequently __mptcp_sockopt_sync() could try to lock the subflow\nsocket for itself, causing a deadlock.\n\nsysrq: Show Blocked State\ntask:ss-server state:D stack: 0 pid: 938 ppid: 1 flags:0x00000000\nCall Trace:\n \u003cTASK\u003e\n __schedule+0x2d6/0x10c0\n ? __mod_memcg_state+0x4d/0x70\n ? csum_partial+0xd/0x20\n ? _raw_spin_lock_irqsave+0x26/0x50\n schedule+0x4e/0xc0\n __lock_sock+0x69/0x90\n ? do_wait_intr_irq+0xa0/0xa0\n __lock_sock_fast+0x35/0x50\n mptcp_sockopt_sync_all+0x38/0xc0\n __mptcp_push_pending+0x105/0x200\n mptcp_sendmsg+0x466/0x490\n sock_sendmsg+0x57/0x60\n __sys_sendto+0xf0/0x160\n ? do_wait_intr_irq+0xa0/0xa0\n ? fpregs_restore_userregs+0x12/0xd0\n __x64_sys_sendto+0x20/0x30\n do_syscall_64+0x38/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f9ba546c2d0\nRSP: 002b:00007ffdc3b762d8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 00007f9ba56c8060 RCX: 00007f9ba546c2d0\nRDX: 000000000000077a RSI: 0000000000e5e180 RDI: 0000000000000234\nRBP: 0000000000cc57f0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007f9ba56c8060\nR13: 0000000000b6ba60 R14: 0000000000cc7840 R15: 41d8685b1d7901b8\n \u003c/TASK\u003e\n\nFix the issue by using __mptcp_flush_join_list() instead of plain\nmptcp_flush_join_list() inside __mptcp_push_pending(), as suggested by\nFlorian. The sockopt sync will be deferred to the workqueue.",
"id": "GHSA-phj6-5vrc-g27m",
"modified": "2024-08-27T18:31:35Z",
"published": "2024-06-19T15:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47590"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/23311b92755ffa9087332d1bb8c71c0f6a10cc08"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3d79e3756ca90f7a6087b77b62c1d9c0801e0820"
}
],
"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-PJ73-39G5-XMF7
Vulnerability from github – Published: 2025-05-01 15:31 – Updated: 2025-11-05 18:14In the Linux kernel, the following vulnerability has been resolved:
net: vlan: don't propagate flags on open
With the device instance lock, there is now a possibility of a deadlock:
[ 1.211455] ============================================ [ 1.211571] WARNING: possible recursive locking detected [ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted [ 1.211823] -------------------------------------------- [ 1.211936] ip/184 is trying to acquire lock: [ 1.212032] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0 [ 1.212207] [ 1.212207] but task is already holding lock: [ 1.212332] ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0 [ 1.212487] [ 1.212487] other info that might help us debug this: [ 1.212626] Possible unsafe locking scenario: [ 1.212626] [ 1.212751] CPU0 [ 1.212815] ---- [ 1.212871] lock(&dev->lock); [ 1.212944] lock(&dev->lock); [ 1.213016] [ 1.213016] *** DEADLOCK *** [ 1.213016] [ 1.213143] May be due to missing lock nesting notation [ 1.213143] [ 1.213294] 3 locks held by ip/184: [ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0 [ 1.213543] #1: ffffffff84e5fc70 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0 [ 1.213727] #2: ffff8881024a4c30 (&dev->lock){+.+.}-{4:4}, at: dev_open+0x50/0xb0 [ 1.213895] [ 1.213895] stack backtrace: [ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 [ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 [ 1.213994] Call Trace: [ 1.213995] [ 1.213996] dump_stack_lvl+0x8e/0xd0 [ 1.214000] print_deadlock_bug+0x28b/0x2a0 [ 1.214020] lock_acquire+0xea/0x2a0 [ 1.214027] __mutex_lock+0xbf/0xd40 [ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev->flags & IFF_ALLMULTI [ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev [ 1.214042] __dev_open+0x145/0x270 [ 1.214046] __dev_change_flags+0xb0/0x1e0 [ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev [ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev->vlan_info [ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0 [ 1.214058] notifier_call_chain+0x78/0x120 [ 1.214062] netif_open+0x6d/0x90 [ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0 [ 1.214066] bond_enslave+0x64c/0x1230 [ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0 [ 1.214077] do_setlink+0x516/0x13b0 [ 1.214094] rtnl_newlink+0xaba/0xb80 [ 1.214132] rtnetlink_rcv_msg+0x440/0x490 [ 1.214144] netlink_rcv_skb+0xeb/0x120 [ 1.214150] netlink_unicast+0x1f9/0x320 [ 1.214153] netlink_sendmsg+0x346/0x3f0 [ 1.214157] __sock_sendmsg+0x86/0xb0 [ 1.214160] _syssendmsg+0x1c8/0x220 [ 1.214164] _sys_sendmsg+0x28f/0x2d0 [ 1.214179] __x64_sys_sendmsg+0xef/0x140 [ 1.214184] do_syscall_64+0xec/0x1d0 [ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f [ 1.214191] RIP: 0033:0x7f2d1b4a7e56
Device setup:
netdevsim0 (down)
^ ^
bond netdevsim1.100@netdevsim1 allmulticast=on (down)
When we enslave the lower device (netdevsim0) which has a vlan, we propagate vlan's allmuti/promisc flags during ndo_open. This causes (re)locking on of the real_dev.
Propagate allmulti/promisc on flags change, not on the open. There is a slight semantics change that vlans that are down now propagate the flags, but this seems unlikely to result in the real issues.
Reproducer:
echo 0 1 > /sys/bus/netdevsim/new_device
dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*) dev=$(echo $dev_path | rev | cut -d/ -f1 | rev)
ip link set dev $dev name netdevsim0 ip link set dev netdevsim0 up
ip link add link netdevsim0 name netdevsim0.100 type vlan id 100 ip link set dev netdevsim0.100 allm ---truncated---
{
"affected": [],
"aliases": [
"CVE-2025-23163"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-01T13:15:52Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: vlan: don\u0027t propagate flags on open\n\nWith the device instance lock, there is now a possibility of a deadlock:\n\n[ 1.211455] ============================================\n[ 1.211571] WARNING: possible recursive locking detected\n[ 1.211687] 6.14.0-rc5-01215-g032756b4ca7a-dirty #5 Not tainted\n[ 1.211823] --------------------------------------------\n[ 1.211936] ip/184 is trying to acquire lock:\n[ 1.212032] ffff8881024a4c30 (\u0026dev-\u003elock){+.+.}-{4:4}, at: dev_set_allmulti+0x4e/0xb0\n[ 1.212207]\n[ 1.212207] but task is already holding lock:\n[ 1.212332] ffff8881024a4c30 (\u0026dev-\u003elock){+.+.}-{4:4}, at: dev_open+0x50/0xb0\n[ 1.212487]\n[ 1.212487] other info that might help us debug this:\n[ 1.212626] Possible unsafe locking scenario:\n[ 1.212626]\n[ 1.212751] CPU0\n[ 1.212815] ----\n[ 1.212871] lock(\u0026dev-\u003elock);\n[ 1.212944] lock(\u0026dev-\u003elock);\n[ 1.213016]\n[ 1.213016] *** DEADLOCK ***\n[ 1.213016]\n[ 1.213143] May be due to missing lock nesting notation\n[ 1.213143]\n[ 1.213294] 3 locks held by ip/184:\n[ 1.213371] #0: ffffffff838b53e0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x1b/0xa0\n[ 1.213543] #1: ffffffff84e5fc70 (\u0026net-\u003ertnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x37/0xa0\n[ 1.213727] #2: ffff8881024a4c30 (\u0026dev-\u003elock){+.+.}-{4:4}, at: dev_open+0x50/0xb0\n[ 1.213895]\n[ 1.213895] stack backtrace:\n[ 1.213991] CPU: 0 UID: 0 PID: 184 Comm: ip Not tainted 6.14.0-rc5-01215-g032756b4ca7a-dirty #5\n[ 1.213993] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\n[ 1.213994] Call Trace:\n[ 1.213995] \u003cTASK\u003e\n[ 1.213996] dump_stack_lvl+0x8e/0xd0\n[ 1.214000] print_deadlock_bug+0x28b/0x2a0\n[ 1.214020] lock_acquire+0xea/0x2a0\n[ 1.214027] __mutex_lock+0xbf/0xd40\n[ 1.214038] dev_set_allmulti+0x4e/0xb0 # real_dev-\u003eflags \u0026 IFF_ALLMULTI\n[ 1.214040] vlan_dev_open+0xa5/0x170 # ndo_open on vlandev\n[ 1.214042] __dev_open+0x145/0x270\n[ 1.214046] __dev_change_flags+0xb0/0x1e0\n[ 1.214051] netif_change_flags+0x22/0x60 # IFF_UP vlandev\n[ 1.214053] dev_change_flags+0x61/0xb0 # for each device in group from dev-\u003evlan_info\n[ 1.214055] vlan_device_event+0x766/0x7c0 # on netdevsim0\n[ 1.214058] notifier_call_chain+0x78/0x120\n[ 1.214062] netif_open+0x6d/0x90\n[ 1.214064] dev_open+0x5b/0xb0 # locks netdevsim0\n[ 1.214066] bond_enslave+0x64c/0x1230\n[ 1.214075] do_set_master+0x175/0x1e0 # on netdevsim0\n[ 1.214077] do_setlink+0x516/0x13b0\n[ 1.214094] rtnl_newlink+0xaba/0xb80\n[ 1.214132] rtnetlink_rcv_msg+0x440/0x490\n[ 1.214144] netlink_rcv_skb+0xeb/0x120\n[ 1.214150] netlink_unicast+0x1f9/0x320\n[ 1.214153] netlink_sendmsg+0x346/0x3f0\n[ 1.214157] __sock_sendmsg+0x86/0xb0\n[ 1.214160] ____sys_sendmsg+0x1c8/0x220\n[ 1.214164] ___sys_sendmsg+0x28f/0x2d0\n[ 1.214179] __x64_sys_sendmsg+0xef/0x140\n[ 1.214184] do_syscall_64+0xec/0x1d0\n[ 1.214190] entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[ 1.214191] RIP: 0033:0x7f2d1b4a7e56\n\nDevice setup:\n\n netdevsim0 (down)\n ^ ^\n bond netdevsim1.100@netdevsim1 allmulticast=on (down)\n\nWhen we enslave the lower device (netdevsim0) which has a vlan, we\npropagate vlan\u0027s allmuti/promisc flags during ndo_open. This causes\n(re)locking on of the real_dev.\n\nPropagate allmulti/promisc on flags change, not on the open. There\nis a slight semantics change that vlans that are down now propagate\nthe flags, but this seems unlikely to result in the real issues.\n\nReproducer:\n\n echo 0 1 \u003e /sys/bus/netdevsim/new_device\n\n dev_path=$(ls -d /sys/bus/netdevsim/devices/netdevsim0/net/*)\n dev=$(echo $dev_path | rev | cut -d/ -f1 | rev)\n\n ip link set dev $dev name netdevsim0\n ip link set dev netdevsim0 up\n\n ip link add link netdevsim0 name netdevsim0.100 type vlan id 100\n ip link set dev netdevsim0.100 allm\n---truncated---",
"id": "GHSA-pj73-39g5-xmf7",
"modified": "2025-11-05T18:14:26Z",
"published": "2025-05-01T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23163"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/27b918007d96402aba10ed52a6af8015230f1793"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/299d7d27af6b5844cda06a0fdfa635705e1bc50f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/523fa0979d842443aa14b80002e45b471cbac137"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/538b43aa21e3b17c110104efd218b966d2eda5f8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/53fb25e90c0a503a17c639341ba5e755cb2feb5c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8980018a9806743d9b80837330d46f06ecf78516"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a32f1d4f1f4c9d978698f3c718621f6198f2e7ac"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b1e3eeb037256a2f1206a8d69810ec47eb152026"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/d537859e56bcc3091805c524484a4c85386b3cc8"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00030.html"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/05/msg00045.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-PMJ2-RJQJ-CMF3
Vulnerability from github – Published: 2023-06-06 15:30 – Updated: 2024-04-04 04:35In vcu, there is a possible out of bounds write due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07519142; Issue ID: ALPS07519142.
{
"affected": [],
"aliases": [
"CVE-2023-20743"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-06T13:15:14Z",
"severity": "MODERATE"
},
"details": "In vcu, there is a possible out of bounds write due to improper locking. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation. Patch ID: ALPS07519142; Issue ID: ALPS07519142.",
"id": "GHSA-pmj2-rjqj-cmf3",
"modified": "2024-04-04T04:35:38Z",
"published": "2023-06-06T15:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-20743"
},
{
"type": "WEB",
"url": "https://corp.mediatek.com/product-security-bulletin/June-2023"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-PMPX-W3F2-X2VP
Vulnerability from github – Published: 2026-05-06 12:30 – Updated: 2026-05-08 18:31In the Linux kernel, the following vulnerability has been resolved:
ntfs3: fix circular locking dependency in run_unpack_ex
Syzbot reported a circular locking dependency between wnd->rw_lock (sbi->used.bitmap) and ni->file.run_lock.
The deadlock scenario: 1. ntfs_extend_mft() takes ni->file.run_lock then wnd->rw_lock. 2. run_unpack_ex() takes wnd->rw_lock then tries to acquire ni->file.run_lock inside ntfs_refresh_zone().
This creates an AB-BA deadlock.
Fix this by using down_read_trylock() instead of down_read() when acquiring run_lock in run_unpack_ex(). If the lock is contended, skip ntfs_refresh_zone() - the MFT zone will be refreshed on the next MFT operation. This breaks the circular dependency since we never block waiting for run_lock while holding wnd->rw_lock.
{
"affected": [],
"aliases": [
"CVE-2026-43127"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-06T12:16:29Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nntfs3: fix circular locking dependency in run_unpack_ex\n\nSyzbot reported a circular locking dependency between wnd-\u003erw_lock\n(sbi-\u003eused.bitmap) and ni-\u003efile.run_lock.\n\nThe deadlock scenario:\n1. ntfs_extend_mft() takes ni-\u003efile.run_lock then wnd-\u003erw_lock.\n2. run_unpack_ex() takes wnd-\u003erw_lock then tries to acquire\n ni-\u003efile.run_lock inside ntfs_refresh_zone().\n\nThis creates an AB-BA deadlock.\n\nFix this by using down_read_trylock() instead of down_read() when\nacquiring run_lock in run_unpack_ex(). If the lock is contended,\nskip ntfs_refresh_zone() - the MFT zone will be refreshed on the\nnext MFT operation. This breaks the circular dependency since we\nnever block waiting for run_lock while holding wnd-\u003erw_lock.",
"id": "GHSA-pmpx-w3f2-x2vp",
"modified": "2026-05-08T18:31:26Z",
"published": "2026-05-06T12:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43127"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/08ce2fee1b869ecbfbd94e0eb2630e52203a2e03"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b014372b62237521444ee51384549bdf48b79015"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b8d22d9d8260b0f4f4d8e2898c98037c9982ea66"
}
],
"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-PP3C-47H7-V942
Vulnerability from github – Published: 2024-12-29 12:30 – Updated: 2025-01-08 00:30In the Linux kernel, the following vulnerability has been resolved:
nfs_common: must not hold RCU while calling nfsd_file_put_local
Move holding the RCU from nfs_to_nfsd_file_put_local to nfs_to_nfsd_net_put. It is the call to nfs_to->nfsd_serv_put that requires the RCU anyway (the puts for nfsd_file and netns were combined to avoid an extra indirect reference but that micro-optimization isn't possible now).
This fixes xfstests generic/013 and it triggering:
"Voluntary context switch within RCU read-side critical section!"
[ 143.545738] Call Trace: [ 143.546206] [ 143.546625] ? show_regs+0x6d/0x80 [ 143.547267] ? __warn+0x91/0x140 [ 143.547951] ? rcu_note_context_switch+0x496/0x5d0 [ 143.548856] ? report_bug+0x193/0x1a0 [ 143.549557] ? handle_bug+0x63/0xa0 [ 143.550214] ? exc_invalid_op+0x1d/0x80 [ 143.550938] ? asm_exc_invalid_op+0x1f/0x30 [ 143.551736] ? rcu_note_context_switch+0x496/0x5d0 [ 143.552634] ? wakeup_preempt+0x62/0x70 [ 143.553358] __schedule+0xaa/0x1380 [ 143.554025] ? _raw_spin_unlock_irqrestore+0x12/0x40 [ 143.554958] ? try_to_wake_up+0x1fe/0x6b0 [ 143.555715] ? wake_up_process+0x19/0x20 [ 143.556452] schedule+0x2e/0x120 [ 143.557066] schedule_preempt_disabled+0x19/0x30 [ 143.557933] rwsem_down_read_slowpath+0x24d/0x4a0 [ 143.558818] ? xfs_efi_item_format+0x50/0xc0 [xfs] [ 143.559894] down_read+0x4e/0xb0 [ 143.560519] xlog_cil_commit+0x1b2/0xbc0 [xfs] [ 143.561460] ? _raw_spin_unlock+0x12/0x30 [ 143.562212] ? xfs_inode_item_precommit+0xc7/0x220 [xfs] [ 143.563309] ? xfs_trans_run_precommits+0x69/0xd0 [xfs] [ 143.564394] __xfs_trans_commit+0xb5/0x330 [xfs] [ 143.565367] xfs_trans_roll+0x48/0xc0 [xfs] [ 143.566262] xfs_defer_trans_roll+0x57/0x100 [xfs] [ 143.567278] xfs_defer_finish_noroll+0x27a/0x490 [xfs] [ 143.568342] xfs_defer_finish+0x1a/0x80 [xfs] [ 143.569267] xfs_bunmapi_range+0x4d/0xb0 [xfs] [ 143.570208] xfs_itruncate_extents_flags+0x13d/0x230 [xfs] [ 143.571353] xfs_free_eofblocks+0x12e/0x190 [xfs] [ 143.572359] xfs_file_release+0x12d/0x140 [xfs] [ 143.573324] __fput+0xe8/0x2d0 [ 143.573922] __fput_sync+0x1d/0x30 [ 143.574574] nfsd_filp_close+0x33/0x60 [nfsd] [ 143.575430] nfsd_file_free+0x96/0x150 [nfsd] [ 143.576274] nfsd_file_put+0xf7/0x1a0 [nfsd] [ 143.577104] nfsd_file_put_local+0x18/0x30 [nfsd] [ 143.578070] nfs_close_local_fh+0x101/0x110 [nfs_localio] [ 143.579079] __put_nfs_open_context+0xc9/0x180 [nfs] [ 143.580031] nfs_file_clear_open_context+0x4a/0x60 [nfs] [ 143.581038] nfs_file_release+0x3e/0x60 [nfs] [ 143.581879] __fput+0xe8/0x2d0 [ 143.582464] __fput_sync+0x1d/0x30 [ 143.583108] __x64_sys_close+0x41/0x80 [ 143.583823] x64_sys_call+0x189a/0x20d0 [ 143.584552] do_syscall_64+0x64/0x170 [ 143.585240] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 143.586185] RIP: 0033:0x7f3c5153efd7
{
"affected": [],
"aliases": [
"CVE-2024-56743"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-29T12:15:07Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfs_common: must not hold RCU while calling nfsd_file_put_local\n\nMove holding the RCU from nfs_to_nfsd_file_put_local to\nnfs_to_nfsd_net_put. It is the call to nfs_to-\u003enfsd_serv_put that\nrequires the RCU anyway (the puts for nfsd_file and netns were\ncombined to avoid an extra indirect reference but that\nmicro-optimization isn\u0027t possible now).\n\nThis fixes xfstests generic/013 and it triggering:\n\n\"Voluntary context switch within RCU read-side critical section!\"\n\n[ 143.545738] Call Trace:\n[ 143.546206] \u003cTASK\u003e\n[ 143.546625] ? show_regs+0x6d/0x80\n[ 143.547267] ? __warn+0x91/0x140\n[ 143.547951] ? rcu_note_context_switch+0x496/0x5d0\n[ 143.548856] ? report_bug+0x193/0x1a0\n[ 143.549557] ? handle_bug+0x63/0xa0\n[ 143.550214] ? exc_invalid_op+0x1d/0x80\n[ 143.550938] ? asm_exc_invalid_op+0x1f/0x30\n[ 143.551736] ? rcu_note_context_switch+0x496/0x5d0\n[ 143.552634] ? wakeup_preempt+0x62/0x70\n[ 143.553358] __schedule+0xaa/0x1380\n[ 143.554025] ? _raw_spin_unlock_irqrestore+0x12/0x40\n[ 143.554958] ? try_to_wake_up+0x1fe/0x6b0\n[ 143.555715] ? wake_up_process+0x19/0x20\n[ 143.556452] schedule+0x2e/0x120\n[ 143.557066] schedule_preempt_disabled+0x19/0x30\n[ 143.557933] rwsem_down_read_slowpath+0x24d/0x4a0\n[ 143.558818] ? xfs_efi_item_format+0x50/0xc0 [xfs]\n[ 143.559894] down_read+0x4e/0xb0\n[ 143.560519] xlog_cil_commit+0x1b2/0xbc0 [xfs]\n[ 143.561460] ? _raw_spin_unlock+0x12/0x30\n[ 143.562212] ? xfs_inode_item_precommit+0xc7/0x220 [xfs]\n[ 143.563309] ? xfs_trans_run_precommits+0x69/0xd0 [xfs]\n[ 143.564394] __xfs_trans_commit+0xb5/0x330 [xfs]\n[ 143.565367] xfs_trans_roll+0x48/0xc0 [xfs]\n[ 143.566262] xfs_defer_trans_roll+0x57/0x100 [xfs]\n[ 143.567278] xfs_defer_finish_noroll+0x27a/0x490 [xfs]\n[ 143.568342] xfs_defer_finish+0x1a/0x80 [xfs]\n[ 143.569267] xfs_bunmapi_range+0x4d/0xb0 [xfs]\n[ 143.570208] xfs_itruncate_extents_flags+0x13d/0x230 [xfs]\n[ 143.571353] xfs_free_eofblocks+0x12e/0x190 [xfs]\n[ 143.572359] xfs_file_release+0x12d/0x140 [xfs]\n[ 143.573324] __fput+0xe8/0x2d0\n[ 143.573922] __fput_sync+0x1d/0x30\n[ 143.574574] nfsd_filp_close+0x33/0x60 [nfsd]\n[ 143.575430] nfsd_file_free+0x96/0x150 [nfsd]\n[ 143.576274] nfsd_file_put+0xf7/0x1a0 [nfsd]\n[ 143.577104] nfsd_file_put_local+0x18/0x30 [nfsd]\n[ 143.578070] nfs_close_local_fh+0x101/0x110 [nfs_localio]\n[ 143.579079] __put_nfs_open_context+0xc9/0x180 [nfs]\n[ 143.580031] nfs_file_clear_open_context+0x4a/0x60 [nfs]\n[ 143.581038] nfs_file_release+0x3e/0x60 [nfs]\n[ 143.581879] __fput+0xe8/0x2d0\n[ 143.582464] __fput_sync+0x1d/0x30\n[ 143.583108] __x64_sys_close+0x41/0x80\n[ 143.583823] x64_sys_call+0x189a/0x20d0\n[ 143.584552] do_syscall_64+0x64/0x170\n[ 143.585240] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 143.586185] RIP: 0033:0x7f3c5153efd7",
"id": "GHSA-pp3c-47h7-v942",
"modified": "2025-01-08T00:30:48Z",
"published": "2024-12-29T12:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56743"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/3e6e3e97d64f50d9b6b1d62274f08925b1adbfc2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c840b8e1f039e90f97ca55525667eb961422f86c"
}
],
"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-PPCF-3XHC-XRX9
Vulnerability from github – Published: 2024-03-06 09:30 – Updated: 2025-02-03 15:31In the Linux kernel, the following vulnerability has been resolved:
ceph: fix deadlock or deadcode of misusing dget()
The lock order is incorrect between denty and its parent, we should always make sure that the parent get the lock first.
But since this deadcode is never used and the parent dir will always be set from the callers, let's just remove it.
{
"affected": [],
"aliases": [
"CVE-2023-52583"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-06T07:15:06Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix deadlock or deadcode of misusing dget()\n\nThe lock order is incorrect between denty and its parent, we should\nalways make sure that the parent get the lock first.\n\nBut since this deadcode is never used and the parent dir will always\nbe set from the callers, let\u0027s just remove it.",
"id": "GHSA-ppcf-3xhc-xrx9",
"modified": "2025-02-03T15:31:59Z",
"published": "2024-03-06T09:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52583"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/196b87e5c00ce021e164a5de0f0d04f4116a9160"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6ab4fd508fad942f1f1ba940492f2735e078e980"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/76cb2aa3421fee4fde706dec41b1344bc0a9ad67"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7f2649c94264d00df6b6ac27161e9f4372a3450e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a9c15d6e8aee074fae66c04d114f20b84274fcca"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b493ad718b1f0357394d2cdecbf00a44a36fa085"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e016e358461b89b231626fcf78c5c38e35c44fd3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/eb55ba8aa7fb7aad54f40fbf4d8dcdfdba0bebf6"
},
{
"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-PR22-X636-XP32
Vulnerability from github – Published: 2024-07-29 18:30 – Updated: 2026-05-12 12:32In the Linux kernel, the following vulnerability has been resolved:
pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER
In create_pinctrl(), pinctrl_maps_mutex is acquired before calling add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl() calls pinctrl_free(). However, pinctrl_free() attempts to acquire pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to a potential deadlock.
This patch resolves the issue by releasing pinctrl_maps_mutex before calling pinctrl_free(), preventing the deadlock.
This bug was discovered and resolved using Coverity Static Analysis Security Testing (SAST) by Synopsys, Inc.
{
"affected": [],
"aliases": [
"CVE-2024-42090"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-29T17:15:11Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER\n\nIn create_pinctrl(), pinctrl_maps_mutex is acquired before calling\nadd_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()\ncalls pinctrl_free(). However, pinctrl_free() attempts to acquire\npinctrl_maps_mutex, which is already held by create_pinctrl(), leading to\na potential deadlock.\n\nThis patch resolves the issue by releasing pinctrl_maps_mutex before\ncalling pinctrl_free(), preventing the deadlock.\n\nThis bug was discovered and resolved using Coverity Static Analysis\nSecurity Testing (SAST) by Synopsys, Inc.",
"id": "GHSA-pr22-x636-xp32",
"modified": "2026-05-12T12:32:03Z",
"published": "2024-07-29T18:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42090"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-265688.html"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/01fe2f885f7813f8aed5d3704b384a97b1116a9e"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/4038c57bf61631219b31f1bd6e92106ec7f084dc"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/420ce1261907e5dbeda1e4daffd5b6c76f8188c0"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/48a7a7c9571c3e62f17012dd7f2063e926179ddd"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/adec57ff8e66aee632f3dd1f93787c13d112b7a1"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b36efd2e3e22a329444b6b24fa48df6d20ae66e6"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/b813e3fd102a959c5b208ed68afe27e0137a561b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e65a0dc2e85efb28e182aca50218e8a056d0ce04"
},
{
"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"
}
]
}
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.