Logo
-

Byte Open Security

(ByteOS Network)

Log In

Sign Up

ByteOS

Security
Vulnerability Details
Registries
Custom Views
Weaknesses
Attack Patterns
Filters & Tools
Vulnerability Details :

CVE-2024-49943

Summary
Assigner-Linux
Assigner Org ID-416baaa9-dc9f-4396-8d5f-8c081fb06d67
Published At-21 Oct, 2024 | 18:02
Updated At-04 May, 2025 | 09:41
Rejected At-
Credits

drm/xe/guc_submit: add missing locking in wedged_fini

In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)

Vendors
-
Not available
Products
-
Metrics (CVSS)
VersionBase scoreBase severityVector
Weaknesses
Attack Patterns
Solution/Workaround
References
HyperlinkResource Type
EPSS History
Score
Latest Score
-
N/A
No data available for selected date range
Percentile
Latest Percentile
-
N/A
No data available for selected date range
Stakeholder-Specific Vulnerability Categorization (SSVC)
▼Common Vulnerabilities and Exposures (CVE)
cve.org
Assigner:Linux
Assigner Org ID:416baaa9-dc9f-4396-8d5f-8c081fb06d67
Published At:21 Oct, 2024 | 18:02
Updated At:04 May, 2025 | 09:41
Rejected At:
▼CVE Numbering Authority (CNA)
drm/xe/guc_submit: add missing locking in wedged_fini

In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)

Affected Products
Vendor
Linux Kernel Organization, IncLinux
Product
Linux
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Program Files
  • drivers/gpu/drm/xe/xe_guc_submit.c
Default Status
unaffected
Versions
Affected
  • From 8ed9aaae39f39130b7a3eb2726be05d7f64b344c before d88f9bab7e62dd0dbe983fa70cf040042a60cc84 (git)
  • From 8ed9aaae39f39130b7a3eb2726be05d7f64b344c before 790533e44bfc7af929842fccd9674c9f424d4627 (git)
Vendor
Linux Kernel Organization, IncLinux
Product
Linux
Repo
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Program Files
  • drivers/gpu/drm/xe/xe_guc_submit.c
Default Status
affected
Versions
Affected
  • 6.11
Unaffected
  • From 0 before 6.11 (semver)
  • From 6.11.3 through 6.11.* (semver)
  • From 6.12 through * (original_commit_for_fix)
Metrics
VersionBase scoreBase severityVector
Metrics Other Info
Impacts
CAPEC IDDescription
Solutions

Configurations

Workarounds

Exploits

Credits

Timeline
EventDate
Replaced By

Rejected Reason

References
HyperlinkResource
https://git.kernel.org/stable/c/d88f9bab7e62dd0dbe983fa70cf040042a60cc84
N/A
https://git.kernel.org/stable/c/790533e44bfc7af929842fccd9674c9f424d4627
N/A
Hyperlink: https://git.kernel.org/stable/c/d88f9bab7e62dd0dbe983fa70cf040042a60cc84
Resource: N/A
Hyperlink: https://git.kernel.org/stable/c/790533e44bfc7af929842fccd9674c9f424d4627
Resource: N/A
▼Authorized Data Publishers (ADP)
CISA ADP Vulnrichment
Affected Products
Metrics
VersionBase scoreBase severityVector
Metrics Other Info
Impacts
CAPEC IDDescription
Solutions

Configurations

Workarounds

Exploits

Credits

Timeline
EventDate
Replaced By

Rejected Reason

References
HyperlinkResource
Information is not available yet
▼National Vulnerability Database (NVD)
nvd.nist.gov
Source:416baaa9-dc9f-4396-8d5f-8c081fb06d67
Published At:21 Oct, 2024 | 18:15
Updated At:01 Nov, 2024 | 14:54

In the Linux kernel, the following vulnerability has been resolved: drm/xe/guc_submit: add missing locking in wedged_fini Any non-wedged queue can have a zero refcount here and can be running concurrently with an async queue destroy, therefore dereferencing the queue ptr to check wedge status after the lookup can trigger UAF if queue is not wedged. Fix this by keeping the submission_state lock held around the check to postpone the free and make the check safe, before dropping again around the put() to avoid the deadlock. (cherry picked from commit d28af0b6b9580b9f90c265a7da0315b0ad20bbfd)

CISA Catalog
Date AddedDue DateVulnerability NameRequired Action
N/A
Date Added: N/A
Due Date: N/A
Vulnerability Name: N/A
Required Action: N/A
Metrics
TypeVersionBase scoreBase severityVector
Primary3.15.5MEDIUM
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
Type: Primary
Version: 3.1
Base score: 5.5
Base severity: MEDIUM
Vector:
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H
CPE Matches

Linux Kernel Organization, Inc
linux
>>linux_kernel>>Versions from 6.11(inclusive) to 6.11.3(exclusive)
cpe:2.3:o:linux:linux_kernel:*:*:*:*:*:*:*:*
Linux Kernel Organization, Inc
linux
>>linux_kernel>>6.12
cpe:2.3:o:linux:linux_kernel:6.12:rc1:*:*:*:*:*:*
Weaknesses
CWE IDTypeSource
CWE-667Primarynvd@nist.gov
CWE ID: CWE-667
Type: Primary
Source: nvd@nist.gov
Evaluator Description

Evaluator Impact

Evaluator Solution

Vendor Statements

References
HyperlinkSourceResource
https://git.kernel.org/stable/c/790533e44bfc7af929842fccd9674c9f424d4627416baaa9-dc9f-4396-8d5f-8c081fb06d67
Patch
https://git.kernel.org/stable/c/d88f9bab7e62dd0dbe983fa70cf040042a60cc84416baaa9-dc9f-4396-8d5f-8c081fb06d67
Patch
Hyperlink: https://git.kernel.org/stable/c/790533e44bfc7af929842fccd9674c9f424d4627
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Resource:
Patch
Hyperlink: https://git.kernel.org/stable/c/d88f9bab7e62dd0dbe983fa70cf040042a60cc84
Source: 416baaa9-dc9f-4396-8d5f-8c081fb06d67
Resource:
Patch

Change History

0
Information is not available yet

Similar CVEs

3009Records found

CVE-2024-26987
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 1.08%
||
7 Day CHG~0.00%
Published-01 May, 2024 | 05:27
Updated-04 May, 2025 | 09:01
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled

In the Linux kernel, the following vulnerability has been resolved: mm/memory-failure: fix deadlock when hugetlb_optimize_vmemmap is enabled When I did hard offline test with hugetlb pages, below deadlock occurs: ====================================================== WARNING: possible circular locking dependency detected 6.8.0-11409-gf6cef5f8c37f #1 Not tainted ------------------------------------------------------ bash/46904 is trying to acquire lock: ffffffffabe68910 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_dec+0x16/0x60 but task is already holding lock: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (pcp_batch_high_lock){+.+.}-{3:3}: __mutex_lock+0x6c/0x770 page_alloc_cpu_online+0x3c/0x70 cpuhp_invoke_callback+0x397/0x5f0 __cpuhp_invoke_callback_range+0x71/0xe0 _cpu_up+0xeb/0x210 cpu_up+0x91/0xe0 cpuhp_bringup_mask+0x49/0xb0 bringup_nonboot_cpus+0xb7/0xe0 smp_init+0x25/0xa0 kernel_init_freeable+0x15f/0x3e0 kernel_init+0x15/0x1b0 ret_from_fork+0x2f/0x50 ret_from_fork_asm+0x1a/0x30 -> #0 (cpu_hotplug_lock){++++}-{0:0}: __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(pcp_batch_high_lock); lock(cpu_hotplug_lock); lock(pcp_batch_high_lock); rlock(cpu_hotplug_lock); *** DEADLOCK *** 5 locks held by bash/46904: #0: ffff98f6c3bb23f0 (sb_writers#5){.+.+}-{0:0}, at: ksys_write+0x64/0xe0 #1: ffff98f6c328e488 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0xf8/0x1d0 #2: ffff98ef83b31890 (kn->active#113){.+.+}-{0:0}, at: kernfs_fop_write_iter+0x100/0x1d0 #3: ffffffffabf9db48 (mf_mutex){+.+.}-{3:3}, at: memory_failure+0x44/0xc70 #4: ffffffffabf92ea8 (pcp_batch_high_lock){+.+.}-{3:3}, at: zone_pcp_disable+0x16/0x40 stack backtrace: CPU: 10 PID: 46904 Comm: bash Kdump: loaded Not tainted 6.8.0-11409-gf6cef5f8c37f #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x68/0xa0 check_noncircular+0x129/0x140 __lock_acquire+0x1298/0x1cd0 lock_acquire+0xc0/0x2b0 cpus_read_lock+0x2a/0xc0 static_key_slow_dec+0x16/0x60 __hugetlb_vmemmap_restore_folio+0x1b9/0x200 dissolve_free_huge_page+0x211/0x260 __page_handle_poison+0x45/0xc0 memory_failure+0x65e/0xc70 hard_offline_page_store+0x55/0xa0 kernfs_fop_write_iter+0x12c/0x1d0 vfs_write+0x387/0x550 ksys_write+0x64/0xe0 do_syscall_64+0xca/0x1e0 entry_SYSCALL_64_after_hwframe+0x6d/0x75 RIP: 0033:0x7fc862314887 Code: 10 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24 RSP: 002b:00007fff19311268 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007fc862314887 RDX: 000000000000000c RSI: 000056405645fe10 RDI: 0000000000000001 RBP: 000056405645fe10 R08: 00007fc8623d1460 R09: 000000007fffffff R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c R13: 00007fc86241b780 R14: 00007fc862417600 R15: 00007fc862416a00 In short, below scene breaks the ---truncated---

