deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-38290
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix node corruption in ar->arvifs list

In current WLAN recovery code flow, ath12k_core_halt() only reinitializes
the "arvifs" list head. This will cause the list node immediately following
the list head to become an invalid list node. Because the prev of that node
still points to the list head "arvifs", but the next of the list head
"arvifs" no longer points to that list node.

When a WLAN recovery occurs during the execution of a vif removal, and it
happens before the spin_lock_bh(&ar->data_lock) in
ath12k_mac_vdev_delete(), list_del() will detect the previously mentioned
situation, thereby triggering a kernel panic.

The fix is to remove and reinitialize all vif list nodes from the list head
"arvifs" during WLAN halt. The reinitialization is to make the list nodes
valid, ensuring that the list_del() in ath12k_mac_vdev_delete() can execute
normally.

Call trace:
__list_del_entry_valid_or_report+0xd4/0x100 (P)
ath12k_mac_remove_link_interface.isra.0+0xf8/0x2e4 [ath12k]
ath12k_scan_vdev_clean_work+0x40/0x164 [ath12k]
cfg80211_wiphy_work+0xfc/0x100
process_one_work+0x164/0x2d0
worker_thread+0x254/0x380
kthread+0xfc/0x100
ret_from_fork+0x10/0x20

The change is mostly copied from the ath11k patch:
https://lore.kernel.org/all/[PII_REDACTED]3[PII_REDACTED]-1-quic_stonez@quicinc.com/

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-362, CWE-672
References: https://git.kernel.org/stable/c/[PII_REDACTED]f9e2f04b9dbf1e5100e0d7cbac22b4; https://git.kernel.org/stable/c/6bfe7ae9bbd9734751b853e2d2e1c13e8b46fd2d; https://git.kernel.org/stable/c/823435bd23108d6f8be89ea2d025c0e2e3769c51
CVE: CVE-2025-38291
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: Prevent sending WMI commands to firmware during firmware crash

Currently, we encounter the following kernel call trace when a firmware
crash occurs. This happens because the host sends WMI commands to the
firmware while it is in recovery, causing the commands to fail and
resulting in the kernel call trace.

Set the ATH12K_FLAG_CRASH_FLUSH and ATH12K_FLAG_RECOVERY flags when the
host driver receives the firmware crash notification from MHI. This
prevents sending WMI commands to the firmware during recovery.

