<?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, 17 Oct 2026 21:05:53 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-98294 — Bluetooth: hci_qca: Do not write to the serial port after it is closed</title>
      <link>https://db.gcve.eu/vuln/cve-2026-98294</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_qca: Do not write to the serial port after it is closed&lt;/p&gt;
&lt;p&gt;hci_uart_close() closes the serdev port if HCI_QUIRK_NON_PERSISTENT_SETUP
is set (for example, for the WCN399x family). A failed hci_dev_open_sync()
following a successful qca_setup() calls hdev-&amp;gt;close() but not
hdev-&amp;gt;shutdown(), so the port is closed while power-&amp;gt;vregs_on is left true.
qca_serdev_remove() then passes its power-&amp;gt;vregs_on test and calls
qca_power_off(), which writes to the closed port unconditionally.&lt;/p&gt;
&lt;p&gt;Seen on a WCN3988 by unbinding the driver after a controller failure. The
trace below is from a 7.0.0 based kernel, where qca_power_off() was still
named qca_power_shutdown():&lt;/p&gt;
&lt;p&gt;Unable to handle kernel NULL pointer dereference at virtual address
  0000000000000038
  Call trace:
   tty_set_termios+0x50/0x238 (P)
   ttyport_set_baudrate+0x84/0xc0
   serdev_device_set_baudrate+0x24/0x40
   qca_power_shutdown+0x158/0x1fc [hci_uart]
   qca_serdev_remove+0x54/0x68 [hci_uart]
   serdev_drv_remove+0x1c/0x2c
   device_remove+0x4c/0x80
   device_release_driver_internal+0x1cc/0x224
   device_driver_detach+0x18/0x24
   unbind_store+0xb4/0xc0&lt;/p&gt;
&lt;p&gt;Check HCI_UART_PROTO_READY, which hci_uart_close() clears in the same place
it closes the port, before writing to it. The regulator disable is left
unconditional so the controller is still powered down.&lt;/p&gt;
&lt;p&gt;The dangling serport-&amp;gt;tty that turns this into a use-after-free is
addressed in a separate p…&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_qca: Do not write to the serial port after it is closed&lt;/p&gt;
&lt;p&gt;hci_uart_close() closes the serdev port if HCI_QUIRK_NON_PERSISTENT_SETUP
is set (for example, for the WCN399x family). A failed hci_dev_open_sync()
following a successful qca_setup() calls hdev-&amp;gt;close() but not
hdev-&amp;gt;shutdown(), so the port is closed while power-&amp;gt;vregs_on is left true.
qca_serdev_remove() then passes its power-&amp;gt;vregs_on test and calls
qca_power_off(), which writes to the closed port unconditionally.&lt;/p&gt;
&lt;p&gt;Seen on a WCN3988 by unbinding the driver after a controller failure. The
trace below is from a 7.0.0 based kernel, where qca_power_off() was still
named qca_power_shutdown():&lt;/p&gt;
&lt;p&gt;Unable to handle kernel NULL pointer dereference at virtual address
  0000000000000038
  Call trace:
   tty_set_termios+0x50/0x238 (P)
   ttyport_set_baudrate+0x84/0xc0
   serdev_device_set_baudrate+0x24/0x40
   qca_power_shutdown+0x158/0x1fc [hci_uart]
   qca_serdev_remove+0x54/0x68 [hci_uart]
   serdev_drv_remove+0x1c/0x2c
   device_remove+0x4c/0x80
   device_release_driver_internal+0x1cc/0x224
   device_driver_detach+0x18/0x24
   unbind_store+0xb4/0xc0&lt;/p&gt;
&lt;p&gt;Check HCI_UART_PROTO_READY, which hci_uart_close() clears in the same place
it closes the port, before writing to it. The regulator disable is left
unconditional so the controller is still powered down.&lt;/p&gt;
&lt;p&gt;The dangling serport-&amp;gt;tty that turns this into a use-after-free is
addressed in a separate p…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-98294</guid>
    </item>
  </channel>
</rss>
