CVE-2026-45849

What it actually does

This is a local race condition in the Linux kernel MSCC Ocelot network switch driver. The transmit injection path, `ocelot_port_xmit_inj()`, calls injection-related routines without holding the required injection group lock. Concurrent access can corrupt driver state or trigger kernel assertions, warnings, hangs, or crashes. The practical impact is denial of service on systems using the affected Ocelot/Felix switch driver path; the CVSS vector indicates local access with low privileges, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

A local user or compromised low-privilege process on an affected Linux system may be able to crash or destabilize the host or networking function. For embedded, industrial, telecom, routing, or switching platforms that use the Ocelot/Felix driver, this can interrupt network forwarding, management access, or dependent services. The issue is not currently listed in CISA KEV, has very low EPSS, and has no reported exploit maturity, so broad internet-scale exploitation is unlikely; however, exposed multi-user systems and appliances where local code execution is possible should still be prioritized because the impact is service disruption.

How an attack unfolds

An attacker first needs local code execution or an authenticated local account on a Linux system using the affected Ocelot network driver path. They then generate traffic or otherwise exercise the packet transmit injection path through the affected interface while attempting to trigger concurrent access to the injection group. Because the vulnerable function does not acquire the expected lock before calling the injection helper routines, competing operations can race. Depending on kernel configuration and timing, the result may be a lockdep assertion, kernel warning, driver malfunction, packet injection path failure, networking disruption, or a kernel panic. Exploitation is reliability-oriented rather than data-theft-oriented and is most relevant as a local denial-of-service primitive.

How to fix it

Upgrade to a Linux kernel build that includes the upstream fix adding `ocelot_lock_inj_grp()` and `ocelot_unlock_inj_grp()` around the register injection path in `ocelot_port_xmit_inj()`. If distribution or vendor fixed versions are not yet available, track the relevant stable kernel, appliance, or BSP advisories and apply the vendor-supplied kernel update as soon as it is released. Where immediate patching is not possible, reduce risk by disabling unused Ocelot/Felix network interfaces or drivers, removing untrusted local shell access, limiting who can run workloads on affected hosts, applying least privilege to local users and services, and using redundancy or failover for devices whose network forwarding availability is critical. The FDMA path is described as using its own locking mechanism and is not the affected path, so mitigations should focus on exposure to the register injection transmit path and local code execution risk.

How to confirm the fix worked

Confirm exposure by checking whether the system runs a Linux kernel version or vendor appliance firmware that contains the vulnerable Ocelot driver code and whether Ocelot/Felix hardware support is enabled or loaded. Validate remediation by confirming the installed kernel package or firmware release includes the patch that wraps the register injection path in `ocelot_port_xmit_inj()` with `ocelot_lock_inj_grp()` and `ocelot_unlock_inj_grp()`. On source-based or internally maintained kernels, inspect the driver source to verify the lock/unlock calls surround `ocelot_can_inject()` and `ocelot_port_inject_frame()` in the affected path. After update, reboot into the patched kernel, confirm the active kernel version, and monitor `dmesg` or the system journal while exercising the affected network interfaces for absence of lockdep warnings, kernel oops messages, and Ocelot driver crashes.

Typical attack path

1. Obtain local access to an affected Linux host or appliance, such as through a shell, compromised service account, container escape context with sufficient host interaction, or another vulnerability.
2. Confirm the system uses an affected Linux kernel with the MSCC Ocelot/Felix switch driver and an active affected network interface.
3. Generate repeated or concurrent transmit activity through the affected driver path to exercise `ocelot_port_xmit_inj()`.
4. Trigger a race in the unprotected register injection path where injection helper functions are called without the required injection group lock.
5. Cause kernel warnings, driver instability, network outage, host hang, or kernel panic, resulting in denial of service.

How to detect it

Look for evidence of prior local denial-of-service activity rather than remote network compromise. Useful sources include `dmesg`, `/var/log/kern.log`, `/var/log/messages`, `journalctl -k`, persistent systemd journal entries, hypervisor or out-of-band management reset logs, kernel crash dumps, kdump/vmcore artifacts, watchdog reset records, and network device availability monitoring. Search for kernel oops, panic, lockdep, warning, or stack traces referencing the Ocelot/Felix transmit injection path. Pay attention to repeated crashes or reboots correlated with local user activity, automated workloads, packet generation tools, or high transmit activity on Ocelot-backed interfaces. Because no public exploit or malware-specific indicators are known, absence of these strings does not prove the issue was not attempted; it only reduces evidence of a successful crash or visible kernel assertion.

• ocelot_port_xmit_inj
• ocelot_can_inject
• ocelot_port_inject_frame
• felix_port_deferred_xmit
• ocelot_lock_inj_grp
• ocelot_unlock_inj_grp
• lockdep_assert_held
• WARNING: CPU:
• BUG: kernel NULL pointer dereference
• Kernel panic - not syncing
• Oops:
• Call Trace:
• mscc_ocelot
• ocelot

What your security team should do

• Inventory Linux systems, appliances, embedded platforms, and network devices that use MSCC Ocelot/Felix switch hardware or load the related kernel driver.
• Prioritize patching for systems where untrusted users can run local code, where services are frequently compromised into local execution, or where network availability is operationally critical.
• Apply vendor kernel, firmware, or BSP updates once available; for custom kernels, backport the upstream locking fix into the maintained kernel branch.
• Until patched, restrict local interactive access, workload execution, and administrative surfaces that could allow attackers to run code on affected hosts.
• Enable collection of kernel logs, crash dumps, and persistent journaling on affected systems so denial-of-service attempts can be investigated after reboot.
• Monitor for repeated kernel warnings, lockdep assertions, oops traces, or unexplained reboots involving Ocelot/Felix driver functions.
• Do not treat low EPSS as a reason to ignore the issue on critical network infrastructure; local denial-of-service flaws can be significant when chained with other vulnerabilities.