CVE-2026-64220

What it actually does

This Linux kernel flaw leaves the fwnode->secondary pointer uninitialized when a firmware node is initialized with fwnode_init(). If the firmware node was stack-allocated or allocated from non-zeroed heap memory, the pointer may contain arbitrary stale data rather than NULL. Later kernel paths that assume the secondary pointer is either NULL or a valid/error-encoded pointer may dereference invalid memory, potentially causing a kernel crash, denial of service, or undefined kernel behavior. Practical impact depends on whether a reachable driver or subsystem creates temporary firmware/software nodes and then calls code paths such as dev_to_swnode() that consume the uninitialized secondary pointer.

Why it matters to the business

Successful exploitation would most likely cause system instability or outages on affected Linux systems, particularly where vulnerable kernel code paths are reachable through hardware, drivers, firmware-described devices, or local device-management activity. Because this issue is not in the CISA KEV catalog, has no known exploit maturity, and has a low EPSS score, immediate mass exploitation is not currently indicated; however, kernel flaws can have broad operational impact when present in server, appliance, embedded, or cloud host fleets.

How an attack unfolds

An attacker would need to reach a kernel code path that initializes a firmware/software node using fwnode_init() on memory that has not been zeroed and then causes the kernel to evaluate the node's secondary pointer. If the stale pointer value is neither NULL nor an expected error pointer, the kernel may treat it as a valid object and dereference it. In the most likely scenario, this produces a kernel oops or panic and results in denial of service. More advanced exploitation would require shaping kernel memory so the uninitialized pointer references attacker-influenced or meaningful data, which is substantially more difficult and currently has no public exploit signal for this CVE.

How to fix it

Upgrade to a Linux kernel version or vendor-maintained kernel package that includes the fix setting fwnode->secondary to NULL during fwnode_init(). Because no exact affected products or fixed versions were provided, use the relevant distribution, appliance, cloud image, or device vendor advisory to identify the corrected kernel package. Where immediate patching is not possible, reduce exposure by disabling unnecessary device drivers or hotplug paths, restricting local administrative and device-management access, limiting access to interfaces that can add or manipulate devices, and applying standard kernel hardening controls such as module-loading restrictions and reboot-on-panic monitoring. Mitigations should be treated as temporary because the robust fix is the kernel code change.

How to confirm the fix worked

Confirm remediation by verifying that the running kernel package includes the upstream fix for fwnode_init() initializing fwnode->secondary to NULL, not merely that an updated package is installed on disk. Check the active kernel version with standard OS tooling, compare it to the vendor advisory's fixed build, and reboot into the fixed kernel if required. For source-based or custom kernels, inspect the device property core implementation and confirm fwnode_init() explicitly assigns fwnode->secondary = NULL. After patching, run regression tests for device enumeration, firmware-node consumers, software-node consumers, hotplug behavior, and affected drivers if known.

Typical attack path

1. Identify a Linux system running an affected kernel build that contains the vulnerable fwnode_init() behavior.
2. Determine whether any installed hardware, driver, virtual device, firmware interface, or device-management path can cause temporary firmware/software nodes to be created.
3. Trigger the relevant driver or subsystem path so a firmware node is initialized from non-zeroed stack or heap memory.
4. Cause a later kernel routine to inspect or dereference fwnode->secondary, such as through software-node conversion or device-property handling.
5. Induce a kernel fault, oops, panic, or undefined behavior, resulting in service disruption or system reboot if panic-on-oops or watchdog recovery is configured.

How to detect it

There are no unique public indicators showing exploitation of this issue. Detection should focus on evidence of kernel faults around firmware-node, software-node, device-property, or driver initialization code. Review kernel logs, persistent journal data, crash dumps, hypervisor reset events, watchdog resets, and system availability telemetry for kernel oops, panic, invalid pointer dereference, general protection fault, page fault, or NULL/non-canonical pointer dereference events near functions related to fwnode_init, dev_to_swnode, software_node, swnode, device_property, or affected drivers. Correlate crashes with recent local activity, device hotplug events, driver loading, firmware/ACPI/device-tree interactions, USB/PCI device insertion, container or VM device passthrough changes, or administrative actions that alter device configuration. If crash dumps are available, inspect stack traces for fwnode/device-property call paths and determine whether fwnode->secondary contained an unexpected non-NULL invalid pointer.

• fwnode_init
• dev_to_swnode
• device_property
• software_node
• swnode
• fwnode->secondary
• BUG: kernel NULL pointer dereference
• BUG: unable to handle kernel paging request
• general protection fault
• kernel panic
• Oops:
• watchdog: watchdog did not stop
• Kernel panic - not syncing

What your security team should do

• Inventory Linux systems, appliances, embedded devices, and custom kernels that may include the vulnerable kernel device-property code.
• Prioritize patching internet-facing, multi-tenant, high-availability, virtualization host, storage, networking, and embedded Linux systems where kernel crashes would have high operational impact.
• Track distribution and vendor advisories for exact fixed kernel package versions and deploy the corrected running kernel through the normal reboot process.
• For custom kernels, backport the specific initialization fix and rebuild rather than relying on unrelated mitigations.
• Review recent kernel crash, oops, panic, and watchdog-reboot telemetry for signs of instability in device-property, firmware-node, software-node, or driver initialization paths.
• Restrict unnecessary local privileged access, device hotplug capabilities, untrusted kernel module loading, and access to device-management interfaces until patching is complete.
• Because there is no known exploitation and the EPSS score is low, handle this through risk-based kernel maintenance unless affected systems are highly critical or frequently exposed to untrusted device/driver interactions.