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

RDMA/hns: Fix double destruction of rsv_qp

rsv_qp may be double destroyed in error flow, first in free_mr_init(),
and then in hns_roce_exit(). Fix it by moving the free_mr_init() call
into hns_roce_v2_init().

list_del corruption, ffff589732eb9b50->next is LIST_POISON1 (dead[PII_REDACTED]00)
WARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240
...
Call trace:
 __list_del_entry_valid+0x148/0x240
 hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2]
 hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2]
 hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2]
 free_mr_exit+0x6c/0x120 [hns_roce_hw_v2]
 hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2]
 hns_roce_exit+0x118/0x350 [hns_roce_hw_v2]
 __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2]
 hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2]
 hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2]
 hclge_notify_roce_client+0x6c/0x160 [hclge]
 hclge_reset_rebuild+0x150/0x5c0 [hclge]
 hclge_reset+0x10c/0x140 [hclge]
 hclge_reset_subtask+0x80/0x104 [hclge]
 hclge_reset_service_task+0x168/0x3ac [hclge]
 hclge_service_task+0x50/0x100 [hclge]
 process_one_work+0x250/0x9a0
 worker_thread+0x324/0x990
 kthread+0x190/0x210
 ret_from_fork+0x10/0x18
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/10b083dbba22be19baa848432b6f25aa68ab2db5; https://git.kernel.org/stable/c/c6957b95ecc5b63c5a4bb4ecc28af326cf8f6dc8; https://git.kernel.org/stable/c/dab173bae3303f074f063750a8dead2550d8c782
CVE: CVE-2025-38583
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

clk: xilinx: vcu: unregister pll_post only if registered correctly

If registration of pll_post is failed, it will be set to NULL or ERR,
unregistering same will fail with following call trace:

Unable to handle kernel NULL pointer dereference at virtual address 008
pc : clk_hw_unregister+0xc/0x20
lr : clk_hw_unregister_fixed_factor+0x18/0x30
sp : ffff[PII_REDACTED]50
...
Call trace:
 clk_hw_unregister+0xc/0x20
 clk_hw_unregister_fixed_factor+0x18/0x30
 xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu]
 xvcu_probe+0x2bc/0x53c [xlnx_vcu]
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/3b0abc443ac22f7d4f61ddbbbbc5dbb06c87139d; https://git.kernel.org/stable/c/51990eecf22f446550befdfd1a9f54147eafd636; https://git.kernel.org/stable/c/7e903da71f8bec4beb7c06707900e1ed8db843ca
CVE: CVE-2025-38584
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

padata: Fix pd UAF once and for all

There is a race condition/UAF in padata_reorder that goes back
to the initial commit.  A reference count is taken at the start
of the process in padata_do_parallel, and released at the end in
padata_serial_worker.

This reference count is (and only is) required for padata_replace
to function correctly.  If padata_replace is never called then
there is no issue.

In the function padata_reorder which serves as the core of padata,
as soon as padata is added to queue->serial.list, and the associated
spin lock released, that padata may be processed and the reference
count on pd would go away.

Fix this by getting the next padata before the squeue->serial lock
is released.

In order to make this possible, simplify padata_reorder by only
calling it once the next padata arrives.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/71203f68c7749609d7fc8ae6ad054bdedeb24f91; https://git.kernel.org/stable/c/cdf79bd2e1ecb3cc75631c73d8f4149be6019a52; https://git.kernel.org/stable/c/dbe3e911a59bda6de96e7cae387ff882c2c177fa
CVE: CVE-2025-38585
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int()

When gmin_get_config_var() calls efi.get_variable() and the EFI variable
is larger than the expected buffer size, two behaviors combine to create
a stack buffer overflow:

1. gmin_get_config_var() does not return the proper error code when
   efi.get_variable() fails. It returns the stale 'ret' value from
   earlier operations instead of indicating the EFI failure.