Action-Not Available
Vendor-Linux Kernel Organization, IncFedora Project
Product-fedoralinux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-38553
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.67%
||
7 Day CHG~0.00%
Published-19 Jun, 2024 | 13:35
Updated-04 May, 2025 | 09:13
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
net: fec: remove .ndo_poll_controller to avoid deadlocks

In the Linux kernel, the following vulnerability has been resolved: net: fec: remove .ndo_poll_controller to avoid deadlocks There is a deadlock issue found in sungem driver, please refer to the commit ac0a230f719b ("eth: sungem: remove .ndo_poll_controller to avoid deadlocks"). The root cause of the issue is that netpoll is in atomic context and disable_irq() is called by .ndo_poll_controller interface of sungem driver, however, disable_irq() might sleep. After analyzing the implementation of fec_poll_controller(), the fec driver should have the same issue. Due to the fec driver uses NAPI for TX completions, the .ndo_poll_controller is unnecessary to be implemented in the fec driver, so fec_poll_controller() can be safely removed.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2023-52484
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 1.15%
||
7 Day CHG~0.00%
Published-29 Feb, 2024 | 05:43
Updated-04 May, 2025 | 07:37
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range

In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range When running an SVA case, the following soft lockup is triggered: -------------------------------------------------------------------- watchdog: BUG: soft lockup - CPU#244 stuck for 26s! pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50 sp : ffff8000d83ef290 x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000 x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000 x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0 x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0 x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 __arm_smmu_tlb_inv_range+0x118/0x254 arm_smmu_tlb_inv_range_asid+0x6c/0x130 arm_smmu_mm_invalidate_range+0xa0/0xa4 __mmu_notifier_invalidate_range_end+0x88/0x120 unmap_vmas+0x194/0x1e0 unmap_region+0xb4/0x144 do_mas_align_munmap+0x290/0x490 do_mas_munmap+0xbc/0x124 __vm_munmap+0xa8/0x19c __arm64_sys_munmap+0x28/0x50 invoke_syscall+0x78/0x11c el0_svc_common.constprop.0+0x58/0x1c0 do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8 -------------------------------------------------------------------- Note that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed to "arm_smmu_mm_arch_invalidate_secondary_tlbs", yet the problem remains. The commit 06ff87bae8d3 ("arm64: mm: remove unused functions and variable protoypes") fixed a similar lockup on the CPU MMU side. Yet, it can occur to SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called typically next to MMU tlb flush function, e.g. tlb_flush_mmu_tlbonly { tlb_flush { __flush_tlb_range { // check MAX_TLBI_OPS } } mmu_notifier_arch_invalidate_secondary_tlbs { arm_smmu_mm_arch_invalidate_secondary_tlbs { // does not check MAX_TLBI_OPS } } } Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an SVA case SMMU uses the CPU page table, so it makes sense to align with the tlbflush code. Then, replace per-page TLBI commands with a single per-asid TLBI command, if the request size hits this threshold.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-36924
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.35%
||
7 Day CHG~0.00%
Published-30 May, 2024 | 15:29
Updated-04 May, 2025 | 09:12
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()

In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up() lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the hbalock. Thus, lpfc_worker_wake_up() should not be called while holding the hbalock to avoid potential deadlock.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2023-52932
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 4.49%
||
7 Day CHG-0.02%
Published-27 Mar, 2025 | 16:37
Updated-04 May, 2025 | 07:46
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
mm/swapfile: add cond_resched() in get_swap_pages()

In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: add cond_resched() in get_swap_pages() The softlockup still occurs in get_swap_pages() under memory pressure. 64 CPU cores, 64GB memory, and 28 zram devices, the disksize of each zram device is 50MB with same priority as si. Use the stress-ng tool to increase memory pressure, causing the system to oom frequently. The plist_for_each_entry_safe() loops in get_swap_pages() could reach tens of thousands of times to find available space (extreme case: cond_resched() is not called in scan_swap_map_slots()). Let's add cond_resched() into get_swap_pages() when failed to find available space to avoid softlockup.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2023-52498
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.57%
||
7 Day CHG~0.00%
Published-29 Feb, 2024 | 15:52
Updated-04 May, 2025 | 07:38
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
PM: sleep: Fix possible deadlocks in core system-wide PM code

In the Linux kernel, the following vulnerability has been resolved: PM: sleep: Fix possible deadlocks in core system-wide PM code It is reported that in low-memory situations the system-wide resume core code deadlocks, because async_schedule_dev() executes its argument function synchronously if it cannot allocate memory (and not only in that case) and that function attempts to acquire a mutex that is already held. Executing the argument function synchronously from within dpm_async_fn() may also be problematic for ordering reasons (it may cause a consumer device's resume callback to be invoked before a requisite supplier device's one, for example). Address this by changing the code in question to use async_schedule_dev_nocall() for scheduling the asynchronous execution of device suspend and resume functions and to directly run them synchronously if async_schedule_dev_nocall() returns false.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2023-52493
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.72%
||
7 Day CHG~0.00%
Published-29 Feb, 2024 | 15:52
Updated-04 May, 2025 | 07:37
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
bus: mhi: host: Drop chan lock before queuing buffers