Call Trace:
 <TASK>
 dump_stack_lvl+0x75/0xc0
 register_lock_class+0x6be/0x7a0
 ? __lock_acquire+0x644/0x19a0
 __lock_acquire+0x95/0x19a0
 lock_acquire+0x265/0x310
 ? ath12k_ce_send+0xa2/0x210 [ath12k]
 ? find_held_lock+0x34/0xa0
 ? ath12k_ce_send+0x56/0x210 [ath12k]
 _raw_spin_lock_bh+0x33/0x70
 ? ath12k_ce_send+0xa2/0x210 [ath12k]
 ath12k_ce_send+0xa2/0x210 [ath12k]
 ath12k_htc_send+0x178/0x390 [ath12k]
 ath12k_wmi_cmd_send_nowait+0x76/0xa0 [ath12k]
 ath12k_wmi_cmd_send+0x62/0x190 [ath12k]
 ath12k_wmi_pdev_bss_chan_info_request+0x62/0xc0 [ath1
 ath12k_mac_op_get_survey+0x2be/0x310 [ath12k]
 ieee80211_dump_survey+0x99/0x240 [mac80211]
 nl80211_dump_survey+0xe7/0x470 [cfg80211]
 ? kmalloc_reserve+0x59/0xf0
 genl_dumpit+0x24/0x70
 netlink_dump+0x177/0x360
 __netlink_dump_start+0x206/0x280
 genl_family_rcv_msg_dumpit.isra.22+0x8a/0xe0
 ? genl_family_rcv_msg_attrs_parse.isra.23+0xe0/0xe0
 ? genl_op_lock.part.12+0x10/0x10
 ? genl_dumpit+0x70/0x70
 genl_rcv_msg+0x1d0/0x290
 ? nl80211_del_station+0x330/0x330 [cfg80211]
 ? genl_get_cmd_both+0x50/0x50
 netlink_rcv_skb+0x4f/0x100
 genl_rcv+0x1f/0x30
 netlink_unicast+0x1b6/0x260
 netlink_sendmsg+0x31a/0x450
 __sock_sendmsg+0xa8/0xb0
 ____sys_sendmsg+0x1e4/0x260
 ___sys_sendmsg+0x89/0xe0
 ? local_clock_noinstr+0xb/0xc0
 ? rcu_is_watching+0xd/0x40
 ? kfree+0x1de/0x370
 ? __sys_sendmsg+0x7a/0xc0

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-670
References: https://git.kernel.org/stable/c/2563069baf243cadc76dc64d[PII_REDACTED]c4b282; https://git.kernel.org/stable/c/e9e094a9734ea3bd4d4d117c915ccf129ac61ba1
CVE: CVE-2025-38292
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix invalid access to memory

In ath12k_dp_rx_msdu_coalesce(), rxcb is fetched from skb and boolean
is_continuation is part of rxcb.
Currently, after freeing the skb, the rxcb->is_continuation accessed
again which is wrong since the memory is already freed.
This might lead use-after-free error.

Hence, fix by locally defining bool is_continuation from rxcb,
so that after freeing skb, is_continuation can be used.

Compile tested only.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/371b340affa52f280f6eadfd25fbd43f09f0d5c0; https://git.kernel.org/stable/c/5f09d16cd57764c95c8548fe5b70672c9ac01127; https://git.kernel.org/stable/c/9f17747fbda6fca[PII_REDACTED]73c4abf8061491d
CVE: CVE-2025-38293
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: fix node corruption in ar->arvifs list

In current WLAN recovery code flow, ath11k_core_halt() only
reinitializes the "arvifs" list head. This will cause the
list node immediately following the list head to become an
invalid list node. Because the prev of that node still points
to the list head "arvifs", but the next of the list head "arvifs"
no longer points to that list node.

When a WLAN recovery occurs during the execution of a vif
removal, and it happens before the spin_lock_bh(&ar->data_lock)
in ath11k_mac_op_remove_interface(), list_del() will detect the
previously mentioned situation, thereby triggering a kernel panic.

The fix is to remove and reinitialize all vif list nodes from the
list head "arvifs" during WLAN halt. The reinitialization is to make
the list nodes valid, ensuring that the list_del() in
ath11k_mac_op_remove_interface() can execute normally.

Call trace:
__list_del_entry_valid_or_report+0xb8/0xd0
ath11k_mac_op_remove_interface+0xb0/0x27c [ath11k]
drv_remove_interface+0x48/0x194 [mac80211]
ieee80211_do_stop+0x6e0/0x844 [mac80211]
ieee80211_stop+0x44/0x17c [mac80211]
__dev_close_many+0xac/0x150
__dev_change_flags+0x194/0x234
dev_change_flags+0x24/0x6c
devinet_ioctl+0x3a0/0x670
inet_ioctl+0x200/0x248
sock_do_ioctl+0x60/0x118
sock_ioctl+0x274/0x35c
__arm64_sys_ioctl+0xac/0xf0
invoke_syscall+0x48/0x114
...

Tested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/31e98e277ae47f56632e4d663b1d4fd12ba33ea8; https://git.kernel.org/stable/c/6c139015b597e570dd5962934e9f9a2f4cc8ef48; https://git.kernel.org/stable/c/6d6cb27fe146061f2512e904618f5e005bb7bb6a
CVE: CVE-2025-38294
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix NULL access in assign channel context handler

Currently, when ath12k_mac_assign_vif_to_vdev() fails, the radio handle
(ar) gets accessed from the link VIF handle (arvif) for debug logging, This
is incorrect. In the fail scenario, radio handle is NULL. Fix the NULL
access, avoid radio handle access by moving to the hardware debug logging
helper function (ath12k_hw_warn).

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3f919f76893069ec3c7475acaeb611eb31fca22d; https://git.kernel.org/stable/c/ea24531d00f782f4e659e8c74578b7ac144720ca
CVE: CVE-2025-38295
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

perf/amlogic: Replace smp_processor_id() with raw_smp_processor_id() in meson_ddr_pmu_create()

The Amlogic DDR PMU driver meson_ddr_pmu_create() function incorrectly uses
smp_processor_id(), which assumes disabled preemption. This leads to kernel
warnings during module loading because meson_ddr_pmu_create() can be called
in a preemptible context.

Following kernel warning and stack trace:
[   31.745138] [   T2289] BUG: using smp_processor_id() in preemptible [00000000] code: (udev-worker)/2289
[   31.745154] [   T2289] caller is debug_smp_processor_id+0x28/0x38
[   31.745172] [   T2289] CPU: 4 UID: 0 PID: 2289 Comm: (udev-worker) Tainted: GW 6.14.0-0-MANJARO-ARM #1 59519addcbca6ba8de735e151fd7b9e97aac7ff0
[   31.745181] [   T2289] Tainted: [W]=WARN
[   31.745183] [   T2289] Hardware name: Hardkernel ODROID-N2Plus (DT)
[   31.745188] [   T2289] Call trace:
[   31.745191] [   T2289]  show_stack+0x28/0x40 (C)
[   31.745199] [   T2289]  dump_stack_lvl+0x4c/0x198
[   31.745205] [   T2289]  dump_stack+0x20/0x50
[   31.745209] [   T2289]  check_preemption_disabled+0xec/0xf0
[   31.745213] [   T2289]  debug_smp_processor_id+0x28/0x38
[   31.745216] [   T2289]  meson_ddr_pmu_create+0x200/0x560 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd]
[   31.745237] [   T2289]  g12_ddr_pmu_probe+0x20/0x38 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd]
[   31.745246] [   T2289]  platform_probe+0x98/0xe0
[   31.745254] [   T2289]  really_probe+0x144/0x3f8
[   31.745258] [   T2289]  __driver_probe_device+0xb8/0x180
[   31.745261] [   T2289]  driver_probe_device+0x54/0x268
[   31.745264] [   T2289]  __driver_attach+0x11c/0x288
[   31.745267] [   T2289]  bus_for_each_dev+0xfc/0x160
[   31.745274] [   T2289]  driver_attach+0x34/0x50
[   31.745277] [   T2289]  bus_add_driver+0x160/0x2b0
[   31.745281] [   T2289]  driver_register+0x78/0x120
[   31.745285] [   T2289]  __platform_driver_register+0x30/0x48
[   31.745288] [   T2289]  init_module+0x30/0xfe0 [meson_ddr_pmu_g12 8095101c49676ad138d9961e3eddaee10acca7bd]
[   31.745298] [   T2289]  do_one_initcall+0x11c/0x438
[   31.745303] [   T2289]  do_init_module+0x68/0x228
[   31.745311] [   T2289]  load_module+0x118c/0x13a8
[   31.745315] [   T2289]  __arm64_sys_finit_module+0x274/0x390
[   31.745320] [   T2289]  invoke_syscall+0x74/0x108
[   31.745326] [   T2289]  el0_svc_common+0x90/0xf8
[   31.745330] [   T2289]  do_el0_svc+0x2c/0x48
[   31.745333] [   T2289]  el0_svc+0x60/0x150
[   31.745337] [   T2289]  el0t_64_sync_handler+0x80/0x118
[   31.745341] [   T2289]  el0t_64_sync+0x1b8/0x1c0

