<?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>Sat, 03 Oct 2026 02:27:46 +0000</lastBuildDate>
    <item>
      <title>ALSA-2026:43307 — Important: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/alsa-2026:43307</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: crypto: af_alg - zero initialize memory allocated via sock_kmalloc (CVE-2025-71113)
  * kernel: scsi: core: Wake up the error handler when final completions race against each other (CVE-2026-23110)
  * kernel: net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels (CVE-2026-46099)
  * kernel: fanotify: fix false positive on permission events (CVE-2026-46150)
  * kernel: drm: Set old handle to NULL before prime swap in change_handle (CVE-2026-46215)
  * kernel: Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp (CVE-2026-53071)&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* [AlmaLinux9] tools/lib/perf/Makefile: libperf includes appended after CFLAGS causes parallel build race, breaking kernel builds [almalinux-9.8.z] (JIRA:AlmaLinux-183980)
  * [AlmaLinux-9.8.z]: mlx5: include bug fixes (JIRA:AlmaLinux-188121)
  * dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() [almalinux-9.8.z] (JIRA:AlmaLinux-212061)&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: crypto: af_alg - zero initialize memory allocated via sock_kmalloc (CVE-2025-71113)
  * kernel: scsi: core: Wake up the error handler when final completions race against each other (CVE-2026-23110)
  * kernel: net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels (CVE-2026-46099)
  * kernel: fanotify: fix false positive on permission events (CVE-2026-46150)
  * kernel: drm: Set old handle to NULL before prime swap in change_handle (CVE-2026-46215)
  * kernel: Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp (CVE-2026-53071)&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* [AlmaLinux9] tools/lib/perf/Makefile: libperf includes appended after CFLAGS causes parallel build race, breaking kernel builds [almalinux-9.8.z] (JIRA:AlmaLinux-183980)
  * [AlmaLinux-9.8.z]: mlx5: include bug fixes (JIRA:AlmaLinux-188121)
  * dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() [almalinux-9.8.z] (JIRA:AlmaLinux-212061)&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:43307</guid>
    </item>
    <item>
      <title>bdu:2026-11580</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-11580</link>
      <description>bdu:2026-11580</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-11580</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-23110</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-23110</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-23110</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-364663</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-364663</link>
      <description>EUVD-2026-364663</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-364663</guid>
    </item>
    <item>
      <title>fkie_cve-2026-23110</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-23110</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;scsi: core: Wake up the error handler when final completions race against each other&lt;/p&gt;
&lt;p&gt;The fragile ordering between marking commands completed or failed so
that the error handler only wakes when the last running command
completes or times out has race conditions. These race conditions can
cause the SCSI layer to fail to wake the error handler, leaving I/O
through the SCSI host stuck as the error state cannot advance.&lt;/p&gt;
&lt;p&gt;First, there is an memory ordering issue within scsi_dec_host_busy().
The write which clears SCMD_STATE_INFLIGHT may be reordered with reads
counting in scsi_host_busy(). While the local CPU will see its own
write, reordering can allow other CPUs in scsi_dec_host_busy() or
scsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to
see a host busy equal to the host_failed count.&lt;/p&gt;
&lt;p&gt;This race condition can be prevented with a memory barrier on the error
path to force the write to be visible before counting host busy
commands.&lt;/p&gt;
&lt;p&gt;Second, there is a general ordering issue with scsi_eh_inc_host_failed(). By
counting busy commands before incrementing host_failed, it can race with a
final command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does
not see host_failed incremented but scsi_eh_inc_host_failed() counts busy
commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(),
resulting in neither waking the error handler task.&lt;/p&gt;
&lt;p&gt;This needs the call to scsi_host_busy() t…&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;scsi: core: Wake up the error handler when final completions race against each other&lt;/p&gt;
&lt;p&gt;The fragile ordering between marking commands completed or failed so
that the error handler only wakes when the last running command
completes or times out has race conditions. These race conditions can
cause the SCSI layer to fail to wake the error handler, leaving I/O
through the SCSI host stuck as the error state cannot advance.&lt;/p&gt;
&lt;p&gt;First, there is an memory ordering issue within scsi_dec_host_busy().
The write which clears SCMD_STATE_INFLIGHT may be reordered with reads
counting in scsi_host_busy(). While the local CPU will see its own
write, reordering can allow other CPUs in scsi_dec_host_busy() or
scsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to
see a host busy equal to the host_failed count.&lt;/p&gt;
&lt;p&gt;This race condition can be prevented with a memory barrier on the error
path to force the write to be visible before counting host busy
commands.&lt;/p&gt;
&lt;p&gt;Second, there is a general ordering issue with scsi_eh_inc_host_failed(). By
counting busy commands before incrementing host_failed, it can race with a
final command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does
not see host_failed incremented but scsi_eh_inc_host_failed() counts busy
commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(),
resulting in neither waking the error handler task.&lt;/p&gt;
&lt;p&gt;This needs the call to scsi_host_busy() t…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-23110</guid>
    </item>
    <item>
      <title>GHSA-7p3h-gfr2-rwcv</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-7p3h-gfr2-rwcv</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;scsi: core: Wake up the error handler when final completions race against each other&lt;/p&gt;
