CVSS: 7.1EPSS: 0%CPEs: 4EXPL: 0CVE-2025-21892 – RDMA/mlx5: Fix the recovery flow of the UMR QP
https://notcve.org/view.php?id=CVE-2025-21892
27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix the recovery flow of the UMR QP This patch addresses an issue in the recovery flow of the UMR QP, ensuring tasks do not get stuck, as highlighted by the call trace [1]. During recovery, before transitioning the QP to the RESET state, the software must wait for all outstanding WRs to complete. Failing to do so can cause the firmware to skip sending some flushed CQEs with errors and simply discard them upon the RESET, as per th... • https://git.kernel.org/stable/c/158e71bb69e368b8b33e8b7c4ac8c111da0c1ae2 •
CVSS: 6.1EPSS: 0%CPEs: 5EXPL: 0CVE-2025-21891 – ipvlan: ensure network headers are in skb linear part
https://notcve.org/view.php?id=CVE-2025-21891
27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: ipvlan: ensure network headers are in skb linear part syzbot found that ipvlan_process_v6_outbound() was assuming the IPv6 network header isis present in skb->head [1] Add the needed pskb_network_may_pull() calls for both IPv4 and IPv6 handlers. [1] BUG: KMSAN: uninit-value in __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 __ipv6_addr_type+0xa2/0x490 net/ipv6/addrconf_core.c:47 ipv6_addr_type include/net/ipv6.h:555 [inline] ip6_rou... • https://git.kernel.org/stable/c/2ad7bf3638411cb547f2823df08166c13ab04269 •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2025-21888 – RDMA/mlx5: Fix a WARN during dereg_mr for DM type
https://notcve.org/view.php?id=CVE-2025-21888
27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: RDMA/mlx5: Fix a WARN during dereg_mr for DM type Memory regions (MR) of type DM (device memory) do not have an associated umem. In the __mlx5_ib_dereg_mr() -> mlx5_free_priv_descs() flow, the code incorrectly takes the wrong branch, attempting to call dma_unmap_single() on a DMA address that is not mapped. This results in a WARN [1], as shown below. The issue is resolved by properly accounting for the DM type and ensuring the correct branc... • https://git.kernel.org/stable/c/f18ec422311767738ef4033b61e91cae07163b22 •
CVSS: 8.8EPSS: 0%CPEs: 9EXPL: 0CVE-2025-21887 – ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up
https://notcve.org/view.php?id=CVE-2025-21887
27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: ovl: fix UAF in ovl_dentry_update_reval by moving dput() in ovl_link_up The issue was caused by dput(upper) being called before ovl_dentry_update_reval(), while upper->d_flags was still accessed in ovl_dentry_remote(). Move dput(upper) after its last use to prevent use-after-free. BUG: KASAN: slab-use-after-free in ovl_dentry_remote fs/overlayfs/util.c:162 [inline] BUG: KASAN: slab-use-after-free in ovl_dentry_update_reval+0xd2/0xf0 fs/over... • https://git.kernel.org/stable/c/62f29ca45f832e281fc14966ac25f6ff3bd121ca • CWE-416: Use After Free •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2025-21885 – RDMA/bnxt_re: Fix the page details for the srq created by kernel consumers
https://notcve.org/view.php?id=CVE-2025-21885
27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix the page details for the srq created by kernel consumers While using nvme target with use_srq on, below kernel panic is noticed. [ 549.698111] bnxt_en 0000:41:00.0 enp65s0np0: FEC autoneg off encoding: Clause 91 RS(544,514) [ 566.393619] Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI .. [ 566.393799]
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2025-21881 – uprobes: Reject the shared zeropage in uprobe_write_opcode()
https://notcve.org/view.php?id=CVE-2025-21881
27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: uprobes: Reject the shared zeropage in uprobe_write_opcode() We triggered the following crash in syzkaller tests: BUG: Bad page state in process syz.7.38 pfn:1eff3 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3 flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff) raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffff... • https://git.kernel.org/stable/c/2b144498350860b6ee9dc57ff27a93ad488de5dc •
CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0CVE-2025-21878 – i2c: npcm: disable interrupt enable bit before devm_request_irq
https://notcve.org/view.php?id=CVE-2025-21878
27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: i2c: npcm: disable interrupt enable bit before devm_request_irq The customer reports that there is a soft lockup issue related to the i2c driver. After checking, the i2c module was doing a tx transfer and the bmc machine reboots in the middle of the i2c transaction, the i2c module keeps the status without being reset. Due to such an i2c module status, the i2c irq handler keeps getting triggered since the i2c irq handler is registered in the... • https://git.kernel.org/stable/c/56a1485b102ed1cd5a4af8e87ed794699fd1cad2 •
CVSS: 5.6EPSS: 0%CPEs: 8EXPL: 0CVE-2025-21877 – usbnet: gl620a: fix endpoint checking in genelink_bind()
https://notcve.org/view.php?id=CVE-2025-21877
27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: usbnet: gl620a: fix endpoint checking in genelink_bind() Syzbot reports [1] a warning in usb_submit_urb() triggered by inconsistencies between expected and actually present endpoints in gl620a driver. Since genelink_bind() does not properly verify whether specified eps are in fact provided by the device, in this case, an artificially manufactured one, one may get a mismatch. Fix the issue by resorting to a usbnet utility function usbnet_get... • https://git.kernel.org/stable/c/47ee3051c856cc2aa95d35d577a8cb37279d540f •
CVSS: 5.6EPSS: 0%CPEs: 7EXPL: 0CVE-2025-21875 – mptcp: always handle address removal under msk socket lock
https://notcve.org/view.php?id=CVE-2025-21875
27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: mptcp: always handle address removal under msk socket lock Syzkaller reported a lockdep splat in the PM control path: WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 sock_owned_by_me include/net/sock.h:1711 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 msk_owned_by_me net/mptcp/protocol.h:363 [inline] WARNING: CPU: 0 PID: 6693 at ./include/net/sock.h:1711 mptcp_pm_nl_addr_send_ack+0x57c/0x610 net/mptcp/pm_netlink.c:... • https://git.kernel.org/stable/c/b6c08380860b926752d57c8fa9911fa388c4b876 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2025-21872 – efi: Don't map the entire mokvar table to determine its size
https://notcve.org/view.php?id=CVE-2025-21872
27 Mar 2025 — In the Linux kernel, the following vulnerability has been resolved: efi: Don't map the entire mokvar table to determine its size Currently, when validating the mokvar table, we (re)map the entire table on each iteration of the loop, adding space as we discover new entries. If the table grows over a certain size, this fails due to limitations of early_memmap(), and we get a failure and traceback: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at mm/early_ioremap.c:139 __early_ioremap+0xef/0x220 ... • https://git.kernel.org/stable/c/46c0454ffb78ce9d3355a3cccac86383ea8ddd55 •