<?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 22:10:37 +0000</lastBuildDate>
    <item>
      <title>ALSA-2026:38491 — Important: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/alsa-2026:38491</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core, AlmaLinux:9: kernel-64k-debug-modules-extra and 64 more&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: Linux kernel: Memory leak in networking due to incorrect GRO packet handling (CVE-2026-22979)
  * kernel: rtmutex: Use waiter::task instead of current in remove_waiter() (CVE-2026-43499)
  * kernel: net: bridge: use a stable FDB dst snapshot in RCU readers (CVE-2026-46086)
  * kernel: crypto: ccp - copy IV using skcipher ivsize (CVE-2026-53016)
  * kernel: futex/requeue: Prevent NULL pointer dereference in remove_waiter() on self-deadlock (CVE-2026-53166)&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* Kernel panic very early during boot while reading a tracefs file (available_filter_functions) due to invalid module name pointer [9.8.z] (JIRA:AlmaLinux-183236)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; AlmaLinux:9: kernel, AlmaLinux:9: kernel-64k, AlmaLinux:9: kernel-64k-core, AlmaLinux:9: kernel-64k-debug, AlmaLinux:9: kernel-64k-debug-core, AlmaLinux:9: kernel-64k-debug-devel, AlmaLinux:9: kernel-64k-debug-devel-matched, AlmaLinux:9: kernel-64k-debug-modules, AlmaLinux:9: kernel-64k-debug-modules-core, AlmaLinux:9: kernel-64k-debug-modules-extra and 64 more&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: Linux kernel: Memory leak in networking due to incorrect GRO packet handling (CVE-2026-22979)
  * kernel: rtmutex: Use waiter::task instead of current in remove_waiter() (CVE-2026-43499)
  * kernel: net: bridge: use a stable FDB dst snapshot in RCU readers (CVE-2026-46086)
  * kernel: crypto: ccp - copy IV using skcipher ivsize (CVE-2026-53016)
  * kernel: futex/requeue: Prevent NULL pointer dereference in remove_waiter() on self-deadlock (CVE-2026-53166)&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* Kernel panic very early during boot while reading a tracefs file (available_filter_functions) due to invalid module name pointer [9.8.z] (JIRA:AlmaLinux-183236)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/alsa-2026:38491</guid>
    </item>
    <item>
      <title>bdu:2026-08874</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-08874</link>
      <description>bdu:2026-08874</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-08874</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-22979</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-22979</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:23: linux-lts, Alpaquita:25: 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:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-22979</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0166 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0166</link>
      <description>certfr-2026-avi-0166</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0166</guid>
    </item>
    <item>
      <title>EUVD-2026-364642</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-364642</link>
      <description>EUVD-2026-364642</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-364642</guid>
    </item>
    <item>
      <title>fkie_cve-2026-22979</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-22979</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: fix memory leak in skb_segment_list for GRO packets&lt;/p&gt;