&lt;p&gt;The fragile ordering between marking commands completed or failed so
that the error handler only wakes when the last running command
completes or times out has race conditions. These race conditions can
cause the SCSI layer to fail to wake the error handler, leaving I/O
through the SCSI host stuck as the error state cannot advance.&lt;/p&gt;
&lt;p&gt;First, there is an memory ordering issue within scsi_dec_host_busy().
The write which clears SCMD_STATE_INFLIGHT may be reordered with reads
counting in scsi_host_busy(). While the local CPU will see its own
write, reordering can allow other CPUs in scsi_dec_host_busy() or
scsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to
see a host busy equal to the host_failed count.&lt;/p&gt;
&lt;p&gt;This race condition can be prevented with a memory barrier on the error
path to force the write to be visible before counting host busy
commands.&lt;/p&gt;
&lt;p&gt;Second, there is a general ordering issue with scsi_eh_inc_host_failed(). By
counting busy commands before incrementing host_failed, it can race with a
final command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does
not see host_failed incremented but scsi_eh_inc_host_failed() counts busy
commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(),
resulting in neither waking the error handler task.&lt;/p&gt;
&lt;p&gt;This needs the call to scsi_host_busy() t…&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;scsi: core: Wake up the error handler when final completions race against each other&lt;/p&gt;
&lt;p&gt;The fragile ordering between marking commands completed or failed so
that the error handler only wakes when the last running command
completes or times out has race conditions. These race conditions can
cause the SCSI layer to fail to wake the error handler, leaving I/O
through the SCSI host stuck as the error state cannot advance.&lt;/p&gt;
&lt;p&gt;First, there is an memory ordering issue within scsi_dec_host_busy().
The write which clears SCMD_STATE_INFLIGHT may be reordered with reads
counting in scsi_host_busy(). While the local CPU will see its own
write, reordering can allow other CPUs in scsi_dec_host_busy() or
scsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to
see a host busy equal to the host_failed count.&lt;/p&gt;
&lt;p&gt;This race condition can be prevented with a memory barrier on the error
path to force the write to be visible before counting host busy
commands.&lt;/p&gt;
&lt;p&gt;Second, there is a general ordering issue with scsi_eh_inc_host_failed(). By
counting busy commands before incrementing host_failed, it can race with a
final command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does
not see host_failed incremented but scsi_eh_inc_host_failed() counts busy
commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(),
resulting in neither waking the error handler task.&lt;/p&gt;
&lt;p&gt;This needs the call to scsi_host_busy() t…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-7p3h-gfr2-rwcv</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-23110 — scsi: core: Wake up the error handler when final completions race against each other</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-23110</link>
      <description>msrc_CVE-2026-23110</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-23110</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>RHSA-2026:55445 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rhsa-2026:55445</link>
      <description>&lt;p&gt;kernel: Arm Processors: Privilege escalation or information disclosure via writes to higher exception level resources kernel: iommu: disable SVA when CONFIG_X86 is set kernel: crypto: seqiv - Do not use req-&amp;gt;iv after crypto_aead_encrypt kernel: scsi: core: Wake up the error handler when final completions race against each other kernel: mm: thp: deny THP for files on anonymous inodes kernel: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() kernel: drm/amd/display: Do not skip unrelated mode changes in DSC validation kernel: ALSA: usb-audio: Add sanity check for OOB writes at silencing kernel: rxrpc: Fix potential UAF after skb_unshare() failure kernel: netfilter: nat: use kfree_rcu to release ops kernel: dm log: fix out-of-bounds write due to region_count overflow kernel: net/sched: act_api: use RCU with deferred freeing for action lifecycle&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel: Arm Processors: Privilege escalation or information disclosure via writes to higher exception level resources kernel: iommu: disable SVA when CONFIG_X86 is set kernel: crypto: seqiv - Do not use req-&amp;gt;iv after crypto_aead_encrypt kernel: scsi: core: Wake up the error handler when final completions race against each other kernel: mm: thp: deny THP for files on anonymous inodes kernel: netfilter: nf_conntrack_h323: check for zero length in DecodeQ931() kernel: drm/amd/display: Do not skip unrelated mode changes in DSC validation kernel: ALSA: usb-audio: Add sanity check for OOB writes at silencing kernel: rxrpc: Fix potential UAF after skb_unshare() failure kernel: netfilter: nat: use kfree_rcu to release ops kernel: dm log: fix out-of-bounds write due to region_count overflow kernel: net/sched: act_api: use RCU with deferred freeing for action lifecycle&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/rhsa-2026:55445</guid>
    </item>
    <item>
      <title>RLSA-2026:43307 — Important: kernel security, bug fix, and enhancement update</title>
      <link>https://cve.radiocsirt.org/vuln/rlsa-2026:43307</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: crypto: af_alg - zero initialize memory allocated via sock_kmalloc (CVE-2025-71113)&lt;/p&gt;
