<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://cve.radiocsirt.org/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-10-02T17:31:27.345222+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>csirt@opendfir.org</email>
  </author>
  <link href="https://cve.radiocsirt.org" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/bell-cve-2026-31503</id>
    <title>BELL-CVE-2026-31503</title>
    <updated>2026-10-02T17:31:27.754524+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><strong>Affected:</strong> Alpaquita:23: linux-lts, Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/bell-cve-2026-31503"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0519</id>
    <title>certfr-2026-avi-0519 — De multiples vulnérabilités ont été découvertes dans Microsoft Azure Linux. Elles permettent à un attaquant de provoque…</title>
    <updated>2026-10-02T17:31:27.754601+00:00</updated>
    <content>certfr-2026-avi-0519</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2026-avi-0519"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-364751</id>
    <title>EUVD-2026-364751</title>
    <updated>2026-10-02T17:31:27.754623+00:00</updated>
    <content>EUVD-2026-364751</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-364751"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-31503</id>
    <title>fkie_cve-2026-31503</title>
    <updated>2026-10-02T17:31:27.754636+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>udp: Fix wildcard bind conflict check when using hash2</p>
<p>When binding a udp_sock to a local address and port, UDP uses
two hashes (udptable-&gt;hash and udptable-&gt;hash2) for collision
detection. The current code switches to "hash2" when
hslot-&gt;count &gt; 10.</p>
<p>"hash2" is keyed by local address and local port.
"hash" is keyed by local port only.</p>
<p>The issue can be shown in the following bind sequence (pseudo code):</p>
<p>bind(fd1,  "[fd00::1]:8888")
bind(fd2,  "[fd00::2]:8888")
bind(fd3,  "[fd00::3]:8888")
bind(fd4,  "[fd00::4]:8888")
bind(fd5,  "[fd00::5]:8888")
bind(fd6,  "[fd00::6]:8888")
bind(fd7,  "[fd00::7]:8888")
bind(fd8,  "[fd00::8]:8888")
bind(fd9,  "[fd00::9]:8888")
bind(fd10, "[fd00::10]:8888")</p>
<p>/* Correctly return -EADDRINUSE because "hash" is used
 * instead of "hash2". udp_lib_lport_inuse() detects the
 * conflict.
 */
bind(fail_fd, "[::]:8888")</p>
<p>/* After one more socket is bound to "[fd00::11]:8888",
 * hslot-&gt;count exceeds 10 and "hash2" is used instead.
 */
bind(fd11, "[fd00::11]:8888")
bind(fail_fd, "[::]:8888")      /* succeeds unexpectedly */</p>
<p>The same issue applies to the IPv4 wildcard address "0.0.0.0"
and the IPv4-mapped wildcard address "::ffff:0.0.0.0". For
example, if there are existing sockets bound to
"192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or
"[::ffff:0.0.0.0]:8888" can also miss the conflict when
hslot-&gt;count &gt; 10.</p>
<p>TCP inet_csk_get_port() already has the correct check in
inet_u…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-31503"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-8g49-x5x5-4c9c</id>
    <title>GHSA-8g49-x5x5-4c9c</title>
    <updated>2026-10-02T17:31:27.754695+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>udp: Fix wildcard bind conflict check when using hash2</p>
<p>When binding a udp_sock to a local address and port, UDP uses
two hashes (udptable-&gt;hash and udptable-&gt;hash2) for collision
detection. The current code switches to "hash2" when
hslot-&gt;count &gt; 10.</p>
<p>"hash2" is keyed by local address and local port.
"hash" is keyed by local port only.</p>
<p>The issue can be shown in the following bind sequence (pseudo code):</p>
<p>bind(fd1,  "[fd00::1]:8888")
bind(fd2,  "[fd00::2]:8888")
bind(fd3,  "[fd00::3]:8888")
bind(fd4,  "[fd00::4]:8888")
bind(fd5,  "[fd00::5]:8888")
bind(fd6,  "[fd00::6]:8888")
bind(fd7,  "[fd00::7]:8888")
bind(fd8,  "[fd00::8]:8888")
bind(fd9,  "[fd00::9]:8888")
bind(fd10, "[fd00::10]:8888")</p>
<p>/* Correctly return -EADDRINUSE because "hash" is used
 * instead of "hash2". udp_lib_lport_inuse() detects the
 * conflict.
 */
