CVE-2026-46282

What it actually does

This is a Linux kernel denial-of-service flaw in the Industrial I/O ADMV1013 frequency driver. If reading a device property string fails during driver initialization or configuration, the driver can continue and compare an uninitialized pointer, which may cause a NULL or invalid pointer dereference in kernel context. The practical result is a kernel oops, driver failure, or system panic depending on kernel configuration and panic-on-oops settings. Exploitation requires the vulnerable driver to be present and exercised with missing, invalid, or otherwise unreadable device property data; it is not a typical remote network-exploitable vulnerability.

Why it matters to the business

Systems using the affected Linux kernel driver for ADMV1013-related hardware may become unstable or unavailable if the vulnerable code path is reached. The primary business risk is service disruption on embedded, industrial, radio-frequency, lab, telecom, or specialized hardware platforms that depend on this driver. The issue is not listed in CISA KEV, is not known to be used in ransomware campaigns, has no reported exploit maturity, and has a very low EPSS score, so broad opportunistic exploitation is unlikely; however, availability-sensitive systems should still prioritize kernel updates during normal maintenance windows.

How an attack unfolds

An attacker or fault condition must be able to influence the device property data consumed by the ADMV1013 driver, or cause the driver to initialize against incomplete or malformed firmware/device-tree/ACPI/platform property information. When the driver calls the property-reading routine and that read fails, the vulnerable implementation may still pass an uninitialized string pointer into a string comparison. Because this occurs in kernel-space driver code, the invalid dereference can trigger a kernel oops or panic. In realistic scenarios, this is most likely triggered by a local privileged actor, malicious or incorrect device firmware/platform configuration, unsafe driver testing, or supply-chain/configuration mistakes rather than by a remote unauthenticated attacker.

How to fix it

Upgrade to a Linux kernel version or vendor-maintained kernel package that includes the ADMV1013 driver fix replacing the unsafe read-and-compare logic with safe property-string matching. Because the advisory notes recent cleanup changes and likely manual backporting, use official distribution, appliance, SoC vendor, or board-support-package updates rather than attempting an ad hoc source patch where possible. If immediate patching is not possible, reduce exposure by disabling or not loading the ADMV1013 driver on systems that do not require it, preventing untrusted device-tree overlays or platform firmware changes, restricting kernel module loading to trusted administrators, and validating hardware configuration data before deployment. No exact fixed package versions were provided in the input, so remediation should be tracked through the relevant kernel vendor advisory or stable kernel release notes for this CVE.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel includes the ADMV1013 driver and whether the system uses matching hardware or platform configuration. Validate remediation by verifying that the installed kernel package or source tree contains the patched ADMV1013 implementation using safe device property matching rather than falling through to strcmp after a failed device_property_read_string call. After upgrading, reboot into the fixed kernel, confirm the old vulnerable kernel is not the active boot entry, and review dmesg or journal logs for ADMV1013 probe failures, NULL pointer dereferences, kernel oops messages, or panics. For embedded systems, also validate device-tree, ACPI, or firmware property definitions in staging before production rollout.

Typical attack path

1. Identify a Linux system running a vulnerable kernel with the ADMV1013 Industrial I/O frequency driver available or loaded.
2. Gain the ability to affect platform/device properties, device-tree overlays, ACPI properties, kernel module probing, or hardware/driver initialization inputs.
3. Cause the ADMV1013 driver to probe or reinitialize with the expected string property missing, invalid, or unreadable.
4. The vulnerable code falls through after the failed property read and compares an uninitialized pointer.
5. The kernel records an oops or panics, causing driver failure, service interruption, reboot, or system unavailability.

How to detect it

Review kernel and system logs for evidence of prior crashes or driver probe failures involving the ADMV1013 driver. Useful sources include dmesg output, systemd journal kernel logs, /var/log/kern.log, /var/log/messages, crash dump directories, kdump/vmcore artifacts, and centralized logging from embedded or appliance platforms. Look for kernel oops or panic records that mention admv1013, Industrial I/O frequency driver initialization, NULL pointer dereferences, invalid pointer dereferences, strcmp, or device property parsing failures. Correlate any crash timestamps with recent firmware updates, device-tree overlay changes, kernel module loading, bootloader changes, hardware attach events, field maintenance, or configuration deployments. Because there are no known public exploitation campaigns or KEV listing, detection should focus on crash forensics and unauthorized platform configuration changes rather than network indicators.

• admv1013
• drivers/iio/frequency/admv1013.c
• NULL pointer dereference
• BUG: kernel NULL pointer dereference
• Unable to handle kernel NULL pointer dereference
• kernel oops
• Kernel panic - not syncing
• device_property_read_string
• device_property_match_property_string
• strcmp
• iio: frequency: admv1013
• admv1013_probe

What your security team should do

• Inventory Linux systems, embedded devices, and specialized hardware platforms that use the ADMV1013 Industrial I/O frequency driver or include it in their kernel builds.
• Prioritize patching for availability-sensitive systems, lab/telecom/industrial platforms, and devices where local administrators, field technicians, or update mechanisms can change device-tree overlays or platform firmware.
• Apply vendor-supported kernel updates or board-support-package updates that include the ADMV1013 fix; avoid unsupported manual backports unless reviewed by kernel engineering staff.
• If the driver is not required, disable it, blacklist the kernel module where applicable, or remove it from custom kernel builds.
• Restrict kernel module loading, device-tree overlay application, firmware updates, and bootloader configuration changes to trusted administrative workflows.
• Monitor kernel logs for ADMV1013 probe failures, NULL pointer dereference messages, oops traces, and unexpected reboots on systems that may include this driver.
• Treat repeated crashes around this driver as potential exploitation, unsafe testing, or configuration tampering until ruled out.