https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 08:19:22 +0000 https://cve.radiocsirt.org/vuln/alsa-2025:20095 <p><strong>Affected:</strong> AlmaLinux:10: kernel, AlmaLinux:10: kernel-64k, AlmaLinux:10: kernel-64k-core, AlmaLinux:10: kernel-64k-debug, AlmaLinux:10: kernel-64k-debug-core, AlmaLinux:10: kernel-64k-debug-devel, AlmaLinux:10: kernel-64k-debug-devel-matched, AlmaLinux:10: kernel-64k-debug-modules, AlmaLinux:10: kernel-64k-debug-modules-core, AlmaLinux:10: kernel-64k-debug-modules-extra and 65 more</p> <p>The kernel packages contain the Linux kernel, the core of any Linux operating system.</p> <p>Security Fix(es):</p> <p>* kernel: xen: Xen hypercall page unsafe against speculative attacks (Xen Security Advisory 466) (CVE-2024-53241) * kernel: exfat: fix out-of-bounds access of directory entries (CVE-2024-53147) * kernel: zram: fix NULL pointer in comp_algorithm_show() (CVE-2024-53222) * kernel: nfsd: release svc_expkey/svc_export with rcu_work (CVE-2024-53216) * kernel: acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl (CVE-2024-56662) * kernel: bpf: Fix UAF via mismatching bpf_prog/attachment RCU flavors (CVE-2024-56675) * kernel: crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY (CVE-2024-56690) * kernel: igb: Fix potential invalid memory access in igb_init_module() (CVE-2024-52332) * kernel: af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK (CVE-2024-57901) * kernel: af_packet: fix vlan_get_tci() vs MSG_PEEK (CVE-2024-57902) * kernel: io_uring/sqpoll: zero sqd-&gt;thread on tctx errors (CVE-2025-21633) * kernel: ipvlan: Fix use-after-free in ipvlan_get_iflink(). (CVE-2025-21652) * kernel: sched: sch_cake: add bounds checks to host bulk flow fairness counts (CVE-2025-21647) * kernel: io_uring/eventfd: ensure io_eventfd_signal() defers another RCU period (CVE-2025-21655) * kernel: netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled (CVE-2024-57941) * kernel: netfs: Fix ceph copy to cache…</p> <p><strong>Affected:</strong> AlmaLinux:10: kernel, AlmaLinux:10: kernel-64k, AlmaLinux:10: kernel-64k-core, AlmaLinux:10: kernel-64k-debug, AlmaLinux:10: kernel-64k-debug-core, AlmaLinux:10: kernel-64k-debug-devel, AlmaLinux:10: kernel-64k-debug-devel-matched, AlmaLinux:10: kernel-64k-debug-modules, AlmaLinux:10: kernel-64k-debug-modules-core, AlmaLinux:10: kernel-64k-debug-modules-extra and 65 more</p> <p>The kernel packages contain the Linux kernel, the core of any Linux operating system.</p> <p>Security Fix(es):</p> <p>* kernel: xen: Xen hypercall page unsafe against speculative attacks (Xen Security Advisory 466) (CVE-2024-53241) * kernel: exfat: fix out-of-bounds access of directory entries (CVE-2024-53147) * kernel: zram: fix NULL pointer in comp_algorithm_show() (CVE-2024-53222) * kernel: nfsd: release svc_expkey/svc_export with rcu_work (CVE-2024-53216) * kernel: acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl (CVE-2024-56662) * kernel: bpf: Fix UAF via mismatching bpf_prog/attachment RCU flavors (CVE-2024-56675) * kernel: crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY (CVE-2024-56690) * kernel: igb: Fix potential invalid memory access in igb_init_module() (CVE-2024-52332) * kernel: af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK (CVE-2024-57901) * kernel: af_packet: fix vlan_get_tci() vs MSG_PEEK (CVE-2024-57902) * kernel: io_uring/sqpoll: zero sqd-&gt;thread on tctx errors (CVE-2025-21633) * kernel: ipvlan: Fix use-after-free in ipvlan_get_iflink(). (CVE-2025-21652) * kernel: sched: sch_cake: add bounds checks to host bulk flow fairness counts (CVE-2025-21647) * kernel: io_uring/eventfd: ensure io_eventfd_signal() defers another RCU period (CVE-2025-21655) * kernel: netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled (CVE-2024-57941) * kernel: netfs: Fix ceph copy to cache…</p> https://cve.radiocsirt.org/vuln/alsa-2025:20095 https://cve.radiocsirt.org/vuln/bdu:2025-12185 bdu:2025-12185 https://cve.radiocsirt.org/vuln/bdu:2025-12185 https://cve.radiocsirt.org/vuln/bell-cve-2025-21864 <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-21864 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0307 certfr-2025-avi-0307 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0307 https://cve.radiocsirt.org/vuln/euvd-2026-364504 EUVD-2026-364504 https://cve.radiocsirt.org/vuln/euvd-2026-364504 https://cve.radiocsirt.org/vuln/fkie_cve-2025-21864 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tcp: drop secpath at the same time as we currently drop dst</p> <p>Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while running tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns</p> <p>The xfrm_state found on spi_byaddr was not deleted at the time we delete the netns, because we still have a reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrm_state), which is still attached to an skb. This skb is not leaked, it ends up on sk_receive_queue and then gets defer-free&#39;d by skb_attempt_defer_free.</p> <p>The problem happens when we defer freeing an skb (push it on one CPU&#39;s defer_list), and don&#39;t flush that list before the netns is deleted. In that case, we still have a reference on the xfrm_state that we don&#39;t expect at this point.</p> <p>We already drop the skb&#39;s dst in the TCP receive path when it&#39;s no longer needed, so let&#39;s also drop the secpath. At this point, tcp_filter has already called into the LSM hooks that may require the secpath, so it should not be needed anymore. However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot simply drop all extensions.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tcp: drop secpath at the same time as we currently drop dst</p> <p>Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while running tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns</p> <p>The xfrm_state found on spi_byaddr was not deleted at the time we delete the netns, because we still have a reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrm_state), which is still attached to an skb. This skb is not leaked, it ends up on sk_receive_queue and then gets defer-free&#39;d by skb_attempt_defer_free.</p> <p>The problem happens when we defer freeing an skb (push it on one CPU&#39;s defer_list), and don&#39;t flush that list before the netns is deleted. In that case, we still have a reference on the xfrm_state that we don&#39;t expect at this point.</p> <p>We already drop the skb&#39;s dst in the TCP receive path when it&#39;s no longer needed, so let&#39;s also drop the secpath. At this point, tcp_filter has already called into the LSM hooks that may require the secpath, so it should not be needed anymore. However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot simply drop all extensions.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2025-21864 https://cve.radiocsirt.org/vuln/ghsa-qpwf-m697-v547 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tcp: drop secpath at the same time as we currently drop dst</p> <p>Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while running tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns</p> <p>The xfrm_state found on spi_byaddr was not deleted at the time we delete the netns, because we still have a reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrm_state), which is still attached to an skb. This skb is not leaked, it ends up on sk_receive_queue and then gets defer-free&#39;d by skb_attempt_defer_free.</p> <p>The problem happens when we defer freeing an skb (push it on one CPU&#39;s defer_list), and don&#39;t flush that list before the netns is deleted. In that case, we still have a reference on the xfrm_state that we don&#39;t expect at this point.</p> <p>We already drop the skb&#39;s dst in the TCP receive path when it&#39;s no longer needed, so let&#39;s also drop the secpath. At this point, tcp_filter has already called into the LSM hooks that may require the secpath, so it should not be needed anymore. However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot simply drop all extensions.</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>tcp: drop secpath at the same time as we currently drop dst</p> <p>Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while running tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns</p> <p>The xfrm_state found on spi_byaddr was not deleted at the time we delete the netns, because we still have a reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrm_state), which is still attached to an skb. This skb is not leaked, it ends up on sk_receive_queue and then gets defer-free&#39;d by skb_attempt_defer_free.</p> <p>The problem happens when we defer freeing an skb (push it on one CPU&#39;s defer_list), and don&#39;t flush that list before the netns is deleted. In that case, we still have a reference on the xfrm_state that we don&#39;t expect at this point.</p> <p>We already drop the skb&#39;s dst in the TCP receive path when it&#39;s no longer needed, so let&#39;s also drop the secpath. At this point, tcp_filter has already called into the LSM hooks that may require the secpath, so it should not be needed anymore. However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot simply drop all extensions.</p> https://cve.radiocsirt.org/vuln/ghsa-qpwf-m697-v547 https://cve.radiocsirt.org/vuln/icsa-25-162-05 <p>sshd in OpenSSH 6.2 through 8.x before 8.8, when certain non-default configurations are used, allows privilege escalation because supplemental groups are not initialized as expected. Helper programs for AuthorizedKeysCommand and AuthorizedPrincipalsCommand may run with privileges associated with group memberships of the sshd process, if the configuration specifies running the command as a different user. A flaw was found in glibc. When the getaddrinfo function is called with the AF_UNSPEC address family and the system is configured with no-aaaa mode via /etc/resolv.conf, a DNS response via TCP larger than 2048 bytes can potentially disclose stack contents through the function returned address data, and may cause a crash. A flaw was found in glibc. In an extremely rare situation, the getaddrinfo function may access memory that has been freed, resulting in an application crash. This issue is only exploitable when a NSS module implements only the _nss_*_gethostbyname2_r and _nss_*_getcanonname_r hooks without implementing the _nss_*_gethostbyname3_r hook. The resolved name should return a large number of IPv6 and IPv4, and the call to the getaddrinfo function should have the AF_INET6 address family with AI_CANONNAME, AI_ALL and AI_V4MAPPED as flags. A buffer overflow was discovered in the GNU C Library&#39;s dynamic loader ld.so while processing the GLIBC_TUNABLES environment variable. This issue could allow a local attacker to use maliciously crafted GLIBC_TUNABLES environment var…</p> <p>sshd in OpenSSH 6.2 through 8.x before 8.8, when certain non-default configurations are used, allows privilege escalation because supplemental groups are not initialized as expected. Helper programs for AuthorizedKeysCommand and AuthorizedPrincipalsCommand may run with privileges associated with group memberships of the sshd process, if the configuration specifies running the command as a different user. A flaw was found in glibc. When the getaddrinfo function is called with the AF_UNSPEC address family and the system is configured with no-aaaa mode via /etc/resolv.conf, a DNS response via TCP larger than 2048 bytes can potentially disclose stack contents through the function returned address data, and may cause a crash. A flaw was found in glibc. In an extremely rare situation, the getaddrinfo function may access memory that has been freed, resulting in an application crash. This issue is only exploitable when a NSS module implements only the _nss_*_gethostbyname2_r and _nss_*_getcanonname_r hooks without implementing the _nss_*_gethostbyname3_r hook. The resolved name should return a large number of IPv6 and IPv4, and the call to the getaddrinfo function should have the AF_INET6 address family with AI_CANONNAME, AI_ALL and AI_V4MAPPED as flags. A buffer overflow was discovered in the GNU C Library&#39;s dynamic loader ld.so while processing the GLIBC_TUNABLES environment variable. This issue could allow a local attacker to use maliciously crafted GLIBC_TUNABLES environment var…</p> https://cve.radiocsirt.org/vuln/icsa-25-162-05 https://cve.radiocsirt.org/vuln/msrc_cve-2025-21864 msrc_CVE-2025-21864 https://cve.radiocsirt.org/vuln/msrc_cve-2025-21864 https://cve.radiocsirt.org/vuln/oesa-2025-2120 <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>gtp: Destroy device along with udp socket&amp;apos;s netns dismantle.</p> <p>gtp_newlink() links the device to a list in dev_net(dev) instead of src_net, where a udp tunnel socket is created.</p> <p>Even when src_net is removed, the device stays alive on dev_net(dev). Then, removing src_net triggers the splat below. [0]</p> <p>In this example, gtp0 is created in ns2, and the udp socket is created in ns1.</p> <p>ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1</p> <p>Let&amp;apos;s link the device to the socket&amp;apos;s netns instead.</p> <p>Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove all gtp devices in the netns.</p> <p>[0]: ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236) inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1558) udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18) gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423) gtp_create_sockets (drivers/net/gtp.c:1447) gtp_newlink (drivers/net/gtp.c:1507) rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlink_rcv_msg (net/core/rtnetlink.c:6922) netlink_rcv_skb (net/netlink/af_netlink.c:2542) netlink_unicast…</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>gtp: Destroy device along with udp socket&amp;apos;s netns dismantle.</p> <p>gtp_newlink() links the device to a list in dev_net(dev) instead of src_net, where a udp tunnel socket is created.</p> <p>Even when src_net is removed, the device stays alive on dev_net(dev). Then, removing src_net triggers the splat below. [0]</p> <p>In this example, gtp0 is created in ns2, and the udp socket is created in ns1.</p> <p>ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1</p> <p>Let&amp;apos;s link the device to the socket&amp;apos;s netns instead.</p> <p>Now, gtp_net_exit_batch_rtnl() needs another netdev iteration to remove all gtp devices in the netns.</p> <p>[0]: ref_tracker: net notrefcnt@000000003d6e7d05 has 1/2 users at sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236) inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252) __sock_create (net/socket.c:1558) udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18) gtp_create_sock (./include/net/udp_tunnel.h:59 drivers/net/gtp.c:1423) gtp_create_sockets (drivers/net/gtp.c:1447) gtp_newlink (drivers/net/gtp.c:1507) rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlink_rcv_msg (net/core/rtnetlink.c:6922) netlink_rcv_skb (net/netlink/af_netlink.c:2542) netlink_unicast…</p> https://cve.radiocsirt.org/vuln/oesa-2025-2120 https://cve.radiocsirt.org/vuln/rhsa-2025:20095 <p>microcode_ctl: From CVEorg collector kernel: information leak via transient execution vulnerability in some AMD processors kernel: transient execution vulnerability in some AMD processors kernel: drm/xe/tracing: Fix a potential TP_printk UAF kernel: igb: Fix potential invalid memory access in igb_init_module() kernel: exfat: fix out-of-bounds access of directory entries kernel: nfsd: release svc_expkey/svc_export with rcu_work kernel: zram: fix NULL pointer in comp_algorithm_show() kernel: xen: Xen hypercall page unsafe against speculative attacks (Xen Security Advisory 466) kernel: NFS: Fix potential buffer overflowin nfs_sysfs_link_rpc_client() kernel: acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl kernel: bpf: Fix UAF via mismatching bpf_prog/attachment RCU flavors kernel: crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY kernel: af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK kernel: af_packet: fix vlan_get_tci() vs MSG_PEEK kernel: netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled kernel: netfs: Fix ceph copy to cache on write-begin kernel: memcg: fix soft lockup in the OOM process kernel: usb: xhci: Fix NULL pointer dereference on certain command aborts kernel: xfrm: state: fix out-of-bounds read during lookup kernel: i3c: dw: Fix use-after-free in dw_i3c_master driver due to race condition kernel: HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections kernel: Bluet…</p> <p>microcode_ctl: From CVEorg collector kernel: information leak via transient execution vulnerability in some AMD processors kernel: transient execution vulnerability in some AMD processors kernel: drm/xe/tracing: Fix a potential TP_printk UAF kernel: igb: Fix potential invalid memory access in igb_init_module() kernel: exfat: fix out-of-bounds access of directory entries kernel: nfsd: release svc_expkey/svc_export with rcu_work kernel: zram: fix NULL pointer in comp_algorithm_show() kernel: xen: Xen hypercall page unsafe against speculative attacks (Xen Security Advisory 466) kernel: NFS: Fix potential buffer overflowin nfs_sysfs_link_rpc_client() kernel: acpi: nfit: vmalloc-out-of-bounds Read in acpi_nfit_ctl kernel: bpf: Fix UAF via mismatching bpf_prog/attachment RCU flavors kernel: crypto: pcrypt - Call crypto layer directly when padata_do_parallel() return -EBUSY kernel: af_packet: fix vlan_get_protocol_dgram() vs MSG_PEEK kernel: af_packet: fix vlan_get_tci() vs MSG_PEEK kernel: netfs: Fix the (non-)cancellation of copy when cache is temporarily disabled kernel: netfs: Fix ceph copy to cache on write-begin kernel: memcg: fix soft lockup in the OOM process kernel: usb: xhci: Fix NULL pointer dereference on certain command aborts kernel: xfrm: state: fix out-of-bounds read during lookup kernel: i3c: dw: Fix use-after-free in dw_i3c_master driver due to race condition kernel: HID: core: Fix assumption that Resolution Multipliers must be in Logical Collections kernel: Bluet…</p> https://cve.radiocsirt.org/vuln/rhsa-2025:20095 https://cve.radiocsirt.org/vuln/ssa-019113 <p>Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).</p> <p>Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p> <p>Multiple vulnerabilities have been identified in the additional GNU/Linux subsystem of the firmware version V3.1.6 for the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP (incl. SIPLUS variant).</p> <p>Siemens has released new versions for several affected products and recommends to update to the latest versions. Siemens is preparing further fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p> https://cve.radiocsirt.org/vuln/ssa-019113 https://cve.radiocsirt.org/vuln/suse-su-2025:01919-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:01919-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21864 <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 107 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: tcp: drop secpath at the same time as we currently drop dst Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while running tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns The xfrm_state found on spi_byaddr was not deleted at the time we delete the netns, because we still have a reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrm_state), which is still attached to an skb. This skb is not leaked, it ends up on sk_receive_queue and then gets defer-free&#39;d by skb_attempt_defer_free. The problem happens when we defer freeing an skb (push it on one CPU&#39;s defer_list), and don&#39;t flush that list before the netns is deleted. In that case, we still have a reference on the xfrm_state that we don&#39;t expect at this point. We already drop the skb&#39;s dst in the TCP receive path when it&#39;s no longer needed, so let&#39;s also drop the secpath. At this point, tcp_filter has already called into the LSM hooks that may require the secpath, so it should not be needed anymore. However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot simply drop all extensions.</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 107 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: tcp: drop secpath at the same time as we currently drop dst Xiumei reported hitting the WARN in xfrm6_tunnel_net_exit while running tests that boil down to: - create a pair of netns - run a basic TCP test over ipcomp6 - delete the pair of netns The xfrm_state found on spi_byaddr was not deleted at the time we delete the netns, because we still have a reference on it. This lingering reference comes from a secpath (which holds a ref on the xfrm_state), which is still attached to an skb. This skb is not leaked, it ends up on sk_receive_queue and then gets defer-free&#39;d by skb_attempt_defer_free. The problem happens when we defer freeing an skb (push it on one CPU&#39;s defer_list), and don&#39;t flush that list before the netns is deleted. In that case, we still have a reference on the xfrm_state that we don&#39;t expect at this point. We already drop the skb&#39;s dst in the TCP receive path when it&#39;s no longer needed, so let&#39;s also drop the secpath. At this point, tcp_filter has already called into the LSM hooks that may require the secpath, so it should not be needed anymore. However, in some of those places, the MPTCP extension has just been attached to the skb, so we cannot simply drop all extensions.</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2025-21864 https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0545 <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen und um nicht näher beschriebene Auswirkungen zu verursachen.</p> <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Zustand herbeizuführen und um nicht näher beschriebene Auswirkungen zu verursachen.</p> https://cve.radiocsirt.org/vuln/wid-sec-w-2025-0545