CVE-2026-98480 in Linux
Summary
by MITRE • 10/18/2026
In the Linux kernel, the following vulnerability has been resolved:
nfc: trf7970a: power down on startup RX gain failure
trf7970a_startup() powers up the device before applying the optional RX gain reduction. If the register read or write fails, it returns without undoing that power-up. Probe's unwind only drops the separate regulator references acquired by probe, leaving the additional VIN enable from startup unbalanced. The system resume caller also has no power-down on this error.
Call trf7970a_power_down() before returning the RX gain error to deassert the enable GPIOs, release the startup VIN reference and restore the powered-off state. Runtime PM has not been enabled yet, so the full shutdown helper is not appropriate here. Preserve the original SPI error.
This issue was identified during our ongoing static-analysis research while reviewing kernel code.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/18/2026
The vulnerability in question resides within the Near Field Communication (NFC) subsystem of the Linux kernel, specifically affecting the trf7970a driver which manages Texas Instruments' TRF7970A NFC transceiver chip. This issue is classified as a resource management error where power state transitions are not properly handled during initialization failures. The core technical flaw lies in the execution flow of the trf7970a_startup function, which is responsible for bringing the hardware device into an operational state. During this process, the driver asserts GPIO lines to enable voltage regulators and powers up the internal circuitry of the transceiver before attempting to configure optional parameters such as RX gain reduction. If a subsequent register read or write operation fails due to communication errors with the SPI bus or other I/O issues, the function currently returns an error code without reversing the power-up actions taken earlier in the sequence. This creates an imbalance where the device remains powered on despite the driver failing to initialize correctly, leading to a leak of hardware resources and potential instability.
From a systems engineering perspective, this oversight results in unbalanced regulator references that are not cleaned up by the standard probe error handling paths. While the probe function's unwind logic is designed to drop separate regulator references acquired during the initial device discovery phase, it does account for the additional VIN enable signal asserted specifically within the startup routine. Consequently, if the RX gain configuration fails, the system leaves the trf7970a chip in a powered-on state even though the driver has reported an initialization failure and detached from the device. This situation is further exacerbated by the fact that runtime power management (PM) features are not yet enabled at this stage of the boot process, meaning the kernel cannot rely on automatic suspend mechanisms to correct the state. The system resume caller also lacks specific logic to handle a powered-on but uninitialized device during error recovery paths, compounding the risk of persistent resource leakage across reboots or driver reloads.
The operational impact of this vulnerability includes unnecessary power consumption and potential interference with other hardware components sharing similar voltage rails. In battery-powered devices such as smartphones or IoT sensors, leaving an NFC transceiver powered on unnecessarily can contribute to reduced battery life over time. Furthermore, if the device remains in a partially configured state where its internal registers are undefined due to the failed RX gain setup, subsequent attempts by user-space applications or other kernel subsystems to interact with the NFC interface may result in unpredictable behavior, including communication timeouts or hardware lockups. This can degrade the overall reliability of the system's near-field connectivity features and potentially cause driver crashes if higher-level code assumes a fully initialized state based on incorrect assumptions about power management status.
To mitigate this vulnerability, the recommended fix involves modifying the error handling path within the trf7970a_startup function to explicitly call trf7970a_power_down before returning an error code upon RX gain failure. This ensures that GPIO lines are deasserted and the startup VIN reference is released, effectively restoring the device to a powered-off state consistent with its pre-initialization condition. It is critical to preserve the original SPI error return value so that diagnostic tools can still identify the root cause of the initialization failure while ensuring hardware safety. By implementing this cleanup routine, developers align the driver's behavior with robust resource management principles, preventing leaks and maintaining system stability during transient I/O errors or hardware faults.
This type of vulnerability is commonly categorized under CWE-401: Missing Release of Memory after Effective Lifetime, although in this specific context it applies to power resources rather than memory allocation. The failure to release acquired resources upon error paths is a classic pattern that leads to resource exhaustion over the lifecycle of an operating system instance. In terms of attack vectors and behavioral analysis, while this is primarily a reliability issue rather than a direct security exploit vector for privilege escalation, improper hardware state management can sometimes be leveraged in side-channel attacks or denial-of-service scenarios where sustained power drain or device instability is used to disrupt service availability. The ATT&CK framework does not have a specific tactic for kernel resource leaks as they are typically considered stability issues rather than malicious techniques, but the underlying principle of maintaining system integrity aligns with general defensive coding practices emphasized in secure software development lifecycle guidelines. Addressing such flaws through static analysis and rigorous code review processes helps ensure that hardware abstraction layers remain robust against both transient faults and potential abuse scenarios targeting power management subsystems.