CVE-2026-43356 in Linux
Summary
by MITRE • 05/08/2026
In the Linux kernel, the following vulnerability has been resolved:
iio: imu: adis: Fix NULL pointer dereference in adis_init
The adis_init() function dereferences adis->ops to check if the individual function pointers (write, read, reset) are NULL, but does not first check if adis->ops itself is NULL.
Drivers like adis16480, adis16490, adis16545 and others do not set custom ops and rely on adis_init() assigning the defaults. Since struct adis is zero-initialized by devm_iio_device_alloc(), adis->ops is NULL when adis_init() is called, causing a NULL pointer dereference:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 pc : adis_init+0xc0/0x118 Call trace: adis_init+0xc0/0x118 adis16480_probe+0xe0/0x670
Fix this by checking if adis->ops is NULL before dereferencing it, falling through to assign the default ops in that case.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/13/2026
This vulnerability represents a critical null pointer dereference flaw in the Linux kernel's Industrial I/O (IIO) subsystem specifically affecting inertial measurement unit drivers. The issue occurs within the adis_init() function which serves as a initialization routine for ADIS family of inertial sensors including models such as adis16480, adis16490, and adis16545. The flaw stems from improper null pointer validation during the driver initialization process, creating a potential system crash condition that could be exploited by malicious actors with kernel-level access.
The technical implementation of this vulnerability demonstrates a classic programming error where the function attempts to access function pointers through a potentially null structure reference. When the adis_init() function executes, it checks individual function pointers within the adis->ops structure to determine if they are NULL, but fails to validate whether the adis->ops pointer itself points to valid memory. This oversight occurs because the struct adis is zero-initialized through the devm_iio_device_alloc() function call, which sets adis->ops to NULL. When the function attempts to dereference this NULL pointer, it triggers an immediate kernel panic due to the null pointer dereference at virtual address zero.
This vulnerability directly maps to CWE-476 which describes "Null Pointer Dereference" in software security contexts, and aligns with ATT&CK technique T1068 which involves exploiting local vulnerabilities to gain system privileges. The operational impact of this flaw is significant as it can cause complete system crashes when these specific IMU drivers are loaded, potentially leading to denial of service conditions in embedded systems and industrial control environments where these sensors are commonly deployed. The crash occurs during driver probe phase, meaning any system attempting to utilize these inertial sensors would experience immediate kernel panic.
The fix implemented addresses this vulnerability by adding a preliminary null check for adis->ops before any dereferencing occurs. When adis->ops is found to be NULL, the function properly falls through to assign default operations, ensuring that all required function pointers are properly initialized regardless of whether custom operations have been defined by specific driver implementations. This defensive programming approach prevents the kernel from crashing while maintaining backward compatibility with existing driver code that relies on the default operation assignments. The solution follows established kernel security practices by implementing proper null pointer validation before structure member access, preventing potential exploitation while preserving the intended functionality of the IIO subsystem's ADIS driver framework.