<?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>Mon, 05 Oct 2026 11:24:34 +0000</lastBuildDate>
    <item>
      <title>certfr-2025-avi-0307 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2025-avi-0307</link>
      <description>certfr-2025-avi-0307</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2025-avi-0307</guid>
    </item>
    <item>
      <title>EUVD-2026-310400</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-310400</link>
      <description>EUVD-2026-310400</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-310400</guid>
    </item>
    <item>
      <title>fkie_cve-2022-49209</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2022-49209</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full&lt;/p&gt;
&lt;p&gt;If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()
returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial
memory has been alloced by sk_msg_alloc(), that is, msg_tx-&amp;gt;sg.size is
greater than osize after sk_msg_alloc(), memleak occurs. To fix we use
sk_msg_trim() to release the allocated memory, then goto wait for memory.&lt;/p&gt;
&lt;p&gt;Other call paths of sk_msg_alloc() have the similar issue, such as
tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),
as Cong Wang suggested.&lt;/p&gt;
&lt;p&gt;This issue can cause the following info:
WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
Call Trace:
 &amp;lt;TASK&amp;gt;
 inet_csk_destroy_sock+0x55/0x110
 __tcp_close+0x279/0x470
 tcp_close+0x1f/0x60
 inet_release+0x3f/0x80
 __sock_release+0x3d/0xb0
 sock_close+0x11/0x20
 __fput+0x92/0x250
 task_work_run+0x6a/0xa0
 do_exit+0x33b/0xb60
 do_group_exit+0x2f/0xa0
 get_signal+0xb6/0x950
 arch_do_signal_or_restart+0xac/0x2a0
 exit_to_user_mode_prepare+0xa9/0x200
 syscall_exit_to_user_mode+0x12/0x30
 do_syscall_64+0x46/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
 &amp;lt;/TASK&amp;gt;&lt;/p&gt;
&lt;p&gt;WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
Call Trace:
 &amp;lt;TASK&amp;gt;
 __sk_destruct+0x24/0x1f0
 sk_psock_destroy+0x19b/0x1c0
 process_one_work+0x1b3/0x3c0
 kthread+0xe6/0x110
 ret_from_fork+0x22/0x30…&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, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full&lt;/p&gt;
&lt;p&gt;If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()
returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial
memory has been alloced by sk_msg_alloc(), that is, msg_tx-&amp;gt;sg.size is
greater than osize after sk_msg_alloc(), memleak occurs. To fix we use
sk_msg_trim() to release the allocated memory, then goto wait for memory.&lt;/p&gt;
&lt;p&gt;Other call paths of sk_msg_alloc() have the similar issue, such as
tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),
as Cong Wang suggested.&lt;/p&gt;
&lt;p&gt;This issue can cause the following info:
WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
Call Trace:
 &amp;lt;TASK&amp;gt;
 inet_csk_destroy_sock+0x55/0x110
 __tcp_close+0x279/0x470
 tcp_close+0x1f/0x60
 inet_release+0x3f/0x80
 __sock_release+0x3d/0xb0
 sock_close+0x11/0x20
 __fput+0x92/0x250
 task_work_run+0x6a/0xa0
 do_exit+0x33b/0xb60
 do_group_exit+0x2f/0xa0
 get_signal+0xb6/0x950
 arch_do_signal_or_restart+0xac/0x2a0
 exit_to_user_mode_prepare+0xa9/0x200
 syscall_exit_to_user_mode+0x12/0x30
 do_syscall_64+0x46/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
 &amp;lt;/TASK&amp;gt;&lt;/p&gt;
&lt;p&gt;WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
Call Trace:
 &amp;lt;TASK&amp;gt;
 __sk_destruct+0x24/0x1f0
 sk_psock_destroy+0x19b/0x1c0
 process_one_work+0x1b3/0x3c0
 kthread+0xe6/0x110
 ret_from_fork+0x22/0x30…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2022-49209</guid>
    </item>
    <item>
      <title>GHSA-pp5f-f2rv-q3vx</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-pp5f-f2rv-q3vx</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full&lt;/p&gt;
