CVE-2026-43264

What it actually does

This vulnerability is a Linux kernel reference-count leak in the fbdev Open Firmware/device-tree display timing parser, specifically in of_get_display_timings(). When certain error paths are reached after of_parse_phandle() increments a device_node reference, cleanup fails to release the native_mode reference. Repeatedly triggering the faulty path can leak kernel references and associated resources, potentially degrading system stability and causing a local denial of service. The CVSS vector indicates local access with low complexity and low privileges, no user interaction, and high availability impact, with no expected confidentiality or integrity impact.

Why it matters to the business

Successful exploitation can make affected Linux systems unstable or unavailable, which may interrupt workloads running on systems that use affected framebuffer/device-tree display timing code paths. The practical risk is highest for embedded Linux, appliance, industrial, kiosk, ARM/SoC, or other device-tree-based systems where local users or constrained services can repeatedly exercise display initialization or error-handling paths. This issue is not listed in CISA KEV, is not reported as ransomware-used, has very low EPSS, and has no known public exploit maturity, so it should be handled through normal kernel maintenance unless the affected systems are safety-critical, highly available, or exposed to untrusted local users.

How an attack unfolds

An attacker first needs local code execution or an existing low-privileged account on an affected Linux system. They then need a way to repeatedly trigger the fbdev/device-tree display timing parsing path that reaches the affected error handling logic, typically through hardware/display initialization, device-tree-related probing, driver reloads where permitted, or other local actions that cause the relevant parser to process malformed, unexpected, or failing display timing data. Each failed path can leave a device_node reference unreleased. Over time, repeated triggering can consume kernel resources or leave internal references pinned, eventually degrading reliability or causing a denial-of-service condition such as driver malfunction, resource exhaustion, or system instability. There is no indication from the provided data that this flaw enables remote exploitation, privilege escalation, data theft, or code execution.

How to fix it

Apply a vendor-supplied Linux kernel update that includes the upstream fix for the fbdev of display_timing reference-count leak in of_get_display_timings(). No exact fixed package versions were provided, so use the affected distribution, appliance, or kernel vendor advisory as the source of truth for the corrected kernel build. Where kernel upgrades cannot be applied immediately, reduce exposure by limiting local shell access, restricting untrusted workloads, preventing unprivileged driver/module manipulation, disabling unused framebuffer/display components where operationally safe, and using hardened kernel configurations appropriate to the platform. For embedded products, rebuild firmware or BSP kernel trees with the patch that changes the relevant error path cleanup to release native_mode via of_node_put().

How to confirm the fix worked

Confirm remediation by verifying the running kernel package or firmware image matches a vendor release that contains the fix. For source-based validation, inspect the fbdev Open Firmware display timing code and confirm the of_get_display_timings() error path releases native_mode by routing cleanup through the path that calls of_node_put(native_mode), rather than skipping that cleanup. Reboot into the updated kernel after patching and confirm the active kernel version is the patched version, not merely installed on disk. On device-tree-based systems, perform regression testing of display initialization and driver probing to ensure the patched kernel behaves normally and does not generate new fbdev or device-tree parsing errors in dmesg.

Typical attack path

1. Obtain local access to an affected Linux system, either as a low-privileged user or through a compromised local service.
2. Identify whether the system uses fbdev and Open Firmware/device-tree display timing parsing, commonly seen on embedded or SoC-based platforms.
3. Trigger display timing parsing paths that reach the vulnerable error handling branch, such as by repeatedly causing relevant device/display initialization or probing failures where local permissions allow.
4. Repeat the trigger enough times to accumulate unreleased kernel device_node references.
5. Cause system instability, degraded display/device behavior, resource exhaustion, or a local denial-of-service condition.

How to detect it

There are no unique public indicators of exploitation for this vulnerability in the provided data, and exploitation would likely appear as local activity followed by repeated kernel/display/driver errors or system instability rather than a distinctive network signature. Review kernel logs such as dmesg, journald, /var/log/kern.log, /var/log/messages, and distribution-specific audit logs for repeated fbdev, Open Firmware, device-tree, display timing, or driver probe failures, especially when correlated with local user sessions, service restarts, module loading/unloading, hardware probing, or suspicious scripts. Look for patterns of repeated local commands or processes that exercise display initialization or device probing shortly before kernel memory/resource pressure, hung tasks, crashes, watchdog resets, or reboots. If endpoint telemetry is available, correlate low-privileged local process activity with bursts of kernel messages involving fbdev, of_get_display_timings, display-timings, native-mode, device tree parsing, or failed display driver probes. Because this is a reference-count leak, forensic confirmation may require kernel debugging, slab/reference diagnostics, or reproducing the suspected trigger on a test system with instrumentation enabled.

What your security team should do

• Prioritize patching affected Linux kernels on embedded, appliance, kiosk, industrial, ARM/SoC, or other device-tree-based systems where fbdev/display timing code is used.
• Treat internet exposure as a lower concern than local access: focus risk assessment on systems with untrusted local users, shared shells, container escape risk, or locally compromised services.
• Use vendor kernel advisories to identify the exact corrected package or firmware release, since no fixed versions were provided in the input.
• Where immediate patching is not possible, restrict local access, remove unnecessary users, limit service accounts, and prevent untrusted users from triggering hardware or driver reconfiguration paths.
• Monitor kernel logs for repeated fbdev, device-tree, display timing, or driver probe failures that may indicate attempts to exercise the vulnerable path or instability from resource leakage.
• Include this issue in routine Linux kernel lifecycle management rather than emergency response unless critical systems show relevant exposure or suspicious local activity.