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 05:04:19 +0000 bdu:2025-15289 https://cve.radiocsirt.org/vuln/bdu:2025-15289 bdu:2025-15289 https://cve.radiocsirt.org/vuln/bdu:2025-15289 BELL-CVE-2025-39828 https://cve.radiocsirt.org/vuln/bell-cve-2025-39828 <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p> https://cve.radiocsirt.org/vuln/bell-cve-2025-39828 certfr-2025-avi-0825 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo… https://cve.radiocsirt.org/vuln/certfr-2025-avi-0825 certfr-2025-avi-0825 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0825 EUVD-2026-317166 https://cve.radiocsirt.org/vuln/euvd-2026-317166 EUVD-2026-317166 https://cve.radiocsirt.org/vuln/euvd-2026-317166 fkie_cve-2025-39828 https://cve.radiocsirt.org/vuln/fkie_cve-2025-39828 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().</p> <p>syzbot reported the splat below. [0]</p> <p>When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message.</p> <p>The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.</p> <p>The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer.</p> <p>struct atmtcp_control { struct atmtcp_hdr hdr; /* must be first */ ... atm_kptr_t vcc; /* both directions */ ... } __ATM_API_ALIGN;</p> <p>typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;</p> <p>The special message is processed in atmtcp_recv_control() called from atmtcp_c_send().</p> <p>atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths:</p> <p>1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg()</p> <p>The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control.</p> <p>Let's add a new ->pre_send() hook to validate messages from sendmsg().</p> <p>[0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gb…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().</p> <p>syzbot reported the splat below. [0]</p> <p>When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message.</p> <p>The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.</p> <p>The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer.</p> <p>struct atmtcp_control { struct atmtcp_hdr hdr; /* must be first */ ... atm_kptr_t vcc; /* both directions */ ... } __ATM_API_ALIGN;</p> <p>typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;</p> <p>The special message is processed in atmtcp_recv_control() called from atmtcp_c_send().</p> <p>atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths:</p> <p>1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg()</p> <p>The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control.</p> <p>Let's add a new ->pre_send() hook to validate messages from sendmsg().</p> <p>[0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gb…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-39828 GHSA-2v5c-9mj7-vp9g https://cve.radiocsirt.org/vuln/ghsa-2v5c-9mj7-vp9g <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().</p> <p>syzbot reported the splat below. [0]</p> <p>When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message.</p> <p>The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.</p> <p>The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer.</p> <p>struct atmtcp_control { struct atmtcp_hdr hdr; /* must be first */ ... atm_kptr_t vcc; /* both directions */ ... } __ATM_API_ALIGN;</p> <p>typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;</p> <p>The special message is processed in atmtcp_recv_control() called from atmtcp_c_send().</p> <p>atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths:</p> <p>1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg()</p> <p>The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control.</p> <p>Let's add a new ->pre_send() hook to validate messages from sendmsg().</p> <p>[0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gb…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control().</p> <p>syzbot reported the splat below. [0]</p> <p>When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message.</p> <p>The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc.</p> <p>The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer.</p> <p>struct atmtcp_control { struct atmtcp_hdr hdr; /* must be first */ ... atm_kptr_t vcc; /* both directions */ ... } __ATM_API_ALIGN;</p> <p>typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t;</p> <p>The special message is processed in atmtcp_recv_control() called from atmtcp_c_send().</p> <p>atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths:</p> <p>1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg()</p> <p>The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control.</p> <p>Let's add a new ->pre_send() hook to validate messages from sendmsg().</p> <p>[0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gb…</p> https://cve.radiocsirt.org/vuln/ghsa-2v5c-9mj7-vp9g ICSA-26-134-10 — Siemens SIMATIC https://cve.radiocsirt.org/vuln/icsa-26-134-10 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:</p> <p>fs: relax assertions on failure to encode file handles</p> <p>Encoding file handles is usually performed by a filesystem >encode_fh() method that may fail for various reasons.</p> <p>The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle.</p> <p>There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when ->encode_fh() fails. Relax those assertions because they are wrong.</p> <p>The second linked bug report states commit 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles") in v6.6 as the regressing commit, but this is not accurate.</p> <p>The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches.</p> <p>Triggering this assertion was always possible with other filesystems and other reasons of ->encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlay…</p> <p>In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:</p> <p>fs: relax assertions on failure to encode file handles</p> <p>Encoding file handles is usually performed by a filesystem >encode_fh() method that may fail for various reasons.</p> <p>The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle.</p> <p>There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when ->encode_fh() fails. Relax those assertions because they are wrong.</p> <p>The second linked bug report states commit 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles") in v6.6 as the regressing commit, but this is not accurate.</p> <p>The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches.</p> <p>Triggering this assertion was always possible with other filesystems and other reasons of ->encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlay…</p> https://cve.radiocsirt.org/vuln/icsa-26-134-10 msrc_CVE-2025-39828 — atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control(). https://cve.radiocsirt.org/vuln/msrc_cve-2025-39828 msrc_CVE-2025-39828 https://cve.radiocsirt.org/vuln/msrc_cve-2025-39828 NCSC-2026-0147 — Kwetsbaarheden verholpen in Siemens-producten https://cve.radiocsirt.org/vuln/ncsc-2026-0147 NCSC-2026-0147 https://cve.radiocsirt.org/vuln/ncsc-2026-0147 OESA-2026-1303 — kernel security update https://cve.radiocsirt.org/vuln/oesa-2026-1303 <p><strong>Affected:</strong> openEuler:24.03-LTS: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()</p> <p>Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page() to increase test coverage.</p> <p>syzbot found a splat caused by hard irq blocking in ptr_ring_resize_multiple() [1]</p> <p>As current users of ptr_ring_resize_multiple() do not require hard irqs being masked, replace it to only block BH.</p> <p>Rename helpers to better reflect they are safe against BH only.</p> <p>- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh() - skb_array_resize_multiple() to skb_array_resize_multiple_bh()</p> <p>[1]</p> <p>WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline] WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Modules linked in: CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline] RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 &lt;0f&gt; 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85 RSP:…</p> <p><strong>Affected:</strong> openEuler:24.03-LTS: kernel</p> <p>The Linux Kernel, the operating system core itself. Security Fix(es):</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>ptr_ring: do not block hard interrupts in ptr_ring_resize_multiple()</p> <p>Jakub added a lockdep_assert_no_hardirq() check in __page_pool_put_page() to increase test coverage.</p> <p>syzbot found a splat caused by hard irq blocking in ptr_ring_resize_multiple() [1]</p> <p>As current users of ptr_ring_resize_multiple() do not require hard irqs being masked, replace it to only block BH.</p> <p>Rename helpers to better reflect they are safe against BH only.</p> <p>- ptr_ring_resize_multiple() to ptr_ring_resize_multiple_bh() - skb_array_resize_multiple() to skb_array_resize_multiple_bh()</p> <p>[1]</p> <p>WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 __page_pool_put_page net/core/page_pool.c:709 [inline] WARNING: CPU: 1 PID: 9150 at net/core/page_pool.c:709 page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Modules linked in: CPU: 1 UID: 0 PID: 9150 Comm: syz.1.1052 Not tainted 6.11.0-rc3-syzkaller-00202-gf8669d7b5f5d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 RIP: 0010:__page_pool_put_page net/core/page_pool.c:709 [inline] RIP: 0010:page_pool_put_unrefed_netmem+0x157/0xa40 net/core/page_pool.c:780 Code: 74 0e e8 7c aa fb f7 eb 43 e8 75 aa fb f7 eb 3c 65 8b 1d 38 a8 6a 76 31 ff 89 de e8 a3 ae fb f7 85 db 74 0b e8 5a aa fb f7 90 &lt;0f&gt; 0b 90 eb 1d 65 8b 1d 15 a8 6a 76 31 ff 89 de e8 84 ae fb f7 85 RSP:…</p> https://cve.radiocsirt.org/vuln/oesa-2026-1303 openSUSE-SU-2025:20081-1 — Security update for the Linux Kernel https://cve.radiocsirt.org/vuln/opensuse-su-2025:20081-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/opensuse-su-2025:20081-1 SSA-032379 — SSA-032379: Multiple Vulnerabilities in SIMATIC CN 4100 Before V5.0 https://cve.radiocsirt.org/vuln/ssa-032379 <p>In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:</p> <p>fs: relax assertions on failure to encode file handles</p> <p>Encoding file handles is usually performed by a filesystem >encode_fh() method that may fail for various reasons.</p> <p>The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle.</p> <p>There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when ->encode_fh() fails. Relax those assertions because they are wrong.</p> <p>The second linked bug report states commit 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles") in v6.6 as the regressing commit, but this is not accurate.</p> <p>The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches.</p> <p>Triggering this assertion was always possible with other filesystems and other reasons of ->encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlay…</p> <p>In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Check link_res->hpo_dp_link_enc before using it [WHAT & HOW] Functions dp_enable_link_phy and dp_disable_link_phy can pass link_res without initializing hpo_dp_link_enc and it is necessary to check for null before dereferencing. This fixes 2 FORWARD_NULL issues reported by Coverity. In the Linux kernel, the following vulnerability has been resolved:</p> <p>fs: relax assertions on failure to encode file handles</p> <p>Encoding file handles is usually performed by a filesystem >encode_fh() method that may fail for various reasons.</p> <p>The legacy users of exportfs_encode_fh(), namely, nfsd and name_to_handle_at(2) syscall are ready to cope with the possibility of failure to encode a file handle.</p> <p>There are a few other users of exportfs_encode_{fh,fid}() that currently have a WARN_ON() assertion when ->encode_fh() fails. Relax those assertions because they are wrong.</p> <p>The second linked bug report states commit 16aac5ad1fa9 ("ovl: support encoding non-decodable file handles") in v6.6 as the regressing commit, but this is not accurate.</p> <p>The aforementioned commit only increases the chances of the assertion and allows triggering the assertion with the reproducer using overlayfs, inotify and drop_caches.</p> <p>Triggering this assertion was always possible with other filesystems and other reasons of ->encode_fh() failures and more particularly, it was also possible with the exact same reproducer using overlay…</p> https://cve.radiocsirt.org/vuln/ssa-032379 SUSE-SU-2025:03634-1 — Security update for the Linux Kernel https://cve.radiocsirt.org/vuln/suse-su-2025:03634-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2025:03634-1 UBUNTU-CVE-2025-39828 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39828 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 215 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control(). syzbot reported the splat below. [0] When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message. The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc. The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer. struct atmtcp_control { struct atmtcp_hdr hdr; /* must be first */ ... atm_kptr_t vcc; /* both directions */ ... } __ATM_API_ALIGN; typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t; The special message is processed in atmtcp_recv_control() called from atmtcp_c_send(). atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths: 1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg() The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control. Let's add a new ->pre_send() hook to validate messages from sendmsg(). [0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #…</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 215 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: atm: atmtcp: Prevent arbitrary write in atmtcp_recv_control(). syzbot reported the splat below. [0] When atmtcp_v_open() or atmtcp_v_close() is called via connect() or close(), atmtcp_send_control() is called to send an in-kernel special message. The message has ATMTCP_HDR_MAGIC in atmtcp_control.hdr.length. Also, a pointer of struct atm_vcc is set to atmtcp_control.vcc. The notable thing is struct atmtcp_control is uAPI but has a space for an in-kernel pointer. struct atmtcp_control { struct atmtcp_hdr hdr; /* must be first */ ... atm_kptr_t vcc; /* both directions */ ... } __ATM_API_ALIGN; typedef struct { unsigned char _[8]; } __ATM_API_ALIGN atm_kptr_t; The special message is processed in atmtcp_recv_control() called from atmtcp_c_send(). atmtcp_c_send() is vcc->dev->ops->send() and called from 2 paths: 1. .ndo_start_xmit() (vcc->send() == atm_send_aal0()) 2. vcc_sendmsg() The problem is sendmsg() does not validate the message length and userspace can abuse atmtcp_recv_control() to overwrite any kptr by atmtcp_control. Let's add a new ->pre_send() hook to validate messages from sendmsg(). [0]: Oops: general protection fault, probably for non-canonical address 0xdffffc00200000ab: 0000 [#1] SMP KASAN PTI KASAN: probably user-memory-access in range [0x0000000100000558-0x000000010000055f] CPU: 0 UID: 0 PID: 5865 Comm: syz-executor331 Not tainted 6.17.0-rc1-syzkaller-00215-gbab3ce404553 #…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-39828 WID-SEC-W-2025-2077 — Linux Kernel: Mehrere Schwachstellen https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2077 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder nicht näher beschriebene Auswirkungen zu erzielen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2077