<?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://cve.radiocsirt.org</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>Sun, 04 Oct 2026 08:56:40 +0000</lastBuildDate>
    <item>
      <title>bdu:2026-14139</title>
      <link>https://cve.radiocsirt.org/vuln/bdu:2026-14139</link>
      <description>bdu:2026-14139</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bdu:2026-14139</guid>
    </item>
    <item>
      <title>BELL-CVE-2026-43488</title>
      <link>https://cve.radiocsirt.org/vuln/bell-cve-2026-43488</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Alpaquita:25: linux-lts, Alpaquita:stream: linux-lts&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/bell-cve-2026-43488</guid>
    </item>
    <item>
      <title>certfr-2026-avi-0926 — De multiples vulnérabilités ont été découvertes dans le noyau Linux d'Ubuntu. Certaines d'entre elles permettent à un a…</title>
      <link>https://cve.radiocsirt.org/vuln/certfr-2026-avi-0926</link>
      <description>certfr-2026-avi-0926</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/certfr-2026-avi-0926</guid>
    </item>
    <item>
      <title>EUVD-2026-318516</title>
      <link>https://cve.radiocsirt.org/vuln/euvd-2026-318516</link>
      <description>EUVD-2026-318516</description>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/euvd-2026-318516</guid>
    </item>
    <item>
      <title>fkie_cve-2026-43488</title>
      <link>https://cve.radiocsirt.org/vuln/fkie_cve-2026-43488</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;usb: xhci: Prevent interrupt storm on host controller error (HCE)&lt;/p&gt;
&lt;p&gt;The xHCI controller reports a Host Controller Error (HCE) in UAS Storage
Device plug/unplug scenarios on Android devices. HCE is checked in
xhci_irq() function and causes an interrupt storm (since the interrupt
isn’t cleared), leading to severe system-level faults.&lt;/p&gt;
&lt;p&gt;When the xHC controller reports HCE in the interrupt handler, the driver
only logs a warning and assumes xHC activity will stop as stated in xHCI
specification. An interrupt storm does however continue on some hosts
even after HCE, and only ceases after manually disabling xHC interrupt
and stopping the controller by calling xhci_halt().&lt;/p&gt;
&lt;p&gt;Add xhci_halt() to xhci_irq() function where STS_HCE status is checked,
mirroring the existing error handling pattern used for STS_FATAL errors.&lt;/p&gt;
&lt;p&gt;This only fixes the interrupt storm. Proper HCE recovery requires resetting
and re-initializing the xHC.&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: xhci: Prevent interrupt storm on host controller error (HCE)&lt;/p&gt;
&lt;p&gt;The xHCI controller reports a Host Controller Error (HCE) in UAS Storage
Device plug/unplug scenarios on Android devices. HCE is checked in
xhci_irq() function and causes an interrupt storm (since the interrupt
isn’t cleared), leading to severe system-level faults.&lt;/p&gt;
&lt;p&gt;When the xHC controller reports HCE in the interrupt handler, the driver
only logs a warning and assumes xHC activity will stop as stated in xHCI
specification. An interrupt storm does however continue on some hosts
even after HCE, and only ceases after manually disabling xHC interrupt
and stopping the controller by calling xhci_halt().&lt;/p&gt;
&lt;p&gt;Add xhci_halt() to xhci_irq() function where STS_HCE status is checked,
mirroring the existing error handling pattern used for STS_FATAL errors.&lt;/p&gt;
&lt;p&gt;This only fixes the interrupt storm. Proper HCE recovery requires resetting
and re-initializing the xHC.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/fkie_cve-2026-43488</guid>
    </item>
    <item>
      <title>GHSA-5x4m-q4p4-96j6</title>
      <link>https://cve.radiocsirt.org/vuln/ghsa-5x4m-q4p4-96j6</link>
      <description>&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;usb: xhci: Prevent interrupt storm on host controller error (HCE)&lt;/p&gt;