bind(fail_fd, "[::]:8888")</p>
<p>/* After one more socket is bound to "[fd00::11]:8888",
 * hslot-&gt;count exceeds 10 and "hash2" is used instead.
 */
bind(fd11, "[fd00::11]:8888")
bind(fail_fd, "[::]:8888")      /* succeeds unexpectedly */</p>
<p>The same issue applies to the IPv4 wildcard address "0.0.0.0"
and the IPv4-mapped wildcard address "::ffff:0.0.0.0". For
example, if there are existing sockets bound to
"192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or
"[::ffff:0.0.0.0]:8888" can also miss the conflict when
hslot-&gt;count &gt; 10.</p>
<p>TCP inet_csk_get_port() already has the correct check in
inet_u…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-8g49-x5x5-4c9c"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/icsa-26-209-04</id>
    <title>ICSA-26-209-04 — Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP</title>
    <updated>2026-10-02T17:31:27.754733+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><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 is preparing fix versions and recommends specific countermeasures for products where fixes are not, or not yet available.</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/icsa-26-209-04"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/msrc_cve-2026-31503</id>
    <title>msrc_CVE-2026-31503 — udp: Fix wildcard bind conflict check when using hash2</title>
    <updated>2026-10-02T17:31:27.754954+00:00</updated>
    <content>msrc_CVE-2026-31503</content>
    <link href="https://cve.radiocsirt.org/vuln/msrc_cve-2026-31503"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/oesa-2026-2493</id>
    <title>OESA-2026-2493 — kernel security update</title>
    <updated>2026-10-02T17:31:27.754971+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><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>scsi: target: Fix recursive locking in __configfs_open_file()</p>
<p>In flush_write_buffer, &amp;amp;p-&amp;gt;frag_sem is acquired and then the loaded store
function is called, which, here, is target_core_item_dbroot_store().  This
function called filp_open(), following which these functions were called
(in reverse order), according to the call trace:</p>
<p>down_read
  __configfs_open_file
  do_dentry_open
  vfs_open
  do_open
  path_openat
  do_filp_open
  file_open_name
  filp_open
  target_core_item_dbroot_store
  flush_write_buffer
  configfs_write_iter</p>
<p>target_core_item_dbroot_store() tries to validate the new file path by
trying to open the file path provided to it; however, in this case, the bug
report shows:</p>
<p>db_root: not a directory: /sys/kernel/config/target/dbroot</p>
<p>indicating that the same configfs file was tried to be opened, on which it
is currently working on. Thus, it is trying to acquire frag_sem semaphore
of the same file of which it already holds the semaphore obtained in
flush_write_buffer(), leading to acquiring the semaphore in a nested manner
and a possibility of recursive locking.</p>
<p>Fix this by modifying target_core_item_dbroot_store() to use kern_path()
instead of filp_open() to avoid opening the file using filesystem-specific
function __configfs_open_file(), and further modifying it to make this fix
compatible.(CVE-2026-23292)…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/oesa-2026-2493"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2026:20826-1</id>
    <title>openSUSE-SU-2026:20826-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-02T17:31:27.755169+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2026:20826-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/rlsa-2026:64775</id>
    <title>RLSA-2026:64775 — Important: kernel security, bug fix, and enhancement update</title>
    <updated>2026-10-02T17:31:27.755351+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Rocky Linux:10: kernel</p>
<p>The kernel packages contain the Linux kernel, the core of any Linux operating system.</p>
<p>Security Fix(es):</p>
<p>* kernel: can: bcm: add locking for bcm_op runtime updates (CVE-2025-38004)</p>
<p>* kernel: ipv6: add NULL checks for idev in SRv6 paths (CVE-2026-23442)</p>
<p>* kernel: udp: Fix wildcard bind conflict check when using hash2 (CVE-2026-31503)</p>
<p>* kernel: ipv6: prevent possible UaF in addrconf_permanent_addr() (CVE-2026-43339)</p>
<p>* kernel: tcp: call sk_data_ready() after listener migration (CVE-2026-46015)</p>
<p>* kernel: inet: RAW sockets using IPPROTO_RAW MUST drop incoming ICMP (CVE-2026-46266)</p>
<p>* kernel: flow_dissector: do not dissect PPPoE PFC frames (CVE-2026-46306)</p>
<p>* kernel: io_uring/poll: fix signed comparison in io_poll_get_ownership() (CVE-2026-52933)</p>
<p>* kernel: ppp: require CAP_NET_ADMIN in target netns for unattached ioctls (CVE-2026-53075)</p>
<p>* kernel: KVM: arm64: Take the SRCU lock for page table walks in fault injection and AT emulation (CVE-2026-53277)</p>
<p>* kernel: ipv6: sit: reload inner IPv6 header after GSO offloads (CVE-2026-53228)</p>
<p>* kernel: net: add pskb_may_pull() to skb_gro_receive_list() (CVE-2026-53235)</p>
<p>* kernel: net: guard timestamp cmsgs to real error queue skbs (CVE-2026-53223)</p>
<p>* kernel: ipv6: mcast: Fix use-after-free when processing MLD queries (CVE-2026-53275)</p>
<p>* kernel: ipv6: anycast: insert aca into global hash under idev-&gt;lock (CVE-2026-53259)</p>
<p>* kernel: ipv4: free net-&gt;ipv4.sysctl_local_reserved_ports after unregister_net_sysctl_table() (CVE-2026-64002)</p>
<p>*…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/rlsa-2026:64775"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ssa-019113</id>
    <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>
    <updated>2026-10-02T17:31:27.755460+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><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></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ssa-019113"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/suse-su-2026:21834-1</id>
    <title>SUSE-SU-2026:21834-1 — Security update for the Linux Kernel</title>
    <updated>2026-10-02T17:31:27.755736+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Security update for the Linux Kernel</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/suse-su-2026:21834-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31503</id>
    <title>UBUNTU-CVE-2026-31503</title>
    <updated>2026-10-02T17:31:27.755858+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe and 232 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: udp: Fix wildcard bind conflict check when using hash2 When binding a udp_sock to a local address and port, UDP uses two hashes (udptable-&gt;hash and udptable-&gt;hash2) for collision detection. The current code switches to "hash2" when hslot-&gt;count &gt; 10. "hash2" is keyed by local address and local port. "hash" is keyed by local port only. The issue can be shown in the following bind sequence (pseudo code): bind(fd1,  "[fd00::1]:8888") bind(fd2,  "[fd00::2]:8888") bind(fd3,  "[fd00::3]:8888") bind(fd4,  "[fd00::4]:8888") bind(fd5,  "[fd00::5]:8888") bind(fd6,  "[fd00::6]:8888") bind(fd7,  "[fd00::7]:8888") bind(fd8,  "[fd00::8]:8888") bind(fd9,  "[fd00::9]:8888") bind(fd10, "[fd00::10]:8888") /* Correctly return -EADDRINUSE because "hash" is used  * instead of "hash2". udp_lib_lport_inuse() detects the  * conflict.  */ bind(fail_fd, "[::]:8888") /* After one more socket is bound to "[fd00::11]:8888",  * hslot-&gt;count exceeds 10 and "hash2" is used instead.  */ bind(fd11, "[fd00::11]:8888") bind(fail_fd, "[::]:8888")      /* succeeds unexpectedly */ The same issue applies to the IPv4 wildcard address "0.0.0.0" and the IPv4-mapped wildcard address "::ffff:0.0.0.0". For example, if there are existing sockets bound to "192.168.1.[1-11]:8888", then binding "0.0.0.0:8888" or "[::ffff:0.0.0.0]:8888" can also miss the conflict when hslot-&gt;count &gt; 10. TCP inet_csk_get_port() already has the correct check in inet_use_bhash2…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-31503"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1252</id>
    <title>WID-SEC-W-2026-1252 — Linux Kernel: Mehrere Schwachstellen</title>
    <updated>2026-10-02T17:31:27.756138+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen, Sicherheitsmaßnahmen zu umgehen, Informationen offenzulegen, andere nicht näher spezifizierte Auswirkungen zu verursachen und möglicherweise Code auszuführen.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1252"/>
  </entry>
</feed>