In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Drop chan lock before queuing buffers Ensure read and write locks for the channel are not taken in succession by dropping the read lock from parse_xfer_event() such that a callback given to client can potentially queue buffers and acquire the write lock in that process. Any queueing of buffers should be done without channel read lock acquired as it can result in multiple locks and a soft lockup. [mani: added fixes tag and cc'ed stable]

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2023-53022
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.73%
||
7 Day CHG-0.01%
Published-27 Mar, 2025 | 16:43
Updated-04 May, 2025 | 07:47
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
net: enetc: avoid deadlock in enetc_tx_onestep_tstamp()

In the Linux kernel, the following vulnerability has been resolved: net: enetc: avoid deadlock in enetc_tx_onestep_tstamp() This lockdep splat says it better than I could: ================================ WARNING: inconsistent lock state 6.2.0-rc2-07010-ga9b9500ffaac-dirty #967 Not tainted -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage. kworker/1:3/179 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff3ec4036ce098 (_xmit_ETHER#2){+.?.}-{3:3}, at: netif_freeze_queues+0x5c/0xc0 {IN-SOFTIRQ-W} state was registered at: _raw_spin_lock+0x5c/0xc0 sch_direct_xmit+0x148/0x37c __dev_queue_xmit+0x528/0x111c ip6_finish_output2+0x5ec/0xb7c ip6_finish_output+0x240/0x3f0 ip6_output+0x78/0x360 ndisc_send_skb+0x33c/0x85c ndisc_send_rs+0x54/0x12c addrconf_rs_timer+0x154/0x260 call_timer_fn+0xb8/0x3a0 __run_timers.part.0+0x214/0x26c run_timer_softirq+0x3c/0x74 __do_softirq+0x14c/0x5d8 ____do_softirq+0x10/0x20 call_on_irq_stack+0x2c/0x5c do_softirq_own_stack+0x1c/0x30 __irq_exit_rcu+0x168/0x1a0 irq_exit_rcu+0x10/0x40 el1_interrupt+0x38/0x64 irq event stamp: 7825 hardirqs last enabled at (7825): [<ffffdf1f7200cae4>] exit_to_kernel_mode+0x34/0x130 hardirqs last disabled at (7823): [<ffffdf1f708105f0>] __do_softirq+0x550/0x5d8 softirqs last enabled at (7824): [<ffffdf1f7081050c>] __do_softirq+0x46c/0x5d8 softirqs last disabled at (7811): [<ffffdf1f708166e0>] ____do_softirq+0x10/0x20 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(_xmit_ETHER#2); <Interrupt> lock(_xmit_ETHER#2); *** DEADLOCK *** 3 locks held by kworker/1:3/179: #0: ffff3ec400004748 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0 #1: ffff80000a0bbdc8 ((work_completion)(&priv->tx_onestep_tstamp)){+.+.}-{0:0}, at: process_one_work+0x1f4/0x6c0 #2: ffff3ec4036cd438 (&dev->tx_global_lock){+.+.}-{3:3}, at: netif_tx_lock+0x1c/0x34 Workqueue: events enetc_tx_onestep_tstamp Call trace: print_usage_bug.part.0+0x208/0x22c mark_lock+0x7f0/0x8b0 __lock_acquire+0x7c4/0x1ce0 lock_acquire.part.0+0xe0/0x220 lock_acquire+0x68/0x84 _raw_spin_lock+0x5c/0xc0 netif_freeze_queues+0x5c/0xc0 netif_tx_lock+0x24/0x34 enetc_tx_onestep_tstamp+0x20/0x100 process_one_work+0x28c/0x6c0 worker_thread+0x74/0x450 kthread+0x118/0x11c but I'll say it anyway: the enetc_tx_onestep_tstamp() work item runs in process context, therefore with softirqs enabled (i.o.w., it can be interrupted by a softirq). If we hold the netif_tx_lock() when there is an interrupt, and the NET_TX softirq then gets scheduled, this will take the netif_tx_lock() a second time and deadlock the kernel. To solve this, use netif_tx_lock_bh(), which blocks softirqs from running.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2023-52638
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.85%
||
7 Day CHG~0.00%
Published-03 Apr, 2024 | 14:54
Updated-04 May, 2025 | 07:40
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock

In the Linux kernel, the following vulnerability has been resolved: can: j1939: prevent deadlock by changing j1939_socks_lock to rwlock The following 3 locks would race against each other, causing the deadlock situation in the Syzbot bug report: - j1939_socks_lock - active_session_list_lock - sk_session_queue_lock A reasonable fix is to change j1939_socks_lock to an rwlock, since in the rare situations where a write lock is required for the linked list that j1939_socks_lock is protecting, the code does not attempt to acquire any more locks. This would break the circular lock dependency, where, for example, the current thread already locks j1939_socks_lock and attempts to acquire sk_session_queue_lock, and at the same time, another thread attempts to acquire j1939_socks_lock while holding sk_session_queue_lock. NOTE: This patch along does not fix the unregister_netdevice bug reported by Syzbot; instead, it solves a deadlock situation to prepare for one or more further patches to actually fix the Syzbot bug, which appears to be a reference counting problem within the j1939 codebase. [mkl: remove unrelated newline change]

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2023-52903
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.04% / 9.95%
||
7 Day CHG~0.00%
Published-21 Aug, 2024 | 06:10
Updated-04 May, 2025 | 07:45
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
io_uring: lock overflowing for IOPOLL

In the Linux kernel, the following vulnerability has been resolved: io_uring: lock overflowing for IOPOLL syzbot reports an issue with overflow filling for IOPOLL: WARNING: CPU: 0 PID: 28 at io_uring/io_uring.c:734 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734 CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0 Workqueue: events_unbound io_ring_exit_work Call trace:  io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734  io_req_cqe_overflow+0x5c/0x70 io_uring/io_uring.c:773  io_fill_cqe_req io_uring/io_uring.h:168 [inline]  io_do_iopoll+0x474/0x62c io_uring/rw.c:1065  io_iopoll_try_reap_events+0x6c/0x108 io_uring/io_uring.c:1513  io_uring_try_cancel_requests+0x13c/0x258 io_uring/io_uring.c:3056  io_ring_exit_work+0xec/0x390 io_uring/io_uring.c:2869  process_one_work+0x2d8/0x504 kernel/workqueue.c:2289  worker_thread+0x340/0x610 kernel/workqueue.c:2436  kthread+0x12c/0x158 kernel/kthread.c:376  ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863 There is no real problem for normal IOPOLL as flush is also called with uring_lock taken, but it's getting more complicated for IOPOLL|SQPOLL, for which __io_cqring_overflow_flush() happens from the CQ waiting path.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2023-52486
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.27%
||
7 Day CHG~0.00%
Published-29 Feb, 2024 | 15:52
Updated-04 May, 2025 | 07:37
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
drm: Don't unref the same fb many times by mistake due to deadlock handling

In 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.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2023-52590
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.40%
||
7 Day CHG~0.00%
Published-06 Mar, 2024 | 06:45
Updated-04 May, 2025 | 07:39
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
ocfs2: Avoid touching renamed directory if parent does not change

In the Linux kernel, the following vulnerability has been resolved: ocfs2: Avoid touching renamed directory if parent does not change The VFS will not be locking moved directory if its parent does not change. Change ocfs2 rename code to avoid touching renamed directory if its parent does not change as without locking that can corrupt the filesystem.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2023-52583
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.84%
||
7 Day CHG~0.00%
Published-06 Mar, 2024 | 06:45
Updated-04 May, 2025 | 07:39
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
ceph: fix deadlock or deadcode of misusing dget()

In 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.

Action-Not Available
Vendor-Linux Kernel Organization, IncDebian GNU/Linux
Product-debian_linuxlinux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2023-53016
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.73%
||
7 Day CHG-0.01%
Published-27 Mar, 2025 | 16:43
Updated-04 May, 2025 | 07:47
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
Bluetooth: Fix possible deadlock in rfcomm_sk_state_change

In the Linux kernel, the following vulnerability has been resolved: Bluetooth: Fix possible deadlock in rfcomm_sk_state_change syzbot reports a possible deadlock in rfcomm_sk_state_change [1]. While rfcomm_sock_connect acquires the sk lock and waits for the rfcomm lock, rfcomm_sock_release could have the rfcomm lock and hit a deadlock for acquiring the sk lock. Here's a simplified flow: rfcomm_sock_connect: lock_sock(sk) rfcomm_dlc_open: rfcomm_lock() rfcomm_sock_release: rfcomm_sock_shutdown: rfcomm_lock() __rfcomm_dlc_close: rfcomm_k_state_change: lock_sock(sk) This patch drops the sk lock before calling rfcomm_dlc_open to avoid the possible deadlock and holds sk's reference count to prevent use-after-free after rfcomm_dlc_open completes.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-416
Use After Free
CWE ID-CWE-667
Improper Locking
CVE-2023-52595
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.89%
||
7 Day CHG~0.00%
Published-06 Mar, 2024 | 06:45
Updated-04 May, 2025 | 07:39
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
wifi: rt2x00: restart beacon queue when hardware reset

In the Linux kernel, the following vulnerability has been resolved: wifi: rt2x00: restart beacon queue when hardware reset When a hardware reset is triggered, all registers are reset, so all queues are forced to stop in hardware interface. However, mac80211 will not automatically stop the queue. If we don't manually stop the beacon queue, the queue will be deadlocked and unable to start again. This patch fixes the issue where Apple devices cannot connect to the AP after calling ieee80211_restart_hw().

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2023-52632
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 1.43%
||
7 Day CHG~0.00%
Published-02 Apr, 2024 | 06:49
Updated-04 May, 2025 | 07:40
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
drm/amdkfd: Fix lock dependency warning with srcu

In the Linux kernel, the following vulnerability has been resolved: drm/amdkfd: Fix lock dependency warning with srcu ====================================================== WARNING: possible circular locking dependency detected 6.5.0-kfd-yangp #2289 Not tainted ------------------------------------------------------ kworker/0:2/996 is trying to acquire lock: (srcu){.+.+}-{0:0}, at: __synchronize_srcu+0x5/0x1a0 but task is already holding lock: ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}, at: process_one_work+0x211/0x560 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 ((work_completion)(&svms->deferred_list_work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 svm_range_list_lock_and_flush_work+0x3d/0x110 [amdgpu] svm_range_set_attr+0xd6/0x14c0 [amdgpu] kfd_ioctl+0x1d1/0x630 [amdgpu] __x64_sys_ioctl+0x88/0xc0 -> #2 (&info->lock#2){+.+.}-{3:3}: __mutex_lock+0x99/0xc70 amdgpu_amdkfd_gpuvm_restore_process_bos+0x54/0x740 [amdgpu] restore_process_helper+0x22/0x80 [amdgpu] restore_process_worker+0x2d/0xa0 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 -> #1 ((work_completion)(&(&process->restore_work)->work)){+.+.}-{0:0}: __flush_work+0x88/0x4f0 __cancel_work_timer+0x12c/0x1c0 kfd_process_notifier_release_internal+0x37/0x1f0 [amdgpu] __mmu_notifier_release+0xad/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 do_exit+0x322/0xb90 do_group_exit+0x37/0xa0 __x64_sys_exit_group+0x18/0x20 do_syscall_64+0x38/0x80 -> #0 (srcu){.+.+}-{0:0}: __lock_acquire+0x1521/0x2510 lock_sync+0x5f/0x90 __synchronize_srcu+0x4f/0x1a0 __mmu_notifier_release+0x128/0x240 exit_mmap+0x6a/0x3a0 mmput+0x6a/0x120 svm_range_deferred_list_work+0x19f/0x350 [amdgpu] process_one_work+0x29b/0x560 worker_thread+0x3d/0x3d0 other info that might help us debug this: Chain exists of: srcu --> &info->lock#2 --> (work_completion)(&svms->deferred_list_work) Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock((work_completion)(&svms->deferred_list_work)); lock(&info->lock#2); lock((work_completion)(&svms->deferred_list_work)); sync(srcu);

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2023-52587
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.30%
||
7 Day CHG~0.00%
Published-06 Mar, 2024 | 06:45
Updated-04 May, 2025 | 07:39
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
IB/ipoib: Fix mcast list locking

In 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 --- <NMI exception stack> --- #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 <ipoib_mcast_join_task>, 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---

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-54683
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 2.98%
||
7 Day CHG~0.00%
Published-11 Jan, 2025 | 12:29
Updated-04 May, 2025 | 09:57
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
netfilter: IDLETIMER: Fix for possible ABBA deadlock

In the Linux kernel, the following vulnerability has been resolved: netfilter: IDLETIMER: Fix for possible ABBA deadlock Deletion of the last rule referencing a given idletimer may happen at the same time as a read of its file in sysfs: | ====================================================== | WARNING: possible circular locking dependency detected | 6.12.0-rc7-01692-g5e9a28f41134-dirty #594 Not tainted | ------------------------------------------------------ | iptables/3303 is trying to acquire lock: | ffff8881057e04b8 (kn->active#48){++++}-{0:0}, at: __kernfs_remove+0x20 | | but task is already holding lock: | ffffffffa0249068 (list_mutex){+.+.}-{3:3}, at: idletimer_tg_destroy_v] | | which lock already depends on the new lock. A simple reproducer is: | #!/bin/bash | | while true; do | iptables -A INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" | iptables -D INPUT -i foo -j IDLETIMER --timeout 10 --label "testme" | done & | while true; do | cat /sys/class/xt_idletimer/timers/testme >/dev/null | done Avoid this by freeing list_mutex right after deleting the element from the list, then continuing with the teardown.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2025-21912
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 1.23%
||
7 Day CHG-0.01%
Published-01 Apr, 2025 | 15:40
Updated-28 Aug, 2025 | 15:15
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
gpio: rcar: Use raw_spinlock to protect register access

In the Linux kernel, the following vulnerability has been resolved: gpio: rcar: Use raw_spinlock to protect register access Use raw_spinlock in order to fix spurious messages about invalid context when spinlock debugging is enabled. The lock is only used to serialize register access. [ 4.239592] ============================= [ 4.239595] [ BUG: Invalid wait context ] [ 4.239599] 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 Not tainted [ 4.239603] ----------------------------- [ 4.239606] kworker/u8:5/76 is trying to lock: [ 4.239609] ffff0000091898a0 (&p->lock){....}-{3:3}, at: gpio_rcar_config_interrupt_input_mode+0x34/0x164 [ 4.239641] other info that might help us debug this: [ 4.239643] context-{5:5} [ 4.239646] 5 locks held by kworker/u8:5/76: [ 4.239651] #0: ffff0000080fb148 ((wq_completion)async){+.+.}-{0:0}, at: process_one_work+0x190/0x62c [ 4.250180] OF: /soc/sound@ec500000/ports/port@0/endpoint: Read of boolean property 'frame-master' with a value. [ 4.254094] #1: ffff80008299bd80 ((work_completion)(&entry->work)){+.+.}-{0:0}, at: process_one_work+0x1b8/0x62c [ 4.254109] #2: ffff00000920c8f8 [ 4.258345] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'bitclock-master' with a value. [ 4.264803] (&dev->mutex){....}-{4:4}, at: __device_attach_async_helper+0x3c/0xdc [ 4.264820] #3: ffff00000a50ca40 (request_class#2){+.+.}-{4:4}, at: __setup_irq+0xa0/0x690 [ 4.264840] #4: [ 4.268872] OF: /soc/sound@ec500000/ports/port@1/endpoint: Read of boolean property 'frame-master' with a value. [ 4.273275] ffff00000a50c8c8 (lock_class){....}-{2:2}, at: __setup_irq+0xc4/0x690 [ 4.296130] renesas_sdhi_internal_dmac ee100000.mmc: mmc1 base at 0x00000000ee100000, max clock rate 200 MHz [ 4.304082] stack backtrace: [ 4.304086] CPU: 1 UID: 0 PID: 76 Comm: kworker/u8:5 Not tainted 6.13.0-rc7-arm64-renesas-05496-gd088502a519f #35 [ 4.304092] Hardware name: Renesas Salvator-X 2nd version board based on r8a77965 (DT) [ 4.304097] Workqueue: async async_run_entry_fn [ 4.304106] Call trace: [ 4.304110] show_stack+0x14/0x20 (C) [ 4.304122] dump_stack_lvl+0x6c/0x90 [ 4.304131] dump_stack+0x14/0x1c [ 4.304138] __lock_acquire+0xdfc/0x1584 [ 4.426274] lock_acquire+0x1c4/0x33c [ 4.429942] _raw_spin_lock_irqsave+0x5c/0x80 [ 4.434307] gpio_rcar_config_interrupt_input_mode+0x34/0x164 [ 4.440061] gpio_rcar_irq_set_type+0xd4/0xd8 [ 4.444422] __irq_set_trigger+0x5c/0x178 [ 4.448435] __setup_irq+0x2e4/0x690 [ 4.452012] request_threaded_irq+0xc4/0x190 [ 4.456285] devm_request_threaded_irq+0x7c/0xf4 [ 4.459398] ata1: link resume succeeded after 1 retries [ 4.460902] mmc_gpiod_request_cd_irq+0x68/0xe0 [ 4.470660] mmc_start_host+0x50/0xac [ 4.474327] mmc_add_host+0x80/0xe4 [ 4.477817] tmio_mmc_host_probe+0x2b0/0x440 [ 4.482094] renesas_sdhi_probe+0x488/0x6f4 [ 4.486281] renesas_sdhi_internal_dmac_probe+0x60/0x78 [ 4.491509] platform_probe+0x64/0xd8 [ 4.495178] really_probe+0xb8/0x2a8 [ 4.498756] __driver_probe_device+0x74/0x118 [ 4.503116] driver_probe_device+0x3c/0x154 [ 4.507303] __device_attach_driver+0xd4/0x160 [ 4.511750] bus_for_each_drv+0x84/0xe0 [ 4.515588] __device_attach_async_helper+0xb0/0xdc [ 4.520470] async_run_entry_fn+0x30/0xd8 [ 4.524481] process_one_work+0x210/0x62c [ 4.528494] worker_thread+0x1ac/0x340 [ 4.532245] kthread+0x10c/0x110 [ 4.535476] ret_from_fork+0x10/0x20

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-53080
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 6.62%
||
7 Day CHG~0.00%
Published-19 Nov, 2024 | 17:45
Updated-04 May, 2025 | 09:52
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
drm/panthor: Lock XArray when getting entries for the VM

In the Linux kernel, the following vulnerability has been resolved: drm/panthor: Lock XArray when getting entries for the VM Similar to commit cac075706f29 ("drm/panthor: Fix race when converting group handle to group object") we need to use the XArray's internal locking when retrieving a vm pointer from there. v2: Removed part of the patch that was trying to protect fetching the heap pointer from XArray, as that operation is protected by the @pool->lock.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-53086
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 5.46%
||
7 Day CHG~0.00%
Published-19 Nov, 2024 | 17:45
Updated-04 May, 2025 | 09:52
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL

In the Linux kernel, the following vulnerability has been resolved: drm/xe: Drop VM dma-resv lock on xe_sync_in_fence_get failure in exec IOCTL Upon failure all locks need to be dropped before returning to the user. (cherry picked from commit 7d1a4258e602ffdce529f56686925034c1b3b095)

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2022-49322
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 3.18%
||
7 Day CHG~0.00%
Published-26 Feb, 2025 | 02:10
Updated-04 May, 2025 | 08:35
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
tracing: Fix sleeping function called from invalid context on RT kernel

In the Linux kernel, the following vulnerability has been resolved: tracing: Fix sleeping function called from invalid context on RT kernel When setting bootparams="trace_event=initcall:initcall_start tp_printk=1" in the cmdline, the output_printk() was called, and the spin_lock_irqsave() was called in the atomic and irq disable interrupt context suitation. On the PREEMPT_RT kernel, these locks are replaced with sleepable rt-spinlock, so the stack calltrace will be triggered. Fix it by raw_spin_lock_irqsave when PREEMPT_RT and "trace_event=initcall:initcall_start tp_printk=1" enabled. BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 1, name: swapper/0 preempt_count: 2, expected: 0 RCU nest depth: 0, expected: 0 Preemption disabled at: [<ffffffff8992303e>] try_to_wake_up+0x7e/0xba0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.17.1-rt17+ #19 34c5812404187a875f32bee7977f7367f9679ea7 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x60/0x8c dump_stack+0x10/0x12 __might_resched.cold+0x11d/0x155 rt_spin_lock+0x40/0x70 trace_event_buffer_commit+0x2fa/0x4c0 ? map_vsyscall+0x93/0x93 trace_event_raw_event_initcall_start+0xbe/0x110 ? perf_trace_initcall_finish+0x210/0x210 ? probe_sched_wakeup+0x34/0x40 ? ttwu_do_wakeup+0xda/0x310 ? trace_hardirqs_on+0x35/0x170 ? map_vsyscall+0x93/0x93 do_one_initcall+0x217/0x3c0 ? trace_event_raw_event_initcall_level+0x170/0x170 ? push_cpu_stop+0x400/0x400 ? cblist_init_generic+0x241/0x290 kernel_init_freeable+0x1ac/0x347 ? _raw_spin_unlock_irq+0x65/0x80 ? rest_init+0xf0/0xf0 kernel_init+0x1e/0x150 ret_from_fork+0x22/0x30 </TASK>

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2022-48734
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.53%
||
7 Day CHG~0.00%
Published-20 Jun, 2024 | 11:13
Updated-04 May, 2025 | 08:22
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
btrfs: fix deadlock between quota disable and qgroup rescan worker

In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock between quota disable and qgroup rescan worker Quota disable ioctl starts a transaction before waiting for the qgroup rescan worker completes. However, this wait can be infinite and results in deadlock because of circular dependency among the quota disable ioctl, the qgroup rescan worker and the other task with transaction such as block group relocation task. The deadlock happens with the steps following: 1) Task A calls ioctl to disable quota. It starts a transaction and waits for qgroup rescan worker completes. 2) Task B such as block group relocation task starts a transaction and joins to the transaction that task A started. Then task B commits to the transaction. In this commit, task B waits for a commit by task A. 3) Task C as the qgroup rescan worker starts its job and starts a transaction. In this transaction start, task C waits for completion of the transaction that task A started and task B committed. This deadlock was found with fstests test case btrfs/115 and a zoned null_blk device. The test case enables and disables quota, and the block group reclaim was triggered during the quota disable by chance. The deadlock was also observed by running quota enable and disable in parallel with 'btrfs balance' command on regular null_blk devices. An example report of the deadlock: [372.469894] INFO: task kworker/u16:6:103 blocked for more than 122 seconds. [372.479944] Not tainted 5.16.0-rc8 #7 [372.485067] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [372.493898] task:kworker/u16:6 state:D stack: 0 pid: 103 ppid: 2 flags:0x00004000 [372.503285] Workqueue: btrfs-qgroup-rescan btrfs_work_helper [btrfs] [372.510782] Call Trace: [372.514092] <TASK> [372.521684] __schedule+0xb56/0x4850 [372.530104] ? io_schedule_timeout+0x190/0x190 [372.538842] ? lockdep_hardirqs_on+0x7e/0x100 [372.547092] ? _raw_spin_unlock_irqrestore+0x3e/0x60 [372.555591] schedule+0xe0/0x270 [372.561894] btrfs_commit_transaction+0x18bb/0x2610 [btrfs] [372.570506] ? btrfs_apply_pending_changes+0x50/0x50 [btrfs] [372.578875] ? free_unref_page+0x3f2/0x650 [372.585484] ? finish_wait+0x270/0x270 [372.591594] ? release_extent_buffer+0x224/0x420 [btrfs] [372.599264] btrfs_qgroup_rescan_worker+0xc13/0x10c0 [btrfs] [372.607157] ? lock_release+0x3a9/0x6d0 [372.613054] ? btrfs_qgroup_account_extent+0xda0/0xda0 [btrfs] [372.620960] ? do_raw_spin_lock+0x11e/0x250 [372.627137] ? rwlock_bug.part.0+0x90/0x90 [372.633215] ? lock_is_held_type+0xe4/0x140 [372.639404] btrfs_work_helper+0x1ae/0xa90 [btrfs] [372.646268] process_one_work+0x7e9/0x1320 [372.652321] ? lock_release+0x6d0/0x6d0 [372.658081] ? pwq_dec_nr_in_flight+0x230/0x230 [372.664513] ? rwlock_bug.part.0+0x90/0x90 [372.670529] worker_thread+0x59e/0xf90 [372.676172] ? process_one_work+0x1320/0x1320 [372.682440] kthread+0x3b9/0x490 [372.687550] ? _raw_spin_unlock_irq+0x24/0x50 [372.693811] ? set_kthread_struct+0x100/0x100 [372.700052] ret_from_fork+0x22/0x30 [372.705517] </TASK> [372.709747] INFO: task btrfs-transacti:2347 blocked for more than 123 seconds. [372.729827] Not tainted 5.16.0-rc8 #7 [372.745907] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [372.767106] task:btrfs-transacti state:D stack: 0 pid: 2347 ppid: 2 flags:0x00004000 [372.787776] Call Trace: [372.801652] <TASK> [372.812961] __schedule+0xb56/0x4850 [372.830011] ? io_schedule_timeout+0x190/0x190 [372.852547] ? lockdep_hardirqs_on+0x7e/0x100 [372.871761] ? _raw_spin_unlock_irqrestore+0x3e/0x60 [372.886792] schedule+0xe0/0x270 [372.901685] wait_current_trans+0x22c/0x310 [btrfs] [372.919743] ? btrfs_put_transaction+0x3d0/0x3d0 [btrfs] [372.938923] ? finish_wait+0x270/0x270 [372.959085] ? join_transaction+0xc7 ---truncated---

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-27003
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 0.91%
||
7 Day CHG~0.00%
Published-01 May, 2024 | 05:28
Updated-04 May, 2025 | 09:01
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
clk: Get runtime PM before walking tree for clk_summary