Changes replaces smp_processor_id() with raw_smp_processor_id() to
ensure safe CPU ID retrieval in preemptible contexts.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/097469a2b0f12b91b4f27b9e9e4f2c46484cde30; https://git.kernel.org/stable/c/6f5f53048d3b761d694430632d3a03977273e987; https://git.kernel.org/stable/c/77511c2d2d1cbce8d9b4f50849843dd469d14173
CVE: CVE-2025-38296
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPI: platform_profile: Avoid initializing on non-ACPI platforms

The platform profile driver is loaded even on platforms that do not have
ACPI enabled. The initialization of the sysfs entries was recently moved
from platform_profile_register() to the module init call, and those
entries need acpi_kobj to be initialized which is not the case when ACPI
is disabled.

This results in the following warning:

 WARNING: CPU: 5 PID: 1 at fs/sysfs/group.c:131 internal_create_group+0xa22/0xdd8
 Modules linked in:
 CPU: 5 UID: 0 PID: 1 Comm: swapper/0 Tainted: G        W           6.15.0-rc7-dirty #6 PREEMPT
 Tainted: [W]=WARN
 Hardware name: riscv-virtio,qemu (DT)
 epc : internal_create_group+0xa22/0xdd8
  ra : internal_create_group+0xa22/0xdd8

 Call Trace:

 internal_create_group+0xa22/0xdd8
 sysfs_create_group+0x22/0x2e
 platform_profile_init+0x74/0xb2
 do_one_initcall+0x198/0xa9e
 kernel_init_freeable+0x6d8/0x780
 kernel_init+0x28/0x24c
 ret_from_fork+0xe/0x18