&lt;p&gt;The xHCI controller reports a Host Controller Error (HCE) in UAS Storage
Device plug/unplug scenarios on Android devices. HCE is checked in
xhci_irq() function and causes an interrupt storm (since the interrupt
isn’t cleared), leading to severe system-level faults.&lt;/p&gt;
&lt;p&gt;When the xHC controller reports HCE in the interrupt handler, the driver
only logs a warning and assumes xHC activity will stop as stated in xHCI
specification. An interrupt storm does however continue on some hosts
even after HCE, and only ceases after manually disabling xHC interrupt
and stopping the controller by calling xhci_halt().&lt;/p&gt;
&lt;p&gt;Add xhci_halt() to xhci_irq() function where STS_HCE status is checked,
mirroring the existing error handling pattern used for STS_FATAL errors.&lt;/p&gt;
&lt;p&gt;This only fixes the interrupt storm. Proper HCE recovery requires resetting
and re-initializing the xHC.&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: xhci: Prevent interrupt storm on host controller error (HCE)&lt;/p&gt;
&lt;p&gt;The xHCI controller reports a Host Controller Error (HCE) in UAS Storage
Device plug/unplug scenarios on Android devices. HCE is checked in
xhci_irq() function and causes an interrupt storm (since the interrupt
isn’t cleared), leading to severe system-level faults.&lt;/p&gt;
&lt;p&gt;When the xHC controller reports HCE in the interrupt handler, the driver
only logs a warning and assumes xHC activity will stop as stated in xHCI
specification. An interrupt storm does however continue on some hosts
even after HCE, and only ceases after manually disabling xHC interrupt
and stopping the controller by calling xhci_halt().&lt;/p&gt;
&lt;p&gt;Add xhci_halt() to xhci_irq() function where STS_HCE status is checked,
mirroring the existing error handling pattern used for STS_FATAL errors.&lt;/p&gt;
&lt;p&gt;This only fixes the interrupt storm. Proper HCE recovery requires resetting
and re-initializing the xHC.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ghsa-5x4m-q4p4-96j6</guid>
    </item>
    <item>
      <title>OESA-2026-2416 — kernel security update</title>
      <link>https://cve.radiocsirt.org/vuln/oesa-2026-2416</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: fix use-after-free in crypt_message when using async crypto&lt;/p&gt;
&lt;p&gt;The CVE-2024-50047 fix removed asynchronous crypto handling from
crypt_message(), assuming all crypto operations are synchronous.
However, when hardware crypto accelerators are used, this can cause
use-after-free crashes:&lt;/p&gt;
&lt;p&gt;crypt_message()
    // Allocate the creq buffer containing the req
    creq = smb2_get_aead_req(..., &amp;amp;amp;req);&lt;/p&gt;
&lt;p&gt;// Async encryption returns -EINPROGRESS immediately
    rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);&lt;/p&gt;
&lt;p&gt;// Free creq while async operation is still in progress
    kvfree_sensitive(creq, ...);&lt;/p&gt;
&lt;p&gt;Hardware crypto modules often implement async AEAD operations for
performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS,
the operation completes asynchronously. Without crypto_wait_req(),
the function immediately frees the request buffer, leading to crashes
when the driver later accesses the freed memory.&lt;/p&gt;
&lt;p&gt;This results in a use-after-free condition when the hardware crypto
driver later accesses the freed request structure, leading to kernel
crashes with NULL pointer dereferences.&lt;/p&gt;
&lt;p&gt;The issue occurs because crypto_alloc_aead() with mask=0 doesn&amp;amp;apos;t
guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in
the mask, async implementations can be selected.&lt;/p&gt;
&lt;p&gt;Fix by restoring the async crypto han…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; openEuler:22.03-LTS-SP4: kernel&lt;/p&gt;
&lt;p&gt;The Linux Kernel, the operating system core itself.&#13;
&#13;
Security Fix(es):&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;smb: client: fix use-after-free in crypt_message when using async crypto&lt;/p&gt;
&lt;p&gt;The CVE-2024-50047 fix removed asynchronous crypto handling from
crypt_message(), assuming all crypto operations are synchronous.
However, when hardware crypto accelerators are used, this can cause
use-after-free crashes:&lt;/p&gt;
&lt;p&gt;crypt_message()
    // Allocate the creq buffer containing the req
    creq = smb2_get_aead_req(..., &amp;amp;amp;req);&lt;/p&gt;
