<?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>Thu, 15 Oct 2026 08:09:44 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-68304 — Bluetooth: hci_core: lookup hci_conn on RX path on protocol side</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-68304</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: hci_core: lookup hci_conn on RX path on protocol side&lt;/p&gt;
&lt;p&gt;The hdev lock/lookup/unlock/use pattern in the packet RX path doesn&amp;#39;t
ensure hci_conn* is not concurrently modified/deleted. This locking
appears to be leftover from before conn_hash started using RCU
commit bf4c63252490b (&amp;#34;Bluetooth: convert conn hash to RCU&amp;#34;)
and not clear if it had purpose since then.&lt;/p&gt;
&lt;p&gt;Currently, there are code paths that delete hci_conn* from elsewhere
than the ordered hdev-&amp;gt;workqueue where the RX work runs in. E.g.
commit 5af1f84ed13a (&amp;#34;Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync&amp;#34;)
introduced some of these, and there probably were a few others before
it.  It&amp;#39;s better to do the locking so that even if these run
concurrently no UAF is possible.&lt;/p&gt;
&lt;p&gt;Move the lookup of hci_conn and associated socket-specific conn to
protocol recv handlers, and do them within a single critical section
to cover hci_conn* usage and lookup.&lt;/p&gt;
&lt;p&gt;syzkaller has reported a crash that appears to be this issue:&lt;/p&gt;
&lt;p&gt;[Task hdev-&amp;gt;workqueue]          [Task 2]
                                    hci_disconnect_all_sync
    l2cap_recv_acldata(hcon)
                                      hci_conn_get(hcon)
                                      hci_abort_conn_sync(hcon)
                                        hci_dev_lock
      hci_dev_lock
                                        hci_conn_del(hcon)
      v-------------------------------- hci_dev_unlock…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: hci_core: lookup hci_conn on RX path on protocol side&lt;/p&gt;
&lt;p&gt;The hdev lock/lookup/unlock/use pattern in the packet RX path doesn&amp;#39;t
ensure hci_conn* is not concurrently modified/deleted. This locking
appears to be leftover from before conn_hash started using RCU
commit bf4c63252490b (&amp;#34;Bluetooth: convert conn hash to RCU&amp;#34;)
and not clear if it had purpose since then.&lt;/p&gt;
&lt;p&gt;Currently, there are code paths that delete hci_conn* from elsewhere
than the ordered hdev-&amp;gt;workqueue where the RX work runs in. E.g.
commit 5af1f84ed13a (&amp;#34;Bluetooth: hci_sync: Fix UAF on hci_abort_conn_sync&amp;#34;)
introduced some of these, and there probably were a few others before
it.  It&amp;#39;s better to do the locking so that even if these run
concurrently no UAF is possible.&lt;/p&gt;
&lt;p&gt;Move the lookup of hci_conn and associated socket-specific conn to
protocol recv handlers, and do them within a single critical section
to cover hci_conn* usage and lookup.&lt;/p&gt;
&lt;p&gt;syzkaller has reported a crash that appears to be this issue:&lt;/p&gt;
&lt;p&gt;[Task hdev-&amp;gt;workqueue]          [Task 2]
                                    hci_disconnect_all_sync
    l2cap_recv_acldata(hcon)
                                      hci_conn_get(hcon)
                                      hci_abort_conn_sync(hcon)
                                        hci_dev_lock
      hci_dev_lock
                                        hci_conn_del(hcon)
      v-------------------------------- hci_dev_unlock…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2025-68304</guid>
    </item>
    <item>
      <title>USN-8094-1 — linux, linux-aws, linux-aws-6.17, linux-gcp, linux-hwe-6.17, linux-oracle, linux-oracle-6.17 vulnerabilities</title>
      <link>https://cve.radiocsirt.org/vuln/usn-8094-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: linux-aws-6.17, Ubuntu:24.04:LTS: linux-hwe-6.17, Ubuntu:24.04:LTS: linux-oracle-6.17, Ubuntu:25.10: linux, Ubuntu:25.10: linux-aws, Ubuntu:25.10: linux-gcp, Ubuntu:25.10: linux-oracle&lt;/p&gt;
&lt;p&gt;Qualys discovered that several vulnerabilities existed in the AppArmor
Linux kernel Security Module (LSM). An unprivileged local attacker could
use these issues to load, replace, and remove arbitrary AppArmor profiles
causing denial of service, exposure of sensitive information (kernel
memory), local privilege escalation, or possibly escape a container.
(LP: #2143853)&lt;/p&gt;
&lt;p&gt;It was discovered that some AMD Zen 5 processors supporting RDSEED
instruction did not properly handle entropy, potentially resulting in the
consumption of insufficiently random values. A local attacker could
possibly use this issue to influence the values returned by the RDSEED
instruction causing loss of confidentiality and integrity. (CVE-2025-62626)&lt;/p&gt;
&lt;p&gt;Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
  - ARM64 architecture;
  - S390 architecture;
  - x86 architecture;
  - Block layer subsystem;
  - Cryptographic API;
  - Compute Acceleration Framework;
  - ATM drivers;
  - Network block device driver;
  - Bluetooth drivers;
  - Data acquisition framework and drivers;
  - Hardware crypto device drivers;
  - Device frequency scaling framework;
  - Intel Stratix 10 firmware drivers;
  - GPIO subsystem;
  - GPU drivers;
  - Microsoft Hyper-V drivers;
  - CoreSight HW tracing drivers;
  - IIO subsystem;
  - InfiniBand drivers;
  - Input Device core drivers;
  - Input Device (Tablet) d…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:24.04:LTS: linux-aws-6.17, Ubuntu:24.04:LTS: linux-hwe-6.17, Ubuntu:24.04:LTS: linux-oracle-6.17, Ubuntu:25.10: linux, Ubuntu:25.10: linux-aws, Ubuntu:25.10: linux-gcp, Ubuntu:25.10: linux-oracle&lt;/p&gt;
&lt;p&gt;Qualys discovered that several vulnerabilities existed in the AppArmor
Linux kernel Security Module (LSM). An unprivileged local attacker could
use these issues to load, replace, and remove arbitrary AppArmor profiles
causing denial of service, exposure of sensitive information (kernel
memory), local privilege escalation, or possibly escape a container.
(LP: #2143853)&lt;/p&gt;
&lt;p&gt;It was discovered that some AMD Zen 5 processors supporting RDSEED
instruction did not properly handle entropy, potentially resulting in the
consumption of insufficiently random values. A local attacker could
possibly use this issue to influence the values returned by the RDSEED
instruction causing loss of confidentiality and integrity. (CVE-2025-62626)&lt;/p&gt;
&lt;p&gt;Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
  - ARM64 architecture;
  - S390 architecture;
  - x86 architecture;
  - Block layer subsystem;
  - Cryptographic API;
  - Compute Acceleration Framework;
  - ATM drivers;
  - Network block device driver;
  - Bluetooth drivers;
  - Data acquisition framework and drivers;
  - Hardware crypto device drivers;
  - Device frequency scaling framework;
  - Intel Stratix 10 firmware drivers;
  - GPIO subsystem;
  - GPU drivers;
  - Microsoft Hyper-V drivers;
  - CoreSight HW tracing drivers;
  - IIO subsystem;
  - InfiniBand drivers;
  - Input Device core drivers;
  - Input Device (Tablet) d…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/usn-8094-1</guid>
    </item>
  </channel>
</rss>