&lt;p&gt;If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()
returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial
memory has been alloced by sk_msg_alloc(), that is, msg_tx-&amp;gt;sg.size is
greater than osize after sk_msg_alloc(), memleak occurs. To fix we use
sk_msg_trim() to release the allocated memory, then goto wait for memory.&lt;/p&gt;
&lt;p&gt;Other call paths of sk_msg_alloc() have the similar issue, such as
tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),
as Cong Wang suggested.&lt;/p&gt;
&lt;p&gt;This issue can cause the following info:
WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
Call Trace:
 &amp;lt;TASK&amp;gt;
 inet_csk_destroy_sock+0x55/0x110
 __tcp_close+0x279/0x470
 tcp_close+0x1f/0x60
 inet_release+0x3f/0x80
 __sock_release+0x3d/0xb0
 sock_close+0x11/0x20
 __fput+0x92/0x250
 task_work_run+0x6a/0xa0
 do_exit+0x33b/0xb60
 do_group_exit+0x2f/0xa0
 get_signal+0xb6/0x950
 arch_do_signal_or_restart+0xac/0x2a0
 exit_to_user_mode_prepare+0xa9/0x200
 syscall_exit_to_user_mode+0x12/0x30
 do_syscall_64+0x46/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
 &amp;lt;/TASK&amp;gt;&lt;/p&gt;
&lt;p&gt;WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
Call Trace:
 &amp;lt;TASK&amp;gt;
 __sk_destruct+0x24/0x1f0
 sk_psock_destroy+0x19b/0x1c0
 process_one_work+0x1b3/0x3c0
 kthread+0xe6/0x110
 ret_from_fork+0x22/0x30…&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, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full&lt;/p&gt;
&lt;p&gt;If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc()
returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial
memory has been alloced by sk_msg_alloc(), that is, msg_tx-&amp;gt;sg.size is
greater than osize after sk_msg_alloc(), memleak occurs. To fix we use
sk_msg_trim() to release the allocated memory, then goto wait for memory.&lt;/p&gt;
&lt;p&gt;Other call paths of sk_msg_alloc() have the similar issue, such as
tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(),
as Cong Wang suggested.&lt;/p&gt;
&lt;p&gt;This issue can cause the following info:
WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0
Call Trace:
 &amp;lt;TASK&amp;gt;
 inet_csk_destroy_sock+0x55/0x110
 __tcp_close+0x279/0x470
 tcp_close+0x1f/0x60
 inet_release+0x3f/0x80
 __sock_release+0x3d/0xb0
 sock_close+0x11/0x20
 __fput+0x92/0x250
 task_work_run+0x6a/0xa0
 do_exit+0x33b/0xb60
 do_group_exit+0x2f/0xa0
 get_signal+0xb6/0x950
 arch_do_signal_or_restart+0xac/0x2a0
 exit_to_user_mode_prepare+0xa9/0x200
 syscall_exit_to_user_mode+0x12/0x30
 do_syscall_64+0x46/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
 &amp;lt;/TASK&amp;gt;&lt;/p&gt;
