<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" version="2.0">
  <channel>
    <title>Most recent entries from all</title>
    <link>https://cve.radiocsirt.org</link>
    <description>Contains only the most 10 recent entries.</description>
    <docs>http://www.rssboard.org/rss-specification</docs>
    <generator>python-feedgen</generator>
    <language>en</language>
    <lastBuildDate>Fri, 02 Oct 2026 16:55:02 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-04429</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-04429</link>
      <description>bdu:2026-04429</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-04429</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-53585</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2023-53585</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2023-53585</guid>
    </item>
    <item>
      <title>certfr-2025-avi-1009 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Elles permettent à un attaquant de provoqu…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-1009</link>
      <description>certfr-2025-avi-1009</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-1009</guid>
    </item>
    <item>
      <title>EUVD-2026-312146</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-312146</link>
      <description>EUVD-2026-312146</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-312146</guid>
    </item>
    <item>
      <title>fkie_cve-2023-53585</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2023-53585</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf: reject unhashed sockets in bpf_sk_assign&lt;/p&gt;
&lt;p&gt;The semantics for bpf_sk_assign are as follows:&lt;/p&gt;
&lt;p&gt;sk = some_lookup_func()
    bpf_sk_assign(skb, sk)
    bpf_sk_release(sk)&lt;/p&gt;
&lt;p&gt;That is, the sk is not consumed by bpf_sk_assign. The function
therefore needs to make sure that sk lives long enough to be
consumed from __inet_lookup_skb. The path through the stack for a
TCPv4 packet is roughly:&lt;/p&gt;
&lt;p&gt;netif_receive_skb_core: takes RCU read lock
    __netif_receive_skb_core:
      sch_handle_ingress:
        tcf_classify:
          bpf_sk_assign()
      deliver_ptype_list_skb:
        deliver_skb:
          ip_packet_type-&amp;gt;func == ip_rcv:
            ip_rcv_core:
            ip_rcv_finish_core:
              dst_input:
                ip_local_deliver:
                  ip_local_deliver_finish:
                    ip_protocol_deliver_rcu:
                      tcp_v4_rcv:
                        __inet_lookup_skb:
                          skb_steal_sock&lt;/p&gt;
&lt;p&gt;The existing helper takes advantage of the fact that everything
happens in the same RCU critical section: for sockets with
SOCK_RCU_FREE set bpf_sk_assign never takes a reference.
skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put
if necessary.&lt;/p&gt;
&lt;p&gt;This approach assumes that SOCK_RCU_FREE is never set on a sk
between bpf_sk_assign and skb_steal_sock, but this invariant is
violated by unhashed UDP sockets. A new UDP socket is created
in TCP_CLOSE state but wi…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf: reject unhashed sockets in bpf_sk_assign&lt;/p&gt;
&lt;p&gt;The semantics for bpf_sk_assign are as follows:&lt;/p&gt;
&lt;p&gt;sk = some_lookup_func()
    bpf_sk_assign(skb, sk)
    bpf_sk_release(sk)&lt;/p&gt;
&lt;p&gt;That is, the sk is not consumed by bpf_sk_assign. The function
therefore needs to make sure that sk lives long enough to be
consumed from __inet_lookup_skb. The path through the stack for a
TCPv4 packet is roughly:&lt;/p&gt;
&lt;p&gt;netif_receive_skb_core: takes RCU read lock
    __netif_receive_skb_core:
      sch_handle_ingress:
        tcf_classify:
          bpf_sk_assign()
      deliver_ptype_list_skb:
        deliver_skb:
          ip_packet_type-&amp;gt;func == ip_rcv:
            ip_rcv_core:
            ip_rcv_finish_core:
              dst_input:
                ip_local_deliver:
                  ip_local_deliver_finish:
                    ip_protocol_deliver_rcu:
                      tcp_v4_rcv:
                        __inet_lookup_skb:
                          skb_steal_sock&lt;/p&gt;
&lt;p&gt;The existing helper takes advantage of the fact that everything
happens in the same RCU critical section: for sockets with
SOCK_RCU_FREE set bpf_sk_assign never takes a reference.
skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put
if necessary.&lt;/p&gt;
&lt;p&gt;This approach assumes that SOCK_RCU_FREE is never set on a sk
between bpf_sk_assign and skb_steal_sock, but this invariant is
violated by unhashed UDP sockets. A new UDP socket is created
in TCP_CLOSE state but wi…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2023-53585</guid>
    </item>
    <item>
      <title>GHSA-39wr-crm4-gxmv</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-39wr-crm4-gxmv</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf: reject unhashed sockets in bpf_sk_assign&lt;/p&gt;
&lt;p&gt;The semantics for bpf_sk_assign are as follows:&lt;/p&gt;
&lt;p&gt;sk = some_lookup_func()
    bpf_sk_assign(skb, sk)
    bpf_sk_release(sk)&lt;/p&gt;