2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates
   *out_len to the required buffer size but writes no data to the output
   buffer. However, due to bug #1, gmin_get_var_int() believes the call
   succeeded.

The caller gmin_get_var_int() then performs:
- Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack
- Calls gmin_get_config_var(dev, is_gmin, var, val, &len) with len=64
- If EFI variable is >64 bytes, efi.get_variable() sets len=required_size
- Due to bug #1, thinks call succeeded with len=required_size
- Executes val[len] = 0, writing past end of 65-byte stack buffer

This creates a stack buffer overflow when EFI variables are larger than
64 bytes. Since EFI variables can be controlled by firmware or system
configuration, this could potentially be exploited for code execution.

Fix the bug by returning proper error codes from gmin_get_config_var()
based on EFI status instead of stale 'ret' value.

The gmin_get_var_int() function is called during device initialization
for camera sensor configuration on Intel Bay Trail and Cherry Trail
platforms using the atomisp camera stack.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/1a7a2f59fb2eb0718a0cff1e5822500cefe50ed9; https://git.kernel.org/stable/c/3d672fe065aa00f4d66f42e3c9720f69a3ed43e7; https://git.kernel.org/stable/c/e6d3453a002e89537e6136f6c774659b297a549b
CVE: CVE-2025-38586
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, arm64: Fix fp initialization for exception boundary

In the ARM64 BPF JIT when prog->aux->exception_boundary is set for a BPF
program, find_used_callee_regs() is not called because for a program
acting as exception boundary, all callee saved registers are saved.
find_used_callee_regs() sets `ctx->fp_used = true;` when it sees FP
being used in any of the instructions.

For programs acting as exception boundary, ctx->fp_used remains false
even if frame pointer is used by the program and therefore, FP is not
set-up for such programs in the prologue. This can cause the kernel to
crash due to a pagefault.

Fix it by setting ctx->fp_used = true for exception boundary programs as
fp is always saved in such programs.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0dbef493cae7d451f[PII_REDACTED]93c000adb2321; https://git.kernel.org/stable/c/1ce30231e0a2c8c361ee5f8f7f265fc17130adce; https://git.kernel.org/stable/c/b114fcee766d5101eada1aca7bb5fd0a86c89b35
CVE: CVE-2025-38587
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv6: fix possible infinite loop in fib6_info_uses_dev()

fib6_info_uses_dev() seems to rely on RCU without an explicit
protection.

Like the prior fix in rt6_nlmsg_size(),
we need to make sure fib6_del_route() or fib6_add_rt2node()
have not removed the anchor from the list, or we risk an infinite loop.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/16d21816c0918f8058b5fc14cbe8595d62046e2d; https://git.kernel.org/stable/c/9cb6de8ee144a94ae7a40bdb32560329ab7276f0; https://git.kernel.org/stable/c/bc85e62394f008fa848c4ba02c936c735a3e8ef5
CVE: CVE-2025-38588
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

ipv6: prevent infinite loop in rt6_nlmsg_size()

While testing prior patch, I was able to trigger
an infinite loop in rt6_nlmsg_size() in the following place:

list_for_each_entry_rcu(sibling, &f6i->fib6_siblings,
			fib6_siblings) {
	rt6_nh_nlmsg_size(sibling->fib6_nh, &nexthop_len);
}

This is because fib6_del_route() and fib6_add_rt2node()
uses list_del_rcu(), which can confuse rcu readers,
because they might no longer see the head of the list.

Restart the loop if f6i->fib6_nsiblings is zero.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-835
References: https://git.kernel.org/stable/c/3c13db3e47e170bab19e574404e7b6be45ea873d; https://git.kernel.org/stable/c/46aeb66e9e54ed0d56c18615e1c3dbd502b327ab; https://git.kernel.org/stable/c/54e6fe9dd3b0e7c481c2228782c9494d653546da
CVE: CVE-2025-38591
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Reject narrower access to pointer ctx fields

