Re: Stack buffer overflow (write) in kvaser_usb_leaf_wait_cmd via malicious USB

[Greg KH <gregkh@linuxfoundation.org>]

On Tue, Feb 17, 2026 at 06:13:30PM -0800, Nicholas Carlini wrote:
> My best guess at a fix would be to check the bounds of the output
> buffer as well. Below I've written an attempt at a patch. (I know that
> it will fail to merge because gmail will break patches, sorry about
> that, I'm working on getting myself permissions to download an email
> client onto my work laptop that will let me send well-formatted
> patches to you all asap.)
> 
> Author: Nicholas Carlini <nicholas@carlini.com>
> Date:   Mon Feb 16 18:12:33 2026 +0000
> 
>     can: kvaser_usb: fix stack buffer overflow in kvaser_usb_leaf_wait_cmd()
> 
>     kvaser_usb_leaf_wait_cmd() copies a command response from a USB device into
>     a caller-provided struct kvaser_cmd on the stack. The length of the copy is
>     provided by the command byte on the USB data (tmp->len), which can be fully
>     controlled by a malicious USB device. The maximum size of tmp->len is 255,
>     but the destination buffer is only sizeof(struct kvaser_cmd) bytes (~32).
> 
>     Add a bounds check to ensure that tmp->len does not exceed sizeof(*cmd)
>     before memcpy.
> 
>     Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser
> CAN/USB devices")
>     Signed-off-by: Nicholas Carlini <nicholas@carlini.com>
> 
> diff --git a/drivers/net/can/usb/kvaser_usb/kvaser_usb_leaf.c
> b/drivers/net/can/usb/kvaser_usb/kvaser_usb_leaf.c
> index 1167d38344f1..465c3a6801e4 100644
> --- a/drivers/net/can/usb/kvaser_usb/kvaser_usb_leaf.c
> +++ b/drivers/net/can/usb/kvaser_usb/kvaser_usb_leaf.c
> @@ -698,6 +698,13 @@ static int kvaser_usb_leaf_wait_cmd(const struct
> kvaser_usb *dev, u8 id,
>                         }
> 
>                         if (tmp->id == id) {
> +                               if (tmp->len > sizeof(*cmd)) {
> +                                       dev_err_ratelimited(&dev->intf->dev,
> +                                               "Command %u too long
> (%u, max %zu)\n",
> +                                               tmp->id, tmp->len,
> sizeof(*cmd));
> +                                       err = -EIO;
> +                                       goto end;
> +                               }
>                                 memcpy(cmd, tmp, tmp->len);
>                                 goto end;
>                         }
> 

Can you just resend this patch, in proper format so that we can actually
apply it?  It is totally corrupted and will not work.

Also, you need to use your corporate email address, as the signed-off-by
line does not match up with your From: line on your email :)

But, I don't think the patch should be spamming the kernel log for a
broken device like this.  Just error out and all will be fine.

And is this the only place in this driver where it treats data in an
untrusted way?  As you know, once a driver is bound to a device, we
trust the hardware to work properly, so this really is just a "let's be
careful" type of fix, not any real bug to be handled as a real device
will not trigger this.

thanks,

greg k-h