CVE-2026-98795 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
net: sparx5: skip ptp deinit if init was skipped
sparx5_ptp_init() returns early on the base lan969x variants because they do not have the SPX5_FEATURE_PTP flag. It also returns early when no "ptp" interrupt is described. Unbinding the driver then causes a NULL pointer dereference when cleaning up uninitialized tx_skbs queues:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 Call trace: skb_queue_purge_reason+0x68/0x120 (P) sparx5_ptp_deinit+0x64/0xc0 mchp_sparx5_remove+0x38/0x70 platform_remove+0x20/0x30 device_remove+0x4c/0x80
Before per-port tx_skbs were added, a NULL dereference would have happened when calling ptp_clock_unregister() on the never-registered PTP clocks.
Fix by returning early in sparx5_ptp_deinit() if PTP is not used.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/18/2026
The Linux kernel driver for Microchip Sparx5 network switches contains a logic flaw within its Precision Time Protocol implementation that leads to a critical NULL pointer dereference during device removal or unbinding operations. This vulnerability specifically affects systems where the hardware does not support PTP features, such as certain base LAN969X variants lacking the SPX5_FEATURE_PTP flag, or configurations where no ptp interrupt is described in the system resources. Under these conditions, the initialization function sparx5_ptp_init correctly identifies the absence of required capabilities and returns early without performing any setup tasks. However, the corresponding deinitialization routine fails to account for this skipped initialization state, resulting in a mismatch between the driver's operational assumptions and its actual runtime behavior.
The technical root cause lies in the asymmetry between the init and deinit functions within the sparx5_ptp module. When the device is unbound or removed from the system, the kernel invokes the remove callback which subsequently calls sparx5_ptp_deinit to clean up resources allocated during initialization. Because the initialization phase was bypassed due to missing hardware features or interrupts, critical data structures such as the tx_skbs queues remain in an uninitialized state with NULL pointers. The deinit function proceeds to access these structures without verifying whether they were ever populated. This leads directly to a kernel panic characterized by a NULL pointer dereference at virtual address 0x8 within the skb_queue_purge_reason routine, which is invoked during the cleanup of socket buffer queues that were never properly allocated or initialized.
Prior to recent updates introducing per-port tx_skbs management, this vulnerability manifested differently but with equally severe consequences. In earlier versions, attempting to unregister a PTP clock that was never successfully registered would trigger a NULL dereference within the ptp_clock_unregister function itself. The introduction of separate queue handling for each port shifted the point of failure from the clock registration layer to the socket buffer management layer during driver teardown. Despite this shift in implementation details, the fundamental issue remains an improper state transition where cleanup routines assume successful initialization has occurred regardless of actual hardware capabilities or configuration constraints.
The operational impact of this vulnerability is significant for system stability and availability. An attacker with local access who can trigger device unbinding events, such as through module reloading or hotplug simulation, could cause a kernel panic leading to immediate system crash and denial of service. This represents a classic example of how improper error handling in driver lifecycle management can compromise the reliability of embedded networking equipment. The vulnerability is particularly dangerous because it does not require complex exploitation techniques; simply triggering the removal path for an unsupported or misconfigured Sparx5 device is sufficient to induce the fault, making it a reliable vector for local denial-of-service attacks against systems relying on these network interfaces.
From a classification perspective, this flaw aligns with CWE-476 NULL Pointer Dereference, as the code attempts to access memory through a pointer that has not been properly initialized or validated before use. It also relates to CWE-251 Lack of Proper Error Handling, specifically in the context of resource management and lifecycle state transitions where cleanup routines do not verify prior initialization status. In terms of adversarial tactics, this vulnerability could be leveraged within the ATT&CK framework under T1079 Windows or Linux Persistence mechanisms if an attacker seeks to cause instability as a distraction for other activities, though its primary utility lies in local denial-of-service scenarios categorized under impact-related techniques that disrupt service availability.
The resolution involves modifying the sparx5_ptp_deinit function to include a guard clause that checks whether PTP functionality was actually enabled during initialization. By returning early if the hardware flags indicate unsupported features or if no interrupts were configured, the driver ensures that cleanup operations are only performed on resources that genuinely exist and require deallocation. This fix restores symmetry between the init and deinit phases of the driver lifecycle. To mitigate similar issues in other drivers, developers should ensure that all resource allocation routines have corresponding validation checks before attempting to free or purge those resources during teardown sequences. System administrators managing Sparx5-based hardware should verify their device tree configurations and kernel module parameters to ensure compatibility with PTP features if high-precision timing is required, although the patch itself resolves the crash regardless of configuration by handling unsupported states gracefully rather than crashing.