<?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-02T18:38:11.178280+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-64405</id>
    <title>BELL-CVE-2026-64405</title>
    <updated>2026-10-02T18:38:11.205410+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-64405"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0981</id>
    <title>certfr-2026-avi-0981 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian. Elles permettent à un attaquant de provo…</title>
    <updated>2026-10-02T18:38:11.205466+00:00</updated>
    <content>certfr-2026-avi-0981</content>
    <link href="https://cve.radiocsirt.org/vuln/certfr-2026-avi-0981"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/euvd-2026-353312</id>
    <title>EUVD-2026-353312</title>
    <updated>2026-10-02T18:38:11.205487+00:00</updated>
    <content>EUVD-2026-353312</content>
    <link href="https://cve.radiocsirt.org/vuln/euvd-2026-353312"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/fkie_cve-2026-64405</id>
    <title>fkie_cve-2026-64405</title>
    <updated>2026-10-02T18:38:11.205499+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>Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()</p>
<p>hci_abort_conn() read hci_skb_event(hdev-&gt;sent_cmd) when a connection
was pending, but hdev-&gt;sent_cmd can be NULL while req_status is still
HCI_REQ_PEND, leading to a NULL pointer dereference and a general
protection fault from the hci_rx_work() receive path.</p>
<p>Instead of inspecting hdev-&gt;sent_cmd, track the in-flight create
connection command with a new per-connection HCI_CONN_CREATE flag and
route all cancellation through hci_cancel_connect_sync(), which
dispatches to a dedicated per-type cancel function. The create command
is in exactly one of two states: still queued, or in flight. The cancel
function holds cmd_sync_work_lock across the whole decision: the worker
takes this lock to dequeue every entry, so while it is held a queued
command cannot start running and an in-flight command cannot complete
and let the next command become pending. This keeps the flag test and
hci_cmd_sync_cancel() atomic with respect to the worker, so a queued
command is simply dequeued, and an in-flight command owned by this
connection is cancelled without the risk of cancelling an unrelated
command that became pending in the meantime. CIS uses the same flag
mechanism via HCI_CONN_CREATE_CIS but cannot be dequeued per-connection.</p>
<p>hci_acl_create_conn_sync() and hci_le_create_conn_sync() clear
HCI_CONN_CREATE after the create command completes, but the command
status h…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/fkie_cve-2026-64405"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ghsa-xvhg-76qh-24v9</id>
    <title>GHSA-xvhg-76qh-24v9</title>
    <updated>2026-10-02T18:38:11.205542+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>Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()</p>
<p>hci_abort_conn() read hci_skb_event(hdev-&gt;sent_cmd) when a connection
was pending, but hdev-&gt;sent_cmd can be NULL while req_status is still
HCI_REQ_PEND, leading to a NULL pointer dereference and a general
protection fault from the hci_rx_work() receive path.</p>
<p>Instead of inspecting hdev-&gt;sent_cmd, track the in-flight create
connection command with a new per-connection HCI_CONN_CREATE flag and
route all cancellation through hci_cancel_connect_sync(), which
dispatches to a dedicated per-type cancel function. The create command
is in exactly one of two states: still queued, or in flight. The cancel
function holds cmd_sync_work_lock across the whole decision: the worker
takes this lock to dequeue every entry, so while it is held a queued
command cannot start running and an in-flight command cannot complete
and let the next command become pending. This keeps the flag test and
hci_cmd_sync_cancel() atomic with respect to the worker, so a queued
command is simply dequeued, and an in-flight command owned by this
connection is cancelled without the risk of cancelling an unrelated
command that became pending in the meantime. CIS uses the same flag
mechanism via HCI_CONN_CREATE_CIS but cannot be dequeued per-connection.</p>
<p>hci_acl_create_conn_sync() and hci_le_create_conn_sync() clear
HCI_CONN_CREATE after the create command completes, but the command
status h…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ghsa-xvhg-76qh-24v9"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/msrc_cve-2026-64405</id>
    <title>msrc_CVE-2026-64405 — Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()</title>
    <updated>2026-10-02T18:38:11.205573+00:00</updated>
    <content>msrc_CVE-2026-64405</content>
    <link href="https://cve.radiocsirt.org/vuln/msrc_cve-2026-64405"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/oesa-2026-3707</id>
    <title>OESA-2026-3707 — kernel security update</title>
    <updated>2026-10-02T18:38:11.205590+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> openEuler:24.03-LTS-SP1: 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>seg6: separate dst_cache for input and output paths in seg6 lwtunnel</p>
