<?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>Wed, 07 Oct 2026 14:22:56 +0000</lastBuildDate>
    <item>
      <title>CVE-2026-46148 — spi: microchip-core-qspi: control built-in cs manually</title>
      <link>https://vulnerability.circl.lu/vuln/cve-2026-46148</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;spi: microchip-core-qspi: control built-in cs manually&lt;/p&gt;
&lt;p&gt;The coreQSPI IP supports only a single chip select, which is
automagically operated by the hardware - set low when the transmit
buffer first gets written to and set high when the number of bytes
written to the TOTALBYTES field of the FRAMES register have been sent on
the bus. Additional devices must use GPIOs for their chip selects.
It was reported to me that if there are two devices attached to this
QSPI controller that the in-built chip select is set low while linux
tries to access the device attached to the GPIO.&lt;/p&gt;
&lt;p&gt;This went undetected as the boards that connected multiple devices to
the SPI controller all exclusively used GPIOs for chip selects, not
relying on the built-in chip select at all. It turns out that this was
because the built-in chip select, when controlled automagically, is set
low when active and high when inactive, thereby ruling out its use for
active-high devices or devices that need to transmit with the chip
select disabled.&lt;/p&gt;
&lt;p&gt;Modify the driver so that it controls chip select directly, retaining
the behaviour for mem_ops of setting the chip select active for the
entire duration of the transfer in the exec_op callback. For regular
transfers, implement the set_cs callback for the core to use.&lt;/p&gt;
&lt;p&gt;As part of this, the existing setup callback, mchp_coreqspi_setup_op(),
is removed. Modifying the CLKIDLE field is not safe to do during
operati…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;spi: microchip-core-qspi: control built-in cs manually&lt;/p&gt;
&lt;p&gt;The coreQSPI IP supports only a single chip select, which is
automagically operated by the hardware - set low when the transmit
buffer first gets written to and set high when the number of bytes
written to the TOTALBYTES field of the FRAMES register have been sent on
the bus. Additional devices must use GPIOs for their chip selects.
It was reported to me that if there are two devices attached to this
QSPI controller that the in-built chip select is set low while linux
tries to access the device attached to the GPIO.&lt;/p&gt;
&lt;p&gt;This went undetected as the boards that connected multiple devices to
the SPI controller all exclusively used GPIOs for chip selects, not
relying on the built-in chip select at all. It turns out that this was
because the built-in chip select, when controlled automagically, is set
low when active and high when inactive, thereby ruling out its use for
active-high devices or devices that need to transmit with the chip
select disabled.&lt;/p&gt;
&lt;p&gt;Modify the driver so that it controls chip select directly, retaining
the behaviour for mem_ops of setting the chip select active for the
entire duration of the transfer in the exec_op callback. For regular
transfers, implement the set_cs callback for the core to use.&lt;/p&gt;
&lt;p&gt;As part of this, the existing setup callback, mchp_coreqspi_setup_op(),
is removed. Modifying the CLKIDLE field is not safe to do during
operati…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/cve-2026-46148</guid>
    </item>
    <item>
      <title>USN-8566-1 — linux, linux-gcp, linux-gke, linux-realtime vulnerabilities</title>
      <link>https://vulnerability.circl.lu/vuln/usn-8566-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:26.04:LTS: linux, Ubuntu:26.04:LTS: linux-gcp, Ubuntu:26.04:LTS: linux-gke, Ubuntu:26.04:LTS: linux-realtime&lt;/p&gt;
&lt;p&gt;It was discovered that some AMD Zen 2 processors did not properly isolate
shared resources in the operation cache. A local attacker could possibly
use this issue to corrupt instructions executed at a higher privilege
level, resulting in privilege escalation. (CVE-2025-54518)&lt;/p&gt;
&lt;p&gt;Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
  - PSP security protocol;
  - ARM64 architecture;
  - PowerPC architecture;
  - RISC-V architecture;
  - S390 architecture;
  - User-Mode Linux (UML);
  - x86 architecture;
  - Block layer subsystem;
  - Cryptographic API;
  - Intel NPU Driver;
  - DRBD Distributed Replicated Block Device drivers;
  - Ublk userspace block driver;
  - Bluetooth drivers;
  - Bus devices;
  - Character device driver;
  - Clock framework and drivers;
  - CPU frequency scaling framework;
  - Hardware crypto device drivers;
  - EDAC drivers;
  - EFI core;
  - FWCTL subsystem;
  - GPU drivers;
  - HID subsystem;
  - I3C subsystem;
  - InfiniBand drivers;
  - IOMMU subsystem;
  - Mailbox framework;
  - Multiple devices driver;
  - Media drivers;
  - NVIDIA Tegra memory controller driver;
  - MTD block device drivers;
  - Network drivers;
  - Ethernet bonding driver;
  - Mellanox network drivers;
  - Microsoft Azure Network Adapter (MANA) driver;
  - STMicroelectronics network drivers;
  - MediaTek network drivers;
  - NVME drivers;
  - PCI subsystem;…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:26.04:LTS: linux, Ubuntu:26.04:LTS: linux-gcp, Ubuntu:26.04:LTS: linux-gke, Ubuntu:26.04:LTS: linux-realtime&lt;/p&gt;
&lt;p&gt;It was discovered that some AMD Zen 2 processors did not properly isolate
shared resources in the operation cache. A local attacker could possibly
use this issue to corrupt instructions executed at a higher privilege
level, resulting in privilege escalation. (CVE-2025-54518)&lt;/p&gt;
&lt;p&gt;Several security issues were discovered in the Linux kernel.
An attacker could possibly use these to compromise the system.
This update corrects flaws in the following subsystems:
  - PSP security protocol;
  - ARM64 architecture;
  - PowerPC architecture;
  - RISC-V architecture;
  - S390 architecture;
  - User-Mode Linux (UML);
  - x86 architecture;
  - Block layer subsystem;
  - Cryptographic API;
  - Intel NPU Driver;
  - DRBD Distributed Replicated Block Device drivers;
  - Ublk userspace block driver;
  - Bluetooth drivers;
  - Bus devices;
  - Character device driver;
  - Clock framework and drivers;
  - CPU frequency scaling framework;
  - Hardware crypto device drivers;
  - EDAC drivers;
  - EFI core;
  - FWCTL subsystem;
  - GPU drivers;
  - HID subsystem;
  - I3C subsystem;
  - InfiniBand drivers;
  - IOMMU subsystem;
  - Mailbox framework;
  - Multiple devices driver;
  - Media drivers;
  - NVIDIA Tegra memory controller driver;
  - MTD block device drivers;
  - Network drivers;
  - Ethernet bonding driver;
  - Mellanox network drivers;
  - Microsoft Azure Network Adapter (MANA) driver;
  - STMicroelectronics network drivers;
  - MediaTek network drivers;
  - NVME drivers;
  - PCI subsystem;…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://vulnerability.circl.lu/vuln/usn-8566-1</guid>
    </item>
  </channel>
</rss>
