https://cve.radiocsirt.org/rss/recent/all/10 Most recent entries from all 2026-10-03T14:21:49.849145+00:00 Vulnerability-Lookup csirt@opendfir.org python-feedgen Contains only the most 10 recent entries. https://cve.radiocsirt.org/vuln/bdu:2025-11910 bdu:2025-11910 2026-10-03T14:21:49.983761+00:00 bdu:2025-11910 https://cve.radiocsirt.org/vuln/bell-cve-2025-22059 BELL-CVE-2025-22059 2026-10-03T14:21:49.983802+00:00

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

 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0559 certfr-2025-avi-0559 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a… 2026-10-03T14:21:49.983832+00:00 certfr-2025-avi-0559 https://cve.radiocsirt.org/vuln/euvd-2026-346762 EUVD-2026-346762 2026-10-03T14:21:49.983850+00:00 EUVD-2026-346762 https://cve.radiocsirt.org/vuln/fkie_cve-2025-22059 fkie_cve-2025-22059 2026-10-03T14:21:49.983861+00:00

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

udp: Fix multiple wraparounds of sk->sk_rmem_alloc.

__udp_enqueue_schedule_skb() has the following condition:

if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) goto drop;

sk->sk_rcvbuf is initialised by net.core.rmem_default and later can be configured by SO_RCVBUF, which is limited by net.core.rmem_max, or SO_RCVBUFFORCE.

If we set INT_MAX to sk->sk_rcvbuf, the condition is always false as sk->sk_rmem_alloc is also signed int.

Then, the size of the incoming skb is added to sk->sk_rmem_alloc unconditionally.

This results in integer overflow (possibly multiple times) on sk->sk_rmem_alloc and allows a single socket to have skb up to net.core.udp_mem[1].

For example, if we set a large value to udp_mem[1] and INT_MAX to sk->sk_rcvbuf and flood packets to the socket, we can see multiple overflows:

# cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 7956736 <-- (7956736 << 12) bytes > INT_MAX * 15 ^- PAGE_SHIFT # ss -uam State Recv-Q ... UNCONN -1757018048 ... <-- flipping the sign repeatedly skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0)

Previously, we had a boundary check for INT_MAX, which was removed by commit 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc").

A complete fix would be to revert it and cap the right operand by INT_MAX:

rmem = atomic_add_return(size, &sk->sk_rm…

 https://cve.radiocsirt.org/vuln/ghsa-h26m-qmpx-mvhh GHSA-h26m-qmpx-mvhh 2026-10-03T14:21:49.983916+00:00

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

udp: Fix multiple wraparounds of sk->sk_rmem_alloc.

__udp_enqueue_schedule_skb() has the following condition:

if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) goto drop;

sk->sk_rcvbuf is initialised by net.core.rmem_default and later can be configured by SO_RCVBUF, which is limited by net.core.rmem_max, or SO_RCVBUFFORCE.

If we set INT_MAX to sk->sk_rcvbuf, the condition is always false as sk->sk_rmem_alloc is also signed int.

Then, the size of the incoming skb is added to sk->sk_rmem_alloc unconditionally.

This results in integer overflow (possibly multiple times) on sk->sk_rmem_alloc and allows a single socket to have skb up to net.core.udp_mem[1].

For example, if we set a large value to udp_mem[1] and INT_MAX to sk->sk_rcvbuf and flood packets to the socket, we can see multiple overflows:

# cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 7956736 <-- (7956736 << 12) bytes > INT_MAX * 15 ^- PAGE_SHIFT # ss -uam State Recv-Q ... UNCONN -1757018048 ... <-- flipping the sign repeatedly skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0)

Previously, we had a boundary check for INT_MAX, which was removed by commit 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc").

A complete fix would be to revert it and cap the right operand by INT_MAX:

rmem = atomic_add_return(size, &sk->sk_rm…

 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-22059 UBUNTU-CVE-2025-22059 2026-10-03T14:21:49.983958+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 77 more

In the Linux kernel, the following vulnerability has been resolved: udp: Fix multiple wraparounds of sk->sk_rmem_alloc. __udp_enqueue_schedule_skb() has the following condition: if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) goto drop; sk->sk_rcvbuf is initialised by net.core.rmem_default and later can be configured by SO_RCVBUF, which is limited by net.core.rmem_max, or SO_RCVBUFFORCE. If we set INT_MAX to sk->sk_rcvbuf, the condition is always false as sk->sk_rmem_alloc is also signed int. Then, the size of the incoming skb is added to sk->sk_rmem_alloc unconditionally. This results in integer overflow (possibly multiple times) on sk->sk_rmem_alloc and allows a single socket to have skb up to net.core.udp_mem[1]. For example, if we set a large value to udp_mem[1] and INT_MAX to sk->sk_rcvbuf and flood packets to the socket, we can see multiple overflows: # cat /proc/net/sockstat | grep UDP: UDP: inuse 3 mem 7956736 <-- (7956736 << 12) bytes > INT_MAX * 15 ^- PAGE_SHIFT # ss -uam State Recv-Q ... UNCONN -1757018048 ... <-- flipping the sign repeatedly skmem:(r2537949248,rb2147483646,t0,tb212992,f1984,w0,o0,bl0,d0) Previously, we had a boundary check for INT_MAX, which was removed by commit 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc"). A complete fix would be to revert it and cap the right operand by INT_MAX: rmem = atomic_add_return(size, &sk->sk_rmem_alloc);…

 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0844 WID-SEC-W-2025-0844 — Linux Kernel: Mehrere Schwachstellen 2026-10-03T14:21:49.984102+00:00

Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht genauer beschriebene Auswirkungen erzielen.