Fix this by checking if ACPI is enabled before trying to create sysfs
entries.

[ rjw: Subject and changelog edits ]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/ccc3d68b92be89c30ba42ac62d2a141bd0c2b457; https://git.kernel.org/stable/c/dd133162c9cff5951a692fab9811fadf46a46457
CVE: CVE-2025-38297
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

PM: EM: Fix potential division-by-zero error in em_compute_costs()

When the device is of a non-CPU type, table[i].performance won't be
initialized in the previous em_init_performance(), resulting in division
by zero when calculating costs in em_compute_costs().

Since the 'cost' algorithm is only used for EAS energy efficiency
calculations and is currently not utilized by other device drivers, we
should add the _is_cpu_device(dev) check to prevent this division-by-zero
issue.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-369
References: https://git.kernel.org/stable/c/14cbdd64f3870cf0a2d94b87919b9056448c59a0; https://git.kernel.org/stable/c/179c0c7044a378198adb36f2a12410ab68cc730a; https://git.kernel.org/stable/c/81d72f9241d884ec29524431f74f8009310cfa0c
CVE: CVE-2025-38298
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

EDAC/skx_common: Fix general protection fault

After loading i10nm_edac (which automatically loads skx_edac_common), if
unload only i10nm_edac, then reload it and perform error injection testing,
a general protection fault may occur:

  mce: [Hardware Error]: Machine check events logged
  Oops: general protection fault ...
  ...
  Workqueue: events mce_gen_pool_process
  RIP: 0010:string+0x53/0xe0
  ...
  Call Trace:
  <TASK>
  ? die_addr+0x37/0x90
  ? exc_general_protection+0x1e7/0x3f0
  ? asm_exc_general_protection+0x26/0x30
  ? string+0x53/0xe0
  vsnprintf+0x23e/0x4c0
  snprintf+0x4d/0x70
  skx_adxl_decode+0x16a/0x330 [skx_edac_common]
  skx_mce_check_error.part.0+0xf8/0x220 [skx_edac_common]
  skx_mce_check_error+0x17/0x20 [skx_edac_common]
  ...

The issue arose was because the variable 'adxl_component_count' (inside
skx_edac_common), which counts the ADXL components, was not reset. During
the reloading of i10nm_edac, the count was incremented by the actual number
of ADXL components again, resulting in a count that was double the real
number of ADXL components. This led to an out-of-bounds reference to the
ADXL component array, causing the general protection fault above.

Fix this issue by resetting the 'adxl_component_count' in adxl_put(),
which is called during the unloading of {skx,i10nm}_edac.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/20d2d476b3ae18041be423671a8637ed5ffd6958; https://git.kernel.org/stable/c/31ef6f7c9aee3be78d63789653e92350f2537f93; https://git.kernel.org/stable/c/3f5d[PII_REDACTED]735350da60ad710f8c804544fe
CVE: CVE-2025-38300
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare()

Fix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare():

1] If dma_map_sg() fails for areq->dst, the device driver would try to free
   DMA memory it has not allocated in the first place. To fix this, on the
   "theend_sgs" error path, call dma unmap only if the corresponding dma
   map was successful.

