Most recent entries from all

Most recent entries from all https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 16:42:25 +0000 bdu:2025-11910 https://cve.radiocsirt.org/vuln/bdu:2025-11910 bdu:2025-11910 https://cve.radiocsirt.org/vuln/bdu:2025-11910 BELL-CVE-2025-22059 https://cve.radiocsirt.org/vuln/bell-cve-2025-22059 <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2025-22059 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… https://cve.radiocsirt.org/vuln/certfr-2025-avi-0559 certfr-2025-avi-0559 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0559 EUVD-2026-346762 https://cve.radiocsirt.org/vuln/euvd-2026-346762 EUVD-2026-346762 https://cve.radiocsirt.org/vuln/euvd-2026-346762 fkie_cve-2025-22059 https://cve.radiocsirt.org/vuln/fkie_cve-2025-22059 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>udp: Fix multiple wraparounds of sk->sk_rmem_alloc.</p> <p>__udp_enqueue_schedule_skb() has the following condition:</p> <p>if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) goto drop;</p> <p>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.</p> <p>If we set INT_MAX to sk->sk_rcvbuf, the condition is always false as sk->sk_rmem_alloc is also signed int.</p> <p>Then, the size of the incoming skb is added to sk->sk_rmem_alloc unconditionally.</p> <p>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].</p> <p>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:</p> <p># 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)</p> <p>Previously, we had a boundary check for INT_MAX, which was removed by commit 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc").</p> <p>A complete fix would be to revert it and cap the right operand by INT_MAX:</p> <p>rmem = atomic_add_return(size, &sk->sk_rm…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>udp: Fix multiple wraparounds of sk->sk_rmem_alloc.</p> <p>__udp_enqueue_schedule_skb() has the following condition:</p> <p>if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) goto drop;</p> <p>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.</p> <p>If we set INT_MAX to sk->sk_rcvbuf, the condition is always false as sk->sk_rmem_alloc is also signed int.</p> <p>Then, the size of the incoming skb is added to sk->sk_rmem_alloc unconditionally.</p> <p>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].</p> <p>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:</p> <p># 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)</p> <p>Previously, we had a boundary check for INT_MAX, which was removed by commit 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc").</p> <p>A complete fix would be to revert it and cap the right operand by INT_MAX:</p> <p>rmem = atomic_add_return(size, &sk->sk_rm…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-22059 GHSA-h26m-qmpx-mvhh https://cve.radiocsirt.org/vuln/ghsa-h26m-qmpx-mvhh <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>udp: Fix multiple wraparounds of sk->sk_rmem_alloc.</p> <p>__udp_enqueue_schedule_skb() has the following condition:</p> <p>if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) goto drop;</p> <p>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.</p> <p>If we set INT_MAX to sk->sk_rcvbuf, the condition is always false as sk->sk_rmem_alloc is also signed int.</p> <p>Then, the size of the incoming skb is added to sk->sk_rmem_alloc unconditionally.</p> <p>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].</p> <p>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:</p> <p># 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)</p> <p>Previously, we had a boundary check for INT_MAX, which was removed by commit 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc").</p> <p>A complete fix would be to revert it and cap the right operand by INT_MAX:</p> <p>rmem = atomic_add_return(size, &sk->sk_rm…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>udp: Fix multiple wraparounds of sk->sk_rmem_alloc.</p> <p>__udp_enqueue_schedule_skb() has the following condition:</p> <p>if (atomic_read(&sk->sk_rmem_alloc) > sk->sk_rcvbuf) goto drop;</p> <p>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.</p> <p>If we set INT_MAX to sk->sk_rcvbuf, the condition is always false as sk->sk_rmem_alloc is also signed int.</p> <p>Then, the size of the incoming skb is added to sk->sk_rmem_alloc unconditionally.</p> <p>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].</p> <p>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:</p> <p># 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)</p> <p>Previously, we had a boundary check for INT_MAX, which was removed by commit 6a1f12dd85a8 ("udp: relax atomic operation on sk->sk_rmem_alloc").</p> <p>A complete fix would be to revert it and cap the right operand by INT_MAX:</p> <p>rmem = atomic_add_return(size, &sk->sk_rm…</p> https://cve.radiocsirt.org/vuln/ghsa-h26m-qmpx-mvhh UBUNTU-CVE-2025-22059 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-22059 <p><strong>Affected:</strong> 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</p> <p>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);…</p> <p><strong>Affected:</strong> 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</p> <p>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);…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-22059 WID-SEC-W-2025-0844 — Linux Kernel: Mehrere Schwachstellen https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0844 <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht genauer beschriebene Auswirkungen erzielen.</p> <p>Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere, nicht genauer beschriebene Auswirkungen erzielen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0844