CVE-2026-43317

What it actually does

This is a Linux kernel availability flaw in the MOST core subsystem. During an early failure in interface registration, the kernel fails to release resources associated with the partially registered interface. A local attacker with sufficient ability to trigger the vulnerable registration path can repeatedly force the failure condition, causing kernel resource leakage. Over time this can exhaust kernel memory or related kernel resources, leading to degraded performance, service instability, or a system crash/denial of service. The issue does not directly provide confidentiality or integrity impact and is not known to enable privilege escalation.

Why it matters to the business

Successful exploitation can make affected Linux systems unstable or unavailable, potentially interrupting workloads, embedded systems, appliances, or servers that include and expose the vulnerable MOST kernel functionality. The CVSS score is moderate, EPSS is very low, there is no known public exploit maturity, and it is not listed in CISA KEV or ransomware-use data, so urgency is lower than for remotely exploitable or actively exploited kernel bugs; however, systems where local users, containers, untrusted workloads, or device-management paths can exercise MOST-related interfaces should still be prioritized for patching.

How an attack unfolds

An attacker first obtains local access to an affected Linux system with enough privileges or execution context to trigger MOST interface registration attempts. The attacker then induces the registration path to fail at the vulnerable early error branch, causing the kernel to abandon the registration attempt without freeing the interface resources. By repeating this operation, the attacker gradually accumulates leaked kernel resources. Once enough resources are consumed, the system may experience memory pressure, kernel allocation failures, service failures, OOM-killer activity, hangs, or a crash. Because exploitation is local and availability-focused, it is most relevant where untrusted local users or workloads can repeatedly exercise kernel device or module registration paths.

How to fix it

Update the Linux kernel to a vendor-supported version that includes the upstream fix for the MOST core resource release path. Because no fixed package versions were provided in the input, use the fixed kernel builds published by the relevant Linux distribution, device vendor, or appliance vendor. Where immediate patching is not possible, reduce exposure by disabling or blacklisting unused MOST-related kernel modules, removing unnecessary hardware/device access paths, restricting local shell access, limiting container or workload privileges, and preventing untrusted users from loading kernel modules or interacting with relevant device-management interfaces. Kernel live patching may be used if offered by the vendor and if it specifically includes this fix, but a full reboot into a fixed kernel should be treated as the authoritative remediation.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel version matches a vendor advisory or package release that contains the fix, not merely that the patched kernel package is installed on disk. Check with commands such as `uname -r`, distribution package tools, and vendor security advisories. Validate that any mitigation is active by confirming unused MOST modules are not loaded, module loading is restricted, and untrusted users or workloads cannot exercise relevant device registration paths. Review kernel logs after reboot for continued MOST registration failures, kernel memory allocation failures, or OOM-killer events. If using vulnerability scanners or configuration management, ensure they evaluate the running kernel version and reboot state.

Typical attack path

1. Gain local code execution or an interactive local account on an affected Linux system.
2. Identify whether the running kernel includes the vulnerable MOST core subsystem and whether MOST-related modules or interfaces can be exercised.
3. Trigger MOST interface registration attempts that fail during the vulnerable early error path.
4. Repeat the failing registration operation to leak kernel resources over time.
5. Cause memory pressure, allocation failures, service disruption, kernel instability, or system crash resulting in denial of service.

How to detect it

Look for evidence of repeated local attempts to exercise MOST interface registration followed by resource exhaustion symptoms. Relevant log sources include `dmesg`, journald/kernel logs, `/var/log/kern.log`, `/var/log/messages`, `/var/log/syslog`, auditd process execution logs, EDR telemetry, and reboot/crash monitoring. Search for clusters of MOST-related kernel messages near memory pressure, page allocation failures, OOM-killer activity, service crashes, or unexpected reboots. Audit command execution for repeated `modprobe`, `insmod`, `rmmod`, or device-management activity involving MOST-related modules by non-administrative or unexpected users. In containerized environments, review privileged containers and workloads with device or module-loading capabilities. Absence of a unique exploit string means detection should correlate repeated MOST registration or module activity with kernel resource exhaustion and availability events.

• most: core
• mostcore
• MOST core
• modprobe most
• insmod most
• rmmod most
• invoked oom-killer
• Out of memory: Killed process
• page allocation failure
• kernel: Out of memory
• kernel panic
• watchdog: BUG: soft lockup
• watchdog: BUG: hard LOCKUP

What your security team should do

• Inventory Linux systems and appliances that include the MOST core subsystem or load MOST-related kernel modules.
• Prioritize patching systems with local multi-user access, untrusted workloads, privileged containers, device-management exposure, or embedded/appliance roles where downtime is operationally significant.
• Apply vendor kernel updates that include the MOST core resource leak fix and reboot systems into the fixed kernel.
• If patching is delayed, disable or blacklist unused MOST-related modules and restrict local users, containers, and services from loading modules or interacting with relevant device interfaces.
• Monitor kernel logs for repeated MOST-related registration failures, memory allocation failures, OOM-killer events, and unexpected reboots or hangs.
• Because there is no current KEV listing, ransomware association, or mature public exploit signal, handle as a reliability and local denial-of-service risk rather than an internet-scale emergency, while still including it in normal kernel patch cycles.