CVSS: 6.6EPSS: 0%CPEs: 3EXPL: 0CVE-2025-40180 – mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop
https://notcve.org/view.php?id=CVE-2025-40180
12 Nov 2025 — In the Linux kernel, the following vulnerability has been resolved: mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop The cleanup loop was starting at the wrong array index, causing out-of-bounds access. Start the loop at the correct index for zero-indexed arrays to prevent accessing memory beyond the allocated array bounds. In the Linux kernel, the following vulnerability has been resolved: mailbox: zynqmp-ipi: Fix out-of-bounds access in mailbox cleanup loop The cleanup loop was starti... • https://git.kernel.org/stable/c/4981b82ba2ff87df6a711fcd7a233c615df5fc79 •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2025-40179 – ext4: verify orphan file size is not too big
https://notcve.org/view.php?id=CVE-2025-40179
12 Nov 2025 — In the Linux kernel, the following vulnerability has been resolved: ext4: verify orphan file size is not too big In principle orphan file can be arbitrarily large. However orphan replay needs to traverse it all and we also pin all its buffers in memory. Thus filesystems with absurdly large orphan files can lead to big amounts of memory consumed. Limit orphan file size to a sane value and also use kvmalloc() for allocating array of block descriptor structures to avoid large order allocations for sane but lar... • https://git.kernel.org/stable/c/02f310fcf47fa9311d6ba2946a8d19e7d7d11f37 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2025-40178 – pid: Add a judgment for ns null in pid_nr_ns
https://notcve.org/view.php?id=CVE-2025-40178
12 Nov 2025 — In the Linux kernel, the following vulnerability has been resolved: pid: Add a judgment for ns null in pid_nr_ns __task_pid_nr_ns ns = task_active_pid_ns(current); pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns); if (pid && ns->level <= pid->level) { Sometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns. For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DA... • https://git.kernel.org/stable/c/75dbc029c5359438be4a6f908bfbfdab969af776 •
CVSS: 5.4EPSS: 0%CPEs: 3EXPL: 0CVE-2025-40177 – accel/qaic: Fix bootlog initialization ordering
https://notcve.org/view.php?id=CVE-2025-40177
12 Nov 2025 — In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Fix bootlog initialization ordering As soon as we queue MHI buffers to receive the bootlog from the device, we could be receiving data. Therefore all the resources needed to process that data need to be setup prior to queuing the buffers. We currently initialize some of the resources after queuing the buffers which creates a race between the probe() and any data that comes back from the device. If the uninitialized resources are... • https://git.kernel.org/stable/c/5f8df5c6def641c164ed1b673d47a41fdd0013f8 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2025-40176 – tls: wait for pending async decryptions if tls_strp_msg_hold fails
https://notcve.org/view.php?id=CVE-2025-40176
12 Nov 2025 — In the Linux kernel, the following vulnerability has been resolved: tls: wait for pending async decryptions if tls_strp_msg_hold fails Async decryption calls tls_strp_msg_hold to create a clone of the input skb to hold references to the memory it uses. If we fail to allocate that clone, proceeding with async decryption can lead to various issues (UAF on the skb, writing into userspace memory after the recv() call has returned). In this case, wait for all pending decryption requests. In the Linux kernel, the... • https://git.kernel.org/stable/c/84c61fe1a75b4255df1e1e7c054c9e6d048da417 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2025-40173 – net/ip6_tunnel: Prevent perpetual tunnel growth
https://notcve.org/view.php?id=CVE-2025-40173
12 Nov 2025 — In the Linux kernel, the following vulnerability has been resolved: net/ip6_tunnel: Prevent perpetual tunnel growth Similarly to ipv4 tunnel, ipv6 version updates dev->needed_headroom, too. While ipv4 tunnel headroom adjustment growth was limited in commit 5ae1e9922bbd ("net: ip_tunnel: prevent perpetual headroom growth"), ipv6 tunnel yet increases the headroom without any ceiling. Reflect ipv4 tunnel headroom adjustment limit on ipv6 version. Credits to Francesco Ruggeri, who was originally debugging this ... • https://git.kernel.org/stable/c/8eb30be0352d09165e94a41fef1c7b994dca0714 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2025-40172 – accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages()
https://notcve.org/view.php?id=CVE-2025-40172
12 Nov 2025 — In the Linux kernel, the following vulnerability has been resolved: accel/qaic: Treat remaining == 0 as error in find_and_map_user_pages() Currently, if find_and_map_user_pages() takes a DMA xfer request from the user with a length field set to 0, or in a rare case, the host receives QAIC_TRANS_DMA_XFER_CONT from the device where resources->xferred_dma_size is equal to the requested transaction size, the function will return 0 before allocating an sgt or setting the fields of the dma_xfer struct. In that ca... • https://git.kernel.org/stable/c/96d3c1cadedb6ae2e8965e19cd12caa244afbd9c •
CVSS: 7.1EPSS: 0%CPEs: 7EXPL: 0CVE-2025-40171 – nvmet-fc: move lsop put work to nvmet_fc_ls_req_op
https://notcve.org/view.php?id=CVE-2025-40171
12 Nov 2025 — In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: move lsop put work to nvmet_fc_ls_req_op It’s possible for more than one async command to be in flight from __nvmet_fc_send_ls_req. For each command, a tgtport reference is taken. In the current code, only one put work item is queued at a time, which results in a leaked reference. To fix this, move the work item to the nvmet_fc_ls_req_op struct, which already tracks all resources related to the command. In the Linux kernel, the fo... • https://git.kernel.org/stable/c/5e0bc09a52b6169ce90f7ac6e195791adb16cec4 •
CVSS: 7.8EPSS: 0%CPEs: 2EXPL: 0CVE-2025-40170 – net: use dst_dev_rcu() in sk_setup_caps()
https://notcve.org/view.php?id=CVE-2025-40170
12 Nov 2025 — In the Linux kernel, the following vulnerability has been resolved: net: use dst_dev_rcu() in sk_setup_caps() Use RCU to protect accesses to dst->dev from sk_setup_caps() and sk_dst_gso_max_size(). Also use dst_dev_rcu() in ip6_dst_mtu_maybe_forward(), and ip_dst_mtu_maybe_forward(). ip4_dst_hoplimit() can use dst_dev_net_rcu(). In the Linux kernel, the following vulnerability has been resolved: net: use dst_dev_rcu() in sk_setup_caps() Use RCU to protect accesses to dst->dev from sk_setup_caps() and sk_dst... • https://git.kernel.org/stable/c/4a6ce2b6f2ecabbddcfe47e7cf61dd0f00b10e36 •
CVSS: 6.6EPSS: 0%CPEs: 4EXPL: 0CVE-2025-40169 – bpf: Reject negative offsets for ALU ops
https://notcve.org/view.php?id=CVE-2025-40169
12 Nov 2025 — In the Linux kernel, the following vulnerability has been resolved: bpf: Reject negative offsets for ALU ops When verifying BPF programs, the check_alu_op() function validates instructions with ALU operations. The 'offset' field in these instructions is a signed 16-bit integer. The existing check 'insn->off > 1' was intended to ensure the offset is either 0, or 1 for BPF_MOD/BPF_DIV. However, because 'insn->off' is signed, this check incorrectly accepts all negative values (e.g., -1). This commit tightens t... • https://git.kernel.org/stable/c/ec0e2da95f72d4a46050a4d994e4fe471474fd80 •