Re: [PATCH net 20/20] can: ems_usb: validate CPC message lengths

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

Pre-existing issues:
- [High] TX context leak in ems_usb_start_xmit() error path.
--

--- Patch [20]: [PATCH net 20/20] can: ems_usb: validate CPC message length=
s ---
commit 2db7f239e46ba1c12e2761c8d9fa8b163a632adc
Author: Pengpeng Hou <[email protected]>

can: ems_usb: validate CPC message lengths

ems_usb_read_bulk_callback() walks CPC messages packed in one USB
receive buffer. Check that each declared message fits in the URB payload
and require type-specific payloads to cover the fields used by handlers.

Link: https://patch.msgid.link/[email protected]

> diff --git a/drivers/net/can/usb/ems_usb.c b/drivers/net/can/usb/ems_usb.c
> index 9b25dda7c1838..24cf8f651f8f1 100644
> --- a/drivers/net/can/usb/ems_usb.c
> +++ b/drivers/net/can/usb/ems_usb.c

[ ... ]

While reviewing this patch, I noticed a pre-existing issue in the
ems_usb_start_xmit() error path:

drivers/net/can/usb/ems_usb.c:ems_usb_start_xmit()
>	err =3D usb_submit_urb(urb, GFP_ATOMIC);
>	if (unlikely(err)) {
>		can_free_echo_skb(netdev, context->echo_index, NULL);
>
>		usb_unanchor_urb(urb);
>		usb_free_coherent(dev->udev, size, buf, urb->transfer_dma);
>
>		atomic_dec(&dev->active_tx_urbs);

[Severity: High]
This isn't a bug introduced by this patch, but does this error path
permanently leak the transmission context slot?

If usb_submit_urb() fails here, it cleans up the URB and echo_skb, but
doesn't reset context->echo_index to MAX_TX_URBS. After enough failures,
could this cause context allocations to fail and wedge the transmission path
indefinitely, causing the driver to always return NETDEV_TX_BUSY?

--=20
Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20260729102802.5051=
[email protected]?part=3D20