<?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://db.gcve.eu</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, 07 Nov 2026 04:28:54 +0000</lastBuildDate>
    <item>
      <title>certfr-2026-avi-1470 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de SUSE. Certaines d'entre elles permettent à un at…</title>
      <link>https://db.gcve.eu/vuln/certfr-2026-avi-1470</link>
      <description>certfr-2026-avi-1470</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/certfr-2026-avi-1470</guid>
    </item>
    <item>
      <title>fkie_cve-2026-99091</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-99091</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: MGMT: Fix status of pending commands flushed on power off&lt;/p&gt;
&lt;p&gt;cmd_complete_rsp() receives a struct cmd_lookup and, for a pending
command that has no cmd_complete callback, falls through to
cmd_status_rsp(cmd, data). cmd_status_rsp() reads data as a u8 *, so
the status sent comes from the first byte of match-&amp;gt;sk&amp;#39;s
representation, not from match-&amp;gt;mgmt_status.&lt;/p&gt;
&lt;p&gt;commit f53e1c9c726d (&amp;#34;Bluetooth: MGMT: Fix possible crash on
mgmt_index_removed&amp;#34;) changed the callers&amp;#39; data from &amp;amp;status to &amp;amp;match
and updated the cmd_complete branch to match-&amp;gt;mgmt_status, but left
the fall-through passing data unchanged.&lt;/p&gt;
&lt;p&gt;In mgmt_index_removed() match-&amp;gt;sk is NULL, so every such command is
answered with status 0x00 (Success) instead of
MGMT_STATUS_INVALID_INDEX. In __mgmt_power_off() it is NULL too,
unless a Set Powered command was pending: then settings_rsp() has
stored that command&amp;#39;s socket in match-&amp;gt;sk, and the byte sent comes
from the socket pointer. Either way the status the caller set,
MGMT_STATUS_NOT_POWERED (or MGMT_STATUS_INVALID_INDEX when the device
is being unregistered), is lost.&lt;/p&gt;
&lt;p&gt;Pass the status the callers set.&lt;/p&gt;
&lt;p&gt;This was seen on a QCA9377 laptop: bluetoothd&amp;#39;s Start Discovery,
pending when the adapter was powered off, was answered with Command
Status 0x00 and no parameters, and bluetoothd 5.72 crashed on the
zero-length success. BlueZ master has since added the length check
on that path (&amp;#34;adapter: Fix crash on sho…&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: MGMT: Fix status of pending commands flushed on power off&lt;/p&gt;
&lt;p&gt;cmd_complete_rsp() receives a struct cmd_lookup and, for a pending
command that has no cmd_complete callback, falls through to
cmd_status_rsp(cmd, data). cmd_status_rsp() reads data as a u8 *, so
the status sent comes from the first byte of match-&amp;gt;sk&amp;#39;s
representation, not from match-&amp;gt;mgmt_status.&lt;/p&gt;
&lt;p&gt;commit f53e1c9c726d (&amp;#34;Bluetooth: MGMT: Fix possible crash on
mgmt_index_removed&amp;#34;) changed the callers&amp;#39; data from &amp;amp;status to &amp;amp;match
and updated the cmd_complete branch to match-&amp;gt;mgmt_status, but left
the fall-through passing data unchanged.&lt;/p&gt;
&lt;p&gt;In mgmt_index_removed() match-&amp;gt;sk is NULL, so every such command is
answered with status 0x00 (Success) instead of
MGMT_STATUS_INVALID_INDEX. In __mgmt_power_off() it is NULL too,
unless a Set Powered command was pending: then settings_rsp() has
stored that command&amp;#39;s socket in match-&amp;gt;sk, and the byte sent comes
from the socket pointer. Either way the status the caller set,
MGMT_STATUS_NOT_POWERED (or MGMT_STATUS_INVALID_INDEX when the device
is being unregistered), is lost.&lt;/p&gt;
&lt;p&gt;Pass the status the callers set.&lt;/p&gt;
&lt;p&gt;This was seen on a QCA9377 laptop: bluetoothd&amp;#39;s Start Discovery,
pending when the adapter was powered off, was answered with Command
Status 0x00 and no parameters, and bluetoothd 5.72 crashed on the
zero-length success. BlueZ master has since added the length check
on that path (&amp;#34;adapter: Fix crash on sho…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-99091</guid>
    </item>
    <item>
      <title>GHSA-75m9-vh6c-66mx</title>
      <link>https://db.gcve.eu/vuln/ghsa-75m9-vh6c-66mx</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;Bluetooth: MGMT: Fix status of pending commands flushed on power off&lt;/p&gt;
&lt;p&gt;cmd_complete_rsp() receives a struct cmd_lookup and, for a pending
command that has no cmd_complete callback, falls through to
cmd_status_rsp(cmd, data). cmd_status_rsp() reads data as a u8 *, so
the status sent comes from the first byte of match-&amp;gt;sk&amp;#39;s
representation, not from match-&amp;gt;mgmt_status.&lt;/p&gt;
&lt;p&gt;commit f53e1c9c726d (&amp;#34;Bluetooth: MGMT: Fix possible crash on
mgmt_index_removed&amp;#34;) changed the callers&amp;#39; data from &amp;amp;status to &amp;amp;match
and updated the cmd_complete branch to match-&amp;gt;mgmt_status, but left
the fall-through passing data unchanged.&lt;/p&gt;
&lt;p&gt;In mgmt_index_removed() match-&amp;gt;sk is NULL, so every such command is
answered with status 0x00 (Success) instead of
MGMT_STATUS_INVALID_INDEX. In __mgmt_power_off() it is NULL too,
unless a Set Powered command was pending: then settings_rsp() has
stored that command&amp;#39;s socket in match-&amp;gt;sk, and the byte sent comes
from the socket pointer. Either way the status the caller set,
MGMT_STATUS_NOT_POWERED (or MGMT_STATUS_INVALID_INDEX when the device
is being unregistered), is lost.&lt;/p&gt;
&lt;p&gt;Pass the status the callers set.&lt;/p&gt;
&lt;p&gt;This was seen on a QCA9377 laptop: bluetoothd&amp;#39;s Start Discovery,
pending when the adapter was powered off, was answered with Command
Status 0x00 and no parameters, and bluetoothd 5.72 crashed on the
zero-length success. BlueZ master has since added the length check
on that path (&amp;#34;adapter: Fix crash on sho…&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: MGMT: Fix status of pending commands flushed on power off&lt;/p&gt;
&lt;p&gt;cmd_complete_rsp() receives a struct cmd_lookup and, for a pending
command that has no cmd_complete callback, falls through to
cmd_status_rsp(cmd, data). cmd_status_rsp() reads data as a u8 *, so
the status sent comes from the first byte of match-&amp;gt;sk&amp;#39;s
representation, not from match-&amp;gt;mgmt_status.&lt;/p&gt;
&lt;p&gt;commit f53e1c9c726d (&amp;#34;Bluetooth: MGMT: Fix possible crash on
mgmt_index_removed&amp;#34;) changed the callers&amp;#39; data from &amp;amp;status to &amp;amp;match
and updated the cmd_complete branch to match-&amp;gt;mgmt_status, but left
the fall-through passing data unchanged.&lt;/p&gt;
&lt;p&gt;In mgmt_index_removed() match-&amp;gt;sk is NULL, so every such command is
answered with status 0x00 (Success) instead of
MGMT_STATUS_INVALID_INDEX. In __mgmt_power_off() it is NULL too,
unless a Set Powered command was pending: then settings_rsp() has
stored that command&amp;#39;s socket in match-&amp;gt;sk, and the byte sent comes
from the socket pointer. Either way the status the caller set,
MGMT_STATUS_NOT_POWERED (or MGMT_STATUS_INVALID_INDEX when the device
is being unregistered), is lost.&lt;/p&gt;
&lt;p&gt;Pass the status the callers set.&lt;/p&gt;
&lt;p&gt;This was seen on a QCA9377 laptop: bluetoothd&amp;#39;s Start Discovery,
pending when the adapter was powered off, was answered with Command
Status 0x00 and no parameters, and bluetoothd 5.72 crashed on the
zero-length success. BlueZ master has since added the length check
on that path (&amp;#34;adapter: Fix crash on sho…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-75m9-vh6c-66mx</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:24550-1 — Security update for the Linux Kernel</title>
      <link>https://db.gcve.eu/vuln/suse-su-2026:24550-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://db.gcve.eu/vuln/suse-su-2026:24550-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-99091</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-99091</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 164 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix status of pending commands flushed on power off cmd_complete_rsp() receives a struct cmd_lookup and, for a pending command that has no cmd_complete callback, falls through to cmd_status_rsp(cmd, data). cmd_status_rsp() reads data as a u8 *, so the status sent comes from the first byte of match-&amp;gt;sk&amp;#39;s representation, not from match-&amp;gt;mgmt_status. commit f53e1c9c726d (&amp;#34;Bluetooth: MGMT: Fix possible crash on mgmt_index_removed&amp;#34;) changed the callers&amp;#39; data from &amp;amp;status to &amp;amp;match and updated the cmd_complete branch to match-&amp;gt;mgmt_status, but left the fall-through passing data unchanged. In mgmt_index_removed() match-&amp;gt;sk is NULL, so every such command is answered with status 0x00 (Success) instead of MGMT_STATUS_INVALID_INDEX. In __mgmt_power_off() it is NULL too, unless a Set Powered command was pending: then settings_rsp() has stored that command&amp;#39;s socket in match-&amp;gt;sk, and the byte sent comes from the socket pointer. Either way the status the caller set, MGMT_STATUS_NOT_POWERED (or MGMT_STATUS_INVALID_INDEX when the device is being unregistered), is lost. Pass the status the callers set. This was seen on a QCA9377 laptop: bluetoothd&amp;#39;s Start Discovery, pending when the adapter was powered off, was answered with Command Status 0x00 and no parameters, and bluetoothd 5.72 crashed on the zero-length success. BlueZ master has since added the length check on that path (&amp;#34;adapter: Fix crash on short sta…&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 164 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: Bluetooth: MGMT: Fix status of pending commands flushed on power off cmd_complete_rsp() receives a struct cmd_lookup and, for a pending command that has no cmd_complete callback, falls through to cmd_status_rsp(cmd, data). cmd_status_rsp() reads data as a u8 *, so the status sent comes from the first byte of match-&amp;gt;sk&amp;#39;s representation, not from match-&amp;gt;mgmt_status. commit f53e1c9c726d (&amp;#34;Bluetooth: MGMT: Fix possible crash on mgmt_index_removed&amp;#34;) changed the callers&amp;#39; data from &amp;amp;status to &amp;amp;match and updated the cmd_complete branch to match-&amp;gt;mgmt_status, but left the fall-through passing data unchanged. In mgmt_index_removed() match-&amp;gt;sk is NULL, so every such command is answered with status 0x00 (Success) instead of MGMT_STATUS_INVALID_INDEX. In __mgmt_power_off() it is NULL too, unless a Set Powered command was pending: then settings_rsp() has stored that command&amp;#39;s socket in match-&amp;gt;sk, and the byte sent comes from the socket pointer. Either way the status the caller set, MGMT_STATUS_NOT_POWERED (or MGMT_STATUS_INVALID_INDEX when the device is being unregistered), is lost. Pass the status the callers set. This was seen on a QCA9377 laptop: bluetoothd&amp;#39;s Start Discovery, pending when the adapter was powered off, was answered with Command Status 0x00 and no parameters, and bluetoothd 5.72 crashed on the zero-length success. BlueZ master has since added the length check on that path (&amp;#34;adapter: Fix crash on short sta…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-99091</guid>
    </item>
  </channel>
</rss>
