In the Linux kernel, the following vulnerability has been resolved: wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback() Robert Morris reported: |If a malicious USB device pretends to be an Intersil p54 wifi |interface and generates an eeprom_readback message with a large |eeprom->v1.len, p54_rx_eeprom_readback() will copy data from the |message beyond the end of priv->eeprom. | |static void p54_rx_eeprom_readback(struct p54_common *priv, | struct sk_buff *skb) |{ | struct p54_hdr *hdr = (struct p54_hdr *) skb->data; | struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr->data; | | if (priv->fw_var >= 0x509) { | memcpy(priv->eeprom, eeprom->v2.data, | le16_to_cpu(eeprom->v2.len)); | } else { | memcpy(priv->eeprom, eeprom->v1.data, | le16_to_cpu(eeprom->v1.len)); | } | [...] The eeprom->v{1,2}.len is set by the driver in p54_download_eeprom(). The device is supposed to provide the same length back to the driver. But yes, it's possible (like shown in the report) to alter the value to something that causes a crash/panic due to overrun. This patch addresses the issue by adding the size to the common device context, so p54_rx_eeprom_readback no longer relies on possibly tampered values... That said, it also checks if the "firmware" altered the value and no longer copies them. The one, small saving grace is: Before the driver tries to read the eeprom, it needs to upload >a< firmware. the vendor firmware has a proprietary license and as a reason, it is not present on most distributions by default.
This vulnerability carries a HIGH severity rating with a CVSS v3.1 score of 7.8, requiring local system access to exploit with relatively low complexity without requiring user interaction requiring only low-level privileges . The vulnerability impacts confidentiality (data exposure), integrity (unauthorized modifications), and availability (service disruption) for affected systems. Impacting 2 products from linux, from debian organizations running these solutions should prioritize assessment and patching.
Reported in 2025, this vulnerability emerged during an era marked by increased sophistication in supply chain attacks, cloud infrastructure vulnerabilities, and software-as-a-service (SaaS) security challenges. Security practices during this period emphasized zero-trust architectures, container security, and API protection.
2025-07-10T09:15:29.840
2025-12-16T17:35:21.510
Analyzed
416baaa9-dc9f-4396-8d5f-8c081fb06d67
CVSSv3.1: 7.8 (HIGH)
| Type | Vendor | Product | Version/Range | Vulnerable? |
|---|---|---|---|---|
| Operating System | linux | linux_kernel | < 5.4.295 | Yes |
| Operating System | linux | linux_kernel | < 5.10.239 | Yes |
| Operating System | linux | linux_kernel | < 5.15.186 | Yes |
| Operating System | linux | linux_kernel | < 6.1.142 | Yes |
| Operating System | linux | linux_kernel | < 6.6.95 | Yes |
| Operating System | linux | linux_kernel | < 6.12.35 | Yes |
| Operating System | linux | linux_kernel | < 6.15.4 | Yes |
| Operating System | debian | debian_linux | 11.0 | Yes |
SecUtils normalizes and enriches National Vulnerability Database (NVD) records by standardizing vendor and product identifiers, aggregating vulnerability metadata from both NVD and MITRE sources, and providing structured context for security teams. For linux's affected products, we extract Common Platform Enumeration (CPE) data, Common Weakness Enumeration (CWE) classifications, CVSS severity metrics, and reference data to enable rapid vulnerability prioritization and asset correlation. This record contains no exploit code, proof-of-concept instructions, or attack methodologies—only defensive intelligence necessary for patch management, risk assessment, and security operations.