CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2025-38454 – ALSA: ad1816a: Fix potential NULL pointer deref in snd_card_ad1816a_pnp()
https://notcve.org/view.php?id=CVE-2025-38454
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: ALSA: ad1816a: Fix potential NULL pointer deref in snd_card_ad1816a_pnp() Use pr_warn() instead of dev_warn() when 'pdev' is NULL to avoid a potential NULL pointer dereference. In the Linux kernel, the following vulnerability has been resolved: ALSA: ad1816a: Fix potential NULL pointer deref in snd_card_ad1816a_pnp() Use pr_warn() instead of dev_warn() when 'pdev' is NULL to avoid a potential NULL pointer dereference. • https://git.kernel.org/stable/c/20869176d7a7509bad9ea6b895469aebea9c8f21 •
CVSS: 7.2EPSS: 0%CPEs: 2EXPL: 0CVE-2025-38453 – io_uring/msg_ring: ensure io_kiocb freeing is deferred for RCU
https://notcve.org/view.php?id=CVE-2025-38453
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: io_uring/msg_ring: ensure io_kiocb freeing is deferred for RCU syzbot reports that defer/local task_work adding via msg_ring can hit a request that has been freed: CPU: 1 UID: 0 PID: 19356 Comm: iou-wrk-19354 Not tainted 6.16.0-rc4-syzkaller-00108-g17bbde2e1716 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025 Call Trace:
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2025-38452 – net: ethernet: rtsn: Fix a null pointer dereference in rtsn_probe()
https://notcve.org/view.php?id=CVE-2025-38452
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: net: ethernet: rtsn: Fix a null pointer dereference in rtsn_probe() Add check for the return value of rcar_gen4_ptp_alloc() to prevent potential null pointer dereference. In the Linux kernel, the following vulnerability has been resolved: net: ethernet: rtsn: Fix a null pointer dereference in rtsn_probe() Add check for the return value of rcar_gen4_ptp_alloc() to prevent potential null pointer dereference. • https://git.kernel.org/stable/c/b0d3969d2b4db82602492cad576b8de494a12ddf •
CVSS: 5.6EPSS: 0%CPEs: 6EXPL: 0CVE-2025-38451 – md/md-bitmap: fix GPF in bitmap_get_stats()
https://notcve.org/view.php?id=CVE-2025-38451
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: md/md-bitmap: fix GPF in bitmap_get_stats() The commit message of commit 6ec1f0239485 ("md/md-bitmap: fix stats collection for external bitmaps") states: Remove the external bitmap check as the statistics should be available regardless of bitmap storage location. Return -EINVAL only for invalid bitmap with no storage (neither in superblock nor in external file). But, the code does not adhere to the above, as it does only check for a valid s... • https://git.kernel.org/stable/c/065f4b1cd41d03702426af44193894b925607073 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2025-38450 – wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_sta_set_decap_offload()
https://notcve.org/view.php?id=CVE-2025-38450
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7925: prevent NULL pointer dereference in mt7925_sta_set_decap_offload() Add a NULL check for msta->vif before accessing its members to prevent a kernel panic in AP mode deployment. This also fix the issue reported in [1]. The crash occurs when this function is triggered before the station is fully initialized. The call trace shows a page fault at mt7925_sta_set_decap_offload() due to accessing resources when msta->vif is NULL... • https://git.kernel.org/stable/c/b859ad65309a5f1654e8b284de582831fc88e2d8 •
CVSS: 7.8EPSS: 0%CPEs: 4EXPL: 0CVE-2025-38449 – drm/gem: Acquire references on GEM handles for framebuffers
https://notcve.org/view.php?id=CVE-2025-38449
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/gem: Acquire references on GEM handles for framebuffers A GEM handle can be released while the GEM buffer object is attached to a DRM framebuffer. This leads to the release of the dma-buf backing the buffer object, if any. [1] Trying to use the framebuffer in further mode-setting operations leads to a segmentation fault. Most easily happens with driver that use shadow planes for vmap-ing the dma-buf during a page flip. An example is sho... • https://git.kernel.org/stable/c/cb4c956a15f8b7f870649454771fc3761f504b5f •
CVSS: 6.9EPSS: 0%CPEs: 8EXPL: 0CVE-2025-38448 – usb: gadget: u_serial: Fix race condition in TTY wakeup
https://notcve.org/view.php?id=CVE-2025-38448
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: usb: gadget: u_serial: Fix race condition in TTY wakeup A race condition occurs when gs_start_io() calls either gs_start_rx() or gs_start_tx(), as those functions briefly drop the port_lock for usb_ep_queue(). This allows gs_close() and gserial_disconnect() to clear port.tty and port_usb, respectively. Use the null-safe TTY Port helper function to wake up TTY. Example CPU1: CPU2: gserial_connect() // lock gs_close() // await lock gs_start_r... • https://git.kernel.org/stable/c/35f95fd7f234d2b58803bab6f6ebd6bb988050a2 •
CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0CVE-2025-38446 – clk: imx: Fix an out-of-bounds access in dispmix_csr_clk_dev_data
https://notcve.org/view.php?id=CVE-2025-38446
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: clk: imx: Fix an out-of-bounds access in dispmix_csr_clk_dev_data When num_parents is 4, __clk_register() occurs an out-of-bounds when accessing parent_names member. Use ARRAY_SIZE() instead of hardcode number here. BUG: KASAN: global-out-of-bounds in __clk_register+0x1844/0x20d8 Read of size 8 at addr ffff800086988e78 by task kworker/u24:3/59 Hardware name: NXP i.MX95 19X19 board (DT) Workqueue: events_unbound deferred_probe_work_func Call... • https://git.kernel.org/stable/c/5224b189462ff70df328f173b71acfd925092c3c •
CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0CVE-2025-38445 – md/raid1: Fix stack memory use after return in raid1_reshape
https://notcve.org/view.php?id=CVE-2025-38445
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: md/raid1: Fix stack memory use after return in raid1_reshape In the raid1_reshape function, newpool is allocated on the stack and assigned to conf->r1bio_pool. This results in conf->r1bio_pool.wait.head pointing to a stack address. Accessing this address later can lead to a kernel panic. Example access path: raid1_reshape() { // newpool is on the stack mempool_t newpool, oldpool; // initialize newpool.wait.head to stack address mempool_init... • https://git.kernel.org/stable/c/afeee514ce7f4cab605beedd03be71ebaf0c5fc8 •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2025-38444 – raid10: cleanup memleak at raid10_make_request
https://notcve.org/view.php?id=CVE-2025-38444
25 Jul 2025 — In the Linux kernel, the following vulnerability has been resolved: raid10: cleanup memleak at raid10_make_request If raid10_read_request or raid10_write_request registers a new request and the REQ_NOWAIT flag is set, the code does not free the malloc from the mempool. unreferenced object 0xffff8884802c3200 (size 192): comm "fio", pid 9197, jiffies 4298078271 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 88 41 02 00 00 00 00 00 .........A...... 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ............. • https://git.kernel.org/stable/c/39db562b3fedb93978a7e42dd216b306740959f8 •