🛡️ AZL-64893 — kernel

CVE-2025-38348 affecting package kernel for versions less than 6.6.96.1-1

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.