In the Linux kernel, the following vulnerability has been resolved: clk: Get runtime PM before walking tree for clk_summary Similar to the previous commit, we should make sure that all devices are runtime resumed before printing the clk_summary through debugfs. Failure to do so would result in a deadlock if the thread is resuming a device to print clk state and that device is also runtime resuming in another thread, e.g the screen is turning on and the display driver is starting up. We remove the calls to clk_pm_runtime_{get,put}() in this path because they're superfluous now that we know the devices are runtime resumed. This also squashes a bug where the return value of clk_pm_runtime_get() wasn't checked, leading to an RPM count underflow on error paths.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-50207
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 6.89%
||
7 Day CHG~0.00%
Published-08 Nov, 2024 | 06:07
Updated-04 May, 2025 | 09:48
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
ring-buffer: Fix reader locking when changing the sub buffer order

In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix reader locking when changing the sub buffer order The function ring_buffer_subbuf_order_set() updates each ring_buffer_per_cpu and installs new sub buffers that match the requested page order. This operation may be invoked concurrently with readers that rely on some of the modified data, such as the head bit (RB_PAGE_HEAD), or the ring_buffer_per_cpu.pages and reader_page pointers. However, no exclusive access is acquired by ring_buffer_subbuf_order_set(). Modifying the mentioned data while a reader also operates on them can then result in incorrect memory access and various crashes. Fix the problem by taking the reader_lock when updating a specific ring_buffer_per_cpu in ring_buffer_subbuf_order_set().

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-56743
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.02% / 4.57%
||
7 Day CHG~0.00%
Published-29 Dec, 2024 | 11:30
Updated-04 May, 2025 | 10:03
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
nfs_common: must not hold RCU while calling nfsd_file_put_local

