deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-38625
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

vfio/pds: Fix missing detach_ioas op

When CONFIG_IOMMUFD is enabled and a device is bound to the pds_vfio_pci
driver, the following WARN_ON() trace is seen and probe fails:

WARNING: CPU: 0 PID: 5040 at drivers/vfio/vfio_main.c:317 __vfio_register_dev+0x130/0x140 [vfio]
<...>
pds_vfio_pci 0000:08:00.1: probe with driver pds_vfio_pci failed with error -22

This is because the driver's vfio_device_ops.detach_ioas isn't set.

Fix this by using the generic vfio_iommufd_physical_detach_ioas
function.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1df8150ab4cc422bddfbd312d6758c50b688a971; https://git.kernel.org/stable/c/7dbfae90c5a33f6b694e7068bc9522cc2655373d; https://git.kernel.org/stable/c/88b962fbd0ac30a65d2869c68d2f145be46ebe4d
CVE: CVE-2025-38626
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to trigger foreground gc during f2fs_map_blocks() in lfs mode

w/ "mode=lfs" mount option, generic/299 will cause system panic as below:

------------[ cut here ]------------
kernel BUG at fs/f2fs/segment.c:2835!
Call Trace:
 <TASK>
 f2fs_allocate_data_block+0x6f4/0xc50
 f2fs_map_blocks+0x970/0x1550
 f2fs_iomap_begin+0xb2/0x1e0
 iomap_iter+0x1d6/0x430
 __iomap_dio_rw+0x208/0x9a0
 f2fs_file_write_iter+0x6b3/0xfa0
 aio_write+0x15d/0x2e0
 io_submit_one+0x55e/0xab0
 __x64_sys_io_submit+0xa5/0x230
 do_syscall_64+0x84/0x2f0
 entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0010:new_curseg+0x70f/0x720

The root cause of we run out-of-space is: in f2fs_map_blocks(), f2fs may
trigger foreground gc only if it allocates any physical block, it will be
a little bit later when there is multiple threads writing data w/
aio/dio/bufio method in parallel, since we always use OPU in lfs mode, so
f2fs_map_blocks() does block allocations aggressively.

In order to fix this issue, let's give a chance to trigger foreground
gc in prior to block allocation in f2fs_map_blocks().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1005a3ca28e90c7a64fa43023f866b960a60f791; https://git.kernel.org/stable/c/264ede8a52f18647ed5bb5f2bd9bf54f556ad8f5; https://git.kernel.org/stable/c/385e64a[PII_REDACTED]b4b52b27c96703516f39968
CVE: CVE-2025-38627
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

f2fs: compress: fix UAF of f2fs_inode_info in f2fs_free_dic

The decompress_io_ctx may be released asynchronously after
I/O completion. If this file is deleted immediately after read,
and the kworker of processing post_read_wq has not been executed yet
due to high workloads, It is possible that the inode(f2fs_inode_info)
is evicted and freed before it is used f2fs_free_dic.

    The UAF case as below:
    Thread A                                      Thread B
    - f2fs_decompress_end_io
     - f2fs_put_dic
      - queue_work
        add free_dic work to post_read_wq
                                                   - do_unlink
                                                    - iput
                                                     - evict
                                                      - call_rcu
    This file is deleted after read.

    Thread C                                 kworker to process post_read_wq
    - rcu_do_batch
     - f2fs_free_inode
      - kmem_cache_free
     inode is freed by rcu
                                             - process_scheduled_works
                                              - f2fs_late_free_dic
                                               - f2fs_free_dic
                                                - f2fs_release_decomp_mem
                                      read (dic->inode)->i_compress_algorithm

This patch store compress_algorithm and sbi in dic to avoid inode UAF.

In addition, the previous solution is deprecated in [1] may cause system hang.
[1] https://lore.kernel.org/all/c36ab955-c8db-4a8b-a9d0-f07b5f426c3f@kernel.org
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/39868685c2a94a70762bc6d77dc81d781d05bff5; https://git.kernel.org/stable/c/5d604d40cd3232b09cb339941ef958e49283ed0a; https://git.kernel.org/stable/c/8fae5b6addd5f6895e03797b56e3c7b9f9cd15c9
CVE: CVE-2025-38628
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

vdpa/mlx5: Fix release of uninitialized resources on error path

