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

Reply via email to