<?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>Mon, 02 Nov 2026 23:08:37 +0000</lastBuildDate>
    <item>
      <title>certfr-2026-avi-1375 — De multiples vulnérabilités ont été découvertes dans le noyau Linux de Debian LTS. Certaines d'entre elles permettent à…</title>
      <link>https://db.gcve.eu/vuln/certfr-2026-avi-1375</link>
      <description>certfr-2026-avi-1375</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/certfr-2026-avi-1375</guid>
    </item>
    <item>
      <title>fkie_cve-2026-98761</title>
      <link>https://db.gcve.eu/vuln/fkie_cve-2026-98761</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;usb: typec: tcpm: recover after failure to start the frs ams&lt;/p&gt;
&lt;p&gt;Reset the port if the tcpm fails to start the FAST_ROLE_SWAP AMS by
initiating error recovery on it.&lt;/p&gt;
&lt;p&gt;This helps in cases where some cables (incorrectly) signal an FRS to
an FRS capable port during disconnection. The TCPC autonomously starts
sourcing VBUS on detecting the FRS signal. However, the VBUS sourcing is
left on when the FAST_ROLE_SWAP AMS fails to start (as tcpm_sink_tx_ok
is 0 as CC is open due to the cable disconnect). This is because the
code sets the state to INVALID_STATE without resetting the port state.&lt;/p&gt;
&lt;p&gt;Log snippet before changes:
[  101.401960] AMS FAST_ROLE_SWAP start
[  101.401971] Sink TX No Go
[  101.401982] sourcing vbus
[  101.401987] VBUS on
[  101.402159] VBUS on
[  109.257809] CC1: 0 -&amp;gt; 0, CC2: 5 -&amp;gt; 0 [state SNK_READY, polarity 1, disconnected]
[  111.267442] VBUS on&lt;/p&gt;
&lt;p&gt;After changes:
[   70.541211] AMS FAST_ROLE_SWAP start
[   70.541220] Sink TX No Go
[   70.541228] state change SNK_READY -&amp;gt; ERROR_RECOVERY [rev3 NONE_AMS]
[   70.541362] VBUS on
[   70.541365] sourcing vbus
[   70.541367] VBUS on
[   70.541374] state change ERROR_RECOVERY -&amp;gt; PORT_RESET [rev3 NONE_AMS]
[   70.541410] disable vbus discharge ret:0
[   70.543028] Setting usb_comm capable false
[   70.544009] Setting voltage/current limit 0 mV 0 mA
[   70.544034] polarity 0
[   70.544239] Requesting mux state 0, usb-role 0, orientation 0
[   70.555550] cc:=0…&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;usb: typec: tcpm: recover after failure to start the frs ams&lt;/p&gt;
&lt;p&gt;Reset the port if the tcpm fails to start the FAST_ROLE_SWAP AMS by
initiating error recovery on it.&lt;/p&gt;
&lt;p&gt;This helps in cases where some cables (incorrectly) signal an FRS to
an FRS capable port during disconnection. The TCPC autonomously starts
sourcing VBUS on detecting the FRS signal. However, the VBUS sourcing is
left on when the FAST_ROLE_SWAP AMS fails to start (as tcpm_sink_tx_ok
is 0 as CC is open due to the cable disconnect). This is because the
code sets the state to INVALID_STATE without resetting the port state.&lt;/p&gt;
&lt;p&gt;Log snippet before changes:
[  101.401960] AMS FAST_ROLE_SWAP start
[  101.401971] Sink TX No Go
[  101.401982] sourcing vbus
[  101.401987] VBUS on
[  101.402159] VBUS on
[  109.257809] CC1: 0 -&amp;gt; 0, CC2: 5 -&amp;gt; 0 [state SNK_READY, polarity 1, disconnected]
[  111.267442] VBUS on&lt;/p&gt;
&lt;p&gt;After changes:
[   70.541211] AMS FAST_ROLE_SWAP start
[   70.541220] Sink TX No Go
[   70.541228] state change SNK_READY -&amp;gt; ERROR_RECOVERY [rev3 NONE_AMS]
[   70.541362] VBUS on
[   70.541365] sourcing vbus
[   70.541367] VBUS on
[   70.541374] state change ERROR_RECOVERY -&amp;gt; PORT_RESET [rev3 NONE_AMS]
[   70.541410] disable vbus discharge ret:0
[   70.543028] Setting usb_comm capable false
[   70.544009] Setting voltage/current limit 0 mV 0 mA
[   70.544034] polarity 0
[   70.544239] Requesting mux state 0, usb-role 0, orientation 0
[   70.555550] cc:=0…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/fkie_cve-2026-98761</guid>
    </item>
    <item>
      <title>GHSA-fcv9-h4wq-59j8</title>
      <link>https://db.gcve.eu/vuln/ghsa-fcv9-h4wq-59j8</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;usb: typec: tcpm: recover after failure to start the frs ams&lt;/p&gt;