The following BPF program, simplified from a syzkaller repro, causes a
kernel warning:

    r0 = *(u8 *)(r1 + 169);
    exit;

With pointer field sk being at offset 168 in __sk_buff. This access is
detected as a narrower read in bpf_skb_is_valid_access because it
doesn't match offsetof(struct __sk_buff, sk). It is therefore allowed
and later proceeds to bpf_convert_ctx_access. Note that for the
"is_narrower_load" case in the convert_ctx_accesses(), the insn->off
is aligned, so the cnt may not be 0 because it matches the
offsetof(struct __sk_buff, sk) in the bpf_convert_ctx_access. However,
the target_size stays 0 and the verifier errors with a kernel warning:

    verifier bug: error during ctx access conversion(1)

This patch fixes that to return a proper "invalid bpf_context access
off=X size=Y" error on the load instruction.

The same issue affects multiple other fields in context structures that
allow narrow access. Some other non-affected fields (for sk_msg,
sk_lookup, and sockopt) were also changed to use bpf_ctx_range_ptr for
consistency.

Note this syzkaller crash was reported in the "Closes" link below, which
used to be about a different bug, fixed in
commit fce7bd8e385a ("bpf/verifier: Handle BPF_LOAD_ACQ instructions
in insn_def_regno()"). Because syzbot somehow confused the two bugs,
the new crash and repro didn't get reported to the mailing list.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/058a0da4f6d916a79b693384111bb80a90d73763; https://git.kernel.org/stable/c/202900ceeef67458c964c2af6e1427c8e533ea7c; https://git.kernel.org/stable/c/33660d44e789edb4f303210c813fc56d56377a90
CVE: CVE-2025-38593
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'

Function 'hci_discovery_filter_clear()' frees 'uuids' array and then
sets it to NULL. There is a tiny chance of the following race:

'hci_cmd_sync_work()'

 'update_passive_scan_sync()'

   'hci_update_passive_scan_sync()'

     'hci_discovery_filter_clear()'
       kfree(uuids);

       <-------------------------preempted-------------------------------->
                                           'start_service_discovery()'

                                             'hci_discovery_filter_clear()'
                                               kfree(uuids); // DOUBLE FREE

       <-------------------------preempted-------------------------------->

      uuids = NULL;

To fix it let's add locking around 'kfree()' call and NULL pointer
assignment. Otherwise the following backtrace fires:

[ ] ------------[ cut here ]------------
[ ] kernel BUG at mm/slub.c:547!
[ ] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
[ ] CPU: 3 UID: 0 PID: 246 Comm: bluetoothd Tainted: G O 6.12.19-kernel #1
[ ] Tainted: [O]=OOT_MODULE
[ ] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ ] pc : __slab_free+0xf8/0x348
[ ] lr : __slab_free+0x48/0x348
...
[ ] Call trace:
[ ]  __slab_free+0xf8/0x348
[ ]  kfree+0x164/0x27c
[ ]  start_service_discovery+0x1d0/0x2c0
[ ]  hci_sock_sendmsg+0x518/0x924
[ ]  __sock_sendmsg+0x54/0x60
[ ]  sock_write_iter+0x98/0xf8
[ ]  do_iter_readv_writev+0xe4/0x1c8
[ ]  vfs_writev+0x128/0x2b0
[ ]  do_writev+0xfc/0x118
[ ]  __arm64_sys_writev+0x20/0x2c
[ ]  invoke_syscall+0x68/0xf0
[ ]  el0_svc_common.constprop.0+0x40/0xe0
[ ]  do_el0_svc+0x1c/0x28
[ ]  el0_svc+0x30/0xd0
[ ]  el0t_64_sync_handler+0x100/0x12c
[ ]  el0t_64_sync+0x194/0x198
[ ] Code: 8b0002e6 eb17031f 54fffbe1 d503201f (d4210000)
[ ] ---[ end trace [PII_REDACTED] ]---
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/16852eccbdfaf41a666705e3f8be55cf2864c5ca; https://git.kernel.org/stable/c/2935e556850e9c94d7a00adf14d3cd7fe406ac03; https://git.kernel.org/stable/c/7ce9bb0b95fc280e9212b8922590c492ca1d9c39
CVE: CVE-2025-38594
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

