https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-03T17:42:48.787117+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/bell-cve-2026-74401 BELL-CVE-2026-74401 2026-10-03T17:42:48.887425+00:00

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

 https://cve.radiocsirt.org/vuln/certfr-2026-avi-1203 certfr-2026-avi-1203 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Elles permettent à un attaquant de provoq… 2026-10-03T17:42:48.887494+00:00 certfr-2026-avi-1203 https://cve.radiocsirt.org/vuln/euvd-2026-354210 EUVD-2026-354210 2026-10-03T17:42:48.887513+00:00 EUVD-2026-354210 https://cve.radiocsirt.org/vuln/fkie_cve-2026-74401 fkie_cve-2026-74401 2026-10-03T17:42:48.887525+00:00

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

dlm: fix add msg handle in send_queue ordered

In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as "before(mh->seq, seq)" will stop to check for older sequence numbers that are ordered in the tail of "node->send_queue".

The side effects of not having it correct ordered regarding "before(mh->seq, seq)" are refcounting issues and use-after free.

I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.

 https://cve.radiocsirt.org/vuln/ghsa-wgc9-j6gh-934m GHSA-wgc9-j6gh-934m 2026-10-03T17:42:48.887557+00:00

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

dlm: fix add msg handle in send_queue ordered

In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as "before(mh->seq, seq)" will stop to check for older sequence numbers that are ordered in the tail of "node->send_queue".

The side effects of not having it correct ordered regarding "before(mh->seq, seq)" are refcounting issues and use-after free.

I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.

 https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-74401 UBUNTU-CVE-2026-74401 2026-10-03T17:42:48.887579+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 193 more

In the Linux kernel, the following vulnerability has been resolved: dlm: fix add msg handle in send_queue ordered In a benchmark scenario triggering a lot of requests that triggers a lot of DLM messages on the network it can be that the mh->seq is not ordered according the oldest seq number. This ordering is required by dlm_receive_ack as "before(mh->seq, seq)" will stop to check for older sequence numbers that are ordered in the tail of "node->send_queue". The side effects of not having it correct ordered regarding "before(mh->seq, seq)" are refcounting issues and use-after free. I only was able to reproduce this issue in a experimental DLM branch and a user space DLM benchmark that uses io_uring. After changing this I don't experienced any refcounting with the sending buffer issues anymore.

 https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2852 WID-SEC-W-2026-2852 — Linux Kernel: Mehrere Schwachstellen 2026-10-03T17:42:48.887790+00:00

Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um root Rechte zu erlangen, um einen Denial of Service herbeizuführen oder einen nicht näher spezifizierten Angriff durchzuführen.