CVE-2025-38348

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()<br /> <br /> Robert Morris reported:<br /> <br /> |If a malicious USB device pretends to be an Intersil p54 wifi<br /> |interface and generates an eeprom_readback message with a large<br /> |eeprom-&gt;v1.len, p54_rx_eeprom_readback() will copy data from the<br /> |message beyond the end of priv-&gt;eeprom.<br /> |<br /> |static void p54_rx_eeprom_readback(struct p54_common *priv,<br /> | struct sk_buff *skb)<br /> |{<br /> | struct p54_hdr *hdr = (struct p54_hdr *) skb-&gt;data;<br /> | struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr-&gt;data;<br /> |<br /> | if (priv-&gt;fw_var &gt;= 0x509) {<br /> | memcpy(priv-&gt;eeprom, eeprom-&gt;v2.data,<br /> | le16_to_cpu(eeprom-&gt;v2.len));<br /> | } else {<br /> | memcpy(priv-&gt;eeprom, eeprom-&gt;v1.data,<br /> | le16_to_cpu(eeprom-&gt;v1.len));<br /> | }<br /> | [...]<br /> <br /> The eeprom-&gt;v{1,2}.len is set by the driver in p54_download_eeprom().<br /> The device is supposed to provide the same length back to the driver.<br /> But yes, it&amp;#39;s possible (like shown in the report) to alter the value<br /> to something that causes a crash/panic due to overrun.<br /> <br /> This patch addresses the issue by adding the size to the common device<br /> context, so p54_rx_eeprom_readback no longer relies on possibly tampered<br /> values... That said, it also checks if the "firmware" altered the value<br /> and no longer copies them.<br /> <br /> The one, small saving grace is: Before the driver tries to read the eeprom,<br /> it needs to upload &gt;a