fkie_cve-2025-38348
Vulnerability from fkie_nvd
Published
2025-07-10 09:15
Modified
2025-07-10 13:17
Severity ?
Summary
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.
Impacted products
Vendor Product Version



{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: p54: prevent buffer-overflow in p54_rx_eeprom_readback()\n\nRobert Morris reported:\n\n|If a malicious USB device pretends to be an Intersil p54 wifi\n|interface and generates an eeprom_readback message with a large\n|eeprom-\u003ev1.len, p54_rx_eeprom_readback() will copy data from the\n|message beyond the end of priv-\u003eeeprom.\n|\n|static void p54_rx_eeprom_readback(struct p54_common *priv,\n|                                   struct sk_buff *skb)\n|{\n|        struct p54_hdr *hdr = (struct p54_hdr *) skb-\u003edata;\n|        struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr-\u003edata;\n|\n|        if (priv-\u003efw_var \u003e= 0x509) {\n|                memcpy(priv-\u003eeeprom, eeprom-\u003ev2.data,\n|                       le16_to_cpu(eeprom-\u003ev2.len));\n|        } else {\n|                memcpy(priv-\u003eeeprom, eeprom-\u003ev1.data,\n|                       le16_to_cpu(eeprom-\u003ev1.len));\n|        }\n| [...]\n\nThe eeprom-\u003ev{1,2}.len is set by the driver in p54_download_eeprom().\nThe device is supposed to provide the same length back to the driver.\nBut yes, it\u0027s possible (like shown in the report) to alter the value\nto something that causes a crash/panic due to overrun.\n\nThis patch addresses the issue by adding the size to the common device\ncontext, so p54_rx_eeprom_readback no longer relies on possibly tampered\nvalues... That said, it also checks if the \"firmware\" altered the value\nand no longer copies them.\n\nThe one, small saving grace is: Before the driver tries to read the eeprom,\nit needs to upload \u003ea\u003c firmware. the vendor firmware has a proprietary\nlicense and as a reason, it is not present on most distributions by\ndefault."
    },
    {
      "lang": "es",
      "value": "En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: p54: evitar desbordamiento de b\u00fafer en p54_rx_eeprom_readback() Robert Morris inform\u00f3: |Si un dispositivo USB malicioso se hace pasar por una interfaz wifi p54 de Intersil y genera un mensaje eeprom_readback con un eeprom-\u0026gt;v1.len largo, p54_rx_eeprom_readback() copiar\u00e1 los datos del mensaje m\u00e1s all\u00e1 del final de priv-\u0026gt;eeprom. | |static void p54_rx_eeprom_readback(struct p54_common *priv, | struct sk_buff *skb) |{ | struct p54_hdr *hdr = (struct p54_hdr *) skb-\u0026gt;data; | struct p54_eeprom_lm86 *eeprom = (struct p54_eeprom_lm86 *) hdr-\u0026gt;data; | | if (priv-\u0026gt;fw_var \u0026gt;= 0x509) { | memcpy(priv-\u0026gt;eeprom, eeprom-\u0026gt;v2.data, | le16_to_cpu(eeprom-\u0026gt;v2.len)); | } else { | memcpy(priv-\u0026gt;eeprom, eeprom-\u0026gt;v1.data, | le16_to_cpu(eeprom-\u0026gt;v1.len)); | } | [...] El controlador establece eeprom-\u0026gt;v{1,2}.len en p54_download_eeprom(). Se supone que el dispositivo debe proporcionar la misma longitud al controlador. Sin embargo, es posible (como se muestra en el informe) modificar el valor para que provoque un bloqueo o p\u00e1nico debido a un desbordamiento. Este parche soluciona el problema a\u00f1adiendo el tama\u00f1o al contexto com\u00fan del dispositivo, de modo que p54_rx_eeprom_readback ya no depende de valores posiblemente manipulados. Dicho esto, tambi\u00e9n comprueba si el firmware alter\u00f3 el valor y ya no los copia. La \u00fanica peque\u00f1a ventaja es que, antes de que el controlador intente leer la EEPROM, necesita cargar un firmware. El firmware del proveedor tiene una licencia propietaria y, por ello, no est\u00e1 presente en la mayor\u00eda de las distribuciones por defecto."
    }
  ],
  "id": "CVE-2025-38348",
  "lastModified": "2025-07-10T13:17:30.017",
  "metrics": {},
  "published": "2025-07-10T09:15:29.840",
  "references": [
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/0e4dc150423b829c35cbcf399481ca11594fc036"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/12134f79e53eb56b0b0b7447fa0c512acf6a8422"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/1f7f8168abe8cbe845ab8bb557228d44784a6b57"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/6d05390d20f110de37d051a3e063ef0a542d01fb"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/714afb4c38edd19a057d519c1f9c5d164b43de94"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/9701f842031b825e2fd5f22d064166f8f13f6e4d"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/da1b9a55ff116cb040528ef664c70a4eec03ae99"
    },
    {
      "source": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
      "url": "https://git.kernel.org/stable/c/f39b2f8c1549a539846e083790fad396ef6cd802"
    }
  ],
  "sourceIdentifier": "416baaa9-dc9f-4396-8d5f-8c081fb06d67",
  "vulnStatus": "Awaiting Analysis"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.


Loading…

Loading…