&lt;p&gt;That is, the sk is not consumed by bpf_sk_assign. The function
therefore needs to make sure that sk lives long enough to be
consumed from __inet_lookup_skb. The path through the stack for a
TCPv4 packet is roughly:&lt;/p&gt;
&lt;p&gt;netif_receive_skb_core: takes RCU read lock
    __netif_receive_skb_core:
      sch_handle_ingress:
        tcf_classify:
          bpf_sk_assign()
      deliver_ptype_list_skb:
        deliver_skb:
          ip_packet_type-&amp;gt;func == ip_rcv:
            ip_rcv_core:
            ip_rcv_finish_core:
              dst_input:
                ip_local_deliver:
                  ip_local_deliver_finish:
                    ip_protocol_deliver_rcu:
                      tcp_v4_rcv:
                        __inet_lookup_skb:
                          skb_steal_sock&lt;/p&gt;
&lt;p&gt;The existing helper takes advantage of the fact that everything
happens in the same RCU critical section: for sockets with
SOCK_RCU_FREE set bpf_sk_assign never takes a reference.
skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put
if necessary.&lt;/p&gt;
&lt;p&gt;This approach assumes that SOCK_RCU_FREE is never set on a sk
between bpf_sk_assign and skb_steal_sock, but this invariant is
violated by unhashed UDP sockets. A new UDP socket is created
in TCP_CLOSE state but wi…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf: reject unhashed sockets in bpf_sk_assign&lt;/p&gt;
&lt;p&gt;The semantics for bpf_sk_assign are as follows:&lt;/p&gt;
&lt;p&gt;sk = some_lookup_func()
    bpf_sk_assign(skb, sk)
    bpf_sk_release(sk)&lt;/p&gt;
&lt;p&gt;That is, the sk is not consumed by bpf_sk_assign. The function
therefore needs to make sure that sk lives long enough to be
consumed from __inet_lookup_skb. The path through the stack for a
TCPv4 packet is roughly:&lt;/p&gt;
&lt;p&gt;netif_receive_skb_core: takes RCU read lock
    __netif_receive_skb_core:
      sch_handle_ingress:
        tcf_classify:
          bpf_sk_assign()
      deliver_ptype_list_skb:
        deliver_skb:
          ip_packet_type-&amp;gt;func == ip_rcv:
            ip_rcv_core:
            ip_rcv_finish_core:
              dst_input:
                ip_local_deliver:
                  ip_local_deliver_finish:
                    ip_protocol_deliver_rcu:
                      tcp_v4_rcv:
                        __inet_lookup_skb:
                          skb_steal_sock&lt;/p&gt;