The commit in the fixes tag made sure that mlx5_vdpa_free()
is the single entrypoint for removing the vdpa device resources
added in mlx5_vdpa_dev_add(), even in the cleanup path of
mlx5_vdpa_dev_add().

This means that all functions from mlx5_vdpa_free() should be able to
handle uninitialized resources. This was not the case though:
mlx5_vdpa_destroy_mr_resources() and mlx5_cmd_cleanup_async_ctx()
were not able to do so. This caused the splat below when adding
a vdpa device without a MAC address.

This patch fixes these remaining issues:

- Makes mlx5_vdpa_destroy_mr_resources() return early if called on
  uninitialized resources.

- Moves mlx5_cmd_init_async_ctx() early on during device addition
  because it can't fail. This means that mlx5_cmd_cleanup_async_ctx()
  also can't fail. To mirror this, move the call site of
  mlx5_cmd_cleanup_async_ctx() in mlx5_vdpa_free().

An additional comment was added in mlx5_vdpa_free() to document
the expectations of functions called from this context.

Splat:

  mlx5_core 0000:b5:03.2: mlx5_vdpa_dev_add:3950:(pid 2306) warning: No mac address provisioned?
  ------------[ cut here ]------------
  WARNING: CPU: 13 PID: 2306 at kernel/workqueue.c:4207 __flush_work+0x9a/0xb0
  [...]
  Call Trace:
   <TASK>
   ? __try_to_del_timer_sync+0x61/0x90
   ? __timer_delete_sync+0x2b/0x40
   mlx5_vdpa_destroy_mr_resources+0x1c/0x40 [mlx5_vdpa]
   mlx5_vdpa_free+0x45/0x160 [mlx5_vdpa]
   vdpa_release_dev+0x1e/0x50 [vdpa]
   device_release+0x31/0x90
   kobject_cleanup+0x37/0x130
   mlx5_vdpa_dev_add+0x327/0x890 [mlx5_vdpa]
   vdpa_nl_cmd_dev_add_set_doit+0x2c1/0x4d0 [vdpa]
   genl_family_rcv_msg_doit+0xd8/0x130
   genl_family_rcv_msg+0x14b/0x220
   ? __pfx_vdpa_nl_cmd_dev_add_set_doit+0x10/0x10 [vdpa]
   genl_rcv_msg+0x47/0xa0
   ? __pfx_genl_rcv_msg+0x10/0x10
   netlink_rcv_skb+0x53/0x100
   genl_rcv+0x24/0x40
   netlink_unicast+0x27b/0x3b0
   netlink_sendmsg+0x1f7/0x430
   __sys_sendto+0x1fa/0x210
   ? ___pte_offset_map+0x17/0x160
   ? next_uptodate_folio+0x85/0x2b0
   ? percpu_counter_add_batch+0x51/0x90
   ? filemap_map_pages+0x515/0x660
   __x64_sys_sendto+0x20/0x30
   do_syscall_64+0x7b/0x2c0
   ? do_read_fault+0x108/0x220
   ? do_pte_missing+0x14a/0x3e0
   ? __handle_mm_fault+0x321/0x730
   ? count_memcg_events+0x13f/0x180
   ? handle_mm_fault+0x1fb/0x2d0
   ? do_user_addr_fault+0x20c/0x700
   ? syscall_exit_work+0x104/0x140
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f0c25b0feca
  [...]
  ---[ end trace [PII_REDACTED] ]---
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/37f26b9013b46457b0a96633fc3a7dc977d8beb1; https://git.kernel.org/stable/c/6de4ef950dd56a6a81daf92d8a1d864fc6a56971; https://git.kernel.org/stable/c/cc51a66815999afb7e9cd845968de4fdf07567b7
CVE: CVE-2025-38629
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: usb: scarlett2: Fix missing NULL check

scarlett2_input_select_ctl_info() sets up the string arrays allocated
via kasprintf(), but it misses NULL checks, which may lead to NULL
dereference Oops.  Let's add the proper NULL check.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/2c735fcaee81ad[PII_REDACTED]dc9dc460891e76b0; https://git.kernel.org/stable/c/d558db85920b124bac36f8a7ddc5de0aa7491bdd; https://git.kernel.org/stable/c/df485a4b2b3ee5b35c80f990beb554e38a8a5fb1
CVE: CVE-2025-38630
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

