<?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 18:36:48 +0000</lastBuildDate>
    <item>
      <title>BELL-CVE-2026-64405</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-64405</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-64405</guid>
    </item>
    <item>
      <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>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0981</link>
      <description>certfr-2026-avi-0981</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0981</guid>
    </item>
    <item>
      <title>EUVD-2026-353312</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-353312</link>
      <description>EUVD-2026-353312</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-353312</guid>
    </item>
    <item>
      <title>fkie_cve-2026-64405</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-64405</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()&lt;/p&gt;
&lt;p&gt;hci_abort_conn() read hci_skb_event(hdev-&amp;gt;sent_cmd) when a connection
was pending, but hdev-&amp;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.&lt;/p&gt;
&lt;p&gt;Instead of inspecting hdev-&amp;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.&lt;/p&gt;
&lt;p&gt;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…&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;Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()&lt;/p&gt;
&lt;p&gt;hci_abort_conn() read hci_skb_event(hdev-&amp;gt;sent_cmd) when a connection
was pending, but hdev-&amp;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.&lt;/p&gt;
&lt;p&gt;Instead of inspecting hdev-&amp;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.&lt;/p&gt;
&lt;p&gt;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…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-64405</guid>
    </item>
    <item>
      <title>GHSA-xvhg-76qh-24v9</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-xvhg-76qh-24v9</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()&lt;/p&gt;
&lt;p&gt;hci_abort_conn() read hci_skb_event(hdev-&amp;gt;sent_cmd) when a connection
was pending, but hdev-&amp;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.&lt;/p&gt;
&lt;p&gt;Instead of inspecting hdev-&amp;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.&lt;/p&gt;
&lt;p&gt;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…&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;Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()&lt;/p&gt;
&lt;p&gt;hci_abort_conn() read hci_skb_event(hdev-&amp;gt;sent_cmd) when a connection
was pending, but hdev-&amp;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.&lt;/p&gt;
&lt;p&gt;Instead of inspecting hdev-&amp;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.&lt;/p&gt;
&lt;p&gt;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…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-xvhg-76qh-24v9</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-64405 — Bluetooth: hci_conn: Fix null ptr deref in hci_abort_conn()</title>
      <link>https://cve.radiocsirt.org/vuln/msrc_cve-2026-64405</link>
      <description>msrc_CVE-2026-64405</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/msrc_cve-2026-64405</guid>
    </item>
    <item>
      <title>OESA-2026-3707 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-3707</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;seg6: separate dst_cache for input and output paths in seg6 lwtunnel&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Fix this by splitting the cache into cache_input and cache_output,
so each path maintains its own cached dst independently.(CVE-2026-31668)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE&lt;/p&gt;
&lt;p&gt;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;amp;gt;page_size step increments, but the
page_list stores individual struct page pointers, each representing
PAGE_SIZE of memory.&lt;/p&gt;
&lt;p&gt;ib_sg_to_page() has ensured that when i&amp;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;amp;gt;page_size aligned.&lt;/p&gt;
&lt;p&gt;This leads to incorrect iova-to-va conversion in scenarios:&lt;/p&gt;
&lt;p&gt;1) page_size &amp;amp;lt; PAGE_SIZE (e.g., MR: 4K, system: 64K):
   ibmr-&amp;amp;gt;iova = 0x1…&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;seg6: separate dst_cache for input and output paths in seg6 lwtunnel&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;
&lt;p&gt;Fix this by splitting the cache into cache_input and cache_output,
so each path maintains its own cached dst independently.(CVE-2026-31668)&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;RDMA/rxe: Fix iova-to-va conversion for MR page sizes != PAGE_SIZE&lt;/p&gt;
&lt;p&gt;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;amp;gt;page_size step increments, but the
page_list stores individual struct page pointers, each representing
PAGE_SIZE of memory.&lt;/p&gt;
&lt;p&gt;ib_sg_to_page() has ensured that when i&amp;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;amp;gt;page_size aligned.&lt;/p&gt;
&lt;p&gt;This leads to incorrect iova-to-va conversion in scenarios:&lt;/p&gt;
&lt;p&gt;1) page_size &amp;amp;lt; PAGE_SIZE (e.g., MR: 4K, system: 64K):
   ibmr-&amp;amp;gt;iova = 0x1…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-3707</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:11476-1 — kernel-devel-7.1.7-1.1 on GA media</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:11476-1</link>
      <description>&lt;p&gt;kernel-devel-7.1.7-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.1.7-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:11476-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-64405</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-64405</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&lt;/p&gt;
&lt;p&gt;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-&amp;gt;sent_cmd) when a connection was pending, but hdev-&amp;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-&amp;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…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; 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&lt;/p&gt;
&lt;p&gt;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-&amp;gt;sent_cmd) when a connection was pending, but hdev-&amp;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-&amp;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…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-64405</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-2527 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2527</link>
      <description>&lt;p&gt;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.&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, dazu können DoS-Angriffe, die Offenlegung von Informationen, die Beschädigung des Speichers oder die Umgehung von Sicherheitsmaßnahmen gehören.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-2527</guid>
    </item>
  </channel>
</rss>
