Re: [PATCH net-next 09/15] net: enetc: add MAC address filtering support for VFs of ENETC v4

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] A Time-Of-Check to Time-Of-Use (TOCTOU) race condition in `enetc_msg_handle_rxmsg` allows a malicious VF to trigger a heap out-of-bounds read in `enetc_msg_set_vf_mac_hash_filter` by changing the message length between allocation and use.
--

commit 46d6bb311e4a8bcc15dcd4d622db8e4c46a5ec75
Author: Wei Fang <wei.fang@nxp.com>

net: enetc: add MAC address filtering support for VFs of ENETC v4

Adds VSI-to-PSI mailbox message support to allow VFs to request MAC filter
configuration from the PF on ENETC v4. Introduces two new command IDs to
program the MAC hash filter table and configure promiscuous mode.

> diff --git a/drivers/net/ethernet/freescale/enetc/enetc_msg.c b/drivers/net/ethernet/freescale/enetc/enetc_msg.c
> index 49c1ca14735c9..7dcb1dcdec84d 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc_msg.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc_msg.c
[ ... ]
> @@ -101,6 +101,115 @@ static u16 enetc_msg_set_vf_primary_mac_addr(struct enetc_pf *pf, int vf_id,
[ ... ]
> +static u16 enetc_msg_set_vf_mac_hash_filter(struct enetc_pf *pf, int vf_id,
> +					    void *vf_msg)
> +{
[ ... ]
> +	} else if (type == ENETC_MAC_FILTER_TYPE_ALL) {
> +		if (!msg->hdr.len) {
> +			pf_msg = FIELD_PREP(ENETC_PF_MSG_CLASS_ID,
> +					    ENETC_MSG_CLASS_ID_INVALID_MSG_LEN);
> +			goto vf_state_unlock;
> +		}
> +
> +		pf->ops->set_si_mac_hash_filter(hw, si_id, UC, hash_tbl);
> +		hash_tbl = (u64)msg->hash_tbl[3] << 32 | msg->hash_tbl[2];

[Severity: High]
Can a malicious VF trigger a heap out-of-bounds read here?

Looking at enetc_msg_handle_rxmsg(), which handles the message allocation, it
reads msg_hdr->len from DMA memory to calculate the size:

    u32 msg_size = ENETC_MSG_SIZE(msg_hdr->len);
    ...
    msg = kzalloc_objs(*msg, msg_size);
    ...
    memcpy(msg, msg_swbd->vaddr, msg_size);

If the VF modifies the length in DMA memory to a non-zero value between the
msg_size calculation and the memcpy, the copied msg->hdr.len will differ from
the size actually allocated.

If the buffer was allocated as 32 bytes (because the initial length was 0),
this check for !msg->hdr.len will pass, and the subsequent read of
msg->hash_tbl[3] (at offset 32) will read out of bounds.

If this object is placed at the end of a slab page next to an unmapped page,
could this cause a panic, leading to a guest-to-host denial of service?
Additionally, would the leaked kernel heap data be programmed into the MAC hash
filter, potentially creating an information leak?

> +		pf->ops->set_si_mac_hash_filter(hw, si_id, MC, hash_tbl);
> +	}
> +
> +vf_state_unlock:
> +	mutex_unlock(&vf_state->lock);
> +
> +	return pf_msg;
> +}

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