&lt;p&gt;* kernel: scsi: core: Wake up the error handler when final completions race against each other (CVE-2026-23110)&lt;/p&gt;
&lt;p&gt;* kernel: Linux kernel: xfrm single-frag length not properly limited ()&lt;/p&gt;
&lt;p&gt;* kernel: net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels (CVE-2026-46099)&lt;/p&gt;
&lt;p&gt;* kernel: fanotify: fix false positive on permission events (CVE-2026-46150)&lt;/p&gt;
&lt;p&gt;* kernel: drm: Set old handle to NULL before prime swap in change_handle (CVE-2026-46215)&lt;/p&gt;
&lt;p&gt;* kernel: Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp (CVE-2026-53071)&lt;/p&gt;
&lt;p&gt;* kernel: can: bcm: thrtimer use-after-free during RX operation teardown ()&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* [Rocky Linux9] tools/lib/perf/Makefile: libperf includes appended after CFLAGS causes parallel build race, breaking kernel builds [rhel-9.8.z] (JIRA:Rocky Linux-183980)&lt;/p&gt;
&lt;p&gt;* [Rocky Linux-9.8.z]: mlx5: include bug fixes (JIRA:Rocky Linux-188121)&lt;/p&gt;
&lt;p&gt;* dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() [rhel-9.8.z] (JIRA:Rocky Linux-212061)&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: crypto: af_alg - zero initialize memory allocated via sock_kmalloc (CVE-2025-71113)&lt;/p&gt;
&lt;p&gt;* kernel: scsi: core: Wake up the error handler when final completions race against each other (CVE-2026-23110)&lt;/p&gt;
&lt;p&gt;* kernel: Linux kernel: xfrm single-frag length not properly limited ()&lt;/p&gt;
&lt;p&gt;* kernel: net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels (CVE-2026-46099)&lt;/p&gt;
&lt;p&gt;* kernel: fanotify: fix false positive on permission events (CVE-2026-46150)&lt;/p&gt;
&lt;p&gt;* kernel: drm: Set old handle to NULL before prime swap in change_handle (CVE-2026-46215)&lt;/p&gt;
&lt;p&gt;* kernel: Bluetooth: l2cap: Add missing chan lock in l2cap_ecred_reconf_rsp (CVE-2026-53071)&lt;/p&gt;
&lt;p&gt;* kernel: can: bcm: thrtimer use-after-free during RX operation teardown ()&lt;/p&gt;
&lt;p&gt;Bug Fix(es) and Enhancement(s):&lt;/p&gt;
&lt;p&gt;* [Rocky Linux9] tools/lib/perf/Makefile: libperf includes appended after CFLAGS causes parallel build race, breaking kernel builds [rhel-9.8.z] (JIRA:Rocky Linux-183980)&lt;/p&gt;
&lt;p&gt;* [Rocky Linux-9.8.z]: mlx5: include bug fixes (JIRA:Rocky Linux-188121)&lt;/p&gt;
&lt;p&gt;* dpll: fix NULL pointer dereference in dpll_msg_add_pin_ref_sync() [rhel-9.8.z] (JIRA:Rocky Linux-212061)&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:43307</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-23110</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23110</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 179 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: scsi: core: Wake up the error handler when final completions race against each other The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance. First, there is an memory ordering issue within scsi_dec_host_busy(). The write which clears SCMD_STATE_INFLIGHT may be reordered with reads counting in scsi_host_busy(). While the local CPU will see its own write, reordering can allow other CPUs in scsi_dec_host_busy() or scsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to see a host busy equal to the host_failed count. This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands. Second, there is a general ordering issue with scsi_eh_inc_host_failed(). By counting busy commands before incrementing host_failed, it can race with a final command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does not see host_failed incremented but scsi_eh_inc_host_failed() counts busy commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(), resulting in neither waking the error handler task. This needs the call to scsi_host_busy() to be m…&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 179 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: scsi: core: Wake up the error handler when final completions race against each other The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance. First, there is an memory ordering issue within scsi_dec_host_busy(). The write which clears SCMD_STATE_INFLIGHT may be reordered with reads counting in scsi_host_busy(). While the local CPU will see its own write, reordering can allow other CPUs in scsi_dec_host_busy() or scsi_eh_inc_host_failed() to see a raised busy count, causing no CPU to see a host busy equal to the host_failed count. This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands. Second, there is a general ordering issue with scsi_eh_inc_host_failed(). By counting busy commands before incrementing host_failed, it can race with a final command in scsi_dec_host_busy(), such that scsi_dec_host_busy() does not see host_failed incremented but scsi_eh_inc_host_failed() counts busy commands before SCMD_STATE_INFLIGHT is cleared by scsi_dec_host_busy(), resulting in neither waking the error handler task. This needs the call to scsi_host_busy() to be m…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-23110</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-0324 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-0324</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-0324</guid>
    </item>
  </channel>
</rss>
