CVE-2026-22982 in Linux
Summary
by MITRE • 01/23/2026
In the Linux kernel, the following vulnerability has been resolved:
net: mscc: ocelot: Fix crash when adding interface under a lag
Commit 15faa1f67ab4 ("lan966x: Fix crash when adding interface under a lag") fixed a similar issue in the lan966x driver caused by a NULL pointer dereference. The ocelot_set_aggr_pgids() function in the ocelot driver has similar logic and is susceptible to the same crash.
This issue specifically affects the ocelot_vsc7514.c frontend, which leaves unused ports as NULL pointers. The felix_vsc9959.c frontend is unaffected as it uses the DSA framework which registers all ports.
Fix this by checking if the port pointer is valid before accessing it.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 05/18/2026
The vulnerability described in CVE-2026-22982 represents a critical null pointer dereference issue within the Linux kernel's networking subsystem, specifically affecting the ocelot driver implementation. This flaw manifests when attempting to add network interfaces under a link aggregation group, creating a potential system crash scenario that could be exploited by malicious actors to cause denial of service conditions. The vulnerability is particularly concerning as it affects the ocelot_vsc7514.c frontend component, which handles unused port management through NULL pointer assignments, creating an attack surface that directly contradicts the principle of defensive programming and input validation.
The technical root cause of this vulnerability stems from the ocelot_set_aggr_pgids() function's failure to properly validate port pointers before dereferencing them during link aggregation operations. This issue is categorized as a CWE-476 Null Pointer Dereference, which occurs when a program attempts to access a memory location through a pointer that has not been properly initialized or validated. The flaw demonstrates poor defensive programming practices where the driver assumes all port pointers will be valid without proper validation checks, creating a scenario where a NULL pointer dereference can occur during normal operational conditions. The vulnerability affects the VSC7514 switch chip frontend implementation, which differs from the VSC9959 frontend that utilizes the DSA framework and therefore remains unaffected due to its more robust port registration mechanisms.
The operational impact of this vulnerability extends beyond simple system crashes, as it represents a potential denial of service vector that could be exploited in network infrastructure environments where link aggregation is commonly used. Attackers could potentially trigger the crash by attempting to add network interfaces to link aggregation groups, causing the system to become unresponsive and requiring manual intervention to restore normal operations. This vulnerability particularly affects network switches and embedded systems that utilize the ocelot driver for managing switch fabrics, where the stability of network connectivity is paramount for system reliability. The issue is closely related to ATT&CK technique T1499.004 Network Denial of Service, as it directly enables an attacker to disrupt network services through system instability.
The fix implemented for this vulnerability addresses the core issue by introducing proper pointer validation checks before accessing port structures during link aggregation operations. This remediation aligns with industry best practices for preventing null pointer dereferences and demonstrates the importance of defensive programming in kernel space drivers. The solution specifically requires checking if port pointers are valid before accessing them, which prevents the system from attempting to dereference NULL pointers during normal network interface management operations. This approach follows the principle of input validation and error handling that is fundamental to secure systems programming. The fix also serves as a preventive measure against similar vulnerabilities in other driver components, as evidenced by the reference to a similar issue in the lan966x driver that was previously addressed through the same validation approach, highlighting the need for comprehensive code review and consistency in driver development practices across kernel subsystems.