&lt;p&gt;When skb_segment_list() is called during packet forwarding, it handles
packets that were aggregated by the GRO engine.&lt;/p&gt;
&lt;p&gt;Historically, the segmentation logic in skb_segment_list assumes that
individual segments are split from a parent SKB and may need to carry
their own socket memory accounting. Accordingly, the code transfers
truesize from the parent to the newly created segments.&lt;/p&gt;
&lt;p&gt;Prior to commit ed4cccef64c1 (&amp;#34;gro: fix ownership transfer&amp;#34;), this
truesize subtraction in skb_segment_list() was valid because fragments
still carry a reference to the original socket.&lt;/p&gt;
&lt;p&gt;However, commit ed4cccef64c1 (&amp;#34;gro: fix ownership transfer&amp;#34;) changed
this behavior by ensuring that fraglist entries are explicitly
orphaned (skb-&amp;gt;sk = NULL) to prevent illegal orphaning later in the
stack. This change meant that the entire socket memory charge remained
with the head SKB, but the corresponding accounting logic in
skb_segment_list() was never updated.&lt;/p&gt;
&lt;p&gt;As a result, the current code unconditionally adds each fragment&amp;#39;s
truesize to delta_truesize and subtracts it from the parent SKB. Since
the fragments are no longer charged to the socket, this subtraction
results in an effective under-count of memory when the head is freed.
This causes sk_wmem_alloc to remain non-zero, preventing socket
destruction and leading to a persistent memory leak.&lt;/p&gt;
&lt;p&gt;The leak can be observed via KMEMLE…&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;net: fix memory leak in skb_segment_list for GRO packets&lt;/p&gt;
&lt;p&gt;When skb_segment_list() is called during packet forwarding, it handles
packets that were aggregated by the GRO engine.&lt;/p&gt;
&lt;p&gt;Historically, the segmentation logic in skb_segment_list assumes that
individual segments are split from a parent SKB and may need to carry
their own socket memory accounting. Accordingly, the code transfers
truesize from the parent to the newly created segments.&lt;/p&gt;
&lt;p&gt;Prior to commit ed4cccef64c1 (&amp;#34;gro: fix ownership transfer&amp;#34;), this
truesize subtraction in skb_segment_list() was valid because fragments
still carry a reference to the original socket.&lt;/p&gt;
&lt;p&gt;However, commit ed4cccef64c1 (&amp;#34;gro: fix ownership transfer&amp;#34;) changed
this behavior by ensuring that fraglist entries are explicitly
orphaned (skb-&amp;gt;sk = NULL) to prevent illegal orphaning later in the
stack. This change meant that the entire socket memory charge remained
with the head SKB, but the corresponding accounting logic in
skb_segment_list() was never updated.&lt;/p&gt;
&lt;p&gt;As a result, the current code unconditionally adds each fragment&amp;#39;s
truesize to delta_truesize and subtracts it from the parent SKB. Since
the fragments are no longer charged to the socket, this subtraction
results in an effective under-count of memory when the head is freed.
This causes sk_wmem_alloc to remain non-zero, preventing socket
destruction and leading to a persistent memory leak.&lt;/p&gt;
&lt;p&gt;The leak can be observed via KMEMLE…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-22979</guid>
    </item>
    <item>
      <title>GHSA-w4ch-7p82-3m56</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-w4ch-7p82-3m56</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: fix memory leak in skb_segment_list for GRO packets&lt;/p&gt;
&lt;p&gt;When skb_segment_list() is called during packet forwarding, it handles
packets that were aggregated by the GRO engine.&lt;/p&gt;
&lt;p&gt;Historically, the segmentation logic in skb_segment_list assumes that
individual segments are split from a parent SKB and may need to carry
their own socket memory accounting. Accordingly, the code transfers
truesize from the parent to the newly created segments.&lt;/p&gt;
&lt;p&gt;Prior to commit ed4cccef64c1 (&amp;#34;gro: fix ownership transfer&amp;#34;), this
truesize subtraction in skb_segment_list() was valid because fragments
still carry a reference to the original socket.&lt;/p&gt;
&lt;p&gt;However, commit ed4cccef64c1 (&amp;#34;gro: fix ownership transfer&amp;#34;) changed
this behavior by ensuring that fraglist entries are explicitly
orphaned (skb-&amp;gt;sk = NULL) to prevent illegal orphaning later in the
stack. This change meant that the entire socket memory charge remained
with the head SKB, but the corresponding accounting logic in
skb_segment_list() was never updated.&lt;/p&gt;
&lt;p&gt;As a result, the current code unconditionally adds each fragment&amp;#39;s
truesize to delta_truesize and subtracts it from the parent SKB. Since
the fragments are no longer charged to the socket, this subtraction
results in an effective under-count of memory when the head is freed.
This causes sk_wmem_alloc to remain non-zero, preventing socket
destruction and leading to a persistent memory leak.&lt;/p&gt;
&lt;p&gt;The leak can be observed via KMEMLE…&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;net: fix memory leak in skb_segment_list for GRO packets&lt;/p&gt;
&lt;p&gt;When skb_segment_list() is called during packet forwarding, it handles
packets that were aggregated by the GRO engine.&lt;/p&gt;
&lt;p&gt;Historically, the segmentation logic in skb_segment_list assumes that
individual segments are split from a parent SKB and may need to carry
their own socket memory accounting. Accordingly, the code transfers
truesize from the parent to the newly created segments.&lt;/p&gt;
&lt;p&gt;Prior to commit ed4cccef64c1 (&amp;#34;gro: fix ownership transfer&amp;#34;), this
truesize subtraction in skb_segment_list() was valid because fragments
still carry a reference to the original socket.&lt;/p&gt;
&lt;p&gt;However, commit ed4cccef64c1 (&amp;#34;gro: fix ownership transfer&amp;#34;) changed
this behavior by ensuring that fraglist entries are explicitly
orphaned (skb-&amp;gt;sk = NULL) to prevent illegal orphaning later in the
stack. This change meant that the entire socket memory charge remained
with the head SKB, but the corresponding accounting logic in
skb_segment_list() was never updated.&lt;/p&gt;
&lt;p&gt;As a result, the current code unconditionally adds each fragment&amp;#39;s
truesize to delta_truesize and subtracts it from the parent SKB. Since
the fragments are no longer charged to the socket, this subtraction
results in an effective under-count of memory when the head is freed.
This causes sk_wmem_alloc to remain non-zero, preventing socket
destruction and leading to a persistent memory leak.&lt;/p&gt;
&lt;p&gt;The leak can be observed via KMEMLE…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-w4ch-7p82-3m56</guid>
    </item>
    <item>
      <title>ICSA-26-209-04 — Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP</title>
      <link>https://cve.radiocsirt.org/vuln/icsa-26-209-04</link>
      <description>&lt;p&gt;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).&lt;/p&gt;
&lt;p&gt;Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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).&lt;/p&gt;
&lt;p&gt;Siemens is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/icsa-26-209-04</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-22979 — net: fix memory leak in skb_segment_list for GRO packets</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-22979</link>
      <description>msrc_CVE-2026-22979</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-22979</guid>
    </item>
    <item>
      <title>OESA-2026-1566 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-1566</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP1: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;udp: Deal with race between UDP socket address change and rehash&lt;/p&gt;
&lt;p&gt;If a UDP socket changes its local address while it&amp;amp;apos;s receiving
datagrams, as a result of connect(), there is a period during which
a lookup operation might fail to find it, after the address is changed
but before the secondary hash (port and address) and the four-tuple
hash (local and remote ports and addresses) are updated.&lt;/p&gt;
&lt;p&gt;Secondary hash chains were introduced by commit 30fff9231fad (&amp;amp;quot;udp:
bind() optimisation&amp;amp;quot;) and, as a result, a rehash operation became
needed to make a bound socket reachable again after a connect().&lt;/p&gt;
&lt;p&gt;This operation was introduced by commit 719f835853a9 (&amp;amp;quot;udp: add
rehash on connect()&amp;amp;quot;) which isn&amp;amp;apos;t however a complete fix: the
socket will be found once the rehashing completes, but not while
it&amp;amp;apos;s pending.&lt;/p&gt;
&lt;p&gt;This is noticeable with a socat(1) server in UDP4-LISTEN mode, and a
client sending datagrams to it. After the server receives the first
datagram (cf. _xioopen_ipdgram_listen()), it issues a connect() to
the address of the sender, in order to set up a directed flow.&lt;/p&gt;
&lt;p&gt;Now, if the client, running on a different CPU thread, happens to
send a (subsequent) datagram while the server&amp;amp;apos;s socket changes its
address, but is not rehashed yet, this will result in a failed
lookup and a port unreachable error delivered to the…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:24.03-LTS-SP1: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;udp: Deal with race between UDP socket address change and rehash&lt;/p&gt;
&lt;p&gt;If a UDP socket changes its local address while it&amp;amp;apos;s receiving
datagrams, as a result of connect(), there is a period during which
a lookup operation might fail to find it, after the address is changed
but before the secondary hash (port and address) and the four-tuple
hash (local and remote ports and addresses) are updated.&lt;/p&gt;
&lt;p&gt;Secondary hash chains were introduced by commit 30fff9231fad (&amp;amp;quot;udp:
bind() optimisation&amp;amp;quot;) and, as a result, a rehash operation became
needed to make a bound socket reachable again after a connect().&lt;/p&gt;
&lt;p&gt;This operation was introduced by commit 719f835853a9 (&amp;amp;quot;udp: add
rehash on connect()&amp;amp;quot;) which isn&amp;amp;apos;t however a complete fix: the
socket will be found once the rehashing completes, but not while
it&amp;amp;apos;s pending.&lt;/p&gt;
&lt;p&gt;This is noticeable with a socat(1) server in UDP4-LISTEN mode, and a
client sending datagrams to it. After the server receives the first
datagram (cf. _xioopen_ipdgram_listen()), it issues a connect() to
the address of the sender, in order to set up a directed flow.&lt;/p&gt;
&lt;p&gt;Now, if the client, running on a different CPU thread, happens to
send a (subsequent) datagram while the server&amp;amp;apos;s socket changes its
address, but is not rehashed yet, this will result in a failed
lookup and a port unreachable error delivered to the…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-1566</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:20416-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20416-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/opensuse-su-2026:20416-1</guid>
    </item>
    <item>
      <title>RLSA-2026:38491 — Important: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rlsa-2026:38491</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Rocky Linux:9: kernel&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: Linux kernel: Memory leak in networking due to incorrect GRO packet handling (CVE-2026-22979)&lt;/p&gt;
&lt;p&gt;* kernel: rtmutex: Use waiter::task instead of current in remove_waiter() (CVE-2026-43499)&lt;/p&gt;
&lt;p&gt;* kernel: net: bridge: use a stable FDB dst snapshot in RCU readers (CVE-2026-46086)&lt;/p&gt;
&lt;p&gt;* kernel: crypto: ccp - copy IV using skcipher ivsize (CVE-2026-53016)&lt;/p&gt;
&lt;p&gt;* kernel: futex/requeue: Prevent NULL pointer dereference in remove_waiter() on self-deadlock (CVE-2026-53166)&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* Kernel panic very early during boot while reading a tracefs file (available_filter_functions) due to invalid module name pointer [9.8.z] (JIRA:Rocky Linux-183236)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Rocky Linux:9: kernel&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;* kernel: Linux kernel: Memory leak in networking due to incorrect GRO packet handling (CVE-2026-22979)&lt;/p&gt;
&lt;p&gt;* kernel: rtmutex: Use waiter::task instead of current in remove_waiter() (CVE-2026-43499)&lt;/p&gt;
&lt;p&gt;* kernel: net: bridge: use a stable FDB dst snapshot in RCU readers (CVE-2026-46086)&lt;/p&gt;
&lt;p&gt;* kernel: crypto: ccp - copy IV using skcipher ivsize (CVE-2026-53016)&lt;/p&gt;
&lt;p&gt;* kernel: futex/requeue: Prevent NULL pointer dereference in remove_waiter() on self-deadlock (CVE-2026-53166)&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* Kernel panic very early during boot while reading a tracefs file (available_filter_functions) due to invalid module name pointer [9.8.z] (JIRA:Rocky Linux-183236)&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rlsa-2026:38491</guid>
    </item>
    <item>
      <title>SSA-019113 — SSA-019113: Vulnerabilities in the additional GNU/Linux subsystem of the SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP V3.1.6</title>
      <link>https://cve.radiocsirt.org/vuln/ssa-019113</link>
      <description>&lt;p&gt;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).&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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).&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ssa-019113</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:0962-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:0962-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-2026:0962-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-22979</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-22979</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 175 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: fix memory leak in skb_segment_list for GRO packets When skb_segment_list() is called during packet forwarding, it handles packets that were aggregated by the GRO engine. Historically, the segmentation logic in skb_segment_list assumes that individual segments are split from a parent SKB and may need to carry their own socket memory accounting. Accordingly, the code transfers truesize from the parent to the newly created segments. Prior to commit ed4cccef64c1 (&amp;#34;gro: fix ownership transfer&amp;#34;), this truesize subtraction in skb_segment_list() was valid because fragments still carry a reference to the original socket. However, commit ed4cccef64c1 (&amp;#34;gro: fix ownership transfer&amp;#34;) changed this behavior by ensuring that fraglist entries are explicitly orphaned (skb-&amp;gt;sk = NULL) to prevent illegal orphaning later in the stack. This change meant that the entire socket memory charge remained with the head SKB, but the corresponding accounting logic in skb_segment_list() was never updated. As a result, the current code unconditionally adds each fragment&amp;#39;s truesize to delta_truesize and subtracts it from the parent SKB. Since the fragments are no longer charged to the socket, this subtraction results in an effective under-count of memory when the head is freed. This causes sk_wmem_alloc to remain non-zero, preventing socket destruction and leading to a persistent memory leak. The leak can be observed via KMEMLEAK when…&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 175 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: net: fix memory leak in skb_segment_list for GRO packets When skb_segment_list() is called during packet forwarding, it handles packets that were aggregated by the GRO engine. Historically, the segmentation logic in skb_segment_list assumes that individual segments are split from a parent SKB and may need to carry their own socket memory accounting. Accordingly, the code transfers truesize from the parent to the newly created segments. Prior to commit ed4cccef64c1 (&amp;#34;gro: fix ownership transfer&amp;#34;), this truesize subtraction in skb_segment_list() was valid because fragments still carry a reference to the original socket. However, commit ed4cccef64c1 (&amp;#34;gro: fix ownership transfer&amp;#34;) changed this behavior by ensuring that fraglist entries are explicitly orphaned (skb-&amp;gt;sk = NULL) to prevent illegal orphaning later in the stack. This change meant that the entire socket memory charge remained with the head SKB, but the corresponding accounting logic in skb_segment_list() was never updated. As a result, the current code unconditionally adds each fragment&amp;#39;s truesize to delta_truesize and subtracts it from the parent SKB. Since the fragments are no longer charged to the socket, this subtraction results in an effective under-count of memory when the head is freed. This causes sk_wmem_alloc to remain non-zero, preventing socket destruction and leading to a persistent memory leak. The leak can be observed via KMEMLEAK when…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-22979</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-0215 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0215</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0215</guid>
    </item>
  </channel>
</rss>
