CVE-2026-43274

What it actually does

This is an out-of-bounds memory access flaw in the Linux kernel Microchip IPC SBI mailbox driver. The vulnerable code allocates a per-CPU configuration array sized by the number of online CPUs, but indexes that array using a hardware hart ID that may be non-contiguous or larger than the allocated array. On affected systems where this driver and hardware/firmware path are present, an attacker able to trigger the affected local kernel code path could cause memory corruption, potentially leading to kernel crash, information disclosure, or privilege escalation depending on memory layout and exploitability.

Why it matters to the business

Successful exploitation could compromise the operating system kernel, allowing disruption of affected Linux systems or potentially full host takeover. The practical exposure is likely concentrated in systems using the affected Microchip IPC SBI mailbox driver and relevant CPU topology, but kernel vulnerabilities carry high operational risk because a single successful exploit can bypass normal application and user-level controls. This issue is not currently listed in CISA KEV, has no known public exploit maturity in the supplied data, and has a low EPSS score, so urgency should be driven primarily by whether affected hardware and kernels are deployed.

How an attack unfolds

An attacker first needs local ability to execute code or otherwise interact with an exposed interface that reaches the affected mailbox driver path. They then trigger the code that enumerates online CPUs and obtains cluster aggregate IRQ configuration. In vulnerable kernels, the driver uses a hart ID as an array index even though the array was allocated by CPU count, so a non-contiguous or high hart ID can read or write outside the intended allocation. If the out-of-bounds access only corrupts unstable memory, exploitation may result in a kernel panic or denial of service. With reliable heap shaping and a favorable kernel build/configuration, the same primitive may be developed into disclosure of kernel memory or arbitrary kernel memory corruption leading to elevated privileges. There are no supplied indications of active exploitation, ransomware use, or named threat actor activity.

How to fix it

Update affected Linux kernels to a version containing the upstream fix for the Microchip IPC SBI mailbox driver, specifically the change that indexes cluster_cfg by cpuid rather than hartid in mchp_ipc_get_cluster_aggr_irq(). Because no exact fixed package versions were provided, use the latest stable kernel or distribution vendor kernel update that references this CVE or the corresponding mailbox/mchp-ipc-sbi fix. If immediate patching is not possible, reduce exposure by disabling or not loading the affected driver where it is not required, limiting local shell access, restricting untrusted workload execution, and applying kernel hardening controls such as lockdown mode, module loading restrictions, KASLR, SMEP/SMAP where available, and least-privilege service isolation. Treat mitigation as temporary; the durable fix is a patched kernel.

How to confirm the fix worked

Confirm the running kernel build includes the fix by checking vendor advisories, package changelogs, or source patches for the mchp_ipc_get_cluster_aggr_irq() change from hartid-based indexing to cpuid-based indexing. Verify the running kernel version after reboot, not only the installed package version. Determine exposure by checking whether the affected driver is present or loaded, whether the platform uses the relevant Microchip IPC SBI mailbox functionality, and whether CPU hart IDs are non-contiguous or exceed the online CPU index range. Regression testing should include boot stability, mailbox/IPC functionality, CPU enumeration, and absence of kernel warnings, KASAN reports, Oopses, or panics involving mchp-ipc-sbi.

Typical attack path

1. Identify a Linux system running an affected kernel with the Microchip IPC SBI mailbox driver enabled and applicable hardware/firmware topology.
2. Gain local code execution or access to a local interface capable of triggering the vulnerable mailbox driver code path.
3. Trigger CPU/cluster IRQ configuration handling where a hart ID is used to index the per-CPU cluster_cfg array.
4. Cause an out-of-bounds access beyond the dynamically allocated array.
5. Use the resulting memory corruption to crash the kernel, leak sensitive memory, or attempt privilege escalation to kernel-level control.

How to detect it

Look for evidence of attempted or successful exploitation in kernel and system logs rather than network telemetry, because exploitation is local. Review dmesg, journald, /var/log/kern.log, /var/log/messages, crash dumps, kdump/vmcore artifacts, auditd, EDR telemetry, and privileged process execution logs. Focus on kernel Oops, panic, KASAN, slab corruption, general protection fault, or page fault messages involving the Microchip IPC SBI mailbox driver or the mchp_ipc_get_cluster_aggr_irq() function. Correlate any such events with local user sessions, container starts, recently executed binaries, privilege changes, sudo/su activity, and unexpected root-owned files or processes created shortly before or after the crash. Absence of these artifacts does not prove non-exploitation, especially if logs were rotated or the system crashed before persistence was written.

• mchp_ipc_get_cluster_aggr_irq
• mchp-ipc-sbi
• BUG: KASAN: out-of-bounds
• BUG: KASAN: slab-out-of-bounds
• kernel BUG at drivers/mailbox
• general protection fault
• Unable to handle kernel paging request
• Oops:
• Kernel panic - not syncing
• drivers/mailbox/mchp-ipc-sbi

What your security team should do

• Inventory Linux systems for affected kernel versions and for presence or loading of the Microchip IPC SBI mailbox driver.
• Prioritize patching systems that use the affected hardware/driver path, host untrusted local users, run multi-tenant workloads, or provide shell/container execution to less-trusted users.
• Apply the latest vendor-supported kernel update and reboot systems to ensure the fixed kernel is active.
• Where patching is delayed, disable or block the affected driver if operationally safe and restrict local code execution paths.
• Monitor kernel logs for crashes, Oopses, KASAN reports, or warnings referencing mchp-ipc-sbi or mchp_ipc_get_cluster_aggr_irq.
• Review recent local privilege escalation alerts, unexpected root-level process creation, kernel panics, and unexplained reboots on potentially affected systems.
• Because this is not currently KEV-listed and has low EPSS in the supplied data, track it through normal kernel patch governance unless affected systems are internet-adjacent management platforms, multi-user systems, or high-value infrastructure.