Entreprise française de cybersécurité depuis 2004
☎ 03 60 47 09 81 - info@securiteinfo.com
☎ 03 60 47 09 81 - info@securiteinfo.com
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 valueto something that causes a crash/panic due to overrun.This patch addresses the issue by adding the size to the common devicecontext, so p54_rx_eeprom_readback no longer relies on possibly tamperedvalues... That said, it also checks if the "firmware" altered the valueand 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 proprietarylicense and as a reason, it is not present on most distributions bydefault.
No PoCs from references.
- https://github.com/w4zu/Debian_security