linux-bluetooth.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcel Holtmann <marcel@holtmann.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Johan Hedberg <johan.hedberg@gmail.com>,
	linux-bluetooth@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 1/2] Bluetooth: check message types in l2cap_get_conf_opt
Date: Fri, 18 Jan 2019 10:35:30 +0100	[thread overview]
Message-ID: <E3A13BCC-C138-4E76-A379-A32CBB9AFF26@holtmann.org> (raw)
In-Reply-To: <20190110062833.GA15047@kroah.com>

Hi Greg,

> l2cap_get_conf_opt can handle a "default" message type, but it needs to
> be verified that it really is the correct type (CONF_EFS or CONF_RFC)
> before passing it back to the caller.  To do this we need to check the
> return value of this call now and handle the error correctly up the
> stack.
> 
> Based on a patch from Ran Menscher.
> 
> Reported-by: Ran Menscher <ran.menscher@karambasecurity.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> net/bluetooth/l2cap_core.c | 25 +++++++++++++++++++------
> 1 file changed, 19 insertions(+), 6 deletions(-)
> 
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 2a7fb517d460..93daf94565cf 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -2980,6 +2980,10 @@ static inline int l2cap_get_conf_opt(void **ptr, int *type, int *olen,
> 		break;
> 
> 	default:
> +		/* Only CONF_EFS and CONF_RFC are allowed here */
> +		if ((opt->type != L2CAP_CONF_EFS) &&
> +		    (opt->type != L2CAP_CONF_RFC))
> +			return -EPROTO;

after re-reading that specification, this also includes CONF_QOS since that is a multi-field variable as well. Even if we currently don’t act on that field, we need to accept it being send.

> 		*val = (unsigned long) opt->val;
> 		break;
> 	}
> @@ -3324,7 +3328,7 @@ static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data
> 	void *endptr = data + data_size;
> 	void *req = chan->conf_req;
> 	int len = chan->conf_len;
> -	int type, hint, olen;
> +	int type, hint, olen, err;
> 	unsigned long val;
> 	struct l2cap_conf_rfc rfc = { .mode = L2CAP_MODE_BASIC };
> 	struct l2cap_conf_efs efs;
> @@ -3336,7 +3340,10 @@ static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data
> 	BT_DBG("chan %p", chan);
> 
> 	while (len >= L2CAP_CONF_OPT_SIZE) {
> -		len -= l2cap_get_conf_opt(&req, &type, &olen, &val);
> +		err = l2cap_get_conf_opt(&req, &type, &olen, &val);
> +		if (err < 0)
> +			return err;
> +		len -= err;

We need to handle not yet known options correctly since otherwise we are breaking forwards compatibility if newer specifications introduce new parameters. So just returning with an error here is not acceptable. It will fail qualification test cases.

Don’t we rather have proper length checks in l2cap_parse_conf_{req,rsp} instead of doing this. I think your second patch is enough.

> 
> 		hint  = type & L2CAP_CONF_HINT;
> 		type &= L2CAP_CONF_MASK;
> @@ -3539,7 +3546,7 @@ static int l2cap_parse_conf_rsp(struct l2cap_chan *chan, void *rsp, int len,
> 	struct l2cap_conf_req *req = data;
> 	void *ptr = req->data;
> 	void *endptr = data + size;
> -	int type, olen;
> +	int type, olen, err;
> 	unsigned long val;
> 	struct l2cap_conf_rfc rfc = { .mode = L2CAP_MODE_BASIC };
> 	struct l2cap_conf_efs efs;
> @@ -3547,7 +3554,10 @@ static int l2cap_parse_conf_rsp(struct l2cap_chan *chan, void *rsp, int len,
> 	BT_DBG("chan %p, rsp %p, len %d, req %p", chan, rsp, len, data);
> 
> 	while (len >= L2CAP_CONF_OPT_SIZE) {
> -		len -= l2cap_get_conf_opt(&rsp, &type, &olen, &val);
> +		err = l2cap_get_conf_opt(&rsp, &type, &olen, &val);
> +		if (err < 0)
> +			return err;
> +		len -= err;
> 
> 		switch (type) {
> 		case L2CAP_CONF_MTU:
> @@ -3707,7 +3717,7 @@ void __l2cap_connect_rsp_defer(struct l2cap_chan *chan)
> 
> static void l2cap_conf_rfc_get(struct l2cap_chan *chan, void *rsp, int len)
> {
> -	int type, olen;
> +	int type, olen, err;
> 	unsigned long val;
> 	/* Use sane default values in case a misbehaving remote device
> 	 * did not send an RFC or extended window size option.
> @@ -3727,7 +3737,10 @@ static void l2cap_conf_rfc_get(struct l2cap_chan *chan, void *rsp, int len)
> 		return;
> 
> 	while (len >= L2CAP_CONF_OPT_SIZE) {
> -		len -= l2cap_get_conf_opt(&rsp, &type, &olen, &val);
> +		err = l2cap_get_conf_opt(&rsp, &type, &olen, &val);
> +		if (err < 0)
> +			return;
> +		len -= err;
> 
> 		switch (type) {
> 		case L2CAP_CONF_RFC:

Regards

Marcel


  parent reply	other threads:[~2019-01-18  9:35 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-10  6:28 Greg Kroah-Hartman
2019-01-10  6:29 ` [PATCH 2/2] Bluetooth: check the buffer size for some messages before parsing Greg Kroah-Hartman
2019-01-10  6:30   ` Greg Kroah-Hartman
2019-01-18  9:37   ` Marcel Holtmann
2019-01-18 10:21     ` Greg Kroah-Hartman
2019-01-18 11:11       ` Marcel Holtmann
2019-01-18 12:44         ` Marcel Holtmann
2019-01-10 21:02 ` [PATCH 1/2] Bluetooth: check message types in l2cap_get_conf_opt Joe Perches
2019-01-11  5:32   ` Greg Kroah-Hartman
2019-01-18  9:35 ` Marcel Holtmann [this message]
2019-01-18 10:19   ` Greg Kroah-Hartman
2019-01-18 11:09     ` Marcel Holtmann
2019-01-18 12:08       ` Marcel Holtmann

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=E3A13BCC-C138-4E76-A379-A32CBB9AFF26@holtmann.org \
    --to=marcel@holtmann.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --subject='Re: [PATCH 1/2] Bluetooth: check message types in l2cap_get_conf_opt' \
    /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

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox