Re: [PATCH net v2] isdn/capi: check message length in capi_write()

2019-09-07 Thread David Miller
From: Eric Biggers Date: Thu, 5 Sep 2019 19:36:37 -0700 > From: Eric Biggers > > syzbot reported: > > BUG: KMSAN: uninit-value in capi_write+0x791/0xa90 > drivers/isdn/capi/capi.c:700 > CPU: 0 PID: 10025 Comm: syz-executor379 Not tainted 4.20.0-rc7+ #2 > Hardware name: Google Goo

[PATCH net v2] isdn/capi: check message length in capi_write()

2019-09-05 Thread Eric Biggers
From: Eric Biggers syzbot reported: BUG: KMSAN: uninit-value in capi_write+0x791/0xa90 drivers/isdn/capi/capi.c:700 CPU: 0 PID: 10025 Comm: syz-executor379 Not tainted 4.20.0-rc7+ #2 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call

Re: [PATCH net] isdn/capi: check message length in capi_write()

2019-09-01 Thread David Miller
From: Eric Biggers Date: Sun, 1 Sep 2019 09:32:39 -0500 > From: Eric Biggers > > syzbot reported: > > BUG: KMSAN: uninit-value in capi_write+0x791/0xa90 > drivers/isdn/capi/capi.c:700 > CPU: 0 PID: 10025 Comm: syz-executor379 Not tainted 4.20.0-rc7+ #2 > Hardware name: Google Goo

[PATCH net] isdn/capi: check message length in capi_write()

2019-09-01 Thread Eric Biggers
From: Eric Biggers syzbot reported: BUG: KMSAN: uninit-value in capi_write+0x791/0xa90 drivers/isdn/capi/capi.c:700 CPU: 0 PID: 10025 Comm: syz-executor379 Not tainted 4.20.0-rc7+ #2 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call

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

2019-01-18 Thread 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 corre

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

2019-01-18 Thread 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

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

2019-01-18 Thread 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

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

2019-01-18 Thread 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

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

2019-01-10 Thread 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 bac

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

2019-01-10 Thread 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 t

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

2019-01-09 Thread 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

CHECK MESSAGE.

2016-05-12 Thread ttg_account4
I have profitable business opportunity i would like to introduce to you, reply with your name and your location. Best regards, Mr. Matthew Daniels.