&lt;p&gt;WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260
Call Trace:
 &amp;lt;TASK&amp;gt;
 __sk_destruct+0x24/0x1f0
 sk_psock_destroy+0x19b/0x1c0
 process_one_work+0x1b3/0x3c0
 kthread+0xe6/0x110
 ret_from_fork+0x22/0x30…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-pp5f-f2rv-q3vx</guid>
    </item>
    <item>
      <title>SUSE-SU-2025:1176-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2025:1176-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:1176-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2022-49209</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49209</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.4, Ubuntu:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-gcp-5.4, Ubuntu:18.04:LTS: linux-hwe-5.4, Ubuntu:18.04:LTS: linux-ibm-5.4, Ubuntu:18.04:LTS: linux-oracle-5.4, Ubuntu:18.04:LTS: linux-raspi-5.4, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3 and 110 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc() returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial memory has been alloced by sk_msg_alloc(), that is, msg_tx-&amp;gt;sg.size is greater than osize after sk_msg_alloc(), memleak occurs. To fix we use sk_msg_trim() to release the allocated memory, then goto wait for memory. Other call paths of sk_msg_alloc() have the similar issue, such as tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(), as Cong Wang suggested. This issue can cause the following info: WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0 Call Trace:  &amp;lt;TASK&amp;gt;  inet_csk_destroy_sock+0x55/0x110  __tcp_close+0x279/0x470  tcp_close+0x1f/0x60  inet_release+0x3f/0x80  __sock_release+0x3d/0xb0  sock_close+0x11/0x20  __fput+0x92/0x250  task_work_run+0x6a/0xa0  do_exit+0x33b/0xb60  do_group_exit+0x2f/0xa0  get_signal+0xb6/0x950  arch_do_signal_or_restart+0xac/0x2a0  exit_to_user_mode_prepare+0xa9/0x200  syscall_exit_to_user_mode+0x12/0x30  do_syscall_64+0x46/0x80  entry_SYSCALL_64_after_hwframe+0x44/0xae  &amp;lt;/TASK&amp;gt; WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Call Trace:  &amp;lt;TASK&amp;gt;  __sk_destruct+0x24/0x1f0  sk_psock_destroy+0x19b/0x1c0  process_one_work+0x1b3/0x3c0  kthread+0xe6/0x110  ret_from_fork+0x22/0x30  &amp;lt;/TA…&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.4, Ubuntu:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-gcp-5.4, Ubuntu:18.04:LTS: linux-hwe-5.4, Ubuntu:18.04:LTS: linux-ibm-5.4, Ubuntu:18.04:LTS: linux-oracle-5.4, Ubuntu:18.04:LTS: linux-raspi-5.4, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3 and 110 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix memleak in tcp_bpf_sendmsg while sk msg is full If tcp_bpf_sendmsg() is running while sk msg is full. When sk_msg_alloc() returns -ENOMEM error, tcp_bpf_sendmsg() goes to wait_for_memory. If partial memory has been alloced by sk_msg_alloc(), that is, msg_tx-&amp;gt;sg.size is greater than osize after sk_msg_alloc(), memleak occurs. To fix we use sk_msg_trim() to release the allocated memory, then goto wait for memory. Other call paths of sk_msg_alloc() have the similar issue, such as tls_sw_sendmsg(), so handle sk_msg_trim logic inside sk_msg_alloc(), as Cong Wang suggested. This issue can cause the following info: WARNING: CPU: 3 PID: 7950 at net/core/stream.c:208 sk_stream_kill_queues+0xd4/0x1a0 Call Trace:  &amp;lt;TASK&amp;gt;  inet_csk_destroy_sock+0x55/0x110  __tcp_close+0x279/0x470  tcp_close+0x1f/0x60  inet_release+0x3f/0x80  __sock_release+0x3d/0xb0  sock_close+0x11/0x20  __fput+0x92/0x250  task_work_run+0x6a/0xa0  do_exit+0x33b/0xb60  do_group_exit+0x2f/0xa0  get_signal+0xb6/0x950  arch_do_signal_or_restart+0xac/0x2a0  exit_to_user_mode_prepare+0xa9/0x200  syscall_exit_to_user_mode+0x12/0x30  do_syscall_64+0x46/0x80  entry_SYSCALL_64_after_hwframe+0x44/0xae  &amp;lt;/TASK&amp;gt; WARNING: CPU: 3 PID: 2094 at net/ipv4/af_inet.c:155 inet_sock_destruct+0x13c/0x260 Call Trace:  &amp;lt;TASK&amp;gt;  __sk_destruct+0x24/0x1f0  sk_psock_destroy+0x19b/0x1c0  process_one_work+0x1b3/0x3c0  kthread+0xe6/0x110  ret_from_fork+0x22/0x30  &amp;lt;/TA…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49209</guid>
    </item>
  </channel>
</rss>
