CVE-2026-43241

What it actually does

CVE-2026-43241 is a local Linux kernel memory-corruption issue in the Switchtec NTB hardware driver, ntb_hw_switchtec. The driver can calculate or accept an invalid memory-window lookup-table index when the number of memory-window LUTs reaches certain NTB configurations, resulting in an out-of-bounds access to the mw_sizes array. A user with local privileges and access to the relevant NTB/Switchtec interfaces could potentially trigger kernel memory disclosure and/or a kernel crash. The CVSS vector indicates local exploitation, low complexity, low privileges required, no user interaction, high confidentiality impact, no integrity impact, and high availability impact.

Why it matters to the business

Organizations using Linux systems with Microchip/Microsemi Switchtec NTB hardware may be exposed to local denial-of-service and possible sensitive kernel memory disclosure. The main operational risk is that a low-privileged local user, compromised account, container escape path with device access, or malicious co-resident workload could crash affected hosts that rely on this hardware. Because EPSS is currently low, the issue is not known to be widely exploited, and it is not listed in CISA KEV, but kernel flaws should still be prioritized on systems where the affected driver is loaded or the hardware is present.

How an attack unfolds

An attacker first obtains local access to a Linux host where the Switchtec NTB driver is present and active. They then interact with the NTB/Switchtec configuration path or device interface in a way that causes the driver to process an invalid memory-window LUT index. In vulnerable kernels, the driver does not sufficiently validate that index before using it to access the mw_sizes array. The invalid access can read memory outside the expected array bounds and may destabilize kernel execution. Depending on kernel hardening, memory layout, and runtime conditions, exploitation is most likely to produce a kernel warning, oops, or panic, and may also expose kernel memory contents. There is no public evidence in the provided data of mature exploit code, ransomware use, named threat-actor exploitation, or KEV-listed active exploitation.

How to fix it

Apply a Linux kernel update that includes the upstream fix for ntb: ntb_hw_switchtec array-index-out-of-bounds validation. No exact fixed package versions were provided, so use the security advisory from the operating-system or kernel vendor for the deployed distribution and kernel stream. Where immediate patching is not possible, reduce exposure by disabling or unloading the ntb_hw_switchtec module if Switchtec NTB functionality is not required, restricting local access to NTB/Switchtec device nodes and management interfaces, limiting untrusted users from accessing affected hosts, and applying kernel hardening controls such as lockdown, module-loading restrictions, and least-privilege device access policies. Do not remove the driver on systems that depend on Switchtec NTB for production clustering, storage, PCIe fabric, or interconnect functionality without validating operational impact.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version contains the vendor backport or upstream commit that adds bounds checking for Switchtec NTB memory-window LUT indexing. Check whether the affected driver is present with modinfo ntb_hw_switchtec and whether it is loaded with lsmod | grep ntb_hw_switchtec. Confirm hardware exposure with lspci and vendor documentation for Switchtec NTB devices. Review vendor package changelogs for references to CVE-2026-43241, ntb_hw_switchtec, mw_sizes, or invalid MW LUT index validation. After patching, reboot into the fixed kernel and confirm uname -r matches the intended fixed kernel package. If the driver is intentionally disabled as a mitigation, verify it cannot be loaded automatically and that dependent services continue operating as expected.

Typical attack path

1. Gain local access to a Linux system with the Switchtec NTB driver installed and loaded.
2. Confirm that Switchtec NTB hardware or the ntb_hw_switchtec driver interface is available.
3. Use local privileges to access or influence NTB/Switchtec configuration paths exposed by the kernel or device.
4. Trigger an NTB configuration where the memory-window LUT index is outside the valid mw_sizes array range.
5. Cause the kernel driver to perform an out-of-bounds array access.
6. Observe kernel memory disclosure, kernel instability, oops, panic, or denial of service.

How to detect it

To assess possible prior exploitation, review kernel logs, persistent journal entries, crash dumps, and monitoring alerts for signs of abnormal ntb_hw_switchtec activity. Useful sources include /var/log/kern.log, /var/log/messages, journalctl -k output, dmesg captures, kdump/vmcore repositories, hypervisor or hardware-management logs, and EDR telemetry that records kernel panics or module faults. Look for KASAN or UBSAN reports showing array-index-out-of-bounds conditions in ntb_hw_switchtec, stack traces referencing Switchtec NTB functions, kernel oops or panic events following NTB configuration changes, and repeated local access to Switchtec/NTB device interfaces shortly before a crash. Because this vulnerability is local and no public exploit maturity or threat-actor activity is indicated, detection should focus on crash forensics, anomalous local device access, and correlation with authenticated user activity on systems where the driver is loaded.

• ntb_hw_switchtec
• ntb_hw_switchtec.ko
• drivers/ntb/hw/mscc/ntb_hw_switchtec.c
• mw_sizes
• Switchtec NTB
• array-index-out-of-bounds
• UBSAN: array-index-out-of-bounds
• KASAN: slab-out-of-bounds
• KASAN: global-out-of-bounds
• kernel BUG
• kernel NULL pointer dereference
• Oops:
• Kernel panic
• invalid MW LUT
• MW LUT
• configuration is not valid
• /lib/modules/*/kernel/drivers/ntb/hw/mscc/ntb_hw_switchtec.ko

What your security team should do

• Prioritize patching Linux systems where ntb_hw_switchtec is loaded or Switchtec NTB hardware is present, especially multi-user, shared compute, storage, or infrastructure hosts.
• Use asset inventory to identify systems with the ntb_hw_switchtec kernel module, Switchtec PCIe/NTB hardware, or NTB-dependent workloads.
• If patching is delayed, disable or blacklist ntb_hw_switchtec on systems that do not require it.
• Restrict shell access, device-node access, and administrative interfaces on systems where the affected driver must remain enabled.
• Monitor kernel logs for array-index-out-of-bounds, KASAN, UBSAN, oops, or panic events involving ntb_hw_switchtec or Switchtec NTB.
• Track operating-system vendor advisories because no exact fixed package versions were provided in the input.
• Treat unexpected crashes on affected Switchtec NTB systems as potentially security relevant and preserve kernel logs, crash dumps, and module state for investigation.