https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-04T00:57:17.188115+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/bdu:2025-14969 bdu:2025-14969 2026-10-04T00:57:17.393524+00:00 bdu:2025-14969 https://cve.radiocsirt.org/vuln/bell-cve-2025-38537 BELL-CVE-2025-38537 2026-10-04T00:57:17.393609+00:00

Affected: Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts

 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0787 certfr-2025-avi-0787 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at… 2026-10-04T00:57:17.393648+00:00 certfr-2025-avi-0787 https://cve.radiocsirt.org/vuln/euvd-2026-314649 EUVD-2026-314649 2026-10-04T00:57:17.393668+00:00 EUVD-2026-314649 https://cve.radiocsirt.org/vuln/fkie_cve-2025-38537 fkie_cve-2025-38537 2026-10-04T00:57:17.393680+00:00

In the Linux kernel, the following vulnerability has been resolved:

net: phy: Don't register LEDs for genphy

If a PHY has no driver, the genphy driver is probed/removed directly in phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the LEDs will be (un)registered when probing/removing the genphy driver. This could occur if the leds are for a non-generic driver that isn't loaded for whatever reason. Synchronously removing the PHY device in phy_detach leads to the following deadlock:

rtnl_lock() ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock()

There is a corresponding deadlock on the open/register side of things (and that one is reported by lockdep), but it requires a race while this one is deterministic.

Generic PHYs do not support LEDs anyway, so don't bother registering them.

 https://cve.radiocsirt.org/vuln/ghsa-wcfp-94c7-jmv4 GHSA-wcfp-94c7-jmv4 2026-10-04T00:57:17.393719+00:00

In the Linux kernel, the following vulnerability has been resolved:

net: phy: Don't register LEDs for genphy

If a PHY has no driver, the genphy driver is probed/removed directly in phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the LEDs will be (un)registered when probing/removing the genphy driver. This could occur if the leds are for a non-generic driver that isn't loaded for whatever reason. Synchronously removing the PHY device in phy_detach leads to the following deadlock:

rtnl_lock() ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock()

There is a corresponding deadlock on the open/register side of things (and that one is reported by lockdep), but it requires a race while this one is deterministic.

Generic PHYs do not support LEDs anyway, so don't bother registering them.

 https://cve.radiocsirt.org/vuln/msrc_cve-2025-38537 msrc_CVE-2025-38537 — net: phy: Don't register LEDs for genphy 2026-10-04T00:57:17.393745+00:00 msrc_CVE-2025-38537 https://cve.radiocsirt.org/vuln/opensuse-su-2026:20287-1 openSUSE-SU-2026:20287-1 — Security update for the Linux Kernel 2026-10-04T00:57:17.393762+00:00

Security update for the Linux Kernel

 https://cve.radiocsirt.org/vuln/suse-su-2025:03272-1 SUSE-SU-2025:03272-1 — Security update for the Linux Kernel 2026-10-04T00:57:17.393900+00:00

Security update for the Linux Kernel

 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-38537 UBUNTU-CVE-2025-38537 2026-10-04T00:57:17.393971+00:00

Affected: Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 123 more

In the Linux kernel, the following vulnerability has been resolved: net: phy: Don't register LEDs for genphy If a PHY has no driver, the genphy driver is probed/removed directly in phy_attach/detach. If the PHY's ofnode has an "leds" subnode, then the LEDs will be (un)registered when probing/removing the genphy driver. This could occur if the leds are for a non-generic driver that isn't loaded for whatever reason. Synchronously removing the PHY device in phy_detach leads to the following deadlock: rtnl_lock() ndo_close() ... phy_detach() phy_remove() phy_leds_unregister() led_classdev_unregister() led_trigger_set() netdev_trigger_deactivate() unregister_netdevice_notifier() rtnl_lock() There is a corresponding deadlock on the open/register side of things (and that one is reported by lockdep), but it requires a race while this one is deterministic. Generic PHYs do not support LEDs anyway, so don't bother registering them.

 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1858 WID-SEC-W-2025-1858 — Linux Kernel: Mehrere Schwachstellen 2026-10-04T00:57:17.394162+00:00

Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht spezifizierte Angriffe durchzuführen.