2] If the dma_map_single() call for the IV fails, the device driver would
   try to free an invalid DMA memory address on the "theend_iv" path:
   ------------[ cut here ]------------
   DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address
   WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90
   Modules linked in: skcipher_example(O+)
   CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G           O        6.15.0-rc3+ #24 PREEMPT
   Tainted: [O]=OOT_MODULE
   Hardware name: OrangePi Zero2 (DT)
   pc : check_unmap+0x123c/0x1b90
   lr : check_unmap+0x123c/0x1b90
   ...
   Call trace:
    check_unmap+0x123c/0x1b90 (P)
    debug_dma_unmap_page+0xac/0xc0
    dma_unmap_page_attrs+0x1f4/0x5fc
    sun8i_ce_cipher_do_one+0x1bd4/0x1f40
    crypto_pump_work+0x334/0x6e0
    kthread_worker_fn+0x21c/0x438
    kthread+0x374/0x664
    ret_from_fork+0x10/0x20
   ---[ end trace [PII_REDACTED] ]---

To fix this, check for !dma_mapping_error() before calling
dma_unmap_single() on the "theend_iv" path.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/19d267d9fad00d94ad8477899e38ed7c11f33fb6; https://git.kernel.org/stable/c/4051250e5db489f8ad65fc337e2677b9b568ac72; https://git.kernel.org/stable/c/a0ac3f85b2e3ef529e852f252a70311f9029d5e6
CVE: CVE-2025-38301
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

nvmem: zynqmp_nvmem: unbreak driver after cleanup

Commit 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup")
changed the driver to expect the device pointer to be passed as the
"context", but in nvmem the context parameter comes from nvmem_config.priv
which is never set - Leading to null pointer exceptions when the device is
accessed.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3728101f56ef54425a11027a3ddc2c3941d60b71; https://git.kernel.org/stable/c/c8bb1bcea877446f86922a8fd1661b8c07d90e5c; https://git.kernel.org/stable/c/fe8abdd175d7b547ae1a612757e7902bcd62e9cf
CVE: CVE-2025-38302
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

block: don't use submit_bio_noacct_nocheck in blk_zone_wplug_bio_work

Bios queued up in the zone write plug have already gone through all all
preparation in the submit_bio path, including the freeze protection.

Submitting them through submit_bio_noacct_nocheck duplicates the work
and can can cause deadlocks when freezing a queue with pending bio
write plugs.

Go straight to ->submit_bio or blk_mq_submit_bio to bypass the
superfluous extra freeze protection and checks.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/0fccb6773b1f4f992e435582cf8e050de421b678; https://git.kernel.org/stable/c/6ffae5d53f704d300cc73b06b4ea99e4507f7cf1; https://git.kernel.org/stable/c/cf625013d8741c01407bbb4a60c111b61b9fa69d
CVE: CVE-2025-38303
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: eir: Fix possible crashes on eir_create_adv_data

eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER
without checking if that would fit.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2af40d795d3fb0ee5c074b7ac56ab22402aa6e4f; https://git.kernel.org/stable/c/2d4588f55cc10fc228f3b46469dbfb3f0a8b13c8; https://git.kernel.org/stable/c/47c03902269aff377f959dc3fd94a9733aa31d6e
CVE: CVE-2025-38304
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: Fix NULL pointer deference on eir_get_service_data

The len parameter is considered optional so it can be NULL so it cannot
be used for skipping to next entry of EIR_SERVICE_DATA.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/20a2aa01f5aeb6daad9aeaa7c33dd512c58d81eb; https://git.kernel.org/stable/c/497c9d2d7d3983826bb02c10fb4a5818be6550fb; https://git.kernel.org/stable/c/4bf[PII_REDACTED]6e668a60d953f8da78e95bb7fa2
CVE: CVE-2025-38305
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

ptp: remove ptp->n_vclocks check logic in ptp_vclock_in_use()

There is no disagreement that we should check both ptp->is_virtual_clock
and ptp->n_vclocks to check if the ptp virtual clock is in use.

However, when we acquire ptp->n_vclocks_mux to read ptp->n_vclocks in
ptp_vclock_in_use(), we observe a recursive lock in the call trace
starting from n_vclocks_store().

