Description

In the Linux kernel, the following vulnerability has been resolved: regulator: fp9931: Fix VPOS/VNEG voltage selector table The VPOSNEG_table[] mapping does not match the FP9931 datasheet. The datasheet defines the VPOS/VNEG voltage mapping as: 00h-04h -> 7.04V (-7.04V) 05h -> 7.26V (-7.26V) 06h -> 7.49V (-7.49V) ... 28h-3Fh -> 15.06V (-15.06V) However, VPOSNEG_table[] has two issues: 1. Selector 0x00~0x04 should all map to 7.04V (5 entries), but the table has 6 entries of 7.04V, causing all subsequent entries to be shifted by one position. 2. Selectors 0x29~0x3F should all clamp to 15.06V (23 entries), but the table has only 41 entries. Any selector value above 0x28 would result in an out-of-bounds table access. Fix both issues by removing the duplicate 7.04V entry and appending the missing 23 clamped 15.06V entries, bringing the table to the correct size of 64 entries (0x00~0x3F).

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.4",
  "pubDate": "2026-09-03T13:06:14.007Z",
  "pubdate": "2026-09-03T13:06:14.007Z",
  "executiveSummary": "This vulnerability is an out-of-bounds (OOB) memory access issue identified in the Linux kernel's fp9931 regulator driver. The flaw stems from an incorrectly defined voltage selector lookup table, which fails to align with the hardware datasheet specifications.\nThe vulnerability type is an out-of-bounds read, potentially leading to information disclosure or system instability. It affects the FP9931 regulator component within the Linux kernel.\nThe risk implication involves the potential for the kernel to perform unauthorized memory reads or incorrect voltage regulation if provided with specific selector values. An attacker with the ability to influence regulator settings—typically through userspace interfaces exposed by the kernel—could trigger this out-of-bounds access.\nWhile exploitation requires a local environment with sufficient privileges to modify regulator parameters via sysfs or similar interfaces, the impact could range from erratic hardware behavior due to incorrect voltage output to kernel memory corruption if the out-of-bounds read is followed by subsequent operations.",
  "technicalDetails": "The root cause of this vulnerability is a misconfiguration of the VPOSNEG_table[] in the fp9931 regulator driver. The lookup table, intended to map register selector values to specific voltages, contains an erroneous entry count that causes a misalignment between the selector index and the corresponding voltage value.\nSpecifically, the table erroneously includes an extra entry for the 7.04V mapping. Because selectors 0x00 through 0x04 are defined to map to 7.04V, the driver expects 5 entries. The inclusion of a 6th entry results in an index shift, where all subsequent voltage mappings are off by one position relative to the hardware registers defined in the FP9931 datasheet.\nFurthermore, the table lacks the necessary padding for the upper range of the selector space. The datasheet specifies that selectors 0x29 through 0x3F should clamp to 15.06V. With the current table implementation, the array is truncated and lacks the required 23 entries to cover the full 0x3F range. Consequently, when a selector value greater than 0x28 is requested, the kernel performs an out-of-bounds array access.\nThe exploitation flow involves an attacker manipulating the regulator voltage via the /sys/class/regulator/ interface. By passing a selector index greater than 0x28, the attacker forces the driver to read memory addresses beyond the buffer boundary of VPOSNEG_table[].\nThe behavior of this OOB access is twofold: first, it results in the retrieval of arbitrary, adjacent kernel data instead of valid voltage configuration constants, potentially leaking sensitive information into logs or register states. Second, as the driver proceeds to use the retrieved (and invalid) value for hardware register programming, it causes the FP9931 regulator to output an incorrect, potentially damaging, voltage level. This misalignment not only leads to a logical inconsistency in hardware control but also exposes the kernel to memory safety violations, as the logic assumes a well-defined table bounds that the current implementation fails to enforce."
}