<?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://vulnerability.circl.lu</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, 05 Oct 2026 01:53:49 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-06024</title>
      <link>https://vulnerability.circl.lu/vuln/bdu:2026-06024</link>
      <description>bdu:2026-06024</description>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/bdu:2026-06024</guid>
    </item>
    <item>
      <title>BELL-CVE-2023-53392</title>
      <link>https://vulnerability.circl.lu/vuln/bell-cve-2023-53392</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/bell-cve-2023-53392</guid>
    </item>
    <item>
      <title>fkie_cve-2023-53392</title>
      <link>https://vulnerability.circl.lu/vuln/fkie_cve-2023-53392</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;HID: intel-ish-hid: Fix kernel panic during warm reset&lt;/p&gt;
&lt;p&gt;During warm reset device-&amp;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-&amp;gt;fw_client-&amp;gt;props.protocol_name.&lt;/p&gt;
&lt;p&gt;ISH firmware after getting successfully loaded, sends a warm reset
notification to remove all clients from the bus and sets
device-&amp;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.&lt;/p&gt;
&lt;p&gt;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.&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;HID: intel-ish-hid: Fix kernel panic during warm reset&lt;/p&gt;
&lt;p&gt;During warm reset device-&amp;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-&amp;gt;fw_client-&amp;gt;props.protocol_name.&lt;/p&gt;
&lt;p&gt;ISH firmware after getting successfully loaded, sends a warm reset
notification to remove all clients from the bus and sets
device-&amp;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/fkie_cve-2023-53392</guid>
    </item>
    <item>
      <title>GHSA-h5fg-gggq-x5vh</title>
      <link>https://vulnerability.circl.lu/vuln/ghsa-h5fg-gggq-x5vh</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;HID: intel-ish-hid: Fix kernel panic during warm reset&lt;/p&gt;
&lt;p&gt;During warm reset device-&amp;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-&amp;gt;fw_client-&amp;gt;props.protocol_name.&lt;/p&gt;
&lt;p&gt;ISH firmware after getting successfully loaded, sends a warm reset
notification to remove all clients from the bus and sets
device-&amp;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.&lt;/p&gt;
&lt;p&gt;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.&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;HID: intel-ish-hid: Fix kernel panic during warm reset&lt;/p&gt;
&lt;p&gt;During warm reset device-&amp;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-&amp;gt;fw_client-&amp;gt;props.protocol_name.&lt;/p&gt;
&lt;p&gt;ISH firmware after getting successfully loaded, sends a warm reset
notification to remove all clients from the bus and sets
device-&amp;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.&lt;/p&gt;
&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ghsa-h5fg-gggq-x5vh</guid>
    </item>
    <item>
      <title>RHSA-2023:6583 — security update for kernel</title>
      <link>https://vulnerability.circl.lu/vuln/rhsa-2023:6583</link>
      <description>&lt;p&gt;security update for kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;security update for kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/rhsa-2023:6583</guid>
    </item>
    <item>
      <title>RXSA-2024:3138 — Moderate: kernel security, bug fix, and enhancement update</title>
      <link>https://vulnerability.circl.lu/vuln/rxsa-2024:3138</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Rocky Linux:8: kernel&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;
&lt;p&gt;Additional Changes:&lt;/p&gt;
&lt;p&gt;For detailed information on changes in this release, see the Rocky Linux SIG Cloud 8.10 Release Notes linked from the References section.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Rocky Linux:8: kernel&lt;/p&gt;
&lt;p&gt;The kernel packages contain the Linux kernel, the core of any Linux operating system.&lt;/p&gt;
&lt;p&gt;Security Fix(es):&lt;/p&gt;
&lt;p&gt;For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.&lt;/p&gt;
&lt;p&gt;Additional Changes:&lt;/p&gt;
&lt;p&gt;For detailed information on changes in this release, see the Rocky Linux SIG Cloud 8.10 Release Notes linked from the References section.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/rxsa-2024:3138</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2023-53392</title>
      <link>https://vulnerability.circl.lu/vuln/ubuntu-cve-2023-53392</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 81 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: Fix kernel panic during warm reset During warm reset device-&amp;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-&amp;gt;fw_client-&amp;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-&amp;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.&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 81 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: Fix kernel panic during warm reset During warm reset device-&amp;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-&amp;gt;fw_client-&amp;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-&amp;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/ubuntu-cve-2023-53392</guid>
    </item>
    <item>
      <title>WID-SEC-W-2025-2092 — Linux Kernel: Mehrere Schwachstellen ermöglichen Denial of Service</title>
      <link>https://vulnerability.circl.lu/vuln/wid-sec-w-2025-2092</link>
      <description>&lt;p&gt;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.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;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.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/wid-sec-w-2025-2092</guid>
    </item>
  </channel>
</rss>
