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