CVE-2026-80711 in Linux
Summary
by MITRE • 08/28/2026
In the Linux kernel, the following vulnerability has been resolved:
power: supply: max17040: handle missing status supplier
MAX17040 does not report charger state itself, so the driver forwards POWER_SUPPLY_PROP_STATUS to a supplier power supply. If no supplier is registered, power_supply_get_property_from_supplier() returns -ENODEV and leaves the output value untouched.
max17040_get_property() currently ignores that error and returns success, so userspace can read an uninitialized status value from the battery power supply. This happens on systems that use the fuel gauge without a charger supplier relationship in firmware.
Return POWER_SUPPLY_STATUS_UNKNOWN when no supplier provides STATUS, and propagate other supplier lookup errors.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The Linux kernel driver for the MAX17040 battery fuel gauge contains a logic flaw related to property retrieval from upstream power supply suppliers. The MAX17040 hardware does not natively report its own charger state or status, necessitating that the driver query an associated supplier power supply to determine this information. This architectural dependency is common in embedded systems where the fuel gauge and charging controller are distinct components communicating via buses such as I2C or SMBus. The driver relies on the function power_supply_get_property_from_supplier() to fetch properties like POWER_SUPPLY_PROP_STATUS from a registered upstream device, typically representing the charger IC.
The vulnerability arises when no supplier is registered for this relationship, which can occur in systems where firmware does not define a charger-supplier link or during early boot stages before all devices are initialized. In such scenarios, power_supply_get_property_from_supplier() correctly returns an error code indicating that the device was not found, specifically -ENODEV. However, the max17040_get_property function fails to check this return value for errors. Instead of treating the failure as a condition requiring specific handling, it proceeds under the assumption that the operation succeeded and leaves the output variable untouched. Since the output variable is typically uninitialized or contains stale data from previous operations, userspace applications reading the battery status via sysfs receive garbage values rather than an accurate representation of the power state.
This behavior constitutes an information disclosure vulnerability as defined by CWE-200, where sensitive system internals are exposed to unprivileged processes through improper error handling. Furthermore, it aligns with CWE-457 regarding use of uninitialized variable, which can lead to unpredictable application behavior or crashes in userspace software that expects valid enum values for battery status. The lack of proper validation allows the kernel to propagate undefined state information up the stack, potentially causing confusion in power management daemons like UPower or systemd-logind, which rely on accurate status reports to make decisions about system sleep states or user notifications.
From a threat modeling perspective using MITRE ATT&CK techniques, this flaw could be leveraged by local attackers for reconnaissance purposes (T1082). By repeatedly reading the battery property and analyzing the returned values across different power conditions, an attacker might infer details about the hardware configuration or firmware state that were not intended to be exposed. While the immediate impact is primarily informational rather than a direct privilege escalation vector, it degrades system reliability and can lead to incorrect power management decisions if userspace logic assumes valid data was received without checking for errors itself.
To mitigate this vulnerability, the driver implementation must strictly validate the return codes of all supplier property lookups. When no supplier provides the STATUS property or when a lookup fails due to -ENODEV, the function should explicitly set the output value to POWER_SUPPLY_STATUS_UNKNOWN rather than leaving it uninitialized. This ensures that userspace receives a defined and safe default state indicating uncertainty about the charger status. For other types of errors returned by the supplier interface, these should be propagated up the call stack appropriately so that higher-level components can handle transient failures or configuration issues correctly.
System administrators and developers should ensure that their device tree configurations accurately reflect hardware dependencies to prevent this code path from being triggered unnecessarily in production environments. However, robust defensive coding practices within the kernel driver are essential because firmware definitions may vary across different board revisions or custom builds. Updating to a patched version of the Linux kernel where max17040_get_property correctly handles missing suppliers is required to eliminate this information leak and ensure consistent power supply status reporting.