CVE-2025-22095 is a vulnerability identified in the Linux kernel, specifically within the PCI subsystem related to the brcmstb driver, which is Broadcom's STB (Set-Top Box) platform support. The issue arises in the error handling path after a call to regulator_bulk_get(), a function responsible for acquiring multiple regulator handles in bulk. If regulator_bulk_get() returns an error and no regulators are created, the number of regulators is not reset to zero. This improper handling leads to a scenario where, if the PCIe link initialization subsequently fails, a call to regulator_bulk_free() attempts to free uninitialized or non-existent regulators. This results in a kernel panic, causing a denial of service (DoS) condition by crashing the system. The vulnerability is rooted in the failure to correctly manage the internal state of regulator counts during error conditions, which is critical for stable PCI device initialization and power management. The patch involves resetting the number of regulators to zero when no regulators are created after an error and logging the error value for better diagnostics. Notably, the kernel cannot propagate this error upwards due to constraints in the add_bus() function, which would WARN() on errors, so the fix focuses on internal state correction and error logging. This vulnerability does not appear to have known exploits in the wild as of the publication date (April 16, 2025). The affected versions are identified by a specific commit hash, indicating this is a recent and targeted fix in the Linux kernel source. The lack of a CVSS score suggests this is a newly disclosed issue with limited public exploitation information.

For European organizations, the primary impact of CVE-2025-22095 is the potential for denial of service through kernel panics on systems running vulnerable Linux kernel versions with the brcmstb PCI driver enabled. This could affect embedded devices, set-top boxes, or specialized hardware platforms using Broadcom STB components, which may be deployed in telecommunications, media, or industrial environments. A kernel panic leads to system crashes requiring manual or automated reboots, potentially disrupting critical services or operations. While this vulnerability does not directly lead to privilege escalation or data breaches, the availability impact can be significant in environments relying on continuous uptime, such as broadcasting infrastructure, network equipment, or IoT deployments. European organizations with Linux-based infrastructure that includes Broadcom STB hardware or similar PCIe devices are at risk. The absence of known exploits reduces immediate threat levels, but the vulnerability's presence in kernel code means that attackers with local access or the ability to trigger PCIe link failures could exploit it to cause service interruptions. This is particularly relevant for sectors with stringent availability requirements, including telecommunications providers, media companies, and industrial control systems across Europe.

To mitigate CVE-2025-22095, European organizations should: 1) Identify and inventory Linux systems running kernels that include the brcmstb PCI driver, especially those using Broadcom STB hardware or similar PCIe devices. 2) Apply the latest Linux kernel updates or patches that include the fix for this vulnerability as soon as they become available from trusted Linux distributions or kernel maintainers. 3) For embedded or specialized devices where kernel updates are not straightforward, coordinate with hardware vendors or device manufacturers to obtain firmware or kernel patches addressing this issue. 4) Implement monitoring for kernel panics and PCIe link failures to detect potential exploitation attempts or instability caused by this vulnerability. 5) Restrict local access to vulnerable systems to trusted personnel only, as exploitation requires triggering PCIe link failures and kernel interactions. 6) In environments where uptime is critical, consider deploying redundant systems or failover mechanisms to minimize disruption from potential kernel panics. 7) Conduct thorough testing of kernel updates in staging environments to ensure stability and compatibility before production deployment. These steps go beyond generic advice by focusing on hardware-specific considerations, proactive monitoring, and operational continuity planning tailored to the nature of this vulnerability.