fbdev: imxfb: Check fb_add_videomode to prevent null-ptr-deref

fb_add_videomode() can fail with -ENOMEM when its internal kmalloc() cannot
allocate a struct fb_modelist.  If that happens, the modelist stays empty but
the driver continues to register.  Add a check for its return value to prevent
poteintial null-ptr-deref, which is similar to the commit 17186f1f90d3 ("fbdev:
Fix do_register_framebuffer to prevent null-ptr-deref in fb_videomode_to_var").
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/40f0a51f6c54d46a94b9f1180339ede7ca7ee190; https://git.kernel.org/stable/c/49377bac9e3bec1635065a033c9679214fe7593e; https://git.kernel.org/stable/c/4b5d36cc3014986e6fac12eaa8433fe56801d4ce
CVE: CVE-2025-38631
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: imx95-blk-ctl: Fix synchronous abort

When enabling runtime PM for clock suppliers that also belong to a power
domain, the following crash is thrown:
error: synchronous external abort: [PII_REDACTED] [#1] PREEMPT SMP
Workqueue: events_unbound deferred_probe_work_func
pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : clk_mux_get_parent+0x60/0x90
lr : clk_core_reparent_orphans_nolock+0x58/0xd8
  Call trace:
   clk_mux_get_parent+0x60/0x90
   clk_core_reparent_orphans_nolock+0x58/0xd8
   of_clk_add_hw_provider.part.0+0x90/0x100
   of_clk_add_hw_provider+0x1c/0x38
   imx95_bc_probe+0x2e0/0x3f0
   platform_probe+0x70/0xd8

Enabling runtime PM without explicitly resuming the device caused
the power domain cut off after clk_register() is called. As a result,
a crash happens when the clock hardware provider is added and attempts
to access the BLK_CTL register.

Fix this by using devm_pm_runtime_enable() instead of pm_runtime_enable()
and getting rid of the pm_runtime_disable() in the cleanup path.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/533dc3cb375cabd8a2beba293d63ef2acd3d0005; https://git.kernel.org/stable/c/9f0ee0baf25b46bb82655c687718ebb0ae1def7b; https://git.kernel.org/stable/c/b08217a257215ed9130fce93d35feba66b49bf0a
CVE: CVE-2025-38632
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

pinmux: fix race causing mux_owner NULL with active mux_usecount

commit 5a3e85c3c397 ("pinmux: Use sequential access to access
desc->pinmux data") tried to address the issue when two client of the
same gpio calls pinctrl_select_state() for the same functionality, was
resulting in NULL pointer issue while accessing desc->mux_owner.
However, issue was not completely fixed due to the way it was handled
and it can still result in the same NULL pointer.

The issue occurs due to the following interleaving:

     cpu0 (process A)                   cpu1 (process B)

      pin_request() {                   pin_free() {

                                         mutex_lock()
                                         desc->mux_usecount--; //becomes 0
                                         ..
                                         mutex_unlock()

  mutex_lock(desc->mux)
  desc->mux_usecount++; // becomes 1
  desc->mux_owner = owner;
  mutex_unlock(desc->mux)

                                         mutex_lock(desc->mux)
                                         desc->mux_owner = NULL;
                                         mutex_unlock(desc->mux)

This sequence leads to a state where the pin appears to be in use
(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can
cause NULL pointer on next pin_request on the same pin.

Ensure that updates to mux_usecount and mux_owner are performed
atomically under the same lock. Only clear mux_owner when mux_usecount
reaches zero and no new owner has been assigned.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362, CWE-476
References: https://git.kernel.org/stable/c/0b075c011032f88d1cfde3b45d6dcf08b44140eb; https://git.kernel.org/stable/c/22b585cbd67d14df3b91529d1b990661c300faa9; https://git.kernel.org/stable/c/9b2a3e7189028aa7c4d53a84364f2ea9fb209787
CVE: CVE-2025-38633
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: spacemit: mark K1 pll1_d8 as critical

The pll1_d8 clock is enabled by the boot loader, and is ultimately a
parent for numerous clocks, including those used by APB and AXI buses.
Guodong Xu discovered that this clock got disabled while responding to
getting -EPROBE_DEFER when requesting a reset controller.

The needed clock (CLK_DMA, along with its parents) had already been
enabled.  To respond to the probe deferral return, the CLK_DMA clock
was disabled, and this led to parent clocks also reducing their enable
count.  When the enable count for pll1_d8 was decremented it became 0,
which caused it to be disabled.  This led to a system hang.

Marking that clock critical resolves this by preventing it from being
disabled.

Define a new macro CCU_FACTOR_GATE_DEFINE() to allow clock flags to
be supplied for a CCU_FACTOR_GATE clock.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/10948c00e548e9ad2ce9d765baf26dce2d9b806b; https://git.kernel.org/stable/c/7554729de27daf6d54bcf8689d863bbe267828bf
CVE: CVE-2025-38634
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

power: supply: cpcap-charger: Fix null check for power_supply_get_by_name

In the cpcap_usb_detect() function, the power_supply_get_by_name()
function may return `NULL` instead of an error pointer.
To prevent potential null pointer dereferences, Added a null check.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/27001e4f146624c4b3389b029bdc0f[PII_REDACTED]; https://git.kernel.org/stable/c/4ebbb9106aaa2fd58e0359bc3a2490953db2ef0c; https://git.kernel.org/stable/c/8e9bdb563916287ba1b[PII_REDACTED]e0585ac6d00
CVE: CVE-2025-38635
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: davinci: Add NULL check in davinci_lpsc_clk_register()

devm_kasprintf() returns NULL when memory allocation fails. Currently,
davinci_lpsc_clk_register() does not check for this case, which results
in a NULL pointer dereference.

Add NULL check after devm_kasprintf() to prevent this issue and ensuring
no resources are left allocated.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/105e8115944a9f93e9412abe7bb07ed96725adf9; https://git.kernel.org/stable/c/13de464f445d42738fe18c9a28bab056ba3a290a; https://git.kernel.org/stable/c/1d92608a[PII_REDACTED]5f57f3572bc950db7519f0
CVE: CVE-2025-38636
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

rv: Use strings in da monitors tracepoints

Using DA monitors tracepoints with KASAN enabled triggers the following
warning:

 BUG: KASAN: global-out-of-bounds in do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0
 Read of size 32 at addr ffffffffaada8980 by task ...
 Call Trace:
  <TASK>
 [...]
  do_trace_event_raw_event_event_da_monitor+0xd6/0x1a0
  ? __pfx_do_trace_event_raw_event_event_da_monitor+0x10/0x10
  ? trace_event_sncid+0x83/0x200
  trace_event_sncid+0x163/0x200
 [...]
 The buggy address belongs to the variable:
  automaton_snep+0x4e0/0x5e0

This is caused by the tracepoints reading 32 bytes __array instead of
__string from the automata definition. Such strings are literals and
reading 32 bytes ends up in out of bound memory accesses (e.g. the next
automaton's data in this case).
The error is harmless as, while printing the string, we stop at the null
terminator, but it should still be fixed.

Use the __string facilities while defining the tracepoints to avoid
reading out of bound memory.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/0ebc70d973ce7a81826b5c4f55f743e07f5864d9; https://git.kernel.org/stable/c/7f904ff6e58d398c4336f3c19c42b338324451f7
CVE: CVE-2025-38638
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv6: add a retry logic in net6_rt_notify()

inet6_rt_notify() can be called under RCU protection only.
This means the route could be changed concurrently
and rt6_fill_node() could return -EMSGSIZE.

Re-size the skb when this happens and retry, removing
one WARN_ON() that syzbot was able to trigger:

WARNING: CPU: 3 PID: 6291 at net/ipv6/route.c:6342 inet6_rt_notify+0x475/0x4b0 net/ipv6/route.c:6342
Modules linked in:
CPU: 3 UID: 0 PID: 6291 Comm: syz.0.77 Not tainted 6.16.0-rc7-syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
 RIP: 0010:inet6_rt_notify+0x475/0x4b0 net/ipv6/route.c:6342
Code: fc ff ff e8 6d 52 ea f7 e9 47 fc ff ff 48 8b 7c 24 08 4c 89 04 24 e8 5a 52 ea f7 4c 8b 04 24 e9 94 fd ff ff e8 9c fe 84 f7 90 <0f> 0b 90 e9 bd fd ff ff e8 6e 52 ea f7 e9 bb fb ff ff 48 89 df e8
RSP: 0018:ffffc900035cf1d8 EFLAGS: 00010293
RAX: [PII_REDACTED] RBX: ffffc900035cf540 RCX: ffffffff8a36e790
RDX: ffff88802f7e8000 RSI: ffffffff8a36e9d4 RDI: [PII_REDACTED]
RBP: ffff88803c230f00 R08: [PII_REDACTED] R09: 00000000ffffffa6
R10: 00000000ffffffa6 R11: [PII_REDACTED] R12: 00000000ffffffa6
R13: [PII_REDACTED] R14: ffff888032ea4100 R15: [PII_REDACTED]
FS:  00007fac7b89a6c0(0000) GS:ffff8880d6a20000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007fac7b899f98 CR3:[PII_REDACTED]b3f000 CR4:[PII_REDACTED]352ef0
Call Trace:
 <TASK>
  ip6_route_mpath_notify+0xde/0x280 net/ipv6/route.c:5356
  ip6_route_multipath_add+0x1181/0x1bd0 net/ipv6/route.c:5536
  inet6_rtm_newroute+0xe4/0x1a0 net/ipv6/route.c:5647
  rtnetlink_rcv_msg+0x95e/0xe90 net/core/rtnetlink.c:6944
  netlink_rcv_skb+0x155/0x420 net/netlink/af_netlink.c:2552
  netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]
  netlink_unicast+0x58d/0x850 net/netlink/af_netlink.c:1346
  netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1896
  sock_sendmsg_nosec net/socket.c:712 [inline]
  __sock_sendmsg net/socket.c:727 [inline]
  ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566
  ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0bdca3439a22c70eb8f404acd61bf7aca5d731b0; https://git.kernel.org/stable/c/ea2f921db7a483a526058c5b5b8162edd88dabe5
CVE: CVE-2025-38639
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: xt_nfacct: don't assume acct name is null-terminated

BUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721
Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851
[..]
 string+0x231/0x2b0 lib/vsprintf.c:721
 vsnprintf+0x739/0xf00 lib/vsprintf.c:2874
 [..]
 nfacct_mt_checkentry+0xd2/0xe0 net/netfilter/xt_nfacct.c:41
 xt_check_match+0x3d1/0xab0 net/netfilter/x_tables.c:523

nfnl_acct_find_get() handles non-null input, but the error
printk relied on its presence.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/58004aa21e79addaf41667bfe65e93ec51653f18; https://git.kernel.org/stable/c/58007fc7b94fb[PII_REDACTED]ff401eb7f5bde7828; https://git.kernel.org/stable/c/66d41268ede1e1b6e71ba28be923397ff0b2b9c3
CVE: CVE-2025-38641
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btusb: Fix potential NULL dereference on kmalloc failure

Avoid potential NULL pointer dereference by checking the return value of
kmalloc and handling allocation failure properly.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/5029d80bfc30b60ff57c70ccb04e027acb404f6a; https://git.kernel.org/stable/c/b505902c66a282dcb01bcdc015aa1fdfaaa075db
CVE: CVE-2025-38642
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: fix WARN_ON for monitor mode on some devices

On devices without WANT_MONITOR_VIF (and probably without
channel context support) we get a WARN_ON for changing the
per-link setting of a monitor interface.

Since we already skip AP_VLAN interfaces and MONITOR with
WANT_MONITOR_VIF and/or NO_VIRTUAL_MONITOR should update
the settings, catch this in the link change code instead
of the warning.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/1e10ded6b0f9b0eeefaacbb6c6c6afff3f702812; https://git.kernel.org/stable/c/c57e5b9819dfd16d709bcd6cb633301ed0829a66; https://git.kernel.org/stable/c/ff15498ebaa49c5429a74e70a1951dede60cd14c
CVE: CVE-2025-38643
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: cfg80211: Add missing lock in cfg80211_check_and_end_cac()

Callers of wdev_chandef() must hold the wiphy mutex.

But the worker cfg80211_propagate_cac_done_wk() never takes the lock.
Which triggers the warning below with the mesh_peer_connected_dfs
test from hostapd and not (yet) released mac80211 code changes:

WARNING: CPU: 0 PID: 495 at net/wireless/chan.c:1552 wdev_chandef+0x60/0x165
Modules linked in:
CPU: 0 UID: 0 PID: 495 Comm: kworker/u4:2 Not tainted 6.14.0-rc5-wt-g03960e6f9d47 #33 13c287eeabfe1efea01c0bcc863723ab082e17cf
Workqueue: cfg80211 cfg80211_propagate_cac_done_wk
Stack:
 [PII_REDACTED] ffffff00 6093267c
 00[PII_REDACTED]ec30 6d577c50 60037608
 00000000 67e8d[PII_REDACTED]b 00000000
Call Trace:
 [<6002ec30>] ? _printk+0x0/0x98
 [<6003c2b3>] show_stack+0x10e/0x11a
 [<6002ec30>] ? _printk+0x0/0x98
 [<60037608>] dump_stack_lvl+0x71/0xb8
 [<6063717b>] ? wdev_chandef+0x60/0x165
 [<6003766d>] dump_stack+0x1e/0x20
 [<6005d1b7>] __warn+0x101/0x20f
 [<6005d3a8>] warn_slowpath_fmt+0xe3/0x15d
 [<600b0c5c>] ? mark_lock.part.0+0x0/0x4ec
 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16
 [<600b11a2>] ? mark_held_locks+0x5a/0x6e
 [<6005d2c5>] ? warn_slowpath_fmt+0x0/0x15d
 [<60052e53>] ? unblock_signals+0x3a/0xe7
 [<60052f2d>] ? um_set_signals+0x2d/0x43
 [<60751191>] ? __this_cpu_preempt_check+0x0/0x16
 [<607508b2>] ? lock_is_held_type+0x207/0x21f
 [<6063717b>] wdev_chandef+0x60/0x165
 [<605f89b4>] regulatory_propagate_dfs_state+0x247/0x43f
 [<60052f00>] ? um_set_signals+0x0/0x43
 [<605e6bfd>] cfg80211_propagate_cac_done_wk+0x3a/0x4a
 [<6007e460>] process_scheduled_works+0x3bc/0x60e
 [<6007d0ec>] ? move_linked_works+0x4d/0x81
 [<6007d120>] ? assign_work+0x0/0xaa
 [<6007f81f>] worker_thread+0x220/0x2dc
 [<600786ef>] ? set_pf_worker+0x0/0x57
 [<60087c96>] ? to_kthread+0x0/0x43
 [<6008ab3c>] kthread+0x2d3/0x2e2
 [<6007f5ff>] ? worker_thread+0x0/0x2dc
 [<6006c05b>] ? calculate_sigpending+0x0/0x56
 [<6003b37d>] new_thread_handler+0x4a/0x64
irq event stamp: 614611
hardirqs last  enabled at (614621): [<[PII_REDACTED]0bc96b>] __up_console_sem+0x82/0xaf
hardirqs last disabled at (614630): [<[PII_REDACTED]0bc92c>] __up_console_sem+0x43/0xaf
softirqs last  enabled at (614268): [<[PII_REDACTED]6c55c6>] __ieee80211_wake_queue+0x933/0x985
softirqs last disabled at (614266): [<[PII_REDACTED]6c52d6>] __ieee80211_wake_queue+0x643/0x985
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/2c5dee15239f3f3e31aa5c8808f18996c039e2c1; https://git.kernel.org/stable/c/4a63523d3541eef4cf504a9682e6fbe94ffe79a6; https://git.kernel.org/stable/c/7022df2248c08c6f75a01714163ac902333bf3db
CVE: CVE-2025-38644
Published: 2025-08-22
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: reject TDLS operations when station is not associated

syzbot triggered a WARN in ieee80211_tdls_oper() by sending
NL80211_TDLS_ENABLE_LINK immediately after NL80211_CMD_CONNECT,
before association completed and without prior TDLS setup.

This left internal state like sdata->u.mgd.tdls_peer uninitialized,
leading to a WARN_ON() in code paths that assumed it was valid.

Reject the operation early if not in station mode or not associated.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/0c84204cf0bbe89e454a5caccc6a908bc7db1542; https://git.kernel.org/stable/c/16ecdab5446f15a61ec88eb0d23d25d009821db0; https://git.kernel.org/stable/c/31af06b574394530f68a4310c45ecbe2f68853c4