In 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] <TASK> [ 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

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-50210
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 8.32%
||
7 Day CHG~0.00%
Published-08 Nov, 2024 | 06:08
Updated-04 May, 2025 | 09:48
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()

In the Linux kernel, the following vulnerability has been resolved: posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime() If get_clock_desc() succeeds, it calls fget() for the clockid's fd, and get the clk->rwsem read lock, so the error path should release the lock to make the lock balance and fput the clockid's fd to make the refcount balance and release the fd related resource. However the below commit left the error path locked behind resulting in unbalanced locking. Check timespec64_valid_strict() before get_clock_desc() to fix it, because the "ts" is not changed after that. [pabeni@redhat.com: fixed commit message typo]

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-27014
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 1.17%
||
7 Day CHG~0.00%
Published-01 May, 2024 | 05:29
Updated-04 May, 2025 | 09:02
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
net/mlx5e: Prevent deadlock while disabling aRFS

In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Prevent deadlock while disabling aRFS When disabling aRFS under the `priv->state_lock`, any scheduled aRFS works are canceled using the `cancel_work_sync` function, which waits for the work to end if it has already started. However, while waiting for the work handler, the handler will try to acquire the `state_lock` which is already acquired. The worker acquires the lock to delete the rules if the state is down, which is not the worker's responsibility since disabling aRFS deletes the rules. Add an aRFS state variable, which indicates whether the aRFS is enabled and prevent adding rules when the aRFS is disabled. Kernel log: ====================================================== WARNING: possible circular locking dependency detected 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G I ------------------------------------------------------ ethtool/386089 is trying to acquire lock: ffff88810f21ce68 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0 but task is already holding lock: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&priv->state_lock){+.+.}-{3:3}: __mutex_lock+0x80/0xc90 arfs_handle_work+0x4b/0x3b0 [mlx5_core] process_one_work+0x1dc/0x4a0 worker_thread+0x1bf/0x3c0 kthread+0xd7/0x100 ret_from_fork+0x2d/0x50 ret_from_fork_asm+0x11/0x20 -> #0 ((work_completion)(&rule->arfs_work)){+.+.}-{0:0}: __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 __flush_work+0x7a/0x4e0 __cancel_work_timer+0x131/0x1c0 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 netlink_rcv_skb+0x54/0x100 genl_rcv+0x24/0x40 netlink_unicast+0x1a1/0x270 netlink_sendmsg+0x214/0x460 __sock_sendmsg+0x38/0x60 __sys_sendto+0x113/0x170 __x64_sys_sendto+0x20/0x30 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x46/0x4e other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); lock(&priv->state_lock); lock((work_completion)(&rule->arfs_work)); *** DEADLOCK *** 3 locks held by ethtool/386089: #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240 #2: ffff8884a1808cc0 (&priv->state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core] stack backtrace: CPU: 15 PID: 386089 Comm: ethtool Tainted: G I 6.7.0-rc4_net_next_mlx5_5483eb2 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x60/0xa0 check_noncircular+0x144/0x160 __lock_acquire+0x17b4/0x2c80 lock_acquire+0xd0/0x2b0 ? __flush_work+0x74/0x4e0 ? save_trace+0x3e/0x360 ? __flush_work+0x74/0x4e0 __flush_work+0x7a/0x4e0 ? __flush_work+0x74/0x4e0 ? __lock_acquire+0xa78/0x2c80 ? lock_acquire+0xd0/0x2b0 ? mark_held_locks+0x49/0x70 __cancel_work_timer+0x131/0x1c0 ? mark_held_locks+0x49/0x70 arfs_del_rules+0x143/0x1e0 [mlx5_core] mlx5e_arfs_disable+0x1b/0x30 [mlx5_core] mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core] ethnl_set_channels+0x28f/0x3b0 ethnl_default_set_doit+0xec/0x240 genl_family_rcv_msg_doit+0xd0/0x120 genl_rcv_msg+0x188/0x2c0 ? ethn ---truncated---

Action-Not Available
Vendor-Linux Kernel Organization, IncFedora Project
Product-fedoralinux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-47736
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.04% / 9.65%
||
7 Day CHG~0.00%
Published-21 Oct, 2024 | 12:14
Updated-04 May, 2025 | 09:38
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
erofs: handle overlapped pclusters out of crafted images properly

In the Linux kernel, the following vulnerability has been resolved: erofs: handle overlapped pclusters out of crafted images properly syzbot reported a task hang issue due to a deadlock case where it is waiting for the folio lock of a cached folio that will be used for cache I/Os. After looking into the crafted fuzzed image, I found it's formed with several overlapped big pclusters as below: Ext: logical offset | length : physical offset | length 0: 0.. 16384 | 16384 : 151552.. 167936 | 16384 1: 16384.. 32768 | 16384 : 155648.. 172032 | 16384 2: 32768.. 49152 | 16384 : 537223168.. 537239552 | 16384 ... Here, extent 0/1 are physically overlapped although it's entirely _impossible_ for normal filesystem images generated by mkfs. First, managed folios containing compressed data will be marked as up-to-date and then unlocked immediately (unlike in-place folios) when compressed I/Os are complete. If physical blocks are not submitted in the incremental order, there should be separate BIOs to avoid dependency issues. However, the current code mis-arranges z_erofs_fill_bio_vec() and BIO submission which causes unexpected BIO waits. Second, managed folios will be connected to their own pclusters for efficient inter-queries. However, this is somewhat hard to implement easily if overlapped big pclusters exist. Again, these only appear in fuzzed images so let's simply fall back to temporary short-lived pages for correctness. Additionally, it justifies that referenced managed folios cannot be truncated for now and reverts part of commit 2080ca1ed3e4 ("erofs: tidy up `struct z_erofs_bvec`") for simplicity although it shouldn't be any difference.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-47744
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.04% / 9.96%
||
7 Day CHG~0.00%
Published-21 Oct, 2024 | 12:14
Updated-04 May, 2025 | 09:38
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock

In the Linux kernel, the following vulnerability has been resolved: KVM: Use dedicated mutex to protect kvm_usage_count to avoid deadlock Use a dedicated mutex to guard kvm_usage_count to fix a potential deadlock on x86 due to a chain of locks and SRCU synchronizations. Translating the below lockdep splat, CPU1 #6 will wait on CPU0 #1, CPU0 #8 will wait on CPU2 #3, and CPU2 #7 will wait on CPU1 #4 (if there's a writer, due to the fairness of r/w semaphores). CPU0 CPU1 CPU2 1 lock(&kvm->slots_lock); 2 lock(&vcpu->mutex); 3 lock(&kvm->srcu); 4 lock(cpu_hotplug_lock); 5 lock(kvm_lock); 6 lock(&kvm->slots_lock); 7 lock(cpu_hotplug_lock); 8 sync(&kvm->srcu); Note, there are likely more potential deadlocks in KVM x86, e.g. the same pattern of taking cpu_hotplug_lock outside of kvm_lock likely exists with __kvmclock_cpufreq_notifier(): cpuhp_cpufreq_online() | -> cpufreq_online() | -> cpufreq_gov_performance_limits() | -> __cpufreq_driver_target() | -> __target_index() | -> cpufreq_freq_transition_begin() | -> cpufreq_notify_transition() | -> ... __kvmclock_cpufreq_notifier() But, actually triggering such deadlocks is beyond rare due to the combination of dependencies and timings involved. E.g. the cpufreq notifier is only used on older CPUs without a constant TSC, mucking with the NX hugepage mitigation while VMs are running is very uncommon, and doing so while also onlining/offlining a CPU (necessary to generate contention on cpu_hotplug_lock) would be even more unusual. The most robust solution to the general cpu_hotplug_lock issue is likely to switch vm_list to be an RCU-protected list, e.g. so that x86's cpufreq notifier doesn't to take kvm_lock. For now, settle for fixing the most blatant deadlock, as switching to an RCU-protected list is a much more involved change, but add a comment in locking.rst to call out that care needs to be taken when walking holding kvm_lock and walking vm_list. ====================================================== WARNING: possible circular locking dependency detected 6.10.0-smp--c257535a0c9d-pip #330 Tainted: G S O ------------------------------------------------------ tee/35048 is trying to acquire lock: ff6a80eced71e0a8 (&kvm->slots_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x179/0x1e0 [kvm] but task is already holding lock: ffffffffc07abb08 (kvm_lock){+.+.}-{3:3}, at: set_nx_huge_pages+0x14a/0x1e0 [kvm] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kvm_lock){+.+.}-{3:3}: __mutex_lock+0x6a/0xb40 mutex_lock_nested+0x1f/0x30 kvm_dev_ioctl+0x4fb/0xe50 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #2 (cpu_hotplug_lock){++++}-{0:0}: cpus_read_lock+0x2e/0xb0 static_key_slow_inc+0x16/0x30 kvm_lapic_set_base+0x6a/0x1c0 [kvm] kvm_set_apic_base+0x8f/0xe0 [kvm] kvm_set_msr_common+0x9ae/0xf80 [kvm] vmx_set_msr+0xa54/0xbe0 [kvm_intel] __kvm_set_msr+0xb6/0x1a0 [kvm] kvm_arch_vcpu_ioctl+0xeca/0x10c0 [kvm] kvm_vcpu_ioctl+0x485/0x5b0 [kvm] __se_sys_ioctl+0x7b/0xd0 __x64_sys_ioctl+0x21/0x30 x64_sys_call+0x15d0/0x2e60 do_syscall_64+0x83/0x160 entry_SYSCALL_64_after_hwframe+0x76/0x7e -> #1 (&kvm->srcu){.+.+}-{0:0}: __synchronize_srcu+0x44/0x1a0 ---truncated---

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-47746
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 6.88%
||
7 Day CHG~0.00%
Published-21 Oct, 2024 | 12:14
Updated-04 May, 2025 | 09:38
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set

In the Linux kernel, the following vulnerability has been resolved: fuse: use exclusive lock when FUSE_I_CACHE_IO_MODE is set This may be a typo. The comment has said shared locks are not allowed when this bit is set. If using shared lock, the wait in `fuse_file_cached_io_open` may be forever.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-47143
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 6.41%
||
7 Day CHG~0.00%
Published-11 Jan, 2025 | 12:25
Updated-04 May, 2025 | 09:36
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
dma-debug: fix a possible deadlock on radix_lock

In the Linux kernel, the following vulnerability has been resolved: dma-debug: fix a possible deadlock on radix_lock radix_lock() shouldn't be held while holding dma_hash_entry[idx].lock otherwise, there's a possible deadlock scenario when dma debug API is called holding rq_lock(): CPU0 CPU1 CPU2 dma_free_attrs() check_unmap() add_dma_entry() __schedule() //out (A) rq_lock() get_hash_bucket() (A) dma_entry_hash check_sync() (A) radix_lock() (W) dma_entry_hash dma_entry_free() (W) radix_lock() // CPU2's one (W) rq_lock() CPU1 situation can happen when it extending radix tree and it tries to wake up kswapd via wake_all_kswapd(). CPU2 situation can happen while perf_event_task_sched_out() (i.e. dma sync operation is called while deleting perf_event using etm and etr tmc which are Arm Coresight hwtracing driver backends). To remove this possible situation, call dma_entry_free() after put_hash_bucket() in check_unmap().

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-46797
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 6.88%
||
7 Day CHG~0.00%
Published-18 Sep, 2024 | 07:12
Updated-04 May, 2025 | 09:34
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
powerpc/qspinlock: Fix deadlock in MCS queue

In the Linux kernel, the following vulnerability has been resolved: powerpc/qspinlock: Fix deadlock in MCS queue If an interrupt occurs in queued_spin_lock_slowpath() after we increment qnodesp->count and before node->lock is initialized, another CPU might see stale lock values in get_tail_qnode(). If the stale lock value happens to match the lock on that CPU, then we write to the "next" pointer of the wrong qnode. This causes a deadlock as the former CPU, once it becomes the head of the MCS queue, will spin indefinitely until it's "next" pointer is set by its successor in the queue. Running stress-ng on a 16 core (16EC/16VP) shared LPAR, results in occasional lockups similar to the following: $ stress-ng --all 128 --vm-bytes 80% --aggressive \ --maximize --oomable --verify --syslog \ --metrics --times --timeout 5m watchdog: CPU 15 Hard LOCKUP ...... NIP [c0000000000b78f4] queued_spin_lock_slowpath+0x1184/0x1490 LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90 Call Trace: 0xc000002cfffa3bf0 (unreliable) _raw_spin_lock+0x6c/0x90 raw_spin_rq_lock_nested.part.135+0x4c/0xd0 sched_ttwu_pending+0x60/0x1f0 __flush_smp_call_function_queue+0x1dc/0x670 smp_ipi_demux_relaxed+0xa4/0x100 xive_muxed_ipi_action+0x20/0x40 __handle_irq_event_percpu+0x80/0x240 handle_irq_event_percpu+0x2c/0x80 handle_percpu_irq+0x84/0xd0 generic_handle_irq+0x54/0x80 __do_irq+0xac/0x210 __do_IRQ+0x74/0xd0 0x0 do_IRQ+0x8c/0x170 hardware_interrupt_common_virt+0x29c/0x2a0 --- interrupt: 500 at queued_spin_lock_slowpath+0x4b8/0x1490 ...... NIP [c0000000000b6c28] queued_spin_lock_slowpath+0x4b8/0x1490 LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90 --- interrupt: 500 0xc0000029c1a41d00 (unreliable) _raw_spin_lock+0x6c/0x90 futex_wake+0x100/0x260 do_futex+0x21c/0x2a0 sys_futex+0x98/0x270 system_call_exception+0x14c/0x2f0 system_call_vectored_common+0x15c/0x2ec The following code flow illustrates how the deadlock occurs. For the sake of brevity, assume that both locks (A and B) are contended and we call the queued_spin_lock_slowpath() function. CPU0 CPU1 ---- ---- spin_lock_irqsave(A) | spin_unlock_irqrestore(A) | spin_lock(B) | | | ▼ | id = qnodesp->count++; | (Note that nodes[0].lock == A) | | | ▼ | Interrupt | (happens before "nodes[0].lock = B") | | | ▼ | spin_lock_irqsave(A) | | | ▼ | id = qnodesp->count++ | nodes[1].lock = A | | | ▼ | Tail of MCS queue | | spin_lock_irqsave(A) ▼ | Head of MCS queue ▼ | CPU0 is previous tail ▼ | Spin indefinitely ▼ (until "nodes[1].next != NULL") prev = get_tail_qnode(A, CPU0) | ▼ prev == &qnodes[CPU0].nodes[0] (as qnodes ---truncated---

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-46692
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 6.88%
||
7 Day CHG~0.00%
Published-13 Sep, 2024 | 05:29
Updated-04 May, 2025 | 09:32
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
firmware: qcom: scm: Mark get_wq_ctx() as atomic call

In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: scm: Mark get_wq_ctx() as atomic call Currently get_wq_ctx() is wrongly configured as a standard call. When two SMC calls are in sleep and one SMC wakes up, it calls get_wq_ctx() to resume the corresponding sleeping thread. But if get_wq_ctx() is interrupted, goes to sleep and another SMC call is waiting to be allocated a waitq context, it leads to a deadlock. To avoid this get_wq_ctx() must be an atomic call and can't be a standard SMC call. Hence mark get_wq_ctx() as a fast call.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-46829
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.04% / 10.83%
||
7 Day CHG~0.00%
Published-27 Sep, 2024 | 12:39
Updated-04 May, 2025 | 12:58
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
rtmutex: Drop rt_mutex::wait_lock before scheduling

In the Linux kernel, the following vulnerability has been resolved: rtmutex: Drop rt_mutex::wait_lock before scheduling rt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held. In the good case it returns with the lock held and in the deadlock case it emits a warning and goes into an endless scheduling loop with the lock held, which triggers the 'scheduling in atomic' warning. Unlock rt_mutex::wait_lock in the dead lock case before issuing the warning and dropping into the schedule for ever loop. [ tglx: Moved unlock before the WARN(), removed the pointless comment, massaged changelog, added Fixes tag ]

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-46868
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.04% / 8.90%
||
7 Day CHG~0.00%
Published-27 Sep, 2024 | 12:42
Updated-04 May, 2025 | 09:36
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
firmware: qcom: uefisecapp: Fix deadlock in qcuefi_acquire()

In the Linux kernel, the following vulnerability has been resolved: firmware: qcom: uefisecapp: Fix deadlock in qcuefi_acquire() If the __qcuefi pointer is not set, then in the original code, we would hold onto the lock. That means that if we tried to set it later, then it would cause a deadlock. Drop the lock on the error path. That's what all the callers are expecting.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-46867
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.04% / 8.90%
||
7 Day CHG~0.00%
Published-27 Sep, 2024 | 12:42
Updated-04 May, 2025 | 09:36
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
drm/xe/client: fix deadlock in show_meminfo()

In the Linux kernel, the following vulnerability has been resolved: drm/xe/client: fix deadlock in show_meminfo() There is a real deadlock as well as sleeping in atomic() bug in here, if the bo put happens to be the last ref, since bo destruction wants to grab the same spinlock and sleeping locks. Fix that by dropping the ref using xe_bo_put_deferred(), and moving the final commit outside of the lock. Dropping the lock around the put is tricky since the bo can go out of scope and delete itself from the list, making it difficult to navigate to the next list entry. (cherry picked from commit 0083b8e6f11d7662283a267d4ce7c966812ffd8a)

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-44957
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 6.88%
||
7 Day CHG~0.00%
Published-04 Sep, 2024 | 18:35
Updated-04 May, 2025 | 09:29
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
xen: privcmd: Switch from mutex to spinlock for irqfds

In the Linux kernel, the following vulnerability has been resolved: xen: privcmd: Switch from mutex to spinlock for irqfds irqfd_wakeup() gets EPOLLHUP, when it is called by eventfd_release() by way of wake_up_poll(&ctx->wqh, EPOLLHUP), which gets called under spin_lock_irqsave(). We can't use a mutex here as it will lead to a deadlock. Fix it by switching over to a spin lock.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-45029
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.05% / 13.69%
||
7 Day CHG~0.00%
Published-11 Sep, 2024 | 15:14
Updated-04 May, 2025 | 09:31
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
i2c: tegra: Do not mark ACPI devices as irq safe

In the Linux kernel, the following vulnerability has been resolved: i2c: tegra: Do not mark ACPI devices as irq safe On ACPI machines, the tegra i2c module encounters an issue due to a mutex being called inside a spinlock. This leads to the following bug: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:585 ... Call trace: __might_sleep __mutex_lock_common mutex_lock_nested acpi_subsys_runtime_resume rpm_resume tegra_i2c_xfer The problem arises because during __pm_runtime_resume(), the spinlock &dev->power.lock is acquired before rpm_resume() is called. Later, rpm_resume() invokes acpi_subsys_runtime_resume(), which relies on mutexes, triggering the error. To address this issue, devices on ACPI are now marked as not IRQ-safe, considering the dependency of acpi_subsys_runtime_resume() on mutexes.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-44995
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.05% / 16.81%
||
7 Day CHG~0.00%
Published-04 Sep, 2024 | 19:54
Updated-04 May, 2025 | 09:30
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
net: hns3: fix a deadlock problem when config TC during resetting

In the Linux kernel, the following vulnerability has been resolved: net: hns3: fix a deadlock problem when config TC during resetting When config TC during the reset process, may cause a deadlock, the flow is as below: pf reset start │ ▼ ...... setup tc │ │ ▼ ▼ DOWN: napi_disable() napi_disable()(skip) │ │ │ ▼ ▼ ...... ...... │ │ ▼ │ napi_enable() │ ▼ UINIT: netif_napi_del() │ ▼ ...... │ ▼ INIT: netif_napi_add() │ ▼ ...... global reset start │ │ ▼ ▼ UP: napi_enable()(skip) ...... │ │ ▼ ▼ ...... napi_disable() In reset process, the driver will DOWN the port and then UINIT, in this case, the setup tc process will UP the port before UINIT, so cause the problem. Adds a DOWN process in UINIT to fix it.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2022-49742
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.01% / 1.84%
||
7 Day CHG-0.00%
Published-27 Mar, 2025 | 16:42
Updated-11 Jul, 2025 | 17:19
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
f2fs: initialize locks earlier in f2fs_fill_super()

In the Linux kernel, the following vulnerability has been resolved: f2fs: initialize locks earlier in f2fs_fill_super() syzbot is reporting lockdep warning at f2fs_handle_error() [1], for spin_lock(&sbi->error_lock) is called before spin_lock_init() is called. For safe locking in error handling, move initialization of locks (and obvious structures) in f2fs_fill_super() to immediately after memory allocation.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-44956
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.04% / 8.89%
||
7 Day CHG~0.00%
Published-04 Sep, 2024 | 18:35
Updated-04 May, 2025 | 09:29
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
drm/xe/preempt_fence: enlarge the fence critical section

In the Linux kernel, the following vulnerability has been resolved: drm/xe/preempt_fence: enlarge the fence critical section It is really easy to introduce subtle deadlocks in preempt_fence_work_func() since we operate on single global ordered-wq for signalling our preempt fences behind the scenes, so even though we signal a particular fence, everything in the callback should be in the fence critical section, since blocking in the callback will prevent other published fences from signalling. If we enlarge the fence critical section to cover the entire callback, then lockdep should be able to understand this better, and complain if we grab a sensitive lock like vm->lock, which is also held when waiting on preempt fences.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-44953
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.04% / 12.78%
||
7 Day CHG~0.00%
Published-04 Sep, 2024 | 18:35
Updated-04 May, 2025 | 09:29
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
scsi: ufs: core: Fix deadlock during RTC update

In the Linux kernel, the following vulnerability has been resolved: scsi: ufs: core: Fix deadlock during RTC update There is a deadlock when runtime suspend waits for the flush of RTC work, and the RTC work calls ufshcd_rpm_get_sync() to wait for runtime resume. Here is deadlock backtrace: kworker/0:1 D 4892.876354 10 10971 4859 0x4208060 0x8 10 0 120 670730152367 ptr f0ffff80c2e40000 0 1 0x00000001 0x000000ff 0x000000ff 0x000000ff <ffffffee5e71ddb0> __switch_to+0x1a8/0x2d4 <ffffffee5e71e604> __schedule+0x684/0xa98 <ffffffee5e71ea60> schedule+0x48/0xc8 <ffffffee5e725f78> schedule_timeout+0x48/0x170 <ffffffee5e71fb74> do_wait_for_common+0x108/0x1b0 <ffffffee5e71efe0> wait_for_completion+0x44/0x60 <ffffffee5d6de968> __flush_work+0x39c/0x424 <ffffffee5d6decc0> __cancel_work_sync+0xd8/0x208 <ffffffee5d6dee2c> cancel_delayed_work_sync+0x14/0x28 <ffffffee5e2551b8> __ufshcd_wl_suspend+0x19c/0x480 <ffffffee5e255fb8> ufshcd_wl_runtime_suspend+0x3c/0x1d4 <ffffffee5dffd80c> scsi_runtime_suspend+0x78/0xc8 <ffffffee5df93580> __rpm_callback+0x94/0x3e0 <ffffffee5df90b0c> rpm_suspend+0x2d4/0x65c <ffffffee5df91448> __pm_runtime_suspend+0x80/0x114 <ffffffee5dffd95c> scsi_runtime_idle+0x38/0x6c <ffffffee5df912f4> rpm_idle+0x264/0x338 <ffffffee5df90f14> __pm_runtime_idle+0x80/0x110 <ffffffee5e24ce44> ufshcd_rtc_work+0x128/0x1e4 <ffffffee5d6e3a40> process_one_work+0x26c/0x650 <ffffffee5d6e65c8> worker_thread+0x260/0x3d8 <ffffffee5d6edec8> kthread+0x110/0x134 <ffffffee5d616b18> ret_from_fork+0x10/0x20 Skip updating RTC if RPM state is not RPM_ACTIVE.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-43872
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.04% / 8.89%
||
7 Day CHG~0.00%
Published-21 Aug, 2024 | 00:06
Updated-04 May, 2025 | 09:28
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
RDMA/hns: Fix soft lockup under heavy CEQE load

In the Linux kernel, the following vulnerability has been resolved: RDMA/hns: Fix soft lockup under heavy CEQE load CEQEs are handled in interrupt handler currently. This may cause the CPU core staying in interrupt context too long and lead to soft lockup under heavy load. Handle CEQEs in BH workqueue and set an upper limit for the number of CEQE handled by a single call of work handler.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2022-48719
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.03% / 5.03%
||
7 Day CHG~0.00%
Published-20 Jun, 2024 | 11:13
Updated-04 May, 2025 | 08:21
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
net, neigh: Do not trigger immediate probes on NUD_FAILED from neigh_managed_work

In the Linux kernel, the following vulnerability has been resolved: net, neigh: Do not trigger immediate probes on NUD_FAILED from neigh_managed_work syzkaller was able to trigger a deadlock for NTF_MANAGED entries [0]: kworker/0:16/14617 is trying to acquire lock: ffffffff8d4dd370 (&tbl->lock){++-.}-{2:2}, at: ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652 [...] but task is already holding lock: ffffffff8d4dd370 (&tbl->lock){++-.}-{2:2}, at: neigh_managed_work+0x35/0x250 net/core/neighbour.c:1572 The neighbor entry turned to NUD_FAILED state, where __neigh_event_send() triggered an immediate probe as per commit cd28ca0a3dd1 ("neigh: reduce arp latency") via neigh_probe() given table lock was held. One option to fix this situation is to defer the neigh_probe() back to the neigh_timer_handler() similarly as pre cd28ca0a3dd1. For the case of NTF_MANAGED, this deferral is acceptable given this only happens on actual failure state and regular / expected state is NUD_VALID with the entry already present. The fix adds a parameter to __neigh_event_send() in order to communicate whether immediate probe is allowed or disallowed. Existing call-sites of neigh_event_send() default as-is to immediate probe. However, the neigh_managed_work() disables it via use of neigh_event_send_probe(). [0] <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_deadlock_bug kernel/locking/lockdep.c:2956 [inline] check_deadlock kernel/locking/lockdep.c:2999 [inline] validate_chain kernel/locking/lockdep.c:3788 [inline] __lock_acquire.cold+0x149/0x3ab kernel/locking/lockdep.c:5027 lock_acquire kernel/locking/lockdep.c:5639 [inline] lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5604 __raw_write_lock_bh include/linux/rwlock_api_smp.h:202 [inline] _raw_write_lock_bh+0x2f/0x40 kernel/locking/spinlock.c:334 ___neigh_create+0x9e1/0x2990 net/core/neighbour.c:652 ip6_finish_output2+0x1070/0x14f0 net/ipv6/ip6_output.c:123 __ip6_finish_output net/ipv6/ip6_output.c:191 [inline] __ip6_finish_output+0x61e/0xe90 net/ipv6/ip6_output.c:170 ip6_finish_output+0x32/0x200 net/ipv6/ip6_output.c:201 NF_HOOK_COND include/linux/netfilter.h:296 [inline] ip6_output+0x1e4/0x530 net/ipv6/ip6_output.c:224 dst_output include/net/dst.h:451 [inline] NF_HOOK include/linux/netfilter.h:307 [inline] ndisc_send_skb+0xa99/0x17f0 net/ipv6/ndisc.c:508 ndisc_send_ns+0x3a9/0x840 net/ipv6/ndisc.c:650 ndisc_solicit+0x2cd/0x4f0 net/ipv6/ndisc.c:742 neigh_probe+0xc2/0x110 net/core/neighbour.c:1040 __neigh_event_send+0x37d/0x1570 net/core/neighbour.c:1201 neigh_event_send include/net/neighbour.h:470 [inline] neigh_managed_work+0x162/0x250 net/core/neighbour.c:1574 process_one_work+0x9ac/0x1650 kernel/workqueue.c:2307 worker_thread+0x657/0x1110 kernel/workqueue.c:2454 kthread+0x2e9/0x3a0 kernel/kthread.c:377 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295 </TASK>

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-43863
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.04% / 9.86%
||
7 Day CHG~0.00%
Published-20 Aug, 2024 | 23:45
Updated-04 Jun, 2025 | 13:15
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
drm/vmwgfx: Fix a deadlock in dma buf fence polling

In the Linux kernel, the following vulnerability has been resolved: drm/vmwgfx: Fix a deadlock in dma buf fence polling Introduce a version of the fence ops that on release doesn't remove the fence from the pending list, and thus doesn't require a lock to fix poll->fence wait->fence unref deadlocks. vmwgfx overwrites the wait callback to iterate over the list of all fences and update their status, to do that it holds a lock to prevent the list modifcations from other threads. The fence destroy callback both deletes the fence and removes it from the list of pending fences, for which it holds a lock. dma buf polling cb unrefs a fence after it's been signaled: so the poll calls the wait, which signals the fences, which are being destroyed. The destruction tries to acquire the lock on the pending fences list which it can never get because it's held by the wait from which it was called. Old bug, but not a lot of userspace apps were using dma-buf polling interfaces. Fix those, in particular this fixes KDE stalls/deadlock.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-43862
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.04% / 8.89%
||
7 Day CHG~0.00%
Published-20 Aug, 2024 | 23:45
Updated-04 May, 2025 | 09:27
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
net: wan: fsl_qmc_hdlc: Convert carrier_lock spinlock to a mutex

In the Linux kernel, the following vulnerability has been resolved: net: wan: fsl_qmc_hdlc: Convert carrier_lock spinlock to a mutex The carrier_lock spinlock protects the carrier detection. While it is held, framer_get_status() is called which in turn takes a mutex. This is not correct and can lead to a deadlock. A run with PROVE_LOCKING enabled detected the issue: [ BUG: Invalid wait context ] ... c204ddbc (&framer->mutex){+.+.}-{3:3}, at: framer_get_status+0x40/0x78 other info that might help us debug this: context-{4:4} 2 locks held by ifconfig/146: #0: c0926a38 (rtnl_mutex){+.+.}-{3:3}, at: devinet_ioctl+0x12c/0x664 #1: c2006a40 (&qmc_hdlc->carrier_lock){....}-{2:2}, at: qmc_hdlc_framer_set_carrier+0x30/0x98 Avoid the spinlock usage and convert carrier_lock to a mutex.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-42090
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.04% / 9.86%
||
7 Day CHG~0.00%
Published-29 Jul, 2024 | 16:26
Updated-04 May, 2025 | 09:22
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER

In 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.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-42268
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.04% / 9.95%
||
7 Day CHG~0.00%
Published-17 Aug, 2024 | 08:54
Updated-04 May, 2025 | 09:25
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
net/mlx5: Fix missing lock on sync reset reload

In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix missing lock on sync reset reload On sync reset reload work, when remote host updates devlink on reload actions performed on that host, it misses taking devlink lock before calling devlink_remote_reload_actions_performed() which results in triggering lock assert like the following: WARNING: CPU: 4 PID: 1164 at net/devlink/core.c:261 devl_assert_locked+0x3e/0x50 … CPU: 4 PID: 1164 Comm: kworker/u96:6 Tainted: G S W 6.10.0-rc2+ #116 Hardware name: Supermicro SYS-2028TP-DECTR/X10DRT-PT, BIOS 2.0 12/18/2015 Workqueue: mlx5_fw_reset_events mlx5_sync_reset_reload_work [mlx5_core] RIP: 0010:devl_assert_locked+0x3e/0x50 … Call Trace: <TASK> ? __warn+0xa4/0x210 ? devl_assert_locked+0x3e/0x50 ? report_bug+0x160/0x280 ? handle_bug+0x3f/0x80 ? exc_invalid_op+0x17/0x40 ? asm_exc_invalid_op+0x1a/0x20 ? devl_assert_locked+0x3e/0x50 devlink_notify+0x88/0x2b0 ? mlx5_attach_device+0x20c/0x230 [mlx5_core] ? __pfx_devlink_notify+0x10/0x10 ? process_one_work+0x4b6/0xbb0 process_one_work+0x4b6/0xbb0 […]

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
CVE-2024-42085
Matching Score-10
Assigner-kernel.org
ShareView Details
Matching Score-10
Assigner-kernel.org
CVSS Score-5.5||MEDIUM
EPSS-0.04% / 9.78%
||
7 Day CHG~0.00%
Published-29 Jul, 2024 | 16:26
Updated-28 Aug, 2025 | 15:15
Rejected-Not Available
Known To Be Used In Ransomware Campaigns?-Not Available
KEV Added-Not Available
KEV Action Due Date-Not Available
usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock

In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: remove lock of otg mode during gadget suspend/resume to avoid deadlock When config CONFIG_USB_DWC3_DUAL_ROLE is selected, and trigger system to enter suspend status with below command: echo mem > /sys/power/state There will be a deadlock issue occurring. Detailed invoking path as below: dwc3_suspend_common() spin_lock_irqsave(&dwc->lock, flags); <-- 1st dwc3_gadget_suspend(dwc); dwc3_gadget_soft_disconnect(dwc); spin_lock_irqsave(&dwc->lock, flags); <-- 2nd This issue is exposed by commit c7ebd8149ee5 ("usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend") that removes the code of checking whether dwc->gadget_driver is NULL or not. It causes the following code is executed and deadlock occurs when trying to get the spinlock. In fact, the root cause is the commit 5265397f9442("usb: dwc3: Remove DWC3 locking during gadget suspend/resume") that forgot to remove the lock of otg mode. So, remove the redundant lock of otg mode during gadget suspend/resume.

Action-Not Available
Vendor-Linux Kernel Organization, Inc
Product-linux_kernelLinux
CWE ID-CWE-667
Improper Locking
  • Previous
  • 1
  • 2
  • 3
  • 4
  • ...
  • 60
  • 61
  • Next
Details not found