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.
692 vulnerabilities reference this CWE, most recent first.
GHSA-2J45-XR49-X8QC
Vulnerability from github – Published: 2024-07-30 09:32 – Updated: 2025-11-04 00:31In the Linux kernel, the following vulnerability has been resolved:
riscv: kexec: Avoid deadlock in kexec crash path
If the kexec crash code is called in the interrupt context, the machine_kexec_mask_interrupts() function will trigger a deadlock while trying to acquire the irqdesc spinlock and then deactivate irqchip in irq_set_irqchip_state() function.
Unlike arm64, riscv only requires irq_eoi handler to complete EOI and keeping irq_set_irqchip_state() will only leave this possible deadlock without any use. So we simply remove it.
{
"affected": [],
"aliases": [
"CVE-2024-42140"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-30T08:15:05Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: kexec: Avoid deadlock in kexec crash path\n\nIf the kexec crash code is called in the interrupt context, the\nmachine_kexec_mask_interrupts() function will trigger a deadlock while\ntrying to acquire the irqdesc spinlock and then deactivate irqchip in\nirq_set_irqchip_state() function.\n\nUnlike arm64, riscv only requires irq_eoi handler to complete EOI and\nkeeping irq_set_irqchip_state() will only leave this possible deadlock\nwithout any use. So we simply remove it.",
"id": "GHSA-2j45-xr49-x8qc",
"modified": "2025-11-04T00:31:07Z",
"published": "2024-07-30T09:32:02Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42140"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/484dd545271d02d1571e1c6b62ea7df9dbe5e692"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/653deee48a4682ea17a05b96fb6842795ab5943c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7692c9b6baacdee378435f58f19baf0eb69e4155"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/bb80a7911218bbab2a69b5db7d2545643ab0073d"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c562ba719df570c986caf0941fea2449150bcbc4"
},
{
"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-2M65-7FPJ-78P9
Vulnerability from github – Published: 2026-02-14 18:30 – Updated: 2026-03-18 15:30In the Linux kernel, the following vulnerability has been resolved:
hwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()
The acpi_power_meter driver's .notify() callback function, acpi_power_meter_notify(), calls hwmon_device_unregister() under a lock that is also acquired by callbacks in sysfs attributes of the device being unregistered which is prone to deadlocks between sysfs access and device removal.
Address this by moving the hwmon device removal in acpi_power_meter_notify() outside the lock in question, but notice that doing it alone is not sufficient because two concurrent METER_NOTIFY_CONFIG notifications may be attempting to remove the same device at the same time. To prevent that from happening, add a new lock serializing the execution of the switch () statement in acpi_power_meter_notify(). For simplicity, it is a static mutex which should not be a problem from the performance perspective.
The new lock also allows the hwmon_device_register_with_info() in acpi_power_meter_notify() to be called outside the inner lock because it prevents the other notifications handled by that function from manipulating the "resource" object while the hwmon device based on it is being registered. The sending of ACPI netlink messages from acpi_power_meter_notify() is serialized by the new lock too which generally helps to ensure that the order of handling firmware notifications is the same as the order of sending netlink messages related to them.
In addition, notice that hwmon_device_register_with_info() may fail in which case resource->hwmon_dev will become an error pointer, so add checks to avoid attempting to unregister the hwmon device pointer to by it in that case to acpi_power_meter_notify() and acpi_power_meter_remove().
{
"affected": [],
"aliases": [
"CVE-2026-23186"
],
"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\nhwmon: (acpi_power_meter) Fix deadlocks related to acpi_power_meter_notify()\n\nThe acpi_power_meter driver\u0027s .notify() callback function,\nacpi_power_meter_notify(), calls hwmon_device_unregister() under a lock\nthat is also acquired by callbacks in sysfs attributes of the device\nbeing unregistered which is prone to deadlocks between sysfs access and\ndevice removal.\n\nAddress this by moving the hwmon device removal in\nacpi_power_meter_notify() outside the lock in question, but notice\nthat doing it alone is not sufficient because two concurrent\nMETER_NOTIFY_CONFIG notifications may be attempting to remove the\nsame device at the same time. To prevent that from happening, add a\nnew lock serializing the execution of the switch () statement in\nacpi_power_meter_notify(). For simplicity, it is a static mutex\nwhich should not be a problem from the performance perspective.\n\nThe new lock also allows the hwmon_device_register_with_info()\nin acpi_power_meter_notify() to be called outside the inner lock\nbecause it prevents the other notifications handled by that function\nfrom manipulating the \"resource\" object while the hwmon device based\non it is being registered. The sending of ACPI netlink messages from\nacpi_power_meter_notify() is serialized by the new lock too which\ngenerally helps to ensure that the order of handling firmware\nnotifications is the same as the order of sending netlink messages\nrelated to them.\n\nIn addition, notice that hwmon_device_register_with_info() may fail\nin which case resource-\u003ehwmon_dev will become an error pointer,\nso add checks to avoid attempting to unregister the hwmon device\npointer to by it in that case to acpi_power_meter_notify() and\nacpi_power_meter_remove().",
"id": "GHSA-2m65-7fpj-78p9",
"modified": "2026-03-18T15:30:41Z",
"published": "2026-02-14T18:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-23186"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/615901b57b7ef8eb655f71358f7e956e42bcd16b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/8860ddf0e07be37169d4ef9f2618e39fca934a66"
}
],
"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-2MH2-9XM5-M59Q
Vulnerability from github – Published: 2024-09-13 06:30 – Updated: 2024-09-23 15:31In the Linux kernel, the following vulnerability has been resolved:
bonding: change ipsec_lock from spin lock to mutex
In the cited commit, bond->ipsec_lock is added to protect ipsec_list, hence xdo_dev_state_add and xdo_dev_state_delete are called inside this lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep, "scheduling while atomic" will be triggered when changing bond's active slave.
[ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200 [ 101.055726] Modules linked in: [ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1 [ 101.058760] Hardware name: [ 101.059434] Call Trace: [ 101.059436] [ 101.060873] dump_stack_lvl+0x51/0x60 [ 101.061275] __schedule_bug+0x4e/0x60 [ 101.061682] __schedule+0x612/0x7c0 [ 101.062078] ? __mod_timer+0x25c/0x370 [ 101.062486] schedule+0x25/0xd0 [ 101.062845] schedule_timeout+0x77/0xf0 [ 101.063265] ? asm_common_interrupt+0x22/0x40 [ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10 [ 101.064215] __wait_for_common+0x87/0x190 [ 101.064648] ? usleep_range_state+0x90/0x90 [ 101.065091] cmd_exec+0x437/0xb20 [mlx5_core] [ 101.065569] mlx5_cmd_do+0x1e/0x40 [mlx5_core] [ 101.066051] mlx5_cmd_exec+0x18/0x30 [mlx5_core] [ 101.066552] mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core] [ 101.067163] ? bonding_sysfs_store_option+0x4d/0x80 [bonding] [ 101.067738] ? kmalloc_trace+0x4d/0x350 [ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core] [ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core] [ 101.069312] bond_change_active_slave+0x392/0x900 [bonding] [ 101.069868] bond_option_active_slave_set+0x1c2/0x240 [bonding] [ 101.070454] __bond_opt_set+0xa6/0x430 [bonding] [ 101.070935] __bond_opt_set_notify+0x2f/0x90 [bonding] [ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [bonding] [ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [bonding] [ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0 [ 101.073033] vfs_write+0x2d8/0x400 [ 101.073416] ? alloc_fd+0x48/0x180 [ 101.073798] ksys_write+0x5f/0xe0 [ 101.074175] do_syscall_64+0x52/0x110 [ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53
As bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called from bond_change_active_slave, which requires holding the RTNL lock. And bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state xdo_dev_state_add and xdo_dev_state_delete APIs, which are in user context. So ipsec_lock doesn't have to be spin lock, change it to mutex, and thus the above issue can be resolved.
{
"affected": [],
"aliases": [
"CVE-2024-46678"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-09-13T06:15:12Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: change ipsec_lock from spin lock to mutex\n\nIn the cited commit, bond-\u003eipsec_lock is added to protect ipsec_list,\nhence xdo_dev_state_add and xdo_dev_state_delete are called inside\nthis lock. As ipsec_lock is a spin lock and such xfrmdev ops may sleep,\n\"scheduling while atomic\" will be triggered when changing bond\u0027s\nactive slave.\n\n[ 101.055189] BUG: scheduling while atomic: bash/902/0x00000200\n[ 101.055726] Modules linked in:\n[ 101.058211] CPU: 3 PID: 902 Comm: bash Not tainted 6.9.0-rc4+ #1\n[ 101.058760] Hardware name:\n[ 101.059434] Call Trace:\n[ 101.059436] \u003cTASK\u003e\n[ 101.060873] dump_stack_lvl+0x51/0x60\n[ 101.061275] __schedule_bug+0x4e/0x60\n[ 101.061682] __schedule+0x612/0x7c0\n[ 101.062078] ? __mod_timer+0x25c/0x370\n[ 101.062486] schedule+0x25/0xd0\n[ 101.062845] schedule_timeout+0x77/0xf0\n[ 101.063265] ? asm_common_interrupt+0x22/0x40\n[ 101.063724] ? __bpf_trace_itimer_state+0x10/0x10\n[ 101.064215] __wait_for_common+0x87/0x190\n[ 101.064648] ? usleep_range_state+0x90/0x90\n[ 101.065091] cmd_exec+0x437/0xb20 [mlx5_core]\n[ 101.065569] mlx5_cmd_do+0x1e/0x40 [mlx5_core]\n[ 101.066051] mlx5_cmd_exec+0x18/0x30 [mlx5_core]\n[ 101.066552] mlx5_crypto_create_dek_key+0xea/0x120 [mlx5_core]\n[ 101.067163] ? bonding_sysfs_store_option+0x4d/0x80 [bonding]\n[ 101.067738] ? kmalloc_trace+0x4d/0x350\n[ 101.068156] mlx5_ipsec_create_sa_ctx+0x33/0x100 [mlx5_core]\n[ 101.068747] mlx5e_xfrm_add_state+0x47b/0xaa0 [mlx5_core]\n[ 101.069312] bond_change_active_slave+0x392/0x900 [bonding]\n[ 101.069868] bond_option_active_slave_set+0x1c2/0x240 [bonding]\n[ 101.070454] __bond_opt_set+0xa6/0x430 [bonding]\n[ 101.070935] __bond_opt_set_notify+0x2f/0x90 [bonding]\n[ 101.071453] bond_opt_tryset_rtnl+0x72/0xb0 [bonding]\n[ 101.071965] bonding_sysfs_store_option+0x4d/0x80 [bonding]\n[ 101.072567] kernfs_fop_write_iter+0x10c/0x1a0\n[ 101.073033] vfs_write+0x2d8/0x400\n[ 101.073416] ? alloc_fd+0x48/0x180\n[ 101.073798] ksys_write+0x5f/0xe0\n[ 101.074175] do_syscall_64+0x52/0x110\n[ 101.074576] entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nAs bond_ipsec_add_sa_all and bond_ipsec_del_sa_all are only called\nfrom bond_change_active_slave, which requires holding the RTNL lock.\nAnd bond_ipsec_add_sa and bond_ipsec_del_sa are xfrm state\nxdo_dev_state_add and xdo_dev_state_delete APIs, which are in user\ncontext. So ipsec_lock doesn\u0027t have to be spin lock, change it to\nmutex, and thus the above issue can be resolved.",
"id": "GHSA-2mh2-9xm5-m59q",
"modified": "2024-09-23T15:31:00Z",
"published": "2024-09-13T06:30:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-46678"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/2aeeef906d5a526dc60cf4af92eda69836c39b1f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/56354b0a2c24a7828eeed7de4b4dc9652d9affa3"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/6b598069164ac1bb60996d6ff94e7f9169dbd2d3"
}
],
"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-2P2C-QGQR-9GHC
Vulnerability from github – Published: 2024-05-21 15:31 – Updated: 2025-05-12 21:30In the Linux kernel, the following vulnerability has been resolved:
powerpc/bpf: Fix detecting BPF atomic instructions
Commit 91c960b0056672 ("bpf: Rename BPF_XADD and prepare to encode other atomics in .imm") converted BPF_XADD to BPF_ATOMIC and added a way to distinguish instructions based on the immediate field. Existing JIT implementations were updated to check for the immediate field and to reject programs utilizing anything more than BPF_ADD (such as BPF_FETCH) in the immediate field.
However, the check added to powerpc64 JIT did not look at the correct BPF instruction. Due to this, such programs would be accepted and incorrectly JIT'ed resulting in soft lockups, as seen with the atomic bounds test. Fix this by looking at the correct immediate value.
{
"affected": [],
"aliases": [
"CVE-2021-47317"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-05-21T15:15:19Z",
"severity": "LOW"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/bpf: Fix detecting BPF atomic instructions\n\nCommit 91c960b0056672 (\"bpf: Rename BPF_XADD and prepare to encode other\natomics in .imm\") converted BPF_XADD to BPF_ATOMIC and added a way to\ndistinguish instructions based on the immediate field. Existing JIT\nimplementations were updated to check for the immediate field and to\nreject programs utilizing anything more than BPF_ADD (such as BPF_FETCH)\nin the immediate field.\n\nHowever, the check added to powerpc64 JIT did not look at the correct\nBPF instruction. Due to this, such programs would be accepted and\nincorrectly JIT\u0027ed resulting in soft lockups, as seen with the atomic\nbounds test. Fix this by looking at the correct immediate value.",
"id": "GHSA-2p2c-qgqr-9ghc",
"modified": "2025-05-12T21:30:55Z",
"published": "2024-05-21T15:31:42Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-47317"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/0d435b6d94b05dcfd836d758a63145aa566618e2"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/419ac821766cbdb9fd85872bb3f1a589df05c94c"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/7284dab07e4d51d453cc42851fae9ec4fac6ef2f"
}
],
"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-2PV7-JFGV-X3FR
Vulnerability from github – Published: 2025-09-11 18:35 – Updated: 2025-11-25 21:32In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Optimize module load time by optimizing PLT/GOT counting
When enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD and CONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock, the relevant logs are as follows:
rcu: INFO: rcu_sched self-detected stall on CPU ... Call Trace: [<900000000024f9e4>] show_stack+0x5c/0x180 [<90000000002482f4>] dump_stack_lvl+0x94/0xbc [<9000000000224544>] rcu_dump_cpu_stacks+0x1fc/0x280 [<900000000037ac80>] rcu_sched_clock_irq+0x720/0xf88 [<9000000000396c34>] update_process_times+0xb4/0x150 [<90000000003b2474>] tick_nohz_handler+0xf4/0x250 [<9000000000397e28>] __hrtimer_run_queues+0x1d0/0x428 [<9000000000399b2c>] hrtimer_interrupt+0x214/0x538 [<9000000000253634>] constant_timer_interrupt+0x64/0x80 [<9000000000349938>] __handle_irq_event_percpu+0x78/0x1a0 [<9000000000349a78>] handle_irq_event_percpu+0x18/0x88 [<9000000000354c00>] handle_percpu_irq+0x90/0xf0 [<9000000000348c74>] handle_irq_desc+0x94/0xb8 [<9000000001012b28>] handle_cpu_irq+0x68/0xa0 [<9000000001def8c0>] handle_loongarch_irq+0x30/0x48 [<9000000001def958>] do_vint+0x80/0xd0 [<9000000000268a0c>] kasan_mem_to_shadow.part.0+0x2c/0x2a0 [<90000000006344f4>] __asan_load8+0x4c/0x120 [<900000000025c0d0>] module_frob_arch_sections+0x5c8/0x6b8 [<90000000003895f0>] load_module+0x9e0/0x2958 [<900000000038b770>] __do_sys_init_module+0x208/0x2d0 [<9000000001df0c34>] do_syscall+0x94/0x190 [<900000000024d6fc>] handle_syscall+0xbc/0x158
After analysis, this is because the slow speed of loading the amdgpu module leads to the long time occupation of the cpu and then the soft deadlock.
When loading a module, module_frob_arch_sections() tries to figure out the number of PLTs/GOTs that will be needed to handle all the RELAs. It will call the count_max_entries() to find in an out-of-order date which counting algorithm has O(n^2) complexity.
To make it faster, we sort the relocation list by info and addend. That way, to check for a duplicate relocation, it just needs to compare with the previous entry. This reduces the complexity of the algorithm to O(n log n), as done in commit d4e0340919fb ("arm64/module: Optimize module load time by optimizing PLT counting"). This gives sinificant reduction in module load time for modules with large number of relocations.
After applying this patch, the soft deadlock problem has been solved, and the kernel starts normally without "Call Trace".
Using the default configuration to test some modules, the results are as follows:
Module Size ip_tables 36K fat 143K radeon 2.5MB amdgpu 16MB
Without this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 54 1221/84 amdgpu 1411 4525/1098
With this patch: Module Module load time (ms) Count(PLTs/GOTs) ip_tables 18 59/6 fat 0 162/14 radeon 22 1221/84 amdgpu 45 4525/1098
{
"affected": [],
"aliases": [
"CVE-2025-39767"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-09-11T17:15:42Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Optimize module load time by optimizing PLT/GOT counting\n\nWhen enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD and\nCONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock,\nthe relevant logs are as follows:\n\nrcu: INFO: rcu_sched self-detected stall on CPU\n...\nCall Trace:\n[\u003c900000000024f9e4\u003e] show_stack+0x5c/0x180\n[\u003c90000000002482f4\u003e] dump_stack_lvl+0x94/0xbc\n[\u003c9000000000224544\u003e] rcu_dump_cpu_stacks+0x1fc/0x280\n[\u003c900000000037ac80\u003e] rcu_sched_clock_irq+0x720/0xf88\n[\u003c9000000000396c34\u003e] update_process_times+0xb4/0x150\n[\u003c90000000003b2474\u003e] tick_nohz_handler+0xf4/0x250\n[\u003c9000000000397e28\u003e] __hrtimer_run_queues+0x1d0/0x428\n[\u003c9000000000399b2c\u003e] hrtimer_interrupt+0x214/0x538\n[\u003c9000000000253634\u003e] constant_timer_interrupt+0x64/0x80\n[\u003c9000000000349938\u003e] __handle_irq_event_percpu+0x78/0x1a0\n[\u003c9000000000349a78\u003e] handle_irq_event_percpu+0x18/0x88\n[\u003c9000000000354c00\u003e] handle_percpu_irq+0x90/0xf0\n[\u003c9000000000348c74\u003e] handle_irq_desc+0x94/0xb8\n[\u003c9000000001012b28\u003e] handle_cpu_irq+0x68/0xa0\n[\u003c9000000001def8c0\u003e] handle_loongarch_irq+0x30/0x48\n[\u003c9000000001def958\u003e] do_vint+0x80/0xd0\n[\u003c9000000000268a0c\u003e] kasan_mem_to_shadow.part.0+0x2c/0x2a0\n[\u003c90000000006344f4\u003e] __asan_load8+0x4c/0x120\n[\u003c900000000025c0d0\u003e] module_frob_arch_sections+0x5c8/0x6b8\n[\u003c90000000003895f0\u003e] load_module+0x9e0/0x2958\n[\u003c900000000038b770\u003e] __do_sys_init_module+0x208/0x2d0\n[\u003c9000000001df0c34\u003e] do_syscall+0x94/0x190\n[\u003c900000000024d6fc\u003e] handle_syscall+0xbc/0x158\n\nAfter analysis, this is because the slow speed of loading the amdgpu\nmodule leads to the long time occupation of the cpu and then the soft\ndeadlock.\n\nWhen loading a module, module_frob_arch_sections() tries to figure out\nthe number of PLTs/GOTs that will be needed to handle all the RELAs. It\nwill call the count_max_entries() to find in an out-of-order date which\ncounting algorithm has O(n^2) complexity.\n\nTo make it faster, we sort the relocation list by info and addend. That\nway, to check for a duplicate relocation, it just needs to compare with\nthe previous entry. This reduces the complexity of the algorithm to O(n\n log n), as done in commit d4e0340919fb (\"arm64/module: Optimize module\nload time by optimizing PLT counting\"). This gives sinificant reduction\nin module load time for modules with large number of relocations.\n\nAfter applying this patch, the soft deadlock problem has been solved,\nand the kernel starts normally without \"Call Trace\".\n\nUsing the default configuration to test some modules, the results are as\nfollows:\n\nModule Size\nip_tables 36K\nfat 143K\nradeon 2.5MB\namdgpu 16MB\n\nWithout this patch:\nModule Module load time (ms)\tCount(PLTs/GOTs)\nip_tables 18\t\t\t\t59/6\nfat 0\t\t\t\t162/14\nradeon 54\t\t\t\t1221/84\namdgpu 1411\t\t\t4525/1098\n\nWith this patch:\nModule Module load time (ms)\tCount(PLTs/GOTs)\nip_tables 18\t\t\t\t59/6\nfat 0\t\t\t\t162/14\nradeon 22\t\t\t\t1221/84\namdgpu 45\t\t\t\t4525/1098",
"id": "GHSA-2pv7-jfgv-x3fr",
"modified": "2025-11-25T21:32:04Z",
"published": "2025-09-11T18:35:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-39767"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/5189c0b7c251363a4dd7678ed11b054c54f36f6f"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/63dbd8fb2af3a89466538599a9acb2d11ef65c06"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/a096b0280168d0c8b0ec1cbbfd56c8b81af8c7d8"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/e94cdb9fb279430cbd323a74c7ec124c85109747"
}
],
"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-2QG3-V24W-XHMX
Vulnerability from github – Published: 2022-05-01 02:08 – Updated: 2025-04-03 04:15Array index overflow in the xfrm_sk_policy_insert function in xfrm_user.c in Linux kernel 2.6 allows local users to cause a denial of service (oops or deadlock) and possibly execute arbitrary code via a p->dir value that is larger than XFRM_POLICY_OUT, which is used as an index in the sock->sk_policy array.
{
"affected": [],
"aliases": [
"CVE-2005-2456"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2005-08-04T04:00:00Z",
"severity": "LOW"
},
"details": "Array index overflow in the xfrm_sk_policy_insert function in xfrm_user.c in Linux kernel 2.6 allows local users to cause a denial of service (oops or deadlock) and possibly execute arbitrary code via a p-\u003edir value that is larger than XFRM_POLICY_OUT, which is used as an index in the sock-\u003esk_policy array.",
"id": "GHSA-2qg3-v24w-xhmx",
"modified": "2025-04-03T04:15:58Z",
"published": "2022-05-01T02:08:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2005-2456"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/21710"
},
{
"type": "WEB",
"url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A10858"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/169-1"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/16298"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/16500"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/17002"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/17073"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/17826"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/18056"
},
{
"type": "WEB",
"url": "http://secunia.com/advisories/18059"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2005/dsa-921"
},
{
"type": "WEB",
"url": "http://www.debian.org/security/2005/dsa-922"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=blobdiff%3Bh=8da3e25b2c4c1f305fd85428d3a9eb62b543bfba%3Bhp=ecade4893a139cc35d4fe345ce70242ede5358c4%3Bhb=a4f1bac62564049ea4718c4624b0fadc9f597c84%3Bf=net/xfrm/xfrm_user.c"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git%3Ba=commit%3Bh=a4f1bac62564049ea4718c4624b0fadc9f597c84"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;h=8da3e25b2c4c1f305fd85428d3a9eb62b543bfba;hp=ecade4893a139cc35d4fe345ce70242ede5358c4;hb=a4f1bac62564049ea4718c4624b0fadc9f597c84;f=net/xfrm/xfrm_user.c"
},
{
"type": "WEB",
"url": "http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=a4f1bac62564049ea4718c4624b0fadc9f597c84"
},
{
"type": "WEB",
"url": "http://www.mail-archive.com/netdev%40vger.kernel.org/msg00520.html"
},
{
"type": "WEB",
"url": "http://www.mail-archive.com/netdev@vger.kernel.org/msg00520.html"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDKSA-2005:219"
},
{
"type": "WEB",
"url": "http://www.mandriva.com/security/advisories?name=MDKSA-2005:220"
},
{
"type": "WEB",
"url": "http://www.novell.com/linux/security/advisories/2005_50_kernel.html"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2005-514.html"
},
{
"type": "WEB",
"url": "http://www.redhat.com/support/errata/RHSA-2005-663.html"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/archive/1/427980/100/0/threaded"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/14477"
},
{
"type": "WEB",
"url": "http://www.vupen.com/english/advisories/2005/1878"
}
],
"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-2QHQ-448H-5333
Vulnerability from github – Published: 2024-08-28 09:30 – Updated: 2024-08-28 09:30A vulnerability identified in NetIQ Advance Authentication that doesn't enforce account lockout when brute force attack is performed on API based login. This issue may lead to user account compromise if successful or may impact server performance. This issue impacts all NetIQ Advance Authentication before 6.3.5.1
{
"affected": [],
"aliases": [
"CVE-2021-22530"
],
"database_specific": {
"cwe_ids": [
"CWE-307",
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-28T07:15:06Z",
"severity": "HIGH"
},
"details": "A vulnerability identified in NetIQ Advance Authentication that doesn\u0027t enforce account lockout when brute force attack is performed on API based login. This issue may lead to user account compromise if successful or may impact server performance. This issue impacts all NetIQ Advance Authentication before 6.3.5.1",
"id": "GHSA-2qhq-448h-5333",
"modified": "2024-08-28T09:30:34Z",
"published": "2024-08-28T09:30:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22530"
},
{
"type": "WEB",
"url": "https://www.netiq.com/documentation/advanced-authentication-63/advanced-authentication-releasenotes-6351/data/advanced-authentication-releasenotes-6351.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-2QP4-G3Q3-F92W
Vulnerability from github – Published: 2022-02-26 00:00 – Updated: 2024-10-29 20:00In JetBrains Kotlin before 1.6.0, it was not possible to lock dependencies for Multiplatform Gradle Projects.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.5.32"
},
"package": {
"ecosystem": "Maven",
"name": "org.jetbrains.kotlin:kotlin-stdlib"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.6.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-24329"
],
"database_specific": {
"cwe_ids": [
"CWE-667",
"CWE-829"
],
"github_reviewed": true,
"github_reviewed_at": "2022-06-20T22:37:38Z",
"nvd_published_at": "2022-02-25T15:15:00Z",
"severity": "MODERATE"
},
"details": "In JetBrains Kotlin before 1.6.0, it was not possible to lock dependencies for Multiplatform Gradle Projects.",
"id": "GHSA-2qp4-g3q3-f92w",
"modified": "2024-10-29T20:00:54Z",
"published": "2022-02-26T00:00:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24329"
},
{
"type": "WEB",
"url": "https://blog.jetbrains.com"
},
{
"type": "WEB",
"url": "https://blog.jetbrains.com/blog/2022/02/08/jetbrains-security-bulletin-q4-2021"
},
{
"type": "PACKAGE",
"url": "https://github.com/JetBrains/kotlin"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpuapr2022.html"
},
{
"type": "WEB",
"url": "https://www.oracle.com/security-alerts/cpujul2022.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Improper Locking in JetBrains Kotlin"
}
GHSA-2R4H-M59F-X4W8
Vulnerability from github – Published: 2021-12-16 00:00 – Updated: 2021-12-21 00:01In mon_smc_load_sp of gs101-sc/plat/samsung/exynos/soc/exynos9845/smc_booting.S, there is a possible reinitialization of TEE due to improper locking. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-198713939References: N/A
{
"affected": [],
"aliases": [
"CVE-2021-39647"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-12-15T19:15:00Z",
"severity": "MODERATE"
},
"details": "In mon_smc_load_sp of gs101-sc/plat/samsung/exynos/soc/exynos9845/smc_booting.S, there is a possible reinitialization of TEE due to improper locking. This could lead to local information disclosure with System execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-198713939References: N/A",
"id": "GHSA-2r4h-m59f-x4w8",
"modified": "2021-12-21T00:01:01Z",
"published": "2021-12-16T00:00:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-39647"
},
{
"type": "WEB",
"url": "https://source.android.com/security/bulletin/pixel/2021-12-01"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-2R8X-HVQM-J9XF
Vulnerability from github – Published: 2025-01-11 15:30 – Updated: 2025-01-16 15:32In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: iso: Fix circular lock in iso_listen_bis
This fixes the circular locking dependency warning below, by releasing the socket lock before enterning iso_listen_bis, to avoid any potential deadlock with hdev lock.
[ 75.307983] ====================================================== [ 75.307984] WARNING: possible circular locking dependency detected [ 75.307985] 6.12.0-rc6+ #22 Not tainted [ 75.307987] ------------------------------------------------------ [ 75.307987] kworker/u81:2/2623 is trying to acquire lock: [ 75.307988] ffff8fde1769da58 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO) at: iso_connect_cfm+0x253/0x840 [bluetooth] [ 75.308021] but task is already holding lock: [ 75.308022] ffff8fdd61a10078 (&hdev->lock) at: hci_le_per_adv_report_evt+0x47/0x2f0 [bluetooth] [ 75.308053] which lock already depends on the new lock.
[ 75.308054] the existing dependency chain (in reverse order) is: [ 75.308055] -> #1 (&hdev->lock){+.+.}-{3:3}: [ 75.308057] __mutex_lock+0xad/0xc50 [ 75.308061] mutex_lock_nested+0x1b/0x30 [ 75.308063] iso_sock_listen+0x143/0x5c0 [bluetooth] [ 75.308085] __sys_listen_socket+0x49/0x60 [ 75.308088] __x64_sys_listen+0x4c/0x90 [ 75.308090] x64_sys_call+0x2517/0x25f0 [ 75.308092] do_syscall_64+0x87/0x150 [ 75.308095] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 75.308098] -> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}: [ 75.308100] __lock_acquire+0x155e/0x25f0 [ 75.308103] lock_acquire+0xc9/0x300 [ 75.308105] lock_sock_nested+0x32/0x90 [ 75.308107] iso_connect_cfm+0x253/0x840 [bluetooth] [ 75.308128] hci_connect_cfm+0x6c/0x190 [bluetooth] [ 75.308155] hci_le_per_adv_report_evt+0x27b/0x2f0 [bluetooth] [ 75.308180] hci_le_meta_evt+0xe7/0x200 [bluetooth] [ 75.308206] hci_event_packet+0x21f/0x5c0 [bluetooth] [ 75.308230] hci_rx_work+0x3ae/0xb10 [bluetooth] [ 75.308254] process_one_work+0x212/0x740 [ 75.308256] worker_thread+0x1bd/0x3a0 [ 75.308258] kthread+0xe4/0x120 [ 75.308259] ret_from_fork+0x44/0x70 [ 75.308261] ret_from_fork_asm+0x1a/0x30 [ 75.308263] other info that might help us debug this:
[ 75.308264] Possible unsafe locking scenario:
[ 75.308264] CPU0 CPU1 [ 75.308265] ---- ---- [ 75.308265] lock(&hdev->lock); [ 75.308267] lock(sk_lock- AF_BLUETOOTH-BTPROTO_ISO); [ 75.308268] lock(&hdev->lock); [ 75.308269] lock(sk_lock-AF_BLUETOOTH-BTPROTO_ISO); [ 75.308270] *** DEADLOCK ***
[ 75.308271] 4 locks held by kworker/u81:2/2623: [ 75.308272] #0: ffff8fdd66e52148 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_one_work+0x443/0x740 [ 75.308276] #1: ffffafb488b7fe48 ((work_completion)(&hdev->rx_work)), at: process_one_work+0x1ce/0x740 [ 75.308280] #2: ffff8fdd61a10078 (&hdev->lock){+.+.}-{3:3} at: hci_le_per_adv_report_evt+0x47/0x2f0 [bluetooth] [ 75.308304] #3: ffffffffb6ba4900 (rcu_read_lock){....}-{1:2}, at: hci_connect_cfm+0x29/0x190 [bluetooth]
{
"affected": [],
"aliases": [
"CVE-2024-54460"
],
"database_specific": {
"cwe_ids": [
"CWE-667"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-11T13:15:27Z",
"severity": "MODERATE"
},
"details": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: iso: Fix circular lock in iso_listen_bis\n\nThis fixes the circular locking dependency warning below, by\nreleasing the socket lock before enterning iso_listen_bis, to\navoid any potential deadlock with hdev lock.\n\n[ 75.307983] ======================================================\n[ 75.307984] WARNING: possible circular locking dependency detected\n[ 75.307985] 6.12.0-rc6+ #22 Not tainted\n[ 75.307987] ------------------------------------------------------\n[ 75.307987] kworker/u81:2/2623 is trying to acquire lock:\n[ 75.307988] ffff8fde1769da58 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO)\n at: iso_connect_cfm+0x253/0x840 [bluetooth]\n[ 75.308021]\n but task is already holding lock:\n[ 75.308022] ffff8fdd61a10078 (\u0026hdev-\u003elock)\n at: hci_le_per_adv_report_evt+0x47/0x2f0 [bluetooth]\n[ 75.308053]\n which lock already depends on the new lock.\n\n[ 75.308054]\n the existing dependency chain (in reverse order) is:\n[ 75.308055]\n -\u003e #1 (\u0026hdev-\u003elock){+.+.}-{3:3}:\n[ 75.308057] __mutex_lock+0xad/0xc50\n[ 75.308061] mutex_lock_nested+0x1b/0x30\n[ 75.308063] iso_sock_listen+0x143/0x5c0 [bluetooth]\n[ 75.308085] __sys_listen_socket+0x49/0x60\n[ 75.308088] __x64_sys_listen+0x4c/0x90\n[ 75.308090] x64_sys_call+0x2517/0x25f0\n[ 75.308092] do_syscall_64+0x87/0x150\n[ 75.308095] entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[ 75.308098]\n -\u003e #0 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}:\n[ 75.308100] __lock_acquire+0x155e/0x25f0\n[ 75.308103] lock_acquire+0xc9/0x300\n[ 75.308105] lock_sock_nested+0x32/0x90\n[ 75.308107] iso_connect_cfm+0x253/0x840 [bluetooth]\n[ 75.308128] hci_connect_cfm+0x6c/0x190 [bluetooth]\n[ 75.308155] hci_le_per_adv_report_evt+0x27b/0x2f0 [bluetooth]\n[ 75.308180] hci_le_meta_evt+0xe7/0x200 [bluetooth]\n[ 75.308206] hci_event_packet+0x21f/0x5c0 [bluetooth]\n[ 75.308230] hci_rx_work+0x3ae/0xb10 [bluetooth]\n[ 75.308254] process_one_work+0x212/0x740\n[ 75.308256] worker_thread+0x1bd/0x3a0\n[ 75.308258] kthread+0xe4/0x120\n[ 75.308259] ret_from_fork+0x44/0x70\n[ 75.308261] ret_from_fork_asm+0x1a/0x30\n[ 75.308263]\n other info that might help us debug this:\n\n[ 75.308264] Possible unsafe locking scenario:\n\n[ 75.308264] CPU0 CPU1\n[ 75.308265] ---- ----\n[ 75.308265] lock(\u0026hdev-\u003elock);\n[ 75.308267] lock(sk_lock-\n AF_BLUETOOTH-BTPROTO_ISO);\n[ 75.308268] lock(\u0026hdev-\u003elock);\n[ 75.308269] lock(sk_lock-AF_BLUETOOTH-BTPROTO_ISO);\n[ 75.308270]\n *** DEADLOCK ***\n\n[ 75.308271] 4 locks held by kworker/u81:2/2623:\n[ 75.308272] #0: ffff8fdd66e52148 ((wq_completion)hci0#2){+.+.}-{0:0},\n at: process_one_work+0x443/0x740\n[ 75.308276] #1: ffffafb488b7fe48 ((work_completion)(\u0026hdev-\u003erx_work)),\n at: process_one_work+0x1ce/0x740\n[ 75.308280] #2: ffff8fdd61a10078 (\u0026hdev-\u003elock){+.+.}-{3:3}\n at: hci_le_per_adv_report_evt+0x47/0x2f0 [bluetooth]\n[ 75.308304] #3: ffffffffb6ba4900 (rcu_read_lock){....}-{1:2},\n at: hci_connect_cfm+0x29/0x190 [bluetooth]",
"id": "GHSA-2r8x-hvqm-j9xf",
"modified": "2025-01-16T15:32:08Z",
"published": "2025-01-11T15:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-54460"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/168e28305b871d8ec604a8f51f35467b8d7ba05b"
},
{
"type": "WEB",
"url": "https://git.kernel.org/stable/c/c541d7b5e17987ed330798b07d4ad508859c1c93"
}
],
"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.