CVE-2026-46293: Linux Microchip Clock Driver Out-of-Bounds Memory Access

Technical summary

CVE-2026-46293 involves an out-of-bounds read/write vulnerability (CWE-125) in the Linux kernel's Microchip Clock and Conditioning Controller (mpfs-ccc) driver, specifically in the output registration function. The driver allocates an hws array sized for two PLLs with four output dividers each, but the ID enumeration includes two additional unsupported DLLs and their outputs. When the driver processes the last two outputs, it uses unadjusted array indices that exceed the allocated buffer. The UBSAN (Undefined Behavior Sanitizer) runtime check detects memory corruption during device initialization. A fix is available that decrements PLL output IDs by two before adding them to the array, ensuring indices remain within bounds.

Business impact

Exploitation could enable local privilege escalation or information disclosure on systems running vulnerable kernel versions with the Microchip clock driver enabled. Affected devices typically include embedded systems and FPGA development boards using the PolarFire SoC architecture. Denial of service is also possible through kernel panic. Organizations deploying such hardware should prioritize patching to prevent memory corruption exploits and maintain system stability.

Affected systems

The vulnerability affects the Linux kernel on systems equipped with Microchip PolarFire SoC devices that utilize the mpfs-ccc clock controller driver. This includes embedded boards, industrial control systems, and FPGA-based platforms running Linux. The vulnerability is present from the introduction of the driver and persists until patched. Desktop and server systems without this specific SoC hardware are not affected.

Exploitability

Exploitation requires local access with user-level privileges; no network vector is available. The vulnerability is triggered during normal clock output registration, making it possible to exploit during system boot or driver initialization. While the UBSAN report indicates the memory access occurs predictably, successful weaponization depends on kernel memory layout, ASLR settings, and adjacent data structures. A motivated local attacker with modest technical capability could craft an exploit to leak kernel data or corrupt critical structures.

Remediation

Apply the Linux kernel patch that corrects the array indexing in the mpfs-ccc driver's output registration code. Verify the patch version against your kernel branch and test thoroughly in a staging environment before production deployment. For systems where kernel updates are constrained, limiting local user access and enforcing strong authentication mitigates the attack surface.

Patch guidance

Obtain the fix from the Linux kernel repository for your distribution or kernel version. The patch modifies the output registration logic to decrement PLL output IDs by two before array insertion, bringing indices into the allocated bounds. Verify the patch against your kernel source to ensure compatibility with any local modifications. Test on a non-production PolarFire SoC system if available before rolling out across infrastructure.

Detection guidance

Monitor system logs for UBSAN warnings or kernel Oops messages originating from the mpfs-ccc driver during boot or initialization. Kernel address sanitizer (KASAN) builds will also flag the memory violation if enabled. Enable kernel debugging features in development environments to catch the issue early. On production systems, watch for unexpected kernel panics or hangs during clock initialization, which may indicate exploitation attempts.

Why prioritize this

Although the vulnerability requires local access, the combination of HIGH CVSS score (7.1), information disclosure risk, and availability impact (kernel panic) places it in the priority patch tier for affected infrastructure. Organizations with PolarFire SoC deployments should address this promptly; others can defer unless local user access is a significant threat model.

Risk score, explained

The CVSS 3.1 score of 7.1 (HIGH) reflects attack complexity of Low and privilege requirement of Low (user-level local access only), with high impact on both confidentiality (memory disclosure) and availability (denial of service). The lack of network attack vector and requirement for local presence constrain the overall score from Critical, but the reliability and ease of exploitation on vulnerable systems justify the HIGH severity rating.

Frequently asked questions