&lt;p&gt;Reset the port if the tcpm fails to start the FAST_ROLE_SWAP AMS by
initiating error recovery on it.&lt;/p&gt;
&lt;p&gt;This helps in cases where some cables (incorrectly) signal an FRS to
an FRS capable port during disconnection. The TCPC autonomously starts
sourcing VBUS on detecting the FRS signal. However, the VBUS sourcing is
left on when the FAST_ROLE_SWAP AMS fails to start (as tcpm_sink_tx_ok
is 0 as CC is open due to the cable disconnect). This is because the
code sets the state to INVALID_STATE without resetting the port state.&lt;/p&gt;
&lt;p&gt;Log snippet before changes:
[  101.401960] AMS FAST_ROLE_SWAP start
[  101.401971] Sink TX No Go
[  101.401982] sourcing vbus
[  101.401987] VBUS on
[  101.402159] VBUS on
[  109.257809] CC1: 0 -&amp;gt; 0, CC2: 5 -&amp;gt; 0 [state SNK_READY, polarity 1, disconnected]
[  111.267442] VBUS on&lt;/p&gt;
&lt;p&gt;After changes:
[   70.541211] AMS FAST_ROLE_SWAP start
[   70.541220] Sink TX No Go
[   70.541228] state change SNK_READY -&amp;gt; ERROR_RECOVERY [rev3 NONE_AMS]
[   70.541362] VBUS on
[   70.541365] sourcing vbus
[   70.541367] VBUS on
[   70.541374] state change ERROR_RECOVERY -&amp;gt; PORT_RESET [rev3 NONE_AMS]
[   70.541410] disable vbus discharge ret:0
[   70.543028] Setting usb_comm capable false
[   70.544009] Setting voltage/current limit 0 mV 0 mA
[   70.544034] polarity 0
[   70.544239] Requesting mux state 0, usb-role 0, orientation 0
[   70.555550] cc:=0…&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;usb: typec: tcpm: recover after failure to start the frs ams&lt;/p&gt;
&lt;p&gt;Reset the port if the tcpm fails to start the FAST_ROLE_SWAP AMS by
initiating error recovery on it.&lt;/p&gt;
&lt;p&gt;This helps in cases where some cables (incorrectly) signal an FRS to
an FRS capable port during disconnection. The TCPC autonomously starts
sourcing VBUS on detecting the FRS signal. However, the VBUS sourcing is
left on when the FAST_ROLE_SWAP AMS fails to start (as tcpm_sink_tx_ok
is 0 as CC is open due to the cable disconnect). This is because the
code sets the state to INVALID_STATE without resetting the port state.&lt;/p&gt;
&lt;p&gt;Log snippet before changes:
[  101.401960] AMS FAST_ROLE_SWAP start
[  101.401971] Sink TX No Go
[  101.401982] sourcing vbus
[  101.401987] VBUS on
[  101.402159] VBUS on
[  109.257809] CC1: 0 -&amp;gt; 0, CC2: 5 -&amp;gt; 0 [state SNK_READY, polarity 1, disconnected]
[  111.267442] VBUS on&lt;/p&gt;
&lt;p&gt;After changes:
[   70.541211] AMS FAST_ROLE_SWAP start
[   70.541220] Sink TX No Go
[   70.541228] state change SNK_READY -&amp;gt; ERROR_RECOVERY [rev3 NONE_AMS]
[   70.541362] VBUS on
[   70.541365] sourcing vbus
[   70.541367] VBUS on
[   70.541374] state change ERROR_RECOVERY -&amp;gt; PORT_RESET [rev3 NONE_AMS]
[   70.541410] disable vbus discharge ret:0
[   70.543028] Setting usb_comm capable false
[   70.544009] Setting voltage/current limit 0 mV 0 mA
[   70.544034] polarity 0
[   70.544239] Requesting mux state 0, usb-role 0, orientation 0
[   70.555550] cc:=0…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ghsa-fcv9-h4wq-59j8</guid>
    </item>
    <item>
      <title>msrc_CVE-2026-98761 — usb: typec: tcpm: recover after failure to start the frs ams</title>
      <link>https://db.gcve.eu/vuln/msrc_cve-2026-98761</link>
      <description>msrc_CVE-2026-98761</description>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/msrc_cve-2026-98761</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-98761</title>
      <link>https://db.gcve.eu/vuln/ubuntu-cve-2026-98761</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 193 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: recover after failure to start the frs ams Reset the port if the tcpm fails to start the FAST_ROLE_SWAP AMS by initiating error recovery on it. This helps in cases where some cables (incorrectly) signal an FRS to an FRS capable port during disconnection. The TCPC autonomously starts sourcing VBUS on detecting the FRS signal. However, the VBUS sourcing is left on when the FAST_ROLE_SWAP AMS fails to start (as tcpm_sink_tx_ok is 0 as CC is open due to the cable disconnect). This is because the code sets the state to INVALID_STATE without resetting the port state. Log snippet before changes: [  101.401960] AMS FAST_ROLE_SWAP start [  101.401971] Sink TX No Go [  101.401982] sourcing vbus [  101.401987] VBUS on [  101.402159] VBUS on [  109.257809] CC1: 0 -&amp;gt; 0, CC2: 5 -&amp;gt; 0 [state SNK_READY, polarity 1, disconnected] [  111.267442] VBUS on After changes: [   70.541211] AMS FAST_ROLE_SWAP start [   70.541220] Sink TX No Go [   70.541228] state change SNK_READY -&amp;gt; ERROR_RECOVERY [rev3 NONE_AMS] [   70.541362] VBUS on [   70.541365] sourcing vbus [   70.541367] VBUS on [   70.541374] state change ERROR_RECOVERY -&amp;gt; PORT_RESET [rev3 NONE_AMS] [   70.541410] disable vbus discharge ret:0 [   70.543028] Setting usb_comm capable false [   70.544009] Setting voltage/current limit 0 mV 0 mA [   70.544034] polarity 0 [   70.544239] Requesting mux state 0, usb-role 0, orientation 0 [   70.555550] cc:=0 [   7…&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 193 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: usb: typec: tcpm: recover after failure to start the frs ams Reset the port if the tcpm fails to start the FAST_ROLE_SWAP AMS by initiating error recovery on it. This helps in cases where some cables (incorrectly) signal an FRS to an FRS capable port during disconnection. The TCPC autonomously starts sourcing VBUS on detecting the FRS signal. However, the VBUS sourcing is left on when the FAST_ROLE_SWAP AMS fails to start (as tcpm_sink_tx_ok is 0 as CC is open due to the cable disconnect). This is because the code sets the state to INVALID_STATE without resetting the port state. Log snippet before changes: [  101.401960] AMS FAST_ROLE_SWAP start [  101.401971] Sink TX No Go [  101.401982] sourcing vbus [  101.401987] VBUS on [  101.402159] VBUS on [  109.257809] CC1: 0 -&amp;gt; 0, CC2: 5 -&amp;gt; 0 [state SNK_READY, polarity 1, disconnected] [  111.267442] VBUS on After changes: [   70.541211] AMS FAST_ROLE_SWAP start [   70.541220] Sink TX No Go [   70.541228] state change SNK_READY -&amp;gt; ERROR_RECOVERY [rev3 NONE_AMS] [   70.541362] VBUS on [   70.541365] sourcing vbus [   70.541367] VBUS on [   70.541374] state change ERROR_RECOVERY -&amp;gt; PORT_RESET [rev3 NONE_AMS] [   70.541410] disable vbus discharge ret:0 [   70.543028] Setting usb_comm capable false [   70.544009] Setting voltage/current limit 0 mV 0 mA [   70.544034] polarity 0 [   70.544239] Requesting mux state 0, usb-role 0, orientation 0 [   70.555550] cc:=0 [   7…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/ubuntu-cve-2026-98761</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-4019 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://db.gcve.eu/vuln/wid-sec-w-2026-4019</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen im Linux Kernel ausnutzen, um einen nicht näher spezifizierten Angriff durchzuführen, möglicherweise einen Denial-of-Service-Angriff auszulösen, Daten zu manipulieren oder offenzulegen oder Sicherheitsmaßnahmen zu umgehen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://db.gcve.eu/vuln/wid-sec-w-2026-4019</guid>
    </item>
  </channel>
</rss>
