Re: [PATCH v2 net-next 04/15] net: enetc: add link speed message support to PF driver

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Pre-existing out-of-bounds heap read in VF mailbox handlers due to unvalidated message length.
--

commit 6b55ba2c40a6c04cf0db8ebb97921067e4376ee1
Author: Wei Fang <wei.fang@nxp.com>
net: enetc: add link speed message support to PF driver

This commit adds link speed message support for DPDK-owned VFs. The PF
driver replies with the current link speed when it receives a get link
speed message from a VF, improving link state visibility for the VF.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_msg.c b/drivers/net/ethernet/freescale/enetc/enetc_msg.c
> index eac71f90d80bd..b24903b23a616 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_msg.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_msg.c
[ ... ]
> @@ -274,6 +277,84 @@ static u16 enetc_msg_handle_link_status(struct enetc_pf *pf, int vf_id,
>  	}
>  }
>  
> +static u16 enetc_msg_get_link_speed(struct enetc_pf *pf, int vf_id)
> +{
[ ... ]
> +}
> +
> +static u16 enetc_msg_handle_link_speed(struct enetc_pf *pf, int vf_id,
> +				       void *vf_msg)
> +{
> +	struct enetc_msg_header *msg_hdr = vf_msg;

[Severity: High]
This isn't a bug introduced by this patch, but could unvalidated message
lengths lead to out-of-bounds heap reads in mailbox handlers?

In existing handlers, the PF driver calculates the allocation size based on
msg_hdr->len (e.g., msg_size = 16 + len) and allocates a buffer. If a trusted
VF sends a message with an artificially small length like 0, only 16 bytes
are allocated.

However, handlers cast this buffer to larger structures and read fields
outside the bounds:

enetc_msg_set_vf_primary_mac_addr() {
    ...
    char *addr = msg->mac[0].addr;
    ...
    if (!is_valid_ether_addr(addr)) {
    ...
        enetc_set_si_hw_addr(pf, vf_id + 1, addr);
    ...
}

Since msg->mac[0].addr starts at offset 20, reading it from a 16-byte
buffer causes an out-of-bounds heap read, which could leak sensitive kernel
memory into the device MAC address registers or crash the host kernel. Should
message lengths be validated against the expected structure size before
processing the messages?

> +
> +	switch (msg_hdr->cmd_id) {
> +	case ENETC_MSG_GET_CURRENT_LINK_SPEED:
> +		return enetc_msg_get_link_speed(pf, vf_id);
> +	case ENETC_MSG_REGISTER_SPEED_CHANGE_NOTIFIER:
> +	case ENETC_MSG_UNREGISTER_SPEED_CHANGE_NOTIFIER:
> +	default:
> +		return ENETC_PF_MSG_NOTSUPP;
> +	}
> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260610091844.3423693-1-wei.fang@oss.nxp.com?part=4