iommu/vt-d: Fix UAF on sva unbind with pending IOPFs

Commit 17fce9d2336d ("iommu/vt-d: Put iopf enablement in domain attach
path") disables IOPF on device by removing the device from its IOMMU's
IOPF queue when the last IOPF-capable domain is detached from the device.
Unfortunately, it did this in a wrong place where there are still pending
IOPFs. As a result, a use-after-free error is potentially triggered and
eventually a kernel panic with a kernel trace similar to the following:

 refcount_t: underflow; use-after-free.
 WARNING: CPU: 3 PID: 313 at lib/refcount.c:28 refcount_warn_saturate+0xd8/0xe0
 Workqueue: iopf_queue/dmar0-iopfq iommu_sva_handle_iopf
 Call Trace:
   <TASK>
   iopf_free_group+0xe/0x20
   process_one_work+0x197/0x3d0
   worker_thread+0x23a/0x350
   ? rescuer_thread+0x4a0/0x4a0
   kthread+0xf8/0x230
   ? finish_task_switch.isra.0+0x81/0x260
   ? kthreads_online_cpu+0x110/0x110
   ? kthreads_online_cpu+0x110/0x110
   ret_from_fork+0x13b/0x170
   ? kthreads_online_cpu+0x110/0x110
   ret_from_fork_asm+0x11/0x20
   </TASK>
  ---[ end trace [PII_REDACTED] ]---

The intel_pasid_tear_down_entry() function is responsible for blocking
hardware from generating new page faults and flushing all in-flight
ones. Therefore, moving iopf_for_domain_remove() after this function
should resolve this.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/c68332b7ee893292bba6e87d31ef2080c066c65d; https://git.kernel.org/stable/c/f0b9d31c6edd50a6207489cd1bd4ddac814b9cd2
CVE: CVE-2025-38595
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

xen: fix UAF in dmabuf_exp_from_pages()

[dma_buf_fd() fixes; no preferences regarding the tree it goes through -
up to xen folks]

As soon as we'd inserted a file reference into descriptor table, another
thread could close it.  That's fine for the case when all we are doing is
returning that descriptor to userland (it's a race, but it's a userland
race and there's nothing the kernel can do about it).  However, if we
follow fd_install() with any kind of access to objects that would be
destroyed on close (be it the struct file itself or anything destroyed
by its ->release()), we have a UAF.

dma_buf_fd() is a combination of reserving a descriptor and fd_install().
gntdev dmabuf_exp_from_pages() calls it and then proceeds to access the
objects destroyed on close - starting with gntdev_dmabuf itself.

Fix that by doing reserving descriptor before anything else and do
fd_install() only when everything had been set up.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/3edfd2353f301bfffd5ee41066e37320a59ccc2d; https://git.kernel.org/stable/c/532c8b51b3a8676cbf533a291f8156774f30ea87; https://git.kernel.org/stable/c/d59d49af4aeed9a81e673e37c26c6a3bacf1a181
CVE: CVE-2025-38596
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/panthor: Fix UAF in panthor_gem_create_with_handle() debugfs code

The object is potentially already gone after the drm_gem_object_put().
In general the object should be fully constructed before calling
drm_gem_handle_create(), except the debugfs tracking uses a separate
lock and list and separate flag to denotate whether the object is
actually initialized.

Since I'm touching this all anyway simplify this by only adding the
object to the debugfs when it's ready for that, which allows us to
delete that separate flag. panthor_gem_debugfs_bo_rm() already checks
whether we've actually been added to the list or this is some error
path cleanup.

v2: Fix build issues for !CONFIG_DEBUGFS (Adrián)

v3: Add linebreak and remove outdated comment (Liviu)
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/5f2be12442db6a2904e6e31b0e3b5ad5aebf868b; https://git.kernel.org/stable/c/fe69a[PII_REDACTED]77b1f002a6e7447de3de7a88e
CVE: CVE-2025-38597
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/rockchip: vop2: fail cleanly if missing a primary plane for a video-port

Each window of a vop2 is usable by a specific set of video ports, so while
binding the vop2, we look through the list of available windows trying to
find one designated as primary-plane and usable by that specific port.

The code later wants to use drm_crtc_init_with_planes with that found
primary plane, but nothing has checked so far if a primary plane was
actually found.

For whatever reason, the rk3576 vp2 does not have a usable primary window
(if vp0 is also in use) which brought the issue to light and ended in a
null-pointer dereference further down.

As we expect a primary-plane to exist for a video-port, add a check at
the end of the window-iteration and fail probing if none was found.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/38682edbbad272b5f8c7bf55128b42cd10626f73; https://git.kernel.org/stable/c/e1eef239399927b368f70a716044fb10085627c8; https://git.kernel.org/stable/c/f9f68bf1d0efeadb6c427c9dbb30f307a7def19b
CVE: CVE-2025-38599
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7996: Fix possible OOB access in mt7996_tx()

Fis possible Out-Of-Boundary access in mt7996_tx routine if link_id is
set to IEEE80211_LINK_UNSPECIFIED
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/64cbf0d7ce9afe20666da90ec6ecaec6ba5ac64b; https://git.kernel.org/stable/c/f43e7d8ae4b6a[PII_REDACTED]5552bab26f76f113a; https://git.kernel.org/stable/c/f82eabd0ff8067d1ee95515f4174c9a9569d54cb
CVE: CVE-2025-38600
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: mt7925: fix off by one in mt7925_mcu_hw_scan()

The ssid->ssids[] and sreq->ssids[] arrays have MT7925_RNR_SCAN_MAX_BSSIDS
elements so this >= needs to be > to prevent an out of bounds access.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-193
References: https://git.kernel.org/stable/c/4d80d4fa986c5da99042b66bf30a028e7f564156; https://git.kernel.org/stable/c/b3a431fe2e399b2e0cc5f43f7e9d63d63d3710ee
CVE: CVE-2025-38601
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: clear initialized flag for deinit-ed srng lists

In a number of cases we see kernel panics on resume due
to ath11k kernel page fault, which happens under the
following circumstances:

1) First ath11k_hal_dump_srng_stats() call

 Last interrupt received for each group:
 ath11k_pci 0000:01:00.0: group_id 0 22511ms before
 ath11k_pci 0000:01:00.0: group_id 1 14440788ms before
 [..]
 ath11k_pci 0000:01:00.0: failed to receive control response completion, polling..
 ath11k_pci 0000:01:00.0: Service connect timeout
 ath11k_pci 0000:01:00.0: failed to connect to HTT: -110
 ath11k_pci 0000:01:00.0: failed to start core: -110
 ath11k_pci 0000:01:00.0: firmware crashed: MHI_CB_EE_RDDM
 ath11k_pci 0000:01:00.0: already resetting count 2
 ath11k_pci 0000:01:00.0: failed to wait wlan mode request (mode 4): -110
 ath11k_pci 0000:01:00.0: qmi failed to send wlan mode off: -110
 ath11k_pci 0000:01:00.0: failed to reconfigure driver on crash recovery
 [..]

2) At this point reconfiguration fails (we have 2 resets) and
  ath11k_core_reconfigure_on_crash() calls ath11k_hal_srng_deinit()
  which destroys srng lists.  However, it does not reset per-list
  ->initialized flag.

