CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2025-21986 – net: switchdev: Convert blocking notification chain to a raw one
https://notcve.org/view.php?id=CVE-2025-21986
01 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: net: switchdev: Convert blocking notification chain to a raw one A blocking notification chain uses a read-write semaphore to protect the integrity of the chain. The semaphore is acquired for writing when adding / removing notifiers to / from the chain and acquired for reading when traversing the chain and informing notifiers about an event. In case of the blocking switchdev notification chain, recursive notifications are possible which lea... • https://git.kernel.org/stable/c/91ac2c79e896b28a4a3a262384689ee6dfeaf083 •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2025-21985 – drm/amd/display: Fix out-of-bound accesses
https://notcve.org/view.php?id=CVE-2025-21985
01 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bound accesses [WHAT & HOW] hpo_stream_to_link_encoder_mapping has size MAX_HPO_DP2_ENCODERS(=4), but location can have size up to 6. As a result, it is necessary to check location against MAX_HPO_DP2_ENCODERS. Similiarly, disp_cfg_stream_location can be used as an array index which should be 0..5, so the ASSERT's conditions should be less without equal. • https://git.kernel.org/stable/c/36793d90d76f667d26c6dd025571481ee0c96abc •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2025-21984 – mm: fix kernel BUG when userfaultfd_move encounters swapcache
https://notcve.org/view.php?id=CVE-2025-21984
01 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: mm: fix kernel BUG when userfaultfd_move encounters swapcache userfaultfd_move() checks whether the PTE entry is present or a swap entry. - If the PTE entry is present, move_present_pte() handles folio migration by setting: src_folio->index = linear_page_index(dst_vma, dst_addr); - If the PTE entry is a swap entry, move_swap_pte() simply copies the PTE to the new dst_addr. This approach is incorrect because, even if the PTE is a swap entry,... • https://git.kernel.org/stable/c/adef440691bab824e39c1b17382322d195e1fab0 •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2025-21982 – pinctrl: nuvoton: npcm8xx: Add NULL check in npcm8xx_gpio_fw
https://notcve.org/view.php?id=CVE-2025-21982
01 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: npcm8xx: Add NULL check in npcm8xx_gpio_fw devm_kasprintf() calls can return null pointers on failure. But the return values were not checked in npcm8xx_gpio_fw(). Add NULL check in npcm8xx_gpio_fw(), to handle kernel NULL pointer dereference error. • https://git.kernel.org/stable/c/acf4884a571709cad99f98aabe08b7cacd62dc80 •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2025-21981 – ice: fix memory leak in aRFS after reset
https://notcve.org/view.php?id=CVE-2025-21981
01 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: ice: fix memory leak in aRFS after reset Fix aRFS (accelerated Receive Flow Steering) structures memory leak by adding a checker to verify if aRFS memory is already allocated while configuring VSI. aRFS objects are allocated in two cases: - as part of VSI initialization (at probe), and - as part of reset handling However, VSI reconfiguration executed during reset involves memory allocation one more time, without prior releasing already allo... • https://git.kernel.org/stable/c/28bf26724fdb0e02267d19e280d6717ee810a10d •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2025-21980 – sched: address a potential NULL pointer dereference in the GRED scheduler.
https://notcve.org/view.php?id=CVE-2025-21980
01 Apr 2025 — In the Linux kernel, the following vulnerability has been resolved: sched: address a potential NULL pointer dereference in the GRED scheduler. If kzalloc in gred_init returns a NULL pointer, the code follows the error handling path, invoking gred_destroy. This, in turn, calls gred_offload, where memset could receive a NULL pointer as input, potentially leading to a kernel crash. When table->opt is NULL in gred_init(), gred_change_table_def() is not called yet, so it is not necessary to call ->ndo_setup_tc()... • https://git.kernel.org/stable/c/f25c0515c521375154c62c72447869f40218c861 •
CVSS: -EPSS: %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: -EPSS: %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: -EPSS: %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: -EPSS: %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]