============================================
WARNING: possible recursive locking detected
6.15.0-rc6 #1 Not tainted
--------------------------------------------
syz.0.1540/13807 is trying to acquire lock:
ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at:
 ptp_vclock_in_use drivers/ptp/ptp_private.h:103 [inline]
ffff888035a24868 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at:
 ptp_clock_unregister+0x21/0x250 drivers/ptp/ptp_clock.c:415

but task is already holding lock:
ffff[PII_REDACTED]68 (&ptp->n_vclocks_mux){+.+.}-{4:4}, at:
 n_vclocks_store+0xf1/0x6d0 drivers/ptp/ptp_sysfs.c:215

other info that might help us debug this:
 Possible unsafe locking scenario:

       CPU0
       ----
  lock(&ptp->n_vclocks_mux);
  lock(&ptp->n_vclocks_mux);

 *** DEADLOCK ***
....
============================================

The best way to solve this is to remove the logic that checks
ptp->n_vclocks in ptp_vclock_in_use().

The reason why this is appropriate is that any path that uses
ptp->n_vclocks must unconditionally check if ptp->n_vclocks is greater
than 0 before unregistering vclocks, and all functions are already
written this way. And in the function that uses ptp->n_vclocks, we
already get ptp->n_vclocks_mux before unregistering vclocks.

Therefore, we need to remove the redundant check for ptp->n_vclocks in
ptp_vclock_in_use() to prevent recursive locking.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/[PII_REDACTED]27fd20f6aa29d85abe086b6fdd9eb1; https://git.kernel.org/stable/c/5d217e7031a5c06d366580fc6ddbf43527b780d4; https://git.kernel.org/stable/c/87f7ce260a3c838b49e1dc1ceedf[PII_REDACTED]a2
CVE: CVE-2025-38306
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

fs/fhandle.c: fix a race in call of has_locked_children()

may_decode_fh() is calling has_locked_children() while holding no locks.
That's an oopsable race...

The rest of the callers are safe since they are holding namespace_sem and
are guaranteed a positive refcount on the mount in question.

Rename the current has_locked_children() to __has_locked_children(), make
it static and switch the fs/namespace.c users to it.

Make has_locked_children() a wrapper for __has_locked_children(), calling
the latter under read_seqlock_excl(&mount_lock).
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/1f282cdc1d219c4a557f7009e81bc792820d9d9a; https://git.kernel.org/stable/c/287c7d34eedd37af1272dfb3b6e8656f4f026424; https://git.kernel.org/stable/c/6482c3dccbfb8d20e2856ce67c[PII_REDACTED]0b3f
CVE: CVE-2025-38307
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: Intel: avs: Verify content returned by parse_int_array()

The first element of the returned array stores its length. If it is 0,
any manipulation beyond the element at index 0 ends with null-ptr-deref.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/18ff538aac63de1866e5a49d57e22788b5c21d12; https://git.kernel.org/stable/c/2916794ffbce604cc2cda105f6b8a4a7c748dd7f; https://git.kernel.org/stable/c/93e246b6769bdacb09cfff4ea0f00fe5ab4f0d7a
CVE: CVE-2025-38308
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

ASoC: Intel: avs: Fix possible null-ptr-deref when initing hw

Search result of avs_dai_find_path_template() shall be verified before
being used. As 'template' is already known when
avs_hw_constraints_init() is fired, drop the search entirely.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2f78724d4f0c665c83e202e3989d5333a2cb1036; https://git.kernel.org/stable/c/ea218ae05e60616531fe652650b98dcd3c328279
CVE: CVE-2025-38309
Published: 2025-07-10
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/xe/vm: move xe_svm_init() earlier

In xe_vm_close_and_put() we need to be able to call xe_svm_fini(),
however during vm creation we can call this on the error path, before
having actually initialised the svm state, leading to various splats
followed by a fatal NPD.

(cherry picked from commit 4f296d77cf49fcb5f90b4674123ad7f3a0676165)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/8cf8cde41ad01150afbd1327ad[PII_REDACTED]f7fd; https://git.kernel.org/stable/c/f5e6a6a8aa46d44ec7a240766cf3b7dd077718b9