CVE-2023-52730 addresses a resource leak vulnerability in the Linux kernel's MMC (MultiMediaCard) subsystem, specifically within the SDIO (Secure Digital Input Output) function handling code. The vulnerability arises from improper resource management in error paths during the initialization and addition of SDIO functions. When either sdio_add_func() or sdio_init_func() fails, the corresponding cleanup function sdio_remove_func() does not release allocated resources properly because the SDIO function is not fully registered or presented. Consequently, critical reference counts for device nodes and device objects (tracked via of_node_put() and put_device()) are not decremented, leading to resource leaks. The patch modifies the logic so that sdio_func_present() only controls whether device_del() is called, but ensures that of_node_put() and put_device() are always invoked to balance reference counts. Additionally, the patch moves get_device() calls to sdio_alloc_func() and put_device() calls to sdio_release_func() to maintain balanced get/put device references, preventing redundant decrements and ensuring proper cleanup. This fix eliminates unreferenced object leaks detected during fault injection testing, which previously manifested as unreleased kernel memory objects associated with SDIO card devices. The vulnerability does not appear to allow direct code execution or privilege escalation but can cause kernel memory leaks that degrade system stability and reliability over time, especially on systems heavily utilizing SDIO devices. The issue affects Linux kernel versions identified by the commit hash 3d10a1ba0d37c8f5fd5afcdda00613fbb8a90bf5 and potentially other versions incorporating the vulnerable code. No known exploits are reported in the wild, and no CVSS score has been assigned yet. The vulnerability is primarily a resource management flaw rather than a direct security bypass or escalation vector.

For European organizations, the primary impact of CVE-2023-52730 lies in potential system stability and reliability degradation on Linux systems that utilize SDIO devices, such as embedded systems, industrial controllers, IoT devices, or laptops with SDIO-based peripherals. Resource leaks in kernel memory can accumulate over time, leading to increased memory consumption, potential kernel panics, or system crashes, which could disrupt critical business operations or industrial processes. While this vulnerability does not directly compromise confidentiality or integrity, availability could be affected due to system instability. Organizations relying on Linux-based infrastructure with SDIO hardware components may experience degraded performance or unexpected downtime if the vulnerability is exploited or triggered by faulty device interactions. This is particularly relevant for sectors with embedded Linux deployments, such as manufacturing, telecommunications, transportation, and critical infrastructure in Europe. Given the lack of known exploits, the immediate risk is moderate, but unpatched systems remain vulnerable to stability issues. The vulnerability also highlights the importance of rigorous kernel maintenance and patching practices to prevent latent bugs from impacting operational continuity.

European organizations should take the following specific mitigation steps: 1. Patch Management: Promptly apply the official Linux kernel patches that address CVE-2023-52730 once available from trusted Linux distributions or kernel maintainers. Monitor vendor advisories for updated kernel packages. 2. Kernel Version Control: Avoid running unpatched or custom kernel builds that include the vulnerable SDIO code paths. Validate kernel versions against known fixed commits. 3. SDIO Device Inventory: Identify and document all systems using SDIO devices, including embedded and IoT devices, to prioritize patch deployment. 4. Monitoring and Diagnostics: Implement kernel memory usage monitoring and logging to detect abnormal memory growth or leaks that could indicate exploitation or triggering of the vulnerability. 5. Fault Injection Testing: For organizations with in-house kernel development or customization, conduct fault injection testing similar to the one described to verify the absence of resource leaks. 6. Controlled Device Usage: Limit or control the use of SDIO devices on critical systems until patches are applied, especially in environments where system availability is paramount. 7. Vendor Coordination: Engage with hardware and Linux distribution vendors to ensure timely updates and support for affected devices and kernels. These measures go beyond generic advice by emphasizing targeted inventory, monitoring, and testing specific to the SDIO subsystem and kernel resource management.