<?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 18:35:39 +0000</lastBuildDate>
    <item>
      <title>fkie_cve-2026-98294</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-98294</link>
      <description>&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;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/fkie_cve-2026-98294</guid>
    </item>
    <item>
      <title>GHSA-5mg2-55jh-rjgr</title>
      <link>https://db.gcve.eu/vuln/ghsa-5mg2-55jh-rjgr</link>
      <description>&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;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/ghsa-5mg2-55jh-rjgr</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-98294 — Bluetooth: hci_qca: Do not write to the serial port after it is closed</title>
      <link>https://db.gcve.eu/vuln/msrc_cve-2026-98294</link>
      <description>msrc_CVE-2026-98294</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/msrc_cve-2026-98294</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:12131-1 — kernel-devel-7.2.10-1.1 on GA media</title>
      <link>https://db.gcve.eu/vuln/opensuse-su-2026:12131-1</link>
      <description>&lt;p&gt;kernel-devel-7.2.10-1.1 on GA media&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;kernel-devel-7.2.10-1.1 on GA media&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/opensuse-su-2026:12131-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-98294</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-98294</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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 220 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Do not write to the serial port after it is closed 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. 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():   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 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. The dangling serport-&amp;gt;tty that turns this into a use-after-free is addressed in a separate patch.&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:Pro:18.04:LTS: linux-aws-5.4, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:Pro:18.04:LTS: linux-azure-5.4, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3 and 220 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Do not write to the serial port after it is closed 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. 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():   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 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. The dangling serport-&amp;gt;tty that turns this into a use-after-free is addressed in a separate patch.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-98294</guid>
    </item>
  </channel>
</rss>
