CVE-2026-43165

What it actually does

This is a local denial-of-service vulnerability in the Linux kernel nct7363 hardware monitoring driver. The driver calls of_parse_phandle_with_args() in nct7363_present_pwm_fanin() but fails to release the returned device-tree node reference with of_node_put(), causing a kernel resource/reference leak. Repeated triggering can consume kernel resources over time and may degrade system stability or availability. The flaw does not directly provide code execution, privilege escalation, or data disclosure based on the published description.

Why it matters to the business

Affected Linux systems that use the nct7363 hardware monitoring driver may become unstable or unavailable if the vulnerable code path is repeatedly exercised. The risk is highest for embedded, appliance, server, or hardware-management platforms that rely on this driver and expose local access to untrusted or semi-trusted users. The vulnerability has a medium CVSS score, very low EPSS, no known public exploit maturity, and is not listed in CISA KEV, so remediation should be handled through normal kernel update cycles unless the driver is present on critical systems.

How an attack unfolds

An attacker first needs local access with sufficient privileges to interact with the affected hardware monitoring functionality or repeatedly trigger driver probing/configuration paths that call nct7363_present_pwm_fanin(). On systems with the vulnerable nct7363 driver and relevant device-tree configuration, the attacker causes the driver to parse phandle references repeatedly. Because the driver fails to release each referenced device node, kernel references accumulate. Over time, this resource leak can contribute to memory/resource exhaustion or unstable kernel behavior, potentially resulting in degraded performance, hangs, or denial of service. Exploitation is configuration-dependent and requires the affected driver to be present and reachable.

How to fix it

Update to a Linux kernel version that includes the upstream fix for the nct7363 driver resource leak. If a distribution kernel is used, apply the vendor-provided security or stable kernel update when available. If building a custom kernel, incorporate the patch that adds the missing of_node_put() after of_parse_phandle_with_args() in nct7363_present_pwm_fanin(). If immediate patching is not possible, reduce exposure by disabling or unloading the nct7363 driver where it is not required, removing the driver from custom kernel builds, limiting local shell access to trusted administrators, and restricting access to hardware monitoring interfaces. No exact fixed package versions were provided, so track the relevant Linux distribution, device vendor, or kernel stable branch advisories for the corrected release.

How to confirm the fix worked

Confirm the running kernel includes the corrected nct7363 driver source or vendor backport. For source-based validation, verify that nct7363_present_pwm_fanin() releases device-node references with of_node_put() after successful of_parse_phandle_with_args() calls. For runtime exposure validation, check whether the nct7363 driver is loaded as a module, built into the kernel, or referenced by device-tree hardware configuration. Commands such as lsmod, modinfo nct7363, grep of /proc/device-tree where available, and review of /sys/class/hwmon can help determine whether the driver is in use. After patching, reboot into the updated kernel and verify uname -r and package manager kernel versions reflect the corrected release.

Typical attack path

1. Gain local access to an affected Linux system.
2. Confirm the nct7363 hardware monitoring driver is present, loaded, or built into the running kernel.
3. Identify a way to repeatedly trigger the affected driver path, such as device probing, hardware monitoring initialization, or related local interactions exposed by the platform.
4. Repeatedly exercise the vulnerable code path so unreleased device-node references accumulate.
5. Cause resource exhaustion or kernel instability, leading to service degradation or denial of service.

How to detect it

There are no known public exploit indicators, named threat actors, ransomware use, or CISA KEV activity for this vulnerability. Detection should focus on exposure and signs of local resource-exhaustion behavior rather than unique compromise artifacts. Review kernel logs, system journals, crash dumps, and monitoring data for unexplained kernel warnings, memory pressure, OOM killer events, hangs, watchdog resets, or reboots on systems where the nct7363 driver is present. Check audit logs, shell history, and process accounting for local users repeatedly interacting with hardware monitoring sysfs paths, module loading/unloading, or platform device probing around the time instability began. Because the flaw is a resource leak, exploitation may leave no distinctive forensic marker beyond repeated local triggering and gradual degradation.

What your security team should do

• Inventory Linux systems for use of the nct7363 hardware monitoring driver, especially embedded, appliance, and hardware-management platforms.
• Prioritize patching systems where the driver is present and where local users, containers, or restricted operators can interact with hardware monitoring interfaces.
• Apply vendor kernel updates or backport the upstream fix into custom kernels.
• Disable or remove the nct7363 driver on systems that do not require it.
• Limit local interactive access to trusted users until patched.
• Monitor affected systems for kernel warnings, unexplained resource growth, OOM activity, hangs, or reboots that could indicate resource-exhaustion behavior.
• Track distribution advisories because exact fixed package versions were not supplied.