<p>The seg6 lwtunnel uses a single dst_cache per encap route, shared
between seg6_input_core() and seg6_output_core(). These two paths
can perform the post-encap SID lookup in different routing contexts
(e.g., ip rules matching on the ingress interface, or VRF table
separation). Whichever path runs first populates the cache, and the
other reuses it blindly, bypassing its own lookup.</p>
<p>Fix this by splitting the cache into cache_input and cache_output,
so each path maintains its own cached dst independently.(CVE-2026-31668)</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE</p>
<p>The current implementation incorrectly handles memory regions (MRs) with
page sizes different from the system PAGE_SIZE. The core issue is that
rxe_set_page() is called with mr-&amp;gt;page_size step increments, but the
page_list stores individual struct page pointers, each representing
PAGE_SIZE of memory.</p>
<p>ib_sg_to_page() has ensured that when i&amp;gt;=1 either
a) SG[i-1].dma_end and SG[i].dma_addr are contiguous
or
b) SG[i-1].dma_end and SG[i].dma_addr are mr-&amp;gt;page_size aligned.</p>
<p>This leads to incorrect iova-to-va conversion in scenarios:</p>
<p>1) page_size &amp;lt; PAGE_SIZE (e.g., MR: 4K, system: 64K):
   ibmr-&amp;gt;iova = 0x1…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/oesa-2026-3707"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11476-1</id>
    <title>openSUSE-SU-2026:11476-1 — kernel-devel-7.1.7-1.1 on GA media</title>
    <updated>2026-10-02T18:38:11.206117+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>kernel-devel-7.1.7-1.1 on GA media</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/opensuse-su-2026:11476-1"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-64405</id>
    <title>UBUNTU-CVE-2026-64405</title>
    <updated>2026-10-02T18:38:11.206311+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 246 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn() hci_abort_conn() read hci_skb_event(hdev-&gt;sent_cmd) when a connection was pending, but hdev-&gt;sent_cmd can be NULL while req_status is still HCI_REQ_PEND, leading to a NULL pointer dereference and a general protection fault from the hci_rx_work() receive path. Instead of inspecting hdev-&gt;sent_cmd, track the in-flight create connection command with a new per-connection HCI_CONN_CREATE flag and route all cancellation through hci_cancel_connect_sync(), which dispatches to a dedicated per-type cancel function. The create command is in exactly one of two states: still queued, or in flight. The cancel function holds cmd_sync_work_lock across the whole decision: the worker takes this lock to dequeue every entry, so while it is held a queued command cannot start running and an in-flight command cannot complete and let the next command become pending. This keeps the flag test and hci_cmd_sync_cancel() atomic with respect to the worker, so a queued command is simply dequeued, and an in-flight command owned by this connection is cancelled without the risk of cancelling an unrelated command that became pending in the meantime. CIS uses the same flag mechanism via HCI_CONN_CREATE_CIS but cannot be dequeued per-connection. hci_acl_create_conn_sync() and hci_le_create_conn_sync() clear HCI_CONN_CREATE after the create command completes, but the command status handl…</p></div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-64405"/>
  </entry>
  <entry>
    <id>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2527</id>
    <title>WID-SEC-W-2026-2527 — Linux Kernel: Mehrere Schwachstellen</title>
    <updated>2026-10-02T18:38:11.206581+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 nicht näher spezifizierte Angriffe durchzuführen, dazu können DoS-Angriffe, die Offenlegung von Informationen, die Beschädigung des Speichers oder die Umgehung von Sicherheitsmaßnahmen gehören.</p>
      </div>
    </content>
    <link href="https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2527"/>
  </entry>
</feed>
