Re: [PATCH 4.19 094/133] USB: serial: iuu_phoenix: fix memory corruption

From: Johan Hovold
Date: Tue Jul 21 2020 - 07:54:58 EST


On Tue, Jul 21, 2020 at 01:33:00PM +0200, Pavel Machek wrote:
> Hi!
>
> > commit e7b931bee739e8a77ae216e613d3b99342b6dec0 upstream.
> >
> > The driver would happily overwrite its write buffer with user data in
> > 256 byte increments due to a removed buffer-space sanity check.
>
> > +++ b/drivers/usb/serial/iuu_phoenix.c
> > @@ -697,14 +697,16 @@ static int iuu_uart_write(struct tty_str
> > struct iuu_private *priv = usb_get_serial_port_data(port);
> > unsigned long flags;
> >
> > - if (count > 256)
> > - return -ENOMEM;
> > -
> > spin_lock_irqsave(&priv->lock, flags);
> >
> > + count = min(count, 256 - priv->writelen);
> > + if (count == 0)
> > + goto out;
> > +
> > /* fill the buffer */
> > memcpy(priv->writebuf + priv->writelen, buf, count);
> > priv->writelen += count;
> > +out:
> > spin_unlock_irqrestore(&priv->lock, flags);
> >
> > return count;
>
> Ok, so... goto and label is unneccessary, memcpy will do the right
> thing with count == 0.

That's generally too subtle. Better to clearly mark the error/exception
path.

> But what is worse, this changes return value in the error case;
> returning 0 instead of -ENOMEM. I don't believe 0 is appropriate
> return code here.
>
> (It should block on the write buffer if blocking or return -EAGAIN if
> nonblocking, right?)

No, zero is the correct return value here when the tty driver's buffer
is full. The line discipline will then handle nonblocking writes
correctly, etc.

Johan

Attachment: signature.asc
Description: PGP signature