CVE-2026-46293

What it actually does

The flaw is an out-of-bounds access in the Linux kernel Microchip PolarFire SoC clock controller driver during clock output registration. The driver allocates space for two PLLs and their output dividers but uses IDs that also account for unsupported DLL entries, causing the final PLL output registrations to index outside the allocated hardware-clock array. On affected systems where this driver is initialized, the issue can trigger kernel memory corruption, UBSAN/KASAN reports, failed device initialization, or a kernel crash. Practical exploitation is expected to be hardware- and configuration-dependent, with no public exploit maturity reported and a low EPSS score.

Why it matters to the business

The primary operational risk is instability or denial of service on Linux systems using the affected Microchip PolarFire SoC clock controller driver, especially embedded, appliance, industrial, or edge systems where a kernel crash can interrupt service. Because this is kernel-level code, any successful abuse or accidental trigger has high reliability and availability implications for affected platforms, but broad internet-scale exploitation is unlikely given the hardware-specific attack surface, non-KEV status, no known ransomware use, and currently low EPSS likelihood.

How an attack unfolds

An attacker would first need to target a Linux system that includes and initializes the Microchip PolarFire SoC CCC clock driver. The vulnerable path is reached when the driver registers clock outputs and uses an ID ordering that includes unsupported DLL identifiers, causing the last PLL output entries to be added using indexes beyond the allocated array. In a realistic scenario, exploitation would likely require local, boot-time, module-loading, device-binding, or device-tree influence rather than a network request. If the vulnerable registration path is triggered, the kernel may read or write outside the intended array, leading to a crash, memory corruption, or unstable device behavior. There is no indication from the provided data that this flaw is being actively exploited or used by named threat actors.

How to fix it

Update to a Linux kernel version or vendor kernel package that includes the upstream fix for the Microchip MPFS CCC clock driver out-of-bounds registration bug. Where an immediate kernel update is not possible, reduce exposure by disabling or not building the affected Microchip PolarFire SoC CCC clock driver on systems that do not require it, avoiding untrusted or externally modifiable device-tree inputs, and restricting the ability to load kernel modules or bind/unbind platform drivers to trusted administrators only. For embedded products, pull the vendor BSP or long-term-support kernel update containing the corrected PLL output ID handling and include it in the next firmware image.

How to confirm the fix worked

Confirm the running kernel or firmware image includes the corrected driver logic that adjusts PLL output IDs before inserting them into the hardware-clock array. Validate by checking vendor kernel advisories, package changelogs, or source patches for the Microchip MPFS CCC clock driver fix. On representative hardware, boot the patched kernel with normal device-tree configuration and confirm that the clock controller initializes without UBSAN, KASAN, WARN, oops, or panic messages. If the affected driver is not required, verify it is not built in, not loadable, or not present in the deployed kernel configuration.

Typical attack path

1. Identify a Linux target built with the Microchip PolarFire SoC CCC clock controller driver enabled.
2. Confirm the driver is present, loaded, or initialized on compatible Microchip PolarFire SoC hardware or via a relevant device-tree configuration.
3. Trigger driver probe or clock output registration, such as during boot, device binding, or module initialization where applicable.
4. Cause the vulnerable output-registration logic to process the final PLL output IDs.
5. The driver indexes past the allocated hardware-clock array, resulting in UBSAN/KASAN findings, kernel memory corruption, driver failure, or a system crash.

How to detect it

To determine whether this issue was already triggered, review kernel and boot logs for UBSAN or KASAN array-index reports, kernel oopses, panics, unexpected watchdog resets, or failed clock-controller probe messages involving the Microchip MPFS CCC driver. Useful log sources include dmesg, journalctl kernel logs, persistent boot logs, serial console captures, crash dumps, pstore/ramoops records, kdump/vmcore analysis, and embedded device watchdog/reset telemetry. Focus on events during system boot, module initialization, platform device binding, firmware upgrades, or device-tree changes. Because no public exploitation or threat actor activity is indicated, treat findings as potential vulnerability triggers or stability events rather than definitive compromise unless accompanied by evidence of unauthorized kernel-module loading, device-tree tampering, or privileged local activity.

• UBSAN: array-index-out-of-bounds
• array-index-out-of-bounds in drivers/clk/microchip
• KASAN: out-of-bounds
• mpfs-ccc
• clk-mpfs-ccc
• microchip mpfs ccc
• Microchip PolarFire SoC
• kernel BUG
• Oops:
• Kernel panic
• watchdog: watchdog0: watchdog did not stop
• pstore
• ramoops

What your security team should do

• Prioritize patching Linux kernels and embedded firmware images on systems using Microchip PolarFire SoC or the affected MPFS CCC clock controller driver.
• Inventory kernel builds and firmware images for Microchip MPFS/PolarFire SoC clock driver support to determine whether the vulnerability is reachable.
• If the driver is unnecessary, remove or disable it in kernel configuration to eliminate the attack surface.
• Restrict kernel module loading, platform-driver binding, and device-tree modification to trusted administrative paths only.
• Monitor kernel logs for UBSAN, KASAN, oops, panic, or reboot events associated with the Microchip clock driver, especially after boot or firmware updates.
• Track vendor BSP, distribution, and long-term-support kernel updates because fixed package versions were not provided in the input data.