&lt;p&gt;// Async encryption returns -EINPROGRESS immediately
    rc = enc ? crypto_aead_encrypt(req) : crypto_aead_decrypt(req);&lt;/p&gt;
&lt;p&gt;// Free creq while async operation is still in progress
    kvfree_sensitive(creq, ...);&lt;/p&gt;
&lt;p&gt;Hardware crypto modules often implement async AEAD operations for
performance. When crypto_aead_encrypt/decrypt() returns -EINPROGRESS,
the operation completes asynchronously. Without crypto_wait_req(),
the function immediately frees the request buffer, leading to crashes
when the driver later accesses the freed memory.&lt;/p&gt;
&lt;p&gt;This results in a use-after-free condition when the hardware crypto
driver later accesses the freed request structure, leading to kernel
crashes with NULL pointer dereferences.&lt;/p&gt;
&lt;p&gt;The issue occurs because crypto_alloc_aead() with mask=0 doesn&amp;amp;apos;t
guarantee synchronous operation. Even without CRYPTO_ALG_ASYNC in
the mask, async implementations can be selected.&lt;/p&gt;
&lt;p&gt;Fix by restoring the async crypto han…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/oesa-2026-2416</guid>
    </item>
    <item>
      <title>openSUSE-SU-2026:21555-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/opensuse-su-2026:21555-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/opensuse-su-2026:21555-1</guid>
    </item>
    <item>
      <title>SUSE-SU-2026:23066-1 — Security update for the Linux Kernel</title>
      <link>https://cve.radiocsirt.org/vuln/suse-su-2026:23066-1</link>
      <description>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Security update for the Linux Kernel&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/suse-su-2026:23066-1</guid>
    </item>
    <item>
      <title>UBUNTU-CVE-2026-43488</title>
      <link>https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43488</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 140 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Prevent interrupt storm on host controller error (HCE) The xHCI controller reports a Host Controller Error (HCE) in UAS Storage Device plug/unplug scenarios on Android devices. HCE is checked in xhci_irq() function and causes an interrupt storm (since the interrupt isn’t cleared), leading to severe system-level faults. When the xHC controller reports HCE in the interrupt handler, the driver only logs a warning and assumes xHC activity will stop as stated in xHCI specification. An interrupt storm does however continue on some hosts even after HCE, and only ceases after manually disabling xHC interrupt and stopping the controller by calling xhci_halt(). Add xhci_halt() to xhci_irq() function where STS_HCE status is checked, mirroring the existing error handling pattern used for STS_FATAL errors. This only fixes the interrupt storm. Proper HCE recovery requires resetting and re-initializing the xHC.&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 140 more&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved: usb: xhci: Prevent interrupt storm on host controller error (HCE) The xHCI controller reports a Host Controller Error (HCE) in UAS Storage Device plug/unplug scenarios on Android devices. HCE is checked in xhci_irq() function and causes an interrupt storm (since the interrupt isn’t cleared), leading to severe system-level faults. When the xHC controller reports HCE in the interrupt handler, the driver only logs a warning and assumes xHC activity will stop as stated in xHCI specification. An interrupt storm does however continue on some hosts even after HCE, and only ceases after manually disabling xHC interrupt and stopping the controller by calling xhci_halt(). Add xhci_halt() to xhci_irq() function where STS_HCE status is checked, mirroring the existing error handling pattern used for STS_FATAL errors. This only fixes the interrupt storm. Proper HCE recovery requires resetting and re-initializing the xHC.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/ubuntu-cve-2026-43488</guid>
    </item>
    <item>
      <title>WID-SEC-W-2026-1531 — Linux Kernel: Mehrere Schwachstellen</title>
      <link>https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1531</link>
      <description>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;Ein Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen oder andere nicht näher spezifizierte Auswirkungen zu erzielen.&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/wid-sec-w-2026-1531</guid>
    </item>
  </channel>
</rss>
