Am Montag, den 19.08.2019, 17:40 +0200 schrieb Andrey Konovalov:
>
> This implies that we can differentiate between different crashes. We
> can differentiate between different manifestations of crashes, but
> those can be caused by the same bug. I think we can remove the word
> "still" though, so
A malicious device can make the driver divide ny zero
with a nonsense maximum packet size.
V2: return a sensible error code
SIgned-off-by: Oliver Neukum
---
drivers/usb/class/usbtmc.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/class/usbtmc.c b/drivers/usb/class/usbtmc.c
Am Montag, den 19.08.2019, 17:50 -0700 schrieb syzbot:
> syzbot has found a reproducer for the following crash on:
Hi Bjørn,
taking you into CC as you are affected.
> HEAD commit:e06ce4da usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzz
Hello,
syzbot has tested the proposed patch but the reproducer still triggered
crash:
INFO: task hung in wdm_flush
INFO: task syz-executor.1:2841 blocked for more than 143 seconds.
Not tainted 5.3.0-rc5+ #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-ex
Oliver Neukum writes:
> diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
> index 1656f5155ab8..a341081a5f47 100644
> --- a/drivers/usb/class/cdc-wdm.c
> +++ b/drivers/usb/class/cdc-wdm.c
> @@ -588,14 +588,24 @@ static int wdm_flush(struct file *file, fl_owner_t id)
> {
>
Am Montag, den 19.08.2019, 17:50 -0700 schrieb syzbot:
> syzbot has found a reproducer for the following crash on:
Hi Bjørn,
taking you into CC as you are affected.
V2: fix logic bug
Regards
Oliver
> HEAD commit:e06ce4da usb-fuzzer: main usb gadget fuzzer driver
> g
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger
crash:
Reported-and-tested-by:
syzbot+d232cca6ec42c2edb...@syzkaller.appspotmail.com
Tested on:
commit: e06ce4da usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasa
Am Dienstag, den 20.08.2019, 12:44 +0200 schrieb Bjørn Mork :
> Oliver Neukum writes:
>
> > diff --git a/drivers/usb/class/cdc-wdm.c b/drivers/usb/class/cdc-wdm.c
> > index 1656f5155ab8..a341081a5f47 100644
> > --- a/drivers/usb/class/cdc-wdm.c
> > +++ b/drivers/usb/class/cdc-wdm.c
> > @@ -588,14
Am Montag, den 19.08.2019, 17:50 -0700 schrieb syzbot:
> syzbot has found a reproducer for the following crash on:
Hi Bjørn,
taking you into CC as you are affected.
V3: changes you suggested
> HEAD commit:e06ce4da usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger
crash:
Reported-and-tested-by:
syzbot+d232cca6ec42c2edb...@syzkaller.appspotmail.com
Tested on:
commit: e06ce4da usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasa
Am Montag, den 19.08.2019, 18:59 +0200 schrieb Andrey Konovalov:
> On Mon, Aug 19, 2019 at 6:18 PM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:d0847550 usb-fuzzer: main usb gadget fuzzer driver
> > git tree: https://github.com/google
Oliver Neukum writes:
> + wait_event(desc->wait,
> + /*
> + * needs both flags. We cannot do with one
> + * because resetting it would cause a race
> + * with write() yet we need to signal
> +
Hello,
syzbot tried to test the proposed patch but build/boot failed:
rs/staging/uwb/lc-dev.o
CC drivers/staging/uwb/lc-rc.o
CC drivers/staging/uwb/neh.o
CC drivers/video/fbdev/core/cfbfillrect.o
AR drivers/staging/wlan-ng/built-in.a
CC drivers/video/fbdev/core
Am Montag, den 19.08.2019, 18:59 +0200 schrieb Andrey Konovalov:
> On Mon, Aug 19, 2019 at 6:18 PM syzbot
> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:d0847550 usb-fuzzer: main usb gadget fuzzer driver
> > git tree: https://github.com/google
Hello,
syzbot has tested the proposed patch but the reproducer still triggered
crash:
WARNING in yurex_write/usb_submit_urb
[ cut here ]
URB 52a92140 submitted while active
WARNING: CPU: 1 PID: 3052 at drivers/usb/core/urb.c:362
usb_submit_urb+0x10c1/0x13b0 d
Am Dienstag, den 20.08.2019, 15:13 +0200 schrieb Bjørn Mork :
> Oliver Neukum writes:
>
> > + wait_event(desc->wait,
> > + /*
> > +* needs both flags. We cannot do with one
> > +* because resetting it would cause a race
> > +
From: Benjamin Herrenschmidt
[ Upstream commit 602fda17c7356bb7ae98467d93549057481d11dd ]
In some cases, one can get out of suspend with a reset or
a disconnect followed by a reconnect. Previously we would
leave a stale suspended flag set.
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: F
From: Benjamin Herrenschmidt
[ Upstream commit 4a56a478a525d6427be90753451c40e1327caa1a ]
If fsg_disable() and fsg_set_alt() are called too closely to each
other (for example due to a quick reset/reconnect), what can happen
is that fsg_set_alt sets common->new_fsg from an interrupt while
handle_
From: Benjamin Herrenschmidt
[ Upstream commit 4a56a478a525d6427be90753451c40e1327caa1a ]
If fsg_disable() and fsg_set_alt() are called too closely to each
other (for example due to a quick reset/reconnect), what can happen
is that fsg_set_alt sets common->new_fsg from an interrupt while
handle_
From: Hans Ulli Kroll
[ Upstream commit 5ffe59ef754cc39ab2f275dc277732f4 ]
On the Gemini SoC the FOTG2 stalls after port reset
so restart the HCD after each port reset.
Signed-off-by: Hans Ulli Kroll
Signed-off-by: Linus Walleij
Link: https://lore.kernel.org/r/20190810150458.817-1-lin
From: Benjamin Herrenschmidt
[ Upstream commit 602fda17c7356bb7ae98467d93549057481d11dd ]
In some cases, one can get out of suspend with a reset or
a disconnect followed by a reconnect. Previously we would
leave a stale suspended flag set.
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: F
From: Hans Ulli Kroll
[ Upstream commit 5ffe59ef754cc39ab2f275dc277732f4 ]
On the Gemini SoC the FOTG2 stalls after port reset
so restart the HCD after each port reset.
Signed-off-by: Hans Ulli Kroll
Signed-off-by: Linus Walleij
Link: https://lore.kernel.org/r/20190810150458.817-1-lin
From: Hans Ulli Kroll
[ Upstream commit 5ffe59ef754cc39ab2f275dc277732f4 ]
On the Gemini SoC the FOTG2 stalls after port reset
so restart the HCD after each port reset.
Signed-off-by: Hans Ulli Kroll
Signed-off-by: Linus Walleij
Link: https://lore.kernel.org/r/20190810150458.817-1-lin
From: Benjamin Herrenschmidt
[ Upstream commit 602fda17c7356bb7ae98467d93549057481d11dd ]
In some cases, one can get out of suspend with a reset or
a disconnect followed by a reconnect. Previously we would
leave a stale suspended flag set.
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: F
From: Benjamin Herrenschmidt
[ Upstream commit 602fda17c7356bb7ae98467d93549057481d11dd ]
In some cases, one can get out of suspend with a reset or
a disconnect followed by a reconnect. Previously we would
leave a stale suspended flag set.
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: F
From: Hans Ulli Kroll
[ Upstream commit 5ffe59ef754cc39ab2f275dc277732f4 ]
On the Gemini SoC the FOTG2 stalls after port reset
so restart the HCD after each port reset.
Signed-off-by: Hans Ulli Kroll
Signed-off-by: Linus Walleij
Link: https://lore.kernel.org/r/20190810150458.817-1-lin
From: Benjamin Herrenschmidt
[ Upstream commit 602fda17c7356bb7ae98467d93549057481d11dd ]
In some cases, one can get out of suspend with a reset or
a disconnect followed by a reconnect. Previously we would
leave a stale suspended flag set.
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: F
From: Benjamin Herrenschmidt
[ Upstream commit 4a56a478a525d6427be90753451c40e1327caa1a ]
If fsg_disable() and fsg_set_alt() are called too closely to each
other (for example due to a quick reset/reconnect), what can happen
is that fsg_set_alt sets common->new_fsg from an interrupt while
handle_
From: Hans Ulli Kroll
[ Upstream commit 5ffe59ef754cc39ab2f275dc277732f4 ]
On the Gemini SoC the FOTG2 stalls after port reset
so restart the HCD after each port reset.
Signed-off-by: Hans Ulli Kroll
Signed-off-by: Linus Walleij
Link: https://lore.kernel.org/r/20190810150458.817-1-lin
Am Montag, den 19.08.2019, 17:50 -0700 schrieb syzbot:
> syzbot has found a reproducer for the following crash on:
Hi Bjørn,
taking you into CC as you are affected.
V4:
> HEAD commit:e06ce4da usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb
Hello,
syzbot has tested the proposed patch and the reproducer did not trigger
crash:
Reported-and-tested-by:
syzbot+d232cca6ec42c2edb...@syzkaller.appspotmail.com
Tested on:
commit: e06ce4da usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasa
On Mon, 19 Aug 2019, Oliver Neukum wrote:
> Am Montag, den 19.08.2019, 07:48 -0700 schrieb syzbot:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:d0847550 usb-fuzzer: main usb gadget fuzzer driver
> > git tree: https://github.com/google/kasan.git usb-fuzzer
Oops, I replied to the wrong email message -- sorry. This was intended
to be about the problem with the yurex driver, not the iowarrior
driver.
Alan Stern
On Tue, 20 Aug 2019, Alan Stern wrote:
> On Mon, 19 Aug 2019, Oliver Neukum wrote:
>
> > Am Montag, den 19.08.2019, 07:48 -0700 schrieb sy
Am Dienstag, den 20.08.2019, 06:40 -0700 schrieb syzbot:
> Hello,
>
> syzbot has tested the proposed patch but the reproducer still triggered
> crash:
> WARNING in yurex_write/usb_submit_urb
It looks to me like we have two issues here. The driver is simply not
ready to deal with concurrent writ
Am Montag, den 19.08.2019, 10:17 -0400 schrieb Alan Stern:
> On Mon, 19 Aug 2019, Oliver Neukum wrote:
>
> > Am Freitag, den 16.08.2019, 13:10 -0400 schrieb Alan Stern:
> > > Oliver and Jiri:
> > >
> > > Why is there duplicated code in
> > > drivers/hid/usbhid/hiddev.c:hiddev_open()?
> > >
> > >
Am Dienstag, den 20.08.2019, 10:18 -0400 schrieb Alan Stern:
> On Mon, 19 Aug 2019, Oliver Neukum wrote:
>
> > Am Montag, den 19.08.2019, 07:48 -0700 schrieb syzbot:
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:d0847550 usb-fuzzer: main usb gadget fuz
Am Dienstag, den 20.08.2019, 16:38 +0200 schrieb Oliver Neukum:
> Am Dienstag, den 20.08.2019, 10:18 -0400 schrieb Alan Stern:
> > On Mon, 19 Aug 2019, Oliver Neukum wrote:
> >
> > > Am Montag, den 19.08.2019, 07:48 -0700 schrieb syzbot:
> > > > Hello,
> > > >
> > > > syzbot found the following c
On Tue, 20 Aug 2019, Oliver Neukum wrote:
> Am Dienstag, den 20.08.2019, 10:18 -0400 schrieb Alan Stern:
> > On Mon, 19 Aug 2019, Oliver Neukum wrote:
> >
> > > Am Montag, den 19.08.2019, 07:48 -0700 schrieb syzbot:
> > > > Hello,
> > > >
> > > > syzbot found the following crash on:
> > > >
> >
On Mon, 19 Aug 2019, Andrea Vai wrote:
> Hi Alan,
> I attach the two traces, collected as follows:
>
> - start the trace;
> - wait 10 seconds;
> - plug the drive;
> - wait 5 seconds;
> - mount the drive;
> - wait 5 seconds;
> - copy a 500 byte file;
> - wait 5 seconds;
> - unmount the drive;
>
From: "Yavuz, Tuba"
cherry pick from commit 7fafcfdf6377b18b2a726ea554d6e593ba44349f
("USB: gadget: f_midi: fixing a possible double-free in f_midi")
Removing 'return err;' from conflict.
It looks like there is a possibility of a double-free vulnerability on an
error path of the f_midi_set_alt f
The syzbot fuzzer found a general protection fault in the HID subsystem:
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: [#1] SMP KASAN
CPU: 0 PID: 3715 Comm: syz-executor.3 Not tainted 5.2.0-rc6+ #15
Hardware nam
On Tue, Aug 20, 2019 at 10:45:13AM -0700, Mark Salyzyn wrote:
> From: "Yavuz, Tuba"
>
> cherry pick from commit 7fafcfdf6377b18b2a726ea554d6e593ba44349f
> ("USB: gadget: f_midi: fixing a possible double-free in f_midi")
> Removing 'return err;' from conflict.
>
> It looks like there is a possibi
On 8/20/19 1:15 PM, Greg Kroah-Hartman wrote:
No signed-off-by from you?
Anyway, this is already in the 4.4.y queue and will be in the next
release.
thanks,
greg k-h
Ok, thanks! I will stand down.
-- Mark
In recent testing of a Dell Universal Dock D6000, I found that MAC address pass
through is not supported in the Linux drivers. However, this same device is
supported in Windows 10 (Pro) on my personal computer, in as much as I was able
to tell Windows to assign a new MAC address of my choosing,
The core USB driver message.c is missing get/set address functionality
that stops ifconfig from being able to push MAC addresses out to USB
based ethernet devices. Without this functionality, some USB devices
stop responding to ethernet packets when using ifconfig to change MAC
addresses. This ha
This patch adds support for pushing a MAC address out to USB based
ethernet controllers driven by cdc_ncm. With this change, ifconfig can
now set the device's MAC address. For example, the Dell Universal Dock
D6000 is driven by cdc_ncm. The D6000 can now have its MAC address set
by ifconfig, as
This change moves ACPI functionality out of the Realtek r8152 driver to
its own source and header file, making it available to other drivers as
needed now and into the future. At the time this ACPI snippet was
introduced in 2016, only the Realtek driver made use of it in support of
Dell's enterpri
This change adds support to cdc_ncm for ACPI MAC address pass through
functionality that also exists in the Realtek r8152 driver. This is in
support of Dell's Universal Dock D6000, to give it the same feature
capability as is currently available in Windows and advertized on Dell's
product web site
On Tue, Aug 20, 2019 at 10:18:42PM +, charles.h...@dellteam.com wrote:
> The core USB driver message.c is missing get/set address functionality
> that stops ifconfig from being able to push MAC addresses out to USB
> based ethernet devices. Without this functionality, some USB devices
> stop r
On Tue, Aug 20, 2019 at 10:18:42PM +, charles.h...@dellteam.com wrote:
> +int usb_get_address(struct usb_device *dev, unsigned char * mac)
> +{
> + int ret = -ENOMEM;
> + unsigned char *tbuf = kmalloc(256, GFP_NOIO);
On a technical level, why are you asking for 256 bytes here, and in t
On Tue, Aug 20, 2019 at 10:18:42PM +, charles.h...@dellteam.com wrote:
> The core USB driver message.c is missing get/set address functionality
> that stops ifconfig from being able to push MAC addresses out to USB
> based ethernet devices. Without this functionality, some USB devices
> stop r
On Tue, Aug 20, 2019 at 10:22:18PM +, charles.h...@dellteam.com wrote:
> This change moves ACPI functionality out of the Realtek r8152 driver to
> its own source and header file, making it available to other drivers as
> needed now and into the future. At the time this ACPI snippet was
> intro
Silence the following fall-through warning by adding a break statement:
drivers/usb/gadget/udc/lpc32xx_udc.c:2230:3: warning: this statement may
fall through [-Wimplicit-fallthrough=]
Signed-off-by: Gustavo A. R. Silva
---
drivers/usb/gadget/udc/lpc32xx_udc.c | 2 +-
1 file changed, 1 insertion
According to xHCI 1.1 CH4.19.4 Port Power:
While Chip Hardware Reset or HCRST is asserted,
the value of PP is undefined. If the xHC supports
power switches (PPC = ‘1’) then VBus may be deasserted
during this time. PP (and VBus) shall be enabled immediately
up
Hi folks !
It seems that f_mass_storage duplicates (well maybe predates too..) a
lot of what's in drivers/target.
Anybody working on implementing a new version of f_mass_storage that
is layered upon drivers/target instead ? That would bring quite a lot
of additional functionality.
If not, I migh
On Mon, Aug 19, 2019 at 10:14:25AM -0400, Alan Stern wrote:
> Let's bring this to the attention of some more people.
>
> It looks like the bug that was supposed to be fixed by commit
> d74ffae8b8dd ("usb-storage: Add a limitation for
> blk_queue_max_hw_sectors()"), which is part of 5.2.5, but appa
On Tue, Aug 20, 2019 at 09:23:26AM +0200, Christoph Hellwig wrote:
> On Mon, Aug 19, 2019 at 10:14:25AM -0400, Alan Stern wrote:
> > Let's bring this to the attention of some more people.
> >
> > It looks like the bug that was supposed to be fixed by commit
> > d74ffae8b8dd ("usb-storage: Add a li
57 matches
Mail list logo