3) Second ath11k_hal_dump_srng_stats() call sees stale ->initialized
  flag and attempts to dump srng stats:

 Last interrupt received for each group:
 ath11k_pci 0000:01:00.0: group_id 0 66785ms before
 ath11k_pci 0000:01:00.0: group_id 1 14485062ms before
 ath11k_pci 0000:01:00.0: group_id 2 14485062ms before
 ath11k_pci 0000:01:00.0: group_id 3 14485062ms before
 ath11k_pci 0000:01:00.0: group_id 4 14780845ms before
 ath11k_pci 0000:01:00.0: group_id 5 14780845ms before
 ath11k_pci 0000:01:00.0: group_id 6 14485062ms before
 ath11k_pci 0000:01:00.0: group_id 7 66814ms before
 ath11k_pci 0000:01:00.0: group_id 8 68997ms before
 ath11k_pci 0000:01:00.0: group_id 9 67588ms before
 ath11k_pci 0000:01:00.0: group_id 10 69511ms before
 BUG: unable to handle page fault for address: ffffa007404eb010
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0
 Oops: 0000 [#1] PREEMPT SMP NOPTI
 RIP: 0010:ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k]
 Call Trace:
 <TASK>
 ? __die_body+0xae/0xb0
 ? page_fault_oops+0x381/0x3e0
 ? exc_page_fault+0x69/0xa0
 ? asm_exc_page_fault+0x22/0x30
 ? ath11k_hal_dump_srng_stats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)]
 ath11k_qmi_driver_event_work+0xbd/0x1050 [ath11k (HASH:6cea 4)]
 worker_thread+0x389/0x930
 kthread+0x149/0x170

