CVSS: 9.8EPSS: 0%CPEs: 5EXPL: 0CVE-2025-21979 – wifi: cfg80211: cancel wiphy_work before freeing wiphy
https://notcve.org/view.php?id=CVE-2025-21979
01 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: wifi: cfg80211: cancel wiphy_work before freeing wiphy A wiphy_work can be queued from the moment the wiphy is allocated and initialized (i.e. wiphy_new_nm). When a wiphy_work is queued, the rdev::wiphy_work is getting queued. If wiphy_free is called before the rdev::wiphy_work had a chance to run, the wiphy memory will be freed, and then when it eventally gets to run it'll use invalid memory. Fix this by canceling the work before freeing t... • https://git.kernel.org/stable/c/3fcc6d7d5f40dad56dee7bde787b7e23edd4b93c •
CVSS: 7.1EPSS: 0%CPEs: 5EXPL: 0CVE-2025-21978 – drm/hyperv: Fix address space leak when Hyper-V DRM device is removed
https://notcve.org/view.php?id=CVE-2025-21978
01 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/hyperv: Fix address space leak when Hyper-V DRM device is removed When a Hyper-V DRM device is probed, the driver allocates MMIO space for the vram, and maps it cacheable. If the device removed, or in the error path for device probing, the MMIO space is released but no unmap is done. Consequently the kernel address space for the mapping is leaked. Fix this by adding iounmap() calls in the device removal path, and in the error path durin... • https://git.kernel.org/stable/c/a0ab5abced550ddeefddb06055ed60779a54eb79 •
CVSS: 5.6EPSS: 0%CPEs: 3EXPL: 0CVE-2025-21977 – fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs
https://notcve.org/view.php?id=CVE-2025-21977
01 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: fbdev: hyperv_fb: Fix hang in kdump kernel when on Hyper-V Gen 2 VMs Gen 2 Hyper-V VMs boot via EFI and have a standard EFI framebuffer device. When the kdump kernel runs in such a VM, loading the efifb driver may hang because of accessing the framebuffer at the wrong memory address. The scenario occurs when the hyperv_fb driver in the original kernel moves the framebuffer to a different MMIO address because of conflicts with an already-run... • https://git.kernel.org/stable/c/c25a19afb81cfd73dab494ba64f9a434cf1a4499 •
CVSS: 7.2EPSS: 0%CPEs: 3EXPL: 0CVE-2025-21976 – fbdev: hyperv_fb: Allow graceful removal of framebuffer
https://notcve.org/view.php?id=CVE-2025-21976
01 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: fbdev: hyperv_fb: Allow graceful removal of framebuffer When a Hyper-V framebuffer device is unbind, hyperv_fb driver tries to release the framebuffer forcefully. If this framebuffer is in use it produce the following WARN and hence this framebuffer is never released. [ 44.111220] WARNING: CPU: 35 PID: 1882 at drivers/video/fbdev/core/fb_info.c:70 framebuffer_release+0x2c/0x40 < snip > [ 44.111289] Call Trace: [ 44.111290]
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2025-21975 – net/mlx5: handle errors in mlx5_chains_create_table()
https://notcve.org/view.php?id=CVE-2025-21975
01 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: net/mlx5: handle errors in mlx5_chains_create_table() In mlx5_chains_create_table(), the return value of mlx5_get_fdb_sub_ns() and mlx5_get_flow_namespace() must be checked to prevent NULL pointer dereferences. If either function fails, the function should log error message with mlx5_core_warn() and return error pointer. In the Linux kernel, the following vulnerability has been resolved: net/mlx5: handle errors in mlx5_chains_create_table()... • https://git.kernel.org/stable/c/39ac237ce00968545e7298faa9e07ecb7e440fb5 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2025-21972 – net: mctp: unshare packets when reassembling
https://notcve.org/view.php?id=CVE-2025-21972
01 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: net: mctp: unshare packets when reassembling Ensure that the frag_list used for reassembly isn't shared with other packets. This avoids incorrect reassembly when packets are cloned, and prevents a memory leak due to circular references between fragments and their skb_shared_info. The upcoming MCTP-over-USB driver uses skb_clone which can trigger the problem - other MCTP drivers don't share SKBs. A kunit test is added to reproduce the issue.... • https://git.kernel.org/stable/c/4a992bbd365094730a31bae1e12a6ca695336d57 •
CVSS: 9.8EPSS: 0%CPEs: 5EXPL: 0CVE-2025-21971 – net_sched: Prevent creation of classes with TC_H_ROOT
https://notcve.org/view.php?id=CVE-2025-21971
01 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: net_sched: Prevent creation of classes with TC_H_ROOT The function qdisc_tree_reduce_backlog() uses TC_H_ROOT as a termination condition when traversing up the qdisc tree to update parent backlog counters. However, if a class is created with classid TC_H_ROOT, the traversal terminates prematurely at this class instead of reaching the actual root qdisc, causing parent statistics to be incorrectly maintained. In case of DRR, this could lead t... • https://git.kernel.org/stable/c/066a3b5b2346febf9a655b444567b7138e3bb939 •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2025-21970 – net/mlx5: Bridge, fix the crash caused by LAG state check
https://notcve.org/view.php?id=CVE-2025-21970
01 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Bridge, fix the crash caused by LAG state check When removing LAG device from bridge, NETDEV_CHANGEUPPER event is triggered. Driver finds the lower devices (PFs) to flush all the offloaded entries. And mlx5_lag_is_shared_fdb is checked, it returns false if one of PF is unloaded. In such case, mlx5_esw_bridge_lag_rep_get() and its caller return NULL, instead of the alive PF, and the flush is skipped. Besides, the bridge fdb entry's... • https://git.kernel.org/stable/c/ff9b7521468bc2909293c1cda66a245a49688f6f •
CVSS: 9.8EPSS: 0%CPEs: 4EXPL: 0CVE-2025-21969 – Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmd
https://notcve.org/view.php?id=CVE-2025-21969
01 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmd After the hci sync command releases l2cap_conn, the hci receive data work queue references the released l2cap_conn when sending to the upper layer. Add hci dev lock to the hci receive data work queue to synchronize the two. [1] BUG: KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954 Read of size 8 at addr ffff8880271a4000 by task kworker/u9... • https://git.kernel.org/stable/c/c96cce853542b3b13da3738f35ef1be8cfcc9d1d •
CVSS: 9.8EPSS: 0%CPEs: 5EXPL: 0CVE-2025-21968 – drm/amd/display: Fix slab-use-after-free on hdcp_work
https://notcve.org/view.php?id=CVE-2025-21968
01 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix slab-use-after-free on hdcp_work [Why] A slab-use-after-free is reported when HDCP is destroyed but the property_validate_dwork queue is still running. [How] Cancel the delayed work when destroying workqueue. (cherry picked from commit 725a04ba5a95e89c89633d4322430cfbca7ce128) In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix slab-use-after-free on hdcp_work [Why] A slab-use-after-... • https://git.kernel.org/stable/c/da3fd7ac0bcf372cc57117bdfcd725cca7ef975a •