[PATCH 1/2] Bluetooth: check message types in l2cap_get_conf_opt

[PATCH 1/2] Bluetooth: check message types in l2cap_get_conf_opt

[Greg Kroah-Hartman]

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;
 		*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;
 
 		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:
-- 
2.20.1

[PATCH 2/2] Bluetooth: check the buffer size for some messages before parsing

[Greg Kroah-Hartman]

The L2CAP_CONF_EFS and L2CAP_CONF_RFC messages can be sent from
userspace so their structure sizes need to be checked before parsing
them.

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 | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index 93daf94565cf..55e48e6efc2b 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -3361,7 +3361,8 @@ static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data
 			break;
 
 		case L2CAP_CONF_RFC:
-			if (olen == sizeof(rfc))
+			if ((olen == sizeof(rfc)) &&
+			    (endptr - ptr >= L2CAP_CONF_OPT_SIZE + sizeof(rfc)))
 				memcpy(&rfc, (void *) val, olen);
 			break;
 
@@ -3371,7 +3372,8 @@ static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data
 			break;
 
 		case L2CAP_CONF_EFS:
-			if (olen == sizeof(efs)) {
+			if ((olen == sizeof(efs)) &&
+			    (endptr - ptr >= L2CAP_CONF_OPT_SIZE + sizeof(efs))) {
 				remote_efs = 1;
 				memcpy(&efs, (void *) val, olen);
 			}
@@ -3576,7 +3578,8 @@ static int l2cap_parse_conf_rsp(struct l2cap_chan *chan, void *rsp, int len,
 			break;
 
 		case L2CAP_CONF_RFC:
-			if (olen == sizeof(rfc))
+			if ((olen == sizeof(rfc)) &&
+			    (endptr - ptr >= L2CAP_CONF_OPT_SIZE + sizeof(rfc)))
 				memcpy(&rfc, (void *)val, olen);
 
 			if (test_bit(CONF_STATE2_DEVICE, &chan->conf_state) &&
@@ -3596,7 +3599,8 @@ static int l2cap_parse_conf_rsp(struct l2cap_chan *chan, void *rsp, int len,
 			break;
 
 		case L2CAP_CONF_EFS:
-			if (olen == sizeof(efs)) {
+			if ((olen == sizeof(efs)) &&
+			    (endptr - ptr >= L2CAP_CONF_OPT_SIZE + sizeof(efs))) {
 				memcpy(&efs, (void *)val, olen);
 
 				if (chan->local_stype != L2CAP_SERV_NOTRAFIC &&
-- 
2.20.1

Re: [PATCH 2/2] Bluetooth: check the buffer size for some messages before parsing

[Greg Kroah-Hartman]

On Thu, Jan 10, 2019 at 07:29:17AM +0100, Greg Kroah-Hartman wrote:
> The L2CAP_CONF_EFS and L2CAP_CONF_RFC messages can be sent from
> userspace so their structure sizes need to be checked before parsing
> them.
> 
> Based on a patch from Ran Menscher.

Ran, can you verify if these two patches solve the problems you reported
or not?

thanks,

greg k-h

Re: [PATCH 1/2] Bluetooth: check message types in l2cap_get_conf_opt

[Joe Perches]

On Thu, 2019-01-10 at 07:28 +0100, Greg Kroah-Hartman wrote:
> 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.
[]
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
[]
> @@ -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;

err doesn't seem the right name for any of these as the
return is now negative only when there is an error.

Maybe opt_len instead.

>  	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;

especially as you subtract the positive return not
an error value.

>  
>  		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:

Re: [PATCH 1/2] Bluetooth: check message types in l2cap_get_conf_opt

[Greg Kroah-Hartman]

On Thu, Jan 10, 2019 at 01:02:09PM -0800, Joe Perches wrote:
> On Thu, 2019-01-10 at 07:28 +0100, Greg Kroah-Hartman wrote:
> > 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.
> []
> > diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> []
> > @@ -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;
> 
> err doesn't seem the right name for any of these as the
> return is now negative only when there is an error.
> 
> Maybe opt_len instead.

I was copying the style that was used in the rest of the file.  If the
maintainers want me to use a different name, I'll be glad to do so.  My
personal preference is just 'ret'.

> >  	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;
> 
> especially as you subtract the positive return not
> an error value.

True, 'ret' would be nicer, but again, I was trying to follow the file's
style.

thanks,

greg k-h

Re: [PATCH 1/2] Bluetooth: check message types in l2cap_get_conf_opt

[Marcel Holtmann]

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

Re: [PATCH 2/2] Bluetooth: check the buffer size for some messages before parsing

[Marcel Holtmann]

Hi Greg,

> The L2CAP_CONF_EFS and L2CAP_CONF_RFC messages can be sent from
> userspace so their structure sizes need to be checked before parsing
> them.

this message is confusing me. How can these be send from userspace?

> 
> 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 | 12 ++++++++----
> 1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> index 93daf94565cf..55e48e6efc2b 100644
> --- a/net/bluetooth/l2cap_core.c
> +++ b/net/bluetooth/l2cap_core.c
> @@ -3361,7 +3361,8 @@ static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data
> 			break;
> 
> 		case L2CAP_CONF_RFC:
> -			if (olen == sizeof(rfc))
> +			if ((olen == sizeof(rfc)) &&
> +			    (endptr - ptr >= L2CAP_CONF_OPT_SIZE + sizeof(rfc)))
> 				memcpy(&rfc, (void *) val, olen);

We don’t do ((x == y) && (..)) actually. Using (x == y && ..) is plenty.

> 			break;
> 
> @@ -3371,7 +3372,8 @@ static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data
> 			break;
> 
> 		case L2CAP_CONF_EFS:
> -			if (olen == sizeof(efs)) {
> +			if ((olen == sizeof(efs)) &&
> +			    (endptr - ptr >= L2CAP_CONF_OPT_SIZE + sizeof(efs))) {
> 				remote_efs = 1;
> 				memcpy(&efs, (void *) val, olen);
> 			}
> @@ -3576,7 +3578,8 @@ static int l2cap_parse_conf_rsp(struct l2cap_chan *chan, void *rsp, int len,
> 			break;
> 
> 		case L2CAP_CONF_RFC:
> -			if (olen == sizeof(rfc))
> +			if ((olen == sizeof(rfc)) &&
> +			    (endptr - ptr >= L2CAP_CONF_OPT_SIZE + sizeof(rfc)))
> 				memcpy(&rfc, (void *)val, olen);
> 
> 			if (test_bit(CONF_STATE2_DEVICE, &chan->conf_state) &&
> @@ -3596,7 +3599,8 @@ static int l2cap_parse_conf_rsp(struct l2cap_chan *chan, void *rsp, int len,
> 			break;
> 
> 		case L2CAP_CONF_EFS:
> -			if (olen == sizeof(efs)) {
> +			if ((olen == sizeof(efs)) &&
> +			    (endptr - ptr >= L2CAP_CONF_OPT_SIZE + sizeof(efs))) {
> 				memcpy(&efs, (void *)val, olen);
> 
> 				if (chan->local_stype != L2CAP_SERV_NOTRAFIC &&

Regards

Marcel

Re: [PATCH 1/2] Bluetooth: check message types in l2cap_get_conf_opt

[Greg Kroah-Hartman]

On Fri, Jan 18, 2019 at 10:35:30AM +0100, Marcel Holtmann wrote:
> 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.

/me hands you some \n characters...

Ok, will fix up.

> > 		*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.

So what should we do here?  We can't keep going as the size is
incorrect.

> 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.

It is?  Ok, if that's all that is needed, that's fine with me.  I was
just taking the patch from the original submitter, I don't understand
the bluetooth protocol at all :)

thanks,

greg k-h

Re: [PATCH 2/2] Bluetooth: check the buffer size for some messages before parsing

[Greg Kroah-Hartman]

On Fri, Jan 18, 2019 at 10:37:25AM +0100, Marcel Holtmann wrote:
> Hi Greg,
> 
> > The L2CAP_CONF_EFS and L2CAP_CONF_RFC messages can be sent from
> > userspace so their structure sizes need to be checked before parsing
> > them.
> 
> this message is confusing me. How can these be send from userspace?

So claimed the original reporter.  You have the information in your
inbox, is it incorrect?

> > 
> > 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 | 12 ++++++++----
> > 1 file changed, 8 insertions(+), 4 deletions(-)
> > 
> > diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
> > index 93daf94565cf..55e48e6efc2b 100644
> > --- a/net/bluetooth/l2cap_core.c
> > +++ b/net/bluetooth/l2cap_core.c
> > @@ -3361,7 +3361,8 @@ static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data
> > 			break;
> > 
> > 		case L2CAP_CONF_RFC:
> > -			if (olen == sizeof(rfc))
> > +			if ((olen == sizeof(rfc)) &&
> > +			    (endptr - ptr >= L2CAP_CONF_OPT_SIZE + sizeof(rfc)))
> > 				memcpy(&rfc, (void *) val, olen);
> 
> We don’t do ((x == y) && (..)) actually. Using (x == y && ..) is plenty.

Ick, ok, whatever, you all trust that your brains can remember C
priority levels, me, I trust ()...

I can fix this up to remove the extra (), but I would like _SOMEONE_ to
at least validate that this resolves the reported issues...

thanks,

greg k-h

Re: [PATCH 1/2] Bluetooth: check message types in l2cap_get_conf_opt

[Marcel Holtmann]

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.
> 
> /me hands you some \n characters...
> 
> Ok, will fix up.
> 
>>> 		*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.
> 
> So what should we do here?  We can't keep going as the size is
> incorrect.
> 
>> 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.
> 
> It is?  Ok, if that's all that is needed, that's fine with me.  I was
> just taking the patch from the original submitter, I don't understand
> the bluetooth protocol at all :)

I need to get my brain back into the nasty details of that protocol. I know for sure that just aborting is violating the handling of unknown options and that will fail qualification.

Let me look at how they managed to trick us.

Regards

Marcel

Re: [PATCH 2/2] Bluetooth: check the buffer size for some messages before parsing

[Marcel Holtmann]

Hi Greg,

>>> The L2CAP_CONF_EFS and L2CAP_CONF_RFC messages can be sent from
>>> userspace so their structure sizes need to be checked before parsing
>>> them.
>> 
>> this message is confusing me. How can these be send from userspace?
> 
> So claimed the original reporter.  You have the information in your
> inbox, is it incorrect?

I am pretty sure he meant that the remote attacker can control it from userspace. This is still a wire protocol and not some socket options.

>>> 
>>> 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 | 12 ++++++++----
>>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>> 
>>> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
>>> index 93daf94565cf..55e48e6efc2b 100644
>>> --- a/net/bluetooth/l2cap_core.c
>>> +++ b/net/bluetooth/l2cap_core.c
>>> @@ -3361,7 +3361,8 @@ static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data
>>> 			break;
>>> 
>>> 		case L2CAP_CONF_RFC:
>>> -			if (olen == sizeof(rfc))
>>> +			if ((olen == sizeof(rfc)) &&
>>> +			    (endptr - ptr >= L2CAP_CONF_OPT_SIZE + sizeof(rfc)))
>>> 				memcpy(&rfc, (void *) val, olen);
>> 
>> We don’t do ((x == y) && (..)) actually. Using (x == y && ..) is plenty.
> 
> Ick, ok, whatever, you all trust that your brains can remember C
> priority levels, me, I trust ()...
> 
> I can fix this up to remove the extra (), but I would like _SOMEONE_ to
> at least validate that this resolves the reported issues…

I need to reproduce this and then I can tell you.

Regards

Marcel

Re: [PATCH 1/2] Bluetooth: check message types in l2cap_get_conf_opt

[Marcel Holtmann]

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.
>> 
>> /me hands you some \n characters...
>> 
>> Ok, will fix up.
>> 
>>>> 		*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.
>> 
>> So what should we do here?  We can't keep going as the size is
>> incorrect.
>> 
>>> 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.
>> 
>> It is?  Ok, if that's all that is needed, that's fine with me.  I was
>> just taking the patch from the original submitter, I don't understand
>> the bluetooth protocol at all :)
> 
> I need to get my brain back into the nasty details of that protocol. I know for sure that just aborting is violating the handling of unknown options and that will fail qualification.
> 
> Let me look at how they managed to trick us.

actually this one was easy to understand. Just fixing was overly complicated by focusing on the default case and then punching in exceptions.

Since all option types are fixed size, I now added length checks to these. Patch has been posted.

Regards

Marcel

Re: [PATCH 2/2] Bluetooth: check the buffer size for some messages before parsing

[Marcel Holtmann]

Hi Greg,

>>>> The L2CAP_CONF_EFS and L2CAP_CONF_RFC messages can be sent from
>>>> userspace so their structure sizes need to be checked before parsing
>>>> them.
>>> 
>>> this message is confusing me. How can these be send from userspace?
>> 
>> So claimed the original reporter.  You have the information in your
>> inbox, is it incorrect?
> 
> I am pretty sure he meant that the remote attacker can control it from userspace. This is still a wire protocol and not some socket options.
> 
>>>> 
>>>> 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 | 12 ++++++++----
>>>> 1 file changed, 8 insertions(+), 4 deletions(-)
>>>> 
>>>> diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
>>>> index 93daf94565cf..55e48e6efc2b 100644
>>>> --- a/net/bluetooth/l2cap_core.c
>>>> +++ b/net/bluetooth/l2cap_core.c
>>>> @@ -3361,7 +3361,8 @@ static int l2cap_parse_conf_req(struct l2cap_chan *chan, void *data, size_t data
>>>> 			break;
>>>> 
>>>> 		case L2CAP_CONF_RFC:
>>>> -			if (olen == sizeof(rfc))
>>>> +			if ((olen == sizeof(rfc)) &&
>>>> +			    (endptr - ptr >= L2CAP_CONF_OPT_SIZE + sizeof(rfc)))
>>>> 				memcpy(&rfc, (void *) val, olen);
>>> 
>>> We don’t do ((x == y) && (..)) actually. Using (x == y && ..) is plenty.
>> 
>> Ick, ok, whatever, you all trust that your brains can remember C
>> priority levels, me, I trust ()...
>> 
>> I can fix this up to remove the extra (), but I would like _SOMEONE_ to
>> at least validate that this resolves the reported issues…
> 
> I need to reproduce this and then I can tell you.

so I think that just checking

	if (len < 0)
		break;

will just prevent any of these attacks. Since in theory you can also do this via the options, but then you can leak at max 2 octets.

I posted a simple patch for this. It would be however good if this gets verified that I understood the issues correctly.

Regards

Marcel