&lt;p&gt;The existing helper takes advantage of the fact that everything
happens in the same RCU critical section: for sockets with
SOCK_RCU_FREE set bpf_sk_assign never takes a reference.
skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put
if necessary.&lt;/p&gt;
&lt;p&gt;This approach assumes that SOCK_RCU_FREE is never set on a sk
between bpf_sk_assign and skb_steal_sock, but this invariant is
violated by unhashed UDP sockets. A new UDP socket is created
in TCP_CLOSE state but wi…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-39wr-crm4-gxmv</guid>
    </item>
    <item>
      <title>RHSA-2020:4431 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2020:4431</link>
      <description>&lt;p&gt;kernel: kernel pointer leak due to WARN_ON statement in video driver leads to local information disclosure kernel: use after free due to race condition in the video driver leads to local privilege escalation kernel: null pointer dereference in dlpar_parse_cc_property in arch/powerrc/platforms/pseries/dlpar.c causing denial of service kernel: use-after-free in drivers/bluetooth/hci_ldisc.c kernel: out-of-bounds access in function hclge_tm_schd_mode_vnet_base_cfg kernel: null-pointer dereference in drivers/net/fjes/fjes_main.c kernel: null pointer dereference in drivers/scsi/qla2xxx/qla_os.c kernel: memory leak in ccp_run_sha_cmd() function in drivers/crypto/ccp/ccp-ops.c kernel: memory leak in  af9005_identify_state() function in drivers/media/usb/dvb-usb/af9005.c kernel: Denial Of Service in the __ipmi_bmc_register() function in drivers/char/ipmi/ipmi_msghandler.c kernel: A memory leak in the mwifiex_pcie_alloc_cmdrsp_buf() function in drivers/net/wireless/marvell/mwifiex/pcie.c allows to cause DoS kernel: memory leak in the crypto_report() function in crypto/crypto_user_base.c allows for DoS kernel: Two memory leaks in the rtl_usb_probe() function in drivers/net/wireless/realtek/rtlwifi/usb.c allow for a DoS kernel: A memory leak in the rtl8xxxu_submit_int_urb() function in drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c allows for a DoS kernel: A memory leak in the predicate_parse() function in kernel/trace/trace_events_filter.c allows for a DoS kernel: out-of-bounds…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: kernel pointer leak due to WARN_ON statement in video driver leads to local information disclosure kernel: use after free due to race condition in the video driver leads to local privilege escalation kernel: null pointer dereference in dlpar_parse_cc_property in arch/powerrc/platforms/pseries/dlpar.c causing denial of service kernel: use-after-free in drivers/bluetooth/hci_ldisc.c kernel: out-of-bounds access in function hclge_tm_schd_mode_vnet_base_cfg kernel: null-pointer dereference in drivers/net/fjes/fjes_main.c kernel: null pointer dereference in drivers/scsi/qla2xxx/qla_os.c kernel: memory leak in ccp_run_sha_cmd() function in drivers/crypto/ccp/ccp-ops.c kernel: memory leak in  af9005_identify_state() function in drivers/media/usb/dvb-usb/af9005.c kernel: Denial Of Service in the __ipmi_bmc_register() function in drivers/char/ipmi/ipmi_msghandler.c kernel: A memory leak in the mwifiex_pcie_alloc_cmdrsp_buf() function in drivers/net/wireless/marvell/mwifiex/pcie.c allows to cause DoS kernel: memory leak in the crypto_report() function in crypto/crypto_user_base.c allows for DoS kernel: Two memory leaks in the rtl_usb_probe() function in drivers/net/wireless/realtek/rtlwifi/usb.c allow for a DoS kernel: A memory leak in the rtl8xxxu_submit_int_urb() function in drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c allows for a DoS kernel: A memory leak in the predicate_parse() function in kernel/trace/trace_events_filter.c allows for a DoS kernel: out-of-bounds…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2020:4431</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:21040-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:21040-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2025:21040-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-53585</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53585</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 115 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf: reject unhashed sockets in bpf_sk_assign The semantics for bpf_sk_assign are as follows:     sk = some_lookup_func()     bpf_sk_assign(skb, sk)     bpf_sk_release(sk) That is, the sk is not consumed by bpf_sk_assign. The function therefore needs to make sure that sk lives long enough to be consumed from __inet_lookup_skb. The path through the stack for a TCPv4 packet is roughly:   netif_receive_skb_core: takes RCU read lock     __netif_receive_skb_core:       sch_handle_ingress:         tcf_classify:           bpf_sk_assign()       deliver_ptype_list_skb:         deliver_skb:           ip_packet_type-&amp;gt;func == ip_rcv:             ip_rcv_core:             ip_rcv_finish_core:               dst_input:                 ip_local_deliver:                   ip_local_deliver_finish:                     ip_protocol_deliver_rcu:                       tcp_v4_rcv:                         __inet_lookup_skb:                           skb_steal_sock The existing helper takes advantage of the fact that everything happens in the same RCU critical section: for sockets with SOCK_RCU_FREE set bpf_sk_assign never takes a reference. skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put if necessary. This approach assumes that SOCK_RCU_FREE is never set on a sk between bpf_sk_assign and skb_steal_sock, but this invariant is violated by unhashed UDP sockets. A new UDP socket is created in TCP_CLOSE state but without S…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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 115 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf: reject unhashed sockets in bpf_sk_assign The semantics for bpf_sk_assign are as follows:     sk = some_lookup_func()     bpf_sk_assign(skb, sk)     bpf_sk_release(sk) That is, the sk is not consumed by bpf_sk_assign. The function therefore needs to make sure that sk lives long enough to be consumed from __inet_lookup_skb. The path through the stack for a TCPv4 packet is roughly:   netif_receive_skb_core: takes RCU read lock     __netif_receive_skb_core:       sch_handle_ingress:         tcf_classify:           bpf_sk_assign()       deliver_ptype_list_skb:         deliver_skb:           ip_packet_type-&amp;gt;func == ip_rcv:             ip_rcv_core:             ip_rcv_finish_core:               dst_input:                 ip_local_deliver:                   ip_local_deliver_finish:                     ip_protocol_deliver_rcu:                       tcp_v4_rcv:                         __inet_lookup_skb:                           skb_steal_sock The existing helper takes advantage of the fact that everything happens in the same RCU critical section: for sockets with SOCK_RCU_FREE set bpf_sk_assign never takes a reference. skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put if necessary. This approach assumes that SOCK_RCU_FREE is never set on a sk between bpf_sk_assign and skb_steal_sock, but this invariant is violated by unhashed UDP sockets. A new UDP socket is created in TCP_CLOSE state but without S…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2023-53585</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2194 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2194</link>
      <description>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2025-2194</guid>
    </item>
  </channel>
</rss>