Clear per-list ->initialized flag in ath11k_hal_srng_deinit().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-909
References: https://git.kernel.org/stable/c/0ebb5fe494501c19f31270008b26ab95201af6fd; https://git.kernel.org/stable/c/16872194c80f2724472fc[PII_REDACTED]95ac8a230; https://git.kernel.org/stable/c/3a6daae987a829534636fd85ed6f84d5f0ad7fa4
CVE: CVE-2025-38602
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

iwlwifi: Add missing check for alloc_ordered_workqueue

Add check for the return value of alloc_ordered_workqueue since it may
return NULL pointer.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-252
References: https://git.kernel.org/stable/c/2e9f85ee3b46453a2f250a57d3a9f10c70c71202; https://git.kernel.org/stable/c/6663c52608d8d8727bf1911e6d9218069ba1c85e; https://git.kernel.org/stable/c/70a1b527eaea9430b1bd87de59f3b9f6bd225701
CVE: CVE-2025-38603
Published: 2025-08-19
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2025-38604
Published: 2025-08-19
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: rtl818x: Kill URBs before clearing tx status queue

In rtl8187_stop() move the call of usb_kill_anchored_urbs() before clearing
b_tx_status.queue. This change prevents callbacks from using already freed
skb due to anchor was not killed before freeing such skb.

 BUG: kernel NULL pointer dereference, address: [PII_REDACTED]
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: Oops: 0000 [#1] SMP NOPTI
 CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Not tainted 6.15.0 #8 PREEMPT(voluntary)
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015
 RIP: 0010:ieee80211_tx_status_irqsafe+0x21/0xc0 [mac80211]
 Call Trace:
  <IRQ>
  rtl8187_tx_cb+0x116/0x150 [rtl8187]
  __usb_hcd_giveback_urb+0x9d/0x120
  usb_giveback_urb_bh+0xbb/0x140
  process_one_work+0x19b/0x3c0
  bh_worker+0x1a7/0x210
  tasklet_action+0x10/0x30
  handle_softirqs+0xf0/0x340
  __irq_exit_rcu+0xcd/0xf0
  common_interrupt+0x85/0xa0
  </IRQ>

Tested on RTL8187BvE device.

Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/14ca6952691fa8cc91e7644512e6ff24a595283f; https://git.kernel.org/stable/c/16d8fd74dbfca0ea58645cd2fca13be10cae3cdd; https://git.kernel.org/stable/c/7858a95566f4ebf[PII_REDACTED]3d2dcdba3fca968