<?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-10-01T12:30:42.592496+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/bdu:2026-06024</id>
    <title>bdu:2026-06024</title>
    <updated>2026-10-01T12:30:43.157672+00:00</updated>
    <content>bdu:2026-06024</content>
    <link href="https://db.gcve.eu/vuln/bdu:2026-06024"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/fkie_cve-2023-53392</id>
    <title>fkie_cve-2023-53392</title>
    <updated>2026-10-01T12:30:43.157911+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>HID: intel-ish-hid: Fix kernel panic during warm reset</p>
<p>During warm reset device-&gt;fw_client is set to NULL. If a bus driver is
registered after this NULL setting and before new firmware clients are
enumerated by ISHTP, kernel panic will result in the function
ishtp_cl_bus_match(). This is because of reference to
device-&gt;fw_client-&gt;props.protocol_name.</p>
<p>ISH firmware after getting successfully loaded, sends a warm reset
notification to remove all clients from the bus and sets
device-&gt;fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel
module drivers were loaded right after any of the first ISHTP device was
registered, regardless of whether it was a matched or an unmatched
device. This resulted in all drivers getting registered much before the
warm reset notification from ISH.</p>
<p>Starting kernel v5.16, this issue got exposed after the change was
introduced to load only bus drivers for the respective matching devices.
In this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are
registered after the warm reset device fw_client NULL setting.
cros_ec_ishtp driver_register() triggers the callback to
ishtp_cl_bus_match() to match ISHTP driver to the device and causes kernel
panic in guid_equal() when dereferencing fw_client NULL pointer to get
protocol_name.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/fkie_cve-2023-53392"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ghsa-h5fg-gggq-x5vh</id>
    <title>GHSA-h5fg-gggq-x5vh</title>
    <updated>2026-10-01T12:30:43.158080+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>HID: intel-ish-hid: Fix kernel panic during warm reset</p>
<p>During warm reset device-&gt;fw_client is set to NULL. If a bus driver is
registered after this NULL setting and before new firmware clients are
enumerated by ISHTP, kernel panic will result in the function
ishtp_cl_bus_match(). This is because of reference to
device-&gt;fw_client-&gt;props.protocol_name.</p>
<p>ISH firmware after getting successfully loaded, sends a warm reset
notification to remove all clients from the bus and sets
device-&gt;fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel
module drivers were loaded right after any of the first ISHTP device was
registered, regardless of whether it was a matched or an unmatched
device. This resulted in all drivers getting registered much before the
warm reset notification from ISH.</p>
<p>Starting kernel v5.16, this issue got exposed after the change was
introduced to load only bus drivers for the respective matching devices.
In this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are
registered after the warm reset device fw_client NULL setting.
cros_ec_ishtp driver_register() triggers the callback to
ishtp_cl_bus_match() to match ISHTP driver to the device and causes kernel
panic in guid_equal() when dereferencing fw_client NULL pointer to get
protocol_name.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ghsa-h5fg-gggq-x5vh"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/rhsa-2023:6583</id>
    <title>RHSA-2023:6583 — Red Hat Security Advisory: kernel security, bug fix, and enhancement update</title>
    <updated>2026-10-01T12:30:43.158137+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p>kernel: seg6: fix the iif in the IPv6 socket control block Kernel: race when faulting a device private page in memory manager kernel: use-after-free in l1oip timer handlers kernel: Rate limit overflow messages in r8152 in intr_callback kernel: vmwgfx: use-after-free in vmw_cmd_res_check kernel: vmwgfx: use-after-free in vmw_execbuf_tie_context hw: Intel: Gather Data Sampling (GDS) side channel vulnerability kernel: Information leak in l2cap_parse_conf_req in net/bluetooth/l2cap_core.c kernel: perf: Fix perf_pending_task() UaF kernel: gpiolib: fix memory leak in gpiochip_setup_dev() kernel: memcg: fix possible use-after-free in memcg_write_event_control() kernel: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths kernel: char: tpm: Protect tpm_pm_suspend with locks kernel: ixgbevf: Fix resource leak in ixgbevf_init_module() kernel: dax: make sure inodes are flushed before destroy cache kernel: watch_queue: Actually free the watch kernel: watch_queue: Fix NULL dereference in error cleanup kernel: rtc: pl031: fix rtc features null pointer dereference kernel: tpm: fix reference counting for struct tpm_chip kernel: NFSv4: Don't hold the layoutget locks across multiple RPC calls kernel: xprtrdma: treat all calls not a bcall when bc_serv is NULL kernel: net: ipv6: unexport __init-annotated seg6_hmac_init() kernel: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). kernel: regulator: scmi: Fix refcount leak in scmi_regulator_probe kernel: mm/mempolicy: fix uninit-v…</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/rhsa-2023:6583"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/ubuntu-cve-2023-53392</id>
    <title>UBUNTU-CVE-2023-53392</title>
    <updated>2026-10-01T12:30:43.162348+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> 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 81 more</p>
<p>In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: Fix kernel panic during warm reset During warm reset device-&gt;fw_client is set to NULL. If a bus driver is registered after this NULL setting and before new firmware clients are enumerated by ISHTP, kernel panic will result in the function ishtp_cl_bus_match(). This is because of reference to device-&gt;fw_client-&gt;props.protocol_name. ISH firmware after getting successfully loaded, sends a warm reset notification to remove all clients from the bus and sets device-&gt;fw_client to NULL. Until kernel v5.15, all enabled ISHTP kernel module drivers were loaded right after any of the first ISHTP device was registered, regardless of whether it was a matched or an unmatched device. This resulted in all drivers getting registered much before the warm reset notification from ISH. Starting kernel v5.16, this issue got exposed after the change was introduced to load only bus drivers for the respective matching devices. In this scenario, cros_ec_ishtp device and cros_ec_ishtp driver are registered after the warm reset device fw_client NULL setting. cros_ec_ishtp driver_register() triggers the callback to ishtp_cl_bus_match() to match ISHTP driver to the device and causes kernel panic in guid_equal() when dereferencing fw_client NULL pointer to get protocol_name.</p></div>
    </content>
    <link href="https://db.gcve.eu/vuln/ubuntu-cve-2023-53392"/>
  </entry>
  <entry>
    <id>https://db.gcve.eu/vuln/wid-sec-w-2025-2092</id>
    <title>WID-SEC-W-2025-2092 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
    <updated>2026-10-01T12:30:43.163304+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 Denial of Service Angriff durchzuführen und um nicht nähere beschriebene Effekte zu verursachen.</p>
      </div>
    </content>
    <link href="https://db.gcve.eu/vuln/wid-sec-w-2025-2092"/>
  </entry>
</feed>
