https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-03T15:03:58.667169+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/bdu:2025-09144 bdu:2025-09144 2026-10-03T15:03:59.220478+00:00 bdu:2025-09144 https://cve.radiocsirt.org/vuln/bell-cve-2025-38376 BELL-CVE-2025-38376 2026-10-03T15:03:59.220544+00:00

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

 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0723 certfr-2025-avi-0723 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at… 2026-10-03T15:03:59.220576+00:00 certfr-2025-avi-0723 https://cve.radiocsirt.org/vuln/euvd-2026-314572 EUVD-2026-314572 2026-10-03T15:03:59.220594+00:00 EUVD-2026-314572 https://cve.radiocsirt.org/vuln/fkie_cve-2025-38376 fkie_cve-2025-38376 2026-10-03T15:03:59.220606+00:00

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

usb: chipidea: udc: disconnect/reconnect from host when do suspend/resume

Shawn and John reported a hang issue during system suspend as below:

- USB gadget is enabled as Ethernet - There is data transfer over USB Ethernet (scp a big file between host and device) - Device is going in/out suspend (echo mem > /sys/power/state)

The root cause is the USB device controller is suspended but the USB bus is still active which caused the USB host continues to transfer data with device and the device continues to queue USB requests (in this case, a delayed TCP ACK packet trigger the issue) after controller is suspended, however the USB controller clock is already gated off. Then if udc driver access registers after that point, the system will hang.

The correct way to avoid such issue is to disconnect device from host when the USB bus is not at suspend state. Then the host will receive disconnect event and stop data transfer in time. To continue make USB gadget device work after system resume, this will reconnect device automatically.

To make usb wakeup work if USB bus is already at suspend state, this will keep connection for it only when USB device controller has enabled wakeup capability.

 https://cve.radiocsirt.org/vuln/ghsa-q9hc-qj7m-hpc9 GHSA-q9hc-qj7m-hpc9 2026-10-03T15:03:59.220644+00:00

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

usb: chipidea: udc: disconnect/reconnect from host when do suspend/resume

Shawn and John reported a hang issue during system suspend as below:

- USB gadget is enabled as Ethernet - There is data transfer over USB Ethernet (scp a big file between host and device) - Device is going in/out suspend (echo mem > /sys/power/state)

The root cause is the USB device controller is suspended but the USB bus is still active which caused the USB host continues to transfer data with device and the device continues to queue USB requests (in this case, a delayed TCP ACK packet trigger the issue) after controller is suspended, however the USB controller clock is already gated off. Then if udc driver access registers after that point, the system will hang.

The correct way to avoid such issue is to disconnect device from host when the USB bus is not at suspend state. Then the host will receive disconnect event and stop data transfer in time. To continue make USB gadget device work after system resume, this will reconnect device automatically.

To make usb wakeup work if USB bus is already at suspend state, this will keep connection for it only when USB device controller has enabled wakeup capability.

 https://cve.radiocsirt.org/vuln/msrc_cve-2025-38376 msrc_CVE-2025-38376 — usb: chipidea: udc: disconnect/reconnect from host when do suspend/resume 2026-10-03T15:03:59.220671+00:00 msrc_CVE-2025-38376 https://cve.radiocsirt.org/vuln/opensuse-su-2025:20081-1 openSUSE-SU-2025:20081-1 — Security update for the Linux Kernel 2026-10-03T15:03:59.220688+00:00

Security update for the Linux Kernel

 https://cve.radiocsirt.org/vuln/suse-su-2025:02853-1 SUSE-SU-2025:02853-1 — Security update for the Linux Kernel 2026-10-03T15:03:59.221014+00:00

Security update for the Linux Kernel

 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-38376 UBUNTU-CVE-2025-38376 2026-10-03T15:03:59.221171+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 122 more

In the Linux kernel, the following vulnerability has been resolved: usb: chipidea: udc: disconnect/reconnect from host when do suspend/resume Shawn and John reported a hang issue during system suspend as below: - USB gadget is enabled as Ethernet - There is data transfer over USB Ethernet (scp a big file between host and device) - Device is going in/out suspend (echo mem > /sys/power/state) The root cause is the USB device controller is suspended but the USB bus is still active which caused the USB host continues to transfer data with device and the device continues to queue USB requests (in this case, a delayed TCP ACK packet trigger the issue) after controller is suspended, however the USB controller clock is already gated off. Then if udc driver access registers after that point, the system will hang. The correct way to avoid such issue is to disconnect device from host when the USB bus is not at suspend state. Then the host will receive disconnect event and stop data transfer in time. To continue make USB gadget device work after system resume, this will reconnect device automatically. To make usb wakeup work if USB bus is already at suspend state, this will keep connection for it only when USB device controller has enabled wakeup capability.

 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-1653 WID-SEC-W-2025-1653 — Linux Kernel: Mehrere Schwachstellen 2026-10-03T15:03:59.221333+00:00

Ein entfernter anonymer Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um einen Denial-of-Service-Zustand zu erzeugen oder andere nicht spezifizierte Angriffe durchzuführen.