CVE-2026-98188 in Linux
Summary
by MITRE • 10/06/2026
In the Linux kernel, the following vulnerability has been resolved:
wifi: p54: validate curve data length in the calibration curve converters
p54_convert_rev0() and p54_convert_rev1() read calibration curve data from the device-supplied EEPROM entry using channel and points-per-channel counts taken verbatim from that same entry, so an entry that declares more data than it carries drives an out-of-bounds read past the EEPROM buffer (verified with a KASAN reproducer of the conversion loop). The sibling converters p54_convert_output_limits() and p54_convert_db() already validate their counts against the entry length; this path was missed.
Reject the entry when the counts do not fit in the entry data.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/06/2026
The Linux kernel driver for the P54 wireless network interface contains a critical input validation flaw within its calibration curve conversion routines, specifically affecting p54_convert_rev0 and p54_convert_rev1 functions. These functions are responsible for processing hardware-specific calibration data stored in the device's EEPROM to ensure optimal radio performance across different channels. The vulnerability arises because these converters retrieve channel counts and points-per-channel metrics directly from the EEPROM entry without performing any bounds checking against the actual size of the available data buffer. This design assumption relies on the integrity of the firmware or EEPROM content, which is a dangerous premise in security-sensitive contexts where corrupted or maliciously crafted hardware images could be introduced through supply chain attacks or physical tampering.
When an EEPROM entry declares more calibration points than are actually present in the binary blob, the conversion loop attempts to read memory locations beyond the allocated buffer boundary. This results in an out-of-bounds read operation that accesses kernel memory outside the intended scope of the device data structure. Such access patterns can lead to information disclosure by leaking sensitive kernel memory contents into user-space or application buffers if the returned values are subsequently used. Furthermore, depending on how the corrupted calibration data is processed downstream, this invalid state could potentially trigger undefined behavior within the network stack or driver logic, contributing to system instability or denial of service conditions where the wireless interface fails to initialize correctly or causes kernel panics during runtime operations involving radio parameter adjustments.
From a classification perspective, this vulnerability aligns with CWE-125 Out-of-bounds Read and CWE-20 Improper Input Validation within the Common Weakness Enumeration framework. The failure to verify that declared data lengths match actual buffer capacities represents a classic validation bypass where trusted sources are assumed safe without verification. In terms of adversary tactics, exploiting this flaw would fall under ATT&CK technique T1608 Overprivileged Resource which involves leveraging excessive permissions or access rights to read restricted memory regions, although the primary impact here is often limited to local information gathering rather than remote code execution unless combined with other vulnerabilities in the driver stack.
The operational impact of this vulnerability extends beyond simple data corruption as it compromises the reliability of wireless connectivity mechanisms that depend on accurate calibration curves for frequency hopping and power control algorithms. If an attacker can influence or replace the EEPROM contents, they could force the device to operate outside safe regulatory limits or cause intermittent connection drops due to invalid signal processing parameters. Mitigation strategies primarily involve applying kernel patches that enforce strict length checks before accessing array elements within these conversion functions. System administrators should ensure their distributions are updated with fixed versions of the p54 driver and consider implementing hardware-level protections such as signed firmware images to prevent unauthorized modification of EEPROM contents during manufacturing or maintenance phases, thereby addressing both the software logic error and its potential vector for exploitation.