<?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>Fri, 16 Oct 2026 18:12:20 +0000</lastBuildDate>
    <item>
      <title>CVE-2025-37945 — net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY</title>
      <link>https://cve.radiocsirt.org/vuln/cve-2025-37945</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux, Siemens SIMATIC S7-1500 CPU 1518-4 PN/DP MFP, Siemens SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP, Siemens SIPLUS S7-1500 CPU 1518-4 PN/DP MFP&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY&lt;/p&gt;
&lt;p&gt;DSA has 2 kinds of drivers:&lt;/p&gt;
&lt;p&gt;1. Those who call dsa_switch_suspend() and dsa_switch_resume() from
   their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz
2. Those who don&amp;#39;t: all others. The above methods should be optional.&lt;/p&gt;
&lt;p&gt;For type 1, dsa_switch_suspend() calls dsa_user_suspend() -&amp;gt; phylink_stop(),
and dsa_switch_resume() calls dsa_user_resume() -&amp;gt; phylink_start().
These seem good candidates for setting mac_managed_pm = true because
that is essentially its definition [1], but that does not seem to be the
biggest problem for now, and is not what this change focuses on.&lt;/p&gt;
&lt;p&gt;Talking strictly about the 2nd category of DSA drivers here (which
do not have MAC managed PM, meaning that for their attached PHYs,
mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full),
I have noticed that the following warning from mdio_bus_phy_resume() is
triggered:&lt;/p&gt;
&lt;p&gt;WARN_ON(phydev-&amp;gt;state != PHY_HALTED &amp;amp;&amp;amp; phydev-&amp;gt;state != PHY_READY &amp;amp;&amp;amp;
		phydev-&amp;gt;state != PHY_UP);&lt;/p&gt;
&lt;p&gt;because the PHY state machine is running.&lt;/p&gt;
&lt;p&gt;It&amp;#39;s running as a result of a previous dsa_user_open() -&amp;gt; ... -&amp;gt;
phylink_start() -&amp;gt; phy_start() having been initiated by the user.&lt;/p&gt;
&lt;p&gt;The previous mdio_bus_phy_suspend() was supposed to have called
phy_stop_machine(), but it didn&amp;#39;t. So this is why the PHY is in state
PHY_NOLINK by the time mdio_bus_phy_resume() runs.&lt;/p&gt;
&lt;p&gt;mdio_bus_phy_su…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Linux, Siemens SIMATIC S7-1500 CPU 1518-4 PN/DP MFP, Siemens SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP, Siemens SIPLUS S7-1500 CPU 1518-4 PN/DP MFP&lt;/p&gt;
&lt;p&gt;In the Linux kernel, the following vulnerability has been resolved:&lt;/p&gt;
&lt;p&gt;net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY&lt;/p&gt;
&lt;p&gt;DSA has 2 kinds of drivers:&lt;/p&gt;
&lt;p&gt;1. Those who call dsa_switch_suspend() and dsa_switch_resume() from
   their device PM ops: qca8k-8xxx, bcm_sf2, microchip ksz
2. Those who don&amp;#39;t: all others. The above methods should be optional.&lt;/p&gt;
&lt;p&gt;For type 1, dsa_switch_suspend() calls dsa_user_suspend() -&amp;gt; phylink_stop(),
and dsa_switch_resume() calls dsa_user_resume() -&amp;gt; phylink_start().
These seem good candidates for setting mac_managed_pm = true because
that is essentially its definition [1], but that does not seem to be the
biggest problem for now, and is not what this change focuses on.&lt;/p&gt;
&lt;p&gt;Talking strictly about the 2nd category of DSA drivers here (which
do not have MAC managed PM, meaning that for their attached PHYs,
mdio_bus_phy_suspend() and mdio_bus_phy_resume() should run in full),
I have noticed that the following warning from mdio_bus_phy_resume() is
triggered:&lt;/p&gt;
&lt;p&gt;WARN_ON(phydev-&amp;gt;state != PHY_HALTED &amp;amp;&amp;amp; phydev-&amp;gt;state != PHY_READY &amp;amp;&amp;amp;
		phydev-&amp;gt;state != PHY_UP);&lt;/p&gt;
&lt;p&gt;because the PHY state machine is running.&lt;/p&gt;
&lt;p&gt;It&amp;#39;s running as a result of a previous dsa_user_open() -&amp;gt; ... -&amp;gt;
phylink_start() -&amp;gt; phy_start() having been initiated by the user.&lt;/p&gt;
&lt;p&gt;The previous mdio_bus_phy_suspend() was supposed to have called
phy_stop_machine(), but it didn&amp;#39;t. So this is why the PHY is in state
PHY_NOLINK by the time mdio_bus_phy_resume() runs.&lt;/p&gt;
&lt;p&gt;mdio_bus_phy_su…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/cve-2025-37945</guid>
    </item>
    <item>
      <title>USN-7594-1 — linux, linux-gcp, linux-raspi, linux-realtime vulnerabilities</title>
      <link>https://cve.radiocsirt.org/vuln/usn-7594-1</link>
      <description>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:25.04: linux, Ubuntu:25.04: linux-gcp, Ubuntu:25.04: linux-raspi, Ubuntu:25.04: linux-realtime&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:
  - ARM32 architecture;
  - ARM64 architecture;
  - PowerPC architecture;
  - RISC-V architecture;
  - User-Mode Linux (UML);
  - x86 architecture;
  - Block layer subsystem;
  - Cryptographic API;
  - Compute Acceleration Framework;
  - ACPI drivers;
  - Serial ATA and Parallel ATA drivers;
  - Drivers core;
  - Ublk userspace block driver;
  - Bluetooth drivers;
  - Bus devices;
  - TPM device driver;
  - Clock framework and drivers;
  - CPU frequency scaling framework;
  - Buffer Sharing and Synchronization framework;
  - DMA engine subsystem;
  - GPU drivers;
  - HID subsystem;
  - HSI subsystem;
  - I2C subsystem;
  - I3C subsystem;
  - IIO subsystem;
  - InfiniBand drivers;
  - IOMMU subsystem;
  - IRQ chip drivers;
  - MCB driver;
  - Multiple devices driver;
  - Media drivers;
  - MemoryStick subsystem;
  - Multifunction device drivers;
  - Microchip PCI driver;
  - Intel Management Engine Interface driver;
  - PCI Endpoint Test driver;
  - MTD block device drivers;
  - Network drivers;
  - Ethernet bonding driver;
  - Mellanox network drivers;
  - STMicroelectronics network drivers;
  - NTB driver;
  - NVME drivers;
  - PCI subsystem;
  - Synopsys DesignWare PCIe PMU;
  - Mellanox platform drivers;
  - PWM drivers;
  - Remote Processor subsystem;
  - S/390 drivers;
  - SCSI subsystem;
  -…&lt;/p&gt;</description>
      <content:encoded>&lt;p&gt;&lt;strong&gt;Affected:&lt;/strong&gt; Ubuntu:25.04: linux, Ubuntu:25.04: linux-gcp, Ubuntu:25.04: linux-raspi, Ubuntu:25.04: linux-realtime&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:
  - ARM32 architecture;
  - ARM64 architecture;
  - PowerPC architecture;
  - RISC-V architecture;
  - User-Mode Linux (UML);
  - x86 architecture;
  - Block layer subsystem;
  - Cryptographic API;
  - Compute Acceleration Framework;
  - ACPI drivers;
  - Serial ATA and Parallel ATA drivers;
  - Drivers core;
  - Ublk userspace block driver;
  - Bluetooth drivers;
  - Bus devices;
  - TPM device driver;
  - Clock framework and drivers;
  - CPU frequency scaling framework;
  - Buffer Sharing and Synchronization framework;
  - DMA engine subsystem;
  - GPU drivers;
  - HID subsystem;
  - HSI subsystem;
  - I2C subsystem;
  - I3C subsystem;
  - IIO subsystem;
  - InfiniBand drivers;
  - IOMMU subsystem;
  - IRQ chip drivers;
  - MCB driver;
  - Multiple devices driver;
  - Media drivers;
  - MemoryStick subsystem;
  - Multifunction device drivers;
  - Microchip PCI driver;
  - Intel Management Engine Interface driver;
  - PCI Endpoint Test driver;
  - MTD block device drivers;
  - Network drivers;
  - Ethernet bonding driver;
  - Mellanox network drivers;
  - STMicroelectronics network drivers;
  - NTB driver;
  - NVME drivers;
  - PCI subsystem;
  - Synopsys DesignWare PCIe PMU;
  - Mellanox platform drivers;
  - PWM drivers;
  - Remote Processor subsystem;
  - S/390 drivers;
  - SCSI subsystem;
  -…&lt;/p&gt;</content:encoded>
      <guid isPermaLink="false">https://cve.radiocsirt.org/vuln/usn-7594-1</guid>
    </item>
  </channel>
</rss>
