linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Andrey Konovalov <andreyknvl@google.com>,
	Johan Hovold <johan@kernel.org>,
	USB list <linux-usb@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Dmitry Vyukov <dvyukov@google.com>,
	Kostya Serebryany <kcc@google.com>,
	syzkaller <syzkaller@googlegroups.com>
Subject: Re: usb/serial/visor: slab-out-of-bounds in palm_os_3_probe
Date: Tue, 3 Oct 2017 11:29:40 +0200	[thread overview]
Message-ID: <20171003092940.GA3404@localhost> (raw)
In-Reply-To: <20170929083755.GB17540@kroah.com>

On Fri, Sep 29, 2017 at 10:37:55AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Sep 28, 2017 at 07:57:46PM +0200, Andrey Konovalov wrote:
> > Hi!
> > 
> > I've got the following report while fuzzing the kernel with syzkaller.
> > 
> > On commit dc972a67cc54585bd83ad811c4e9b6ab3dcd427e (4.14-rc2+).
> > 
> > There's no check on the connection_info->num_ports value when
> > iterating over ports.
> > 
> > usb 1-1: Handspring Visor / Palm OS: port 162, is for unknown use
> > usb 1-1: Handspring Visor / Palm OS: port 81, is for unknown use
> > ==================================================================
> > BUG: KASAN: slab-out-of-bounds in palm_os_3_probe+0x4e4/0x570
> > Read of size 1 at addr ffff8800686daa26 by task kworker/0:1/24

Thanks for the report, Andrey.

> Ah, nice catch, this bug is _old_, sorry about that.
> 
> The patch below should resolve this.  It looks bigger than it really is,
> as I'm just moving the error checking higher up in the function, and
> loosing an indentation for when there is invalid data.
> 
> Can you let me know if this solves the issue?

And thanks for fixing this up, Greg. Will you send a proper patch that I
can apply?

A couple of comments below.

> diff --git a/drivers/usb/serial/visor.c b/drivers/usb/serial/visor.c
> index 9f3317a940ef..18c31bae0e10 100644
> --- a/drivers/usb/serial/visor.c
> +++ b/drivers/usb/serial/visor.c
> @@ -338,47 +338,48 @@ static int palm_os_3_probe(struct usb_serial *serial,
>  		goto exit;
>  	}
>  
> -	if (retval == sizeof(*connection_info)) {
> -			connection_info = (struct visor_connection_info *)
> -							transfer_buffer;
> -
> -		num_ports = le16_to_cpu(connection_info->num_ports);
> -		for (i = 0; i < num_ports; ++i) {
> -			switch (
> -			   connection_info->connections[i].port_function_id) {
> -			case VISOR_FUNCTION_GENERIC:
> -				string = "Generic";
> -				break;
> -			case VISOR_FUNCTION_DEBUGGER:
> -				string = "Debugger";
> -				break;
> -			case VISOR_FUNCTION_HOTSYNC:
> -				string = "HotSync";
> -				break;
> -			case VISOR_FUNCTION_CONSOLE:
> -				string = "Console";
> -				break;
> -			case VISOR_FUNCTION_REMOTE_FILE_SYS:
> -				string = "Remote File System";
> -				break;
> -			default:
> -				string = "unknown";
> -				break;
> -			}
> -			dev_info(dev, "%s: port %d, is for %s use\n",
> -				serial->type->description,
> -				connection_info->connections[i].port, string);
> -		}
> +	if (retval != sizeof(*connection_info)) {
> +		retval = -EINVAL;

Since we're refusing to bind here -ENODEV may be more appropriate. And
I think a dev_err() (or dev_warn()) is warranted too.

> +		goto exit;

So far we have not been bailing probe when the returned connection-info size
wasn't the expected one (we'd only skip the dev_info() above). I'm sure
this is fine, but the tightened check could potentially cause issues if
there are devices returning additional fields.

>  	}
> -	/*
> -	* Handle devices that report invalid stuff here.
> -	*/
> +
> +	connection_info = (struct visor_connection_info *)transfer_buffer;
> +
> +	num_ports = le16_to_cpu(connection_info->num_ports);
> +
> +	/* Handle devices that report invalid stuff here. */
>  	if (num_ports == 0 || num_ports > 2) {
>  		dev_warn(dev, "%s: No valid connect info available\n",
>  			serial->type->description);
>  		num_ports = 2;
>  	}
>  
> +	for (i = 0; i < num_ports; ++i) {
> +		switch (
> +		   connection_info->connections[i].port_function_id) {

Perhaps you can merge the above two lines now while at it.

> +		case VISOR_FUNCTION_GENERIC:
> +			string = "Generic";
> +			break;
> +		case VISOR_FUNCTION_DEBUGGER:
> +			string = "Debugger";
> +			break;
> +		case VISOR_FUNCTION_HOTSYNC:
> +			string = "HotSync";
> +			break;
> +		case VISOR_FUNCTION_CONSOLE:
> +			string = "Console";
> +			break;
> +		case VISOR_FUNCTION_REMOTE_FILE_SYS:
> +			string = "Remote File System";
> +			break;
> +		default:
> +			string = "unknown";
> +			break;
> +		}
> +		dev_info(dev, "%s: port %d, is for %s use\n",
> +			serial->type->description,
> +			connection_info->connections[i].port, string);
> +	}
>  	dev_info(dev, "%s: Number of ports: %d\n", serial->type->description,
>  		num_ports);
>  

Thanks,
Johan

  parent reply	other threads:[~2017-10-03  9:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-28 17:57 usb/serial/visor: slab-out-of-bounds in palm_os_3_probe Andrey Konovalov
2017-09-29  8:37 ` Greg Kroah-Hartman
2017-09-29 11:35   ` Andrey Konovalov
2017-10-03  9:29   ` Johan Hovold [this message]
2017-10-04 14:40     ` Greg Kroah-Hartman
2017-10-19 11:19       ` Andrey Konovalov
2017-10-19 11:43         ` Greg Kroah-Hartman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171003092940.GA3404@localhost \
    --to=johan@kernel.org \
    --cc=andreyknvl@google.com \
    --cc=dvyukov@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=kcc@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=syzkaller@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).