<?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, 03 Oct 2026 02:02:29 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-53051 — PCI: tegra194: Fix CBB timeout caused by DBI access before core power-on</title>
      <link>https://db.gcve.eu/vuln/cve-2026-53051</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;PCI: tegra194: Fix CBB timeout caused by DBI access before core power-on&lt;/p&gt;
&lt;p&gt;When PERST# is deasserted twice (assert -&amp;gt; deassert -&amp;gt; assert -&amp;gt; deassert),
a CBB (Control Backbone) timeout occurs at DBI register offset 0x8bc
(PCIE_MISC_CONTROL_1_OFF). This happens because pci_epc_deinit_notify()
and dw_pcie_ep_cleanup() are called before reset_control_deassert() powers
on the controller core.&lt;/p&gt;
&lt;p&gt;The call chain that causes the timeout:&lt;/p&gt;
&lt;p&gt;pex_ep_event_pex_rst_deassert()
    pci_epc_deinit_notify()
      pci_epf_test_epc_deinit()
        pci_epf_test_clear_bar()
          pci_epc_clear_bar()
            dw_pcie_ep_clear_bar()
              __dw_pcie_ep_reset_bar()
                dw_pcie_dbi_ro_wr_en()      &amp;lt;- Accesses 0x8bc DBI register
    reset_control_deassert(pcie-&amp;gt;core_rst)  &amp;lt;- Core powered on HERE&lt;/p&gt;
&lt;p&gt;The DBI registers, including PCIE_MISC_CONTROL_1_OFF (0x8bc), are only
accessible after the controller core is powered on via
reset_control_deassert(pcie-&amp;gt;core_rst). Accessing them before this point
results in a CBB timeout because the hardware is not yet operational.&lt;/p&gt;
&lt;p&gt;Fix this by moving pci_epc_deinit_notify() and dw_pcie_ep_cleanup() to
after reset_control_deassert(pcie-&amp;gt;core_rst), ensuring the controller is
fully powered on before any DBI register accesses occur.&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;PCI: tegra194: Fix CBB timeout caused by DBI access before core power-on&lt;/p&gt;
&lt;p&gt;When PERST# is deasserted twice (assert -&amp;gt; deassert -&amp;gt; assert -&amp;gt; deassert),
a CBB (Control Backbone) timeout occurs at DBI register offset 0x8bc
(PCIE_MISC_CONTROL_1_OFF). This happens because pci_epc_deinit_notify()
and dw_pcie_ep_cleanup() are called before reset_control_deassert() powers
on the controller core.&lt;/p&gt;
&lt;p&gt;The call chain that causes the timeout:&lt;/p&gt;
&lt;p&gt;pex_ep_event_pex_rst_deassert()
    pci_epc_deinit_notify()
      pci_epf_test_epc_deinit()
        pci_epf_test_clear_bar()
          pci_epc_clear_bar()
            dw_pcie_ep_clear_bar()
              __dw_pcie_ep_reset_bar()
                dw_pcie_dbi_ro_wr_en()      &amp;lt;- Accesses 0x8bc DBI register
    reset_control_deassert(pcie-&amp;gt;core_rst)  &amp;lt;- Core powered on HERE&lt;/p&gt;
&lt;p&gt;The DBI registers, including PCIE_MISC_CONTROL_1_OFF (0x8bc), are only
accessible after the controller core is powered on via
reset_control_deassert(pcie-&amp;gt;core_rst). Accessing them before this point
results in a CBB timeout because the hardware is not yet operational.&lt;/p&gt;
&lt;p&gt;Fix this by moving pci_epc_deinit_notify() and dw_pcie_ep_cleanup() to
after reset_control_deassert(pcie-&amp;gt;core_rst), ensuring the controller is
fully powered on before any DBI register accesses occur.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/cve-2026-53051</guid>
    </item>
  </channel>
</rss>
