<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://db.gcve.eu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-11-10T00:32:24.508138+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@gcve.eu</email>
  </author>
  <link href="https://db.gcve.eu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2026-99215</id>
    <title>fkie_cve-2026-99215</title>
    <updated>2026-11-10T00:32:24.514994+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>power: supply: core: prevent unregistering a power supply while a callback runs</p>
<p>Once a power supply is registered, its callbacks can immediately start
firing from other contexts, such as external_power_changed() triggered by
the TCPM stack. If a power supply is unregistered while the callback is
still running, the driver data can already be freed when the callback
tries to access it, leading to a use-after-free.</p>
<p>This happens e.g. when the hardware bus carrying the power supply device
malfunctions (e.g. I2C is hogged down by another malfunctioning device)
immediately after the power supply is registered, and thus the core is
still processing the callbacks which were queued up when the driver
starts the removal, leading in some cases to a kernel crash, e.g.:</p>
<p>[   11.645942] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000005
[   11.646751] Mem abort info:
[   11.647006]   ESR = 0x0000000096000004
[   11.647338]   EC = 0x25: DABT (current EL), IL = 32 bits
[   11.647806]   SET = 0, FnV = 0
[   11.648077]   EA = 0, S1PTW = 0
[   11.648356]   FSC = 0x04: level 0 translation fault
[   11.648785] Data abort info:
[   11.649041]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[   11.649524]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[   11.649981]   GCS = 0, Overlay = 0, DirtyBit = 0
[   11.650390] [0000000000000005] user address but active_mm is swapper
[   11.650955] Internal erro…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2026-99215"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-5qv3-9727-cwhm</id>
    <title>GHSA-5qv3-9727-cwhm</title>
    <updated>2026-11-10T00:32:24.515079+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>power: supply: core: prevent unregistering a power supply while a callback runs</p>
<p>Once a power supply is registered, its callbacks can immediately start
firing from other contexts, such as external_power_changed() triggered by
the TCPM stack. If a power supply is unregistered while the callback is
still running, the driver data can already be freed when the callback
tries to access it, leading to a use-after-free.</p>
<p>This happens e.g. when the hardware bus carrying the power supply device
malfunctions (e.g. I2C is hogged down by another malfunctioning device)
immediately after the power supply is registered, and thus the core is
still processing the callbacks which were queued up when the driver
starts the removal, leading in some cases to a kernel crash, e.g.:</p>
<p>[   11.645942] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000005
[   11.646751] Mem abort info:
[   11.647006]   ESR = 0x0000000096000004
[   11.647338]   EC = 0x25: DABT (current EL), IL = 32 bits
[   11.647806]   SET = 0, FnV = 0
[   11.648077]   EA = 0, S1PTW = 0
[   11.648356]   FSC = 0x04: level 0 translation fault
[   11.648785] Data abort info:
[   11.649041]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[   11.649524]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[   11.649981]   GCS = 0, Overlay = 0, DirtyBit = 0
[   11.650390] [0000000000000005] user address but active_mm is swapper
[   11.650955] Internal erro…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-5qv3-9727-cwhm"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/msrc_cve-2026-99215</id>
    <title>msrc_CVE-2026-99215 — power: supply: core: prevent unregistering a power supply while a callback runs</title>
    <updated>2026-11-10T00:32:24.515123+00:00</updated>
    <content>msrc_CVE-2026-99215</content>
    <link href="https://db.gcve.eu/vuln/msrc_cve-2026-99215"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ubuntu-cve-2026-99215</id>
    <title>UBUNTU-CVE-2026-99215</title>
    <updated>2026-11-10T00:32:24.515143+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:16.04:LTS: linux-hwe-edge and 256 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: power: supply: core: prevent unregistering a power supply while a callback runs Once a power supply is registered, its callbacks can immediately start firing from other contexts, such as external_power_changed() triggered by the TCPM stack. If a power supply is unregistered while the callback is still running, the driver data can already be freed when the callback tries to access it, leading to a use-after-free. This happens e.g. when the hardware bus carrying the power supply device malfunctions (e.g. I2C is hogged down by another malfunctioning device) immediately after the power supply is registered, and thus the core is still processing the callbacks which were queued up when the driver starts the removal, leading in some cases to a kernel crash, e.g.: [   11.645942] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000005 [   11.646751] Mem abort info: [   11.647006]   ESR = 0x0000000096000004 [   11.647338]   EC = 0x25: DABT (current EL), IL = 32 bits [   11.647806]   SET = 0, FnV = 0 [   11.648077]   EA = 0, S1PTW = 0 [   11.648356]   FSC = 0x04: level 0 translation fault [   11.648785] Data abort info: [   11.649041]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 [   11.649524]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0 [   11.649981]   GCS = 0, Overlay = 0, DirtyBit = 0 [   11.650390] [0000000000000005] user address but active_mm is swapper [   11.650955] Internal error: O…</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ubuntu-cve-2026-99215"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/wid-sec-w-2026-4224</id>
    <title>WID-SEC-W-2026-4224 — Linux Kernel: Mehrere Schwachstellen ermöglichen nicht spezifizierten Angriff</title>
    <updated>2026-11-10T00:32:24.515446+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>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.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/wid-sec-w-2026-4224"/>
  </entry>
</feed>
