CVE-2026-23070 in Linux
Summary
by MITRE • 02/04/2026
In the Linux kernel, the following vulnerability has been resolved:
Octeontx2-af: Add proper checks for fwdata
firmware populates MAC address, link modes (supported, advertised) and EEPROM data in shared firmware structure which kernel access via MAC block(CGX/RPM).
Accessing fwdata, on boards booted with out MAC block leading to kernel panics.
Internal error: Oops: 0000000096000005 [#1] SMP
[ 10.460721] Modules linked in:
[ 10.463779] CPU: 0 UID: 0 PID: 174 Comm: kworker/0:3 Not tainted 6.19.0-rc5-00154-g76ec646abdf7-dirty #3 PREEMPT
[ 10.474045] Hardware name: Marvell OcteonTX CN98XX board (DT)
[ 10.479793] Workqueue: events work_for_cpu_fn
[ 10.484159] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 10.491124] pc : rvu_sdp_init+0x18/0x114
[ 10.495051] lr : rvu_probe+0xe58/0x1d18
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 04/30/2026
This vulnerability exists within the Linux kernel's Octeontx2-af driver where insufficient validation occurs when accessing firmware data structures. The issue specifically affects systems where the MAC block (CGX/RPM) is not properly initialized during boot, leading to kernel panics when attempting to read shared firmware data containing MAC addresses, link modes, and EEPROM information. The vulnerability stems from a lack of proper null pointer checks and validation before accessing firmware-populated data structures, creating a direct execution path that results in system crashes. The affected driver component interacts with the hardware's firmware through shared memory structures, but fails to verify the presence or proper initialization of the MAC block before attempting data access operations.
The technical flaw manifests as a classic null pointer dereference scenario where the kernel attempts to access firmware data without confirming that the underlying MAC block infrastructure has been properly established. This condition is particularly critical in embedded systems where firmware initialization sequences may vary based on hardware configuration or boot parameters. The error occurs during the kernel's device probing phase when it attempts to initialize the RVU (Rapid Virtualization Unit) subsystem, specifically in the rvu_sdp_init function which directly accesses the shared firmware structure. The system state shows a kernel worker thread attempting to process CPU workqueue operations when the panic occurs, indicating that this is not a simple user-space issue but rather a fundamental kernel subsystem failure.
The operational impact of this vulnerability is severe as it can cause complete system crashes and panics, particularly affecting servers and network appliances running on Marvell OcteonTX CN98XX hardware platforms. Systems booting with MAC block configurations that don't initialize properly will experience immediate kernel oops conditions, rendering the entire system unstable and requiring manual intervention for recovery. This vulnerability affects the availability and reliability of network infrastructure components, potentially causing denial of service conditions in production environments where these devices are deployed. The issue has been classified under CWE-476 as a NULL Pointer Dereference, representing a fundamental software engineering flaw in input validation and error handling. The ATT&CK framework categorizes this under T1499.004 - Endpoint Denial of Service, as it directly impacts system availability through kernel-level crashes.
Mitigation strategies include implementing proper firmware data validation checks before accessing shared memory structures, ensuring that the MAC block initialization status is verified before firmware data access operations. Kernel patches should include conditional logic to skip firmware data processing when MAC block components are not properly initialized, rather than allowing direct memory access that leads to system crashes. Additionally, proper error handling should be implemented to gracefully handle cases where firmware data structures are not populated as expected. System administrators should verify firmware versions and ensure proper hardware initialization sequences are followed during system boot. The vulnerability highlights the importance of defensive programming practices in kernel space where hardware assumptions must be validated before data access operations. Regular kernel updates and firmware patches should be applied to address this and related initialization sequence issues that could affect similar hardware platforms.