Am Mittwoch, den 09.10.2019, 11:57 -0700 schrieb Kenneth:
> Hi,
>
> I was informed that there were bug fixes for the Etron EJ168A controller in
> kernel 5.2 and 5.3
>
> While I can read most USB sticks, if I connect an android phone to this port,
> applications hang trying to access the phone.
Am Mittwoch, den 09.10.2019, 09:27 -0400 schrieb Adam Bennett:
> On 10/9/19 4:53 AM, Bjørn Mork wrote:
> > This warning means that the gadget doesn't accept the packets we send
> > it. There isn't much the host can do about that, except dropping
> > packets on the floor. Which is why the warning
t; Cc: stable
> Reported-by: syzbot+5630ca7c3b2be5c9d...@syzkaller.appspotmail.com
> Signed-off-by: Johan Hovold
Acked-by: Oliver Neukum
Am Montag, den 16.09.2019, 21:03 +1000 schrieb Rhys Kidd:
> The Myriad ma24xx in USB Intel Neural Compute Stick and Intel Neural
> Compute Stick 2 provides an API to accelerate AI inference calculations
> on the dedicated SHAVE VLIW vector co-processors, which are orchestrated
> by one or more LEON
Am Donnerstag, den 12.09.2019, 07:09 + schrieb Joakim Tjernlund:
> On Wed, 2019-09-11 at 20:27 +0200, Oliver Neukum wrote:
> > Am Mittwoch, den 11.09.2019, 14:34 + schrieb Joakim Tjernlund:
> > > On Wed, 2019-09-11 at 16:22 +0200, Oliver Neukum wrote:
> > > >
Am Mittwoch, den 11.09.2019, 14:34 + schrieb Joakim Tjernlund:
> On Wed, 2019-09-11 at 16:22 +0200, Oliver Neukum wrote:
> > CAUTION: This email originated from outside of the organization. Do not
> > click links or open attachments unless you recognize the sender and know
>
Am Mittwoch, den 11.09.2019, 12:39 + schrieb Joakim Tjernlund:
> Every now and then my ttyACM0 hangs up or sends a BREAK char to my device.
> I am trying to make ttyACM ignore incoming(over USB) and not emit
> any BREAK automatically using termios (IGN_BRK) but that does not make a
> differenc
Am Mittwoch, den 04.09.2019, 19:10 +0200 schrieb Julian Sikorski:
>
>
> Moreover, does this matter that the two Read Capacity errors only appear
> after the device is disconnected?
Hi,
yes it does. However, it didn't in the first log I looked at.
Could you check whether the command the failure
rence between Usb-storage
and UAS is the order in which the 10 and 16 versions are tried.
The attached patches introduce a quirk to reverse the order
for this particular device under UAS. Could you try them?
Regards
Oliver
From 883355951a23d3c4b3c14ca0540972739ae6ffb2 Mon Se
e same feature
> capability as is currently available in Windows and advertized on Dell's
> product web site.
>
> Signed-off-by: Charles Hyde
> Cc: Mario Limonciello
> Cc: Oliver Neukum
> Cc: Rafael J. Wysocki
> Cc: Len Brown
> Cc: linux-usb@vger.kernel.org
> Cc: li
Am Freitag, den 30.08.2019, 19:37 + schrieb
charles.h...@dellteam.com:
> 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
(). There is no point in ever
clearing WDM_IN_USE, as no further writes make sense.
The issue is as old as the driver.
Fixes: afba937e540c9 ("USB: CDC WDM driver")
Reported-by: syzbot+d232cca6ec42c2edb...@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum
---
drivers/usb/class/cdc-
Am Freitag, den 23.08.2019, 22:26 + schrieb
charles.h...@dellteam.com:
> 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
Am Freitag, den 23.08.2019, 16:21 +0200 schrieb Julian Sikorski:
>
> I did some further digging regarding whether this is a regression: the
> quirk file on the laptop is from 15 July 2014. The machine is from ca.
> May 2011. Looking through my earlier posts to linux-usb it appears that
> the addit
Am Freitag, den 23.08.2019, 15:31 +0200 schrieb Julian Sikorski:
> it appears that lacie rugged usb3-fw is not compatible with UAS.
> I have just connected my few years old Lacie Rugged USB3-FW to my new
> desktop PC to see if the backups I have been creating on the laptop can
> actually be restore
https://github.com/google/kasan.git eea39f24
>From 4f21b5aabc448719aa612b9359d90a178cb485d8 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Thu, 22 Aug 2019 16:37:33 +0200
Subject: [PATCH] rtl8712: fix race between firmware failing to load and
disconnect
We have to wait for the attempt to lo
Am Mittwoch, den 07.08.2019, 16:03 +0200 schrieb Andrey Konovalov:
I may offer a preliminary analysis.
Regards
Oliver
> On Fri, Apr 12, 2019 at 1:32 PM Andrey Konovalov
> wrote:
> >
> > On Fri, Apr 12, 2019 at 1:29 AM syzbot
> > wrote:
> > >
> > > syzbot has found a
Am Donnerstag, den 22.08.2019, 21:23 +0800 schrieb Kai-Heng Feng:
> at 18:38, Oliver Neukum wrote:
> > Well, sort of. The USB spec merely states how to enter and exit
> > a suspended state and that device state must not be lost.
> > It does not tell you what a suspended devi
Am Donnerstag, den 22.08.2019, 18:04 +0800 schrieb Kai-Heng Feng:
> Hi Oliver,
>
> at 17:45, Oliver Neukum wrote:
>
> > Am Donnerstag, den 22.08.2019, 17:17 +0800 schrieb Kai-Heng Feng:
> > > The optical sensor of the mouse gets turned off when it's runtime
>
Am Donnerstag, den 22.08.2019, 17:17 +0800 schrieb Kai-Heng Feng:
> The optical sensor of the mouse gets turned off when it's runtime
> suspended, so moving the mouse can't wake the mouse up, despite that
> USB remote wakeup is successfully set.
>
> Introduce a new quirk to prevent the mouse from
Am Mittwoch, den 21.08.2019, 23:35 + schrieb
charles.h...@dellteam.com:
>
> >
> > This is a VERY cdc-net-specific function. It is not a "generic" USB
> > function at all. Why does it belong in the USB core? Shouldn't it live
> > in the code that handles the other cdc-net-specific logic?
>
Am Dienstag, den 20.08.2019, 22:15 + schrieb
charles.h...@dellteam.com:
> In recent testing of a Dell Universal Dock D6000, I found that MAC address
> pass through is not supported in the Linux drivers.
Hi,
thank you for writing this code. It adds cool functionality.
There are, however, a fe
AC to default.
You need to reset it to the user's setting in reset_resume().
Please add that to usbnet.
>
> Signed-off-by: Charles Hyde
> Cc: Mario Limonciello
> Cc: Oliver Neukum
> Cc: net...@vger.kernel.org
> Cc: linux-usb@vger.kernel.org
> ---
> drivers/net/usb
Am Dienstag, den 20.08.2019, 22:18 + schrieb
charles.h...@dellteam.com:
> The core USB driver message.c is missing get/set address functionality
This should go into usbnet. The CDC parser is where it is because
it is needed for serial and network devices. As serial devices
do not have a MAC, t
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,
> &g
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:
> > >
> >
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
> &
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
006dcc28 RCX: 00447029
> RDX: RSI: RDI: 0004
> RBP: 006dcc20 R08: R09:
> R10: R11: 0246 R12: 006dcc2c
> R13: 2000 R14: 004af170
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
> > +* becaus
PORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+0e7b6b6001ca8ed65...@syzkaller.appspotmail.com
> >
#syz test: https://github.com/google/kasan.git d0847550
>From 8d100dc018a0c1ba9c25dc5a222527ea4748f4c7 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Da
PORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+0e7b6b6001ca8ed65...@syzkaller.appspotmail.com
> >
#syz test: https://github.com/google/kasan.git d0847550
>From eeb920819e1d98e631fb78fe849649dc8dd6eb1b Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Da
NECTED in flush(). There is no point in ever
clearing WDM_IN_USE, as no further writes make sense.
The issue is as old as the driver.
Fixes: afba937e540c9 ("USB: CDC WDM driver")
Reported-by: syzbot+d232cca6ec42c2edb...@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum
---
drive
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
> > +++
6dcc2c
> R13: 2000 R14: 004af170 R15: 03e8
#syz test: https://github.com/google/kasan.git e06ce4da
>From 8d0c7a38b1a4883e7bdab76b06a9e564fc466506 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Tue, 20 Aug 2019 12:08:19 +0200
Subject: [PATCH] USB: cdc-w
6dcc28 RCX: 00447029
> RDX: RSI: RDI: 0004
> RBP: 006dcc20 R08: R09:
> R10: R11: 0246 R12: 006dcc2c
> R13: 2000 R14: 004af170 R15:
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: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
tps://github.com/google/kasan.git d0847550
From 43c4270a424052dcb168a0fea5a9ad89778eadc7 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Mon, 19 Aug 2019 17:22:53 +0200
Subject: [PATCH] Revert "usb: iowarrior: fix deadlock on disconnect"
This reverts commit aa40cfb4d2f134322a782
Am Montag, den 19.08.2019, 15:18 +0200 schrieb Andrey Konovalov:
> On Mon, Aug 19, 2019 at 3:09 PM Oliver Neukum wrote:
> >
> > Am Montag, den 19.08.2019, 14:43 +0200 schrieb Andrey Konovalov:
> > > On Mon, Aug 19, 2019 at 2:37 PM Oliver Neukum wrote:
> > > >
Am Montag, den 19.08.2019, 14:43 +0200 schrieb Andrey Konovalov:
> On Mon, Aug 19, 2019 at 2:37 PM Oliver Neukum wrote:
> > The original error was a divide by zero. The first fix fixed that
> > but still another error showed up. If I propose a fix there are
> > other pos
Am Montag, den 19.08.2019, 14:17 +0200 schrieb Andrey Konovalov:
> On Thu, Aug 15, 2019 at 3:31 PM Oliver Neukum wrote:
> >
> > Am Mittwoch, den 14.08.2019, 06:38 -0700 schrieb syzbot:
> > > syzbot has tested the proposed patch but the reproducer still triggered
>
Am Donnerstag, den 15.08.2019, 12:02 + schrieb Schmid, Carsten :
> > > I don't think its a regression.
> >
> > It would be better to know than to assume.
> >
>
> Happens with kernel 4.14.102 also, not only with 4.14.129.
> Looks more HW related.
>
> >
> > > Is there something i can do to
sts the code in those two routines to do just that. It
> > > > also relies on the fact that the probe and disconnect routines are
> > > > protected by the device mutex, so the initial test of rio->present
> > > > needs no extra locking.
> > > >
&
Am Freitag, den 16.08.2019, 23:18 +0100 schrieb Jonathan Bell:
> On Thu, Aug 15, 2019 at 3:52 PM Oliver Neukum wrote:
> > That is an accident waiting to happen. Please make a patch using
> > a bounce buffer allocated with knalloc() in
> > drivers/media/usb/uvc/uvc_ctrl.c:uv
runs.
>
> Even more disturbing, why is one of these code sections protected by a
> mutex and the other not?
I suppose the comment I made back then:
079034073faf9 drivers/hid/usbhid/hiddev.c (Oliver Neukum
2008-12-16 10:55:15 +0100 268)* no need for locking because the
Am Donnerstag, den 15.08.2019, 12:41 +0100 schrieb Jonathan Bell:
> On Thu, Aug 15, 2019 at 11:55 AM Oliver Neukum wrote:
> >
> > Am Mittwoch, den 14.08.2019, 16:59 +0100 schrieb Jonathan Bell:
> > > As reported by one of our users here:
> > > https://github.
//github.com/google/kasan.git d0847550
>From df64f5cd2e6a9b43c75bb7e3276b8805a225db75 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Wed, 14 Aug 2019 15:21:41 +0200
Subject: [PATCH] usbtmc: more sanity checking for packet size
A malicious device can make the driver divide ny zero
wi
Am Mittwoch, den 14.08.2019, 06:38 -0700 schrieb syzbot:
> syzbot has tested the proposed patch but the reproducer still triggered
> crash:
> KASAN: use-after-free Read in usbtmc_disconnect
I am afraid that is a difficiency in KASAN that should be fixed.
Is the class of the error compared if I l
Am Mittwoch, den 14.08.2019, 16:59 +0100 schrieb Jonathan Bell:
> As reported by one of our users here:
> https://github.com/raspberrypi/linux/issues/3148
>
> There is a bug when the dwc2 core receives USB data packets that are
> between 1 and 4 bytes in length - 4 bytes are always written to memo
Am Mittwoch, den 14.08.2019, 12:41 -0500 schrieb Wenwen Wang:
> In usbnet_start_xmit(), 'urb->sg' is allocated through kmalloc_array() by
> invoking build_dma_sg(). Later on, if 'CONFIG_PM' is defined and the if
> branch is taken, the execution will go to the label 'deferred'. However,
> 'urb->sg'
https://github.com/google/kasan.git d0847550
>From 5fa900e86e57d92a0b23a1a60ff4f4f13e997a93 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Wed, 14 Aug 2019 15:21:41 +0200
Subject: [PATCH] usbtmc: more sanity checking for packet size
A malicious device can make the driver divide ny zero
wit
Am Mittwoch, den 14.08.2019, 08:56 + schrieb Schmid, Carsten :
> > This is on a lower layer than ax88179. This comes from xhci_hcd.
> > Is this a regression?
> >
>
> I don't think its a regression.
It would be better to know than to assume.
> Is there something i can do to force an error
Am Dienstag, den 13.08.2019, 17:08 +0200 schrieb Andrey Konovalov:
> On Tue, Aug 13, 2019 at 2:43 PM Oliver Neukum wrote:
> >
> >
> > Hi,
> >
> > this looks like a false positive to me.
> > The offending code is likely this:
> >
> >
Am Mittwoch, den 14.08.2019, 08:17 + schrieb Schmid, Carsten :
> [Resend - had mailer errors ]
>
> Hi Florian,
>
> today i have seen a strange behaviour of two D-Link DUB-1312 adapters (same
> Revision A1).
> Plugging them into the same port (!) on my device one of them is recognized
> as
Am Dienstag, den 13.08.2019, 14:42 +0200 schrieb Andrey Konovalov:
> >
[..]
> On Thu, Aug 8, 2019 at 4:00 PM Alan Stern wrote:
> > Ah, that looks right, thank you. The patch worked correctly -- good
> > work Oliver!
>
> Great! Just a reminder to submit the fix :)
I did last week:
https://pa
Am Freitag, den 09.08.2019, 01:48 -0700 schrieb syzbot:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:beaab8a3 fix KASAN build
> git tree: kmsan
[..]
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x191/0x1f0 lib/dump_stack.c:113
> kmsa
A few checks checked for the size of the pointer to a structure
instead of the structure itself. Copy & paste issue presumably.
Fixes: e4c6fb7794982 ("usbnet: move the CDC parser into USB core")
Reported-by: syzbot+45a53506b65321c1f...@syzkaller.appspotmail.com
Signed-off-by:
Am Montag, den 12.08.2019, 14:27 +0200 schrieb Andrey Konovalov:
> On
> This one is funny, we do sizeof(struct usb_cdc_mdlm_desc *) instead of
> sizeof(struct usb_cdc_mdlm_desc) and the same for
> usb_cdc_mdlm_detail_desc in cdc_parse_cdc_header().
You are right. Old copy & paste error presumably.
Am Dienstag, den 13.08.2019, 12:26 +0800 schrieb Hillf Danton:
> [respin with the mess in Cc list cleaned up]
> Followup of commit e3e14de50dff ("HID: fix start/stop cycle in usbhid driver")
>
> --- a/drivers/hid/usbhid/hid-core.c
> +++ b/drivers/hid/usbhid/hid-core.c
> @@ -1214,6 +1214,8 @@ stat
st: https://github.com/google/kasan.git e96407b4
>From 700a7cc270f06c6e9881f49e36a7722d16ee37db Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Thu, 8 Aug 2019 15:08:48 +0200
Subject: [PATCH] HID: use strnlen to not walk through kernel memory
If a device sets no phy name we must limit the range
for
Am Montag, den 12.08.2019, 15:24 +0800 schrieb Rick Tseng:
> From: Rick
>
> NVIDIA 3.1 xHCI card would lose power when moving power state into D3Cold.
> Thus we need to wait CNR bit to clear when xhci resmue as xhci init.
Should any controller have CNR set? Why is this specific to a vendor?
Am Donnerstag, den 08.08.2019, 20:54 +0200 schrieb Andrey Konovalov:
> On Thu, Jul 25, 2019 at 5:09 PM Alan Stern wrote:
> >
> > On Thu, 25 Jul 2019, Oliver Neukum wrote:
> >
> > > Am Mittwoch, den 24.07.2019, 17:02 -0400 schrieb Alan Stern:
> > > >
ned-off-by: Oliver Neukum
---
drivers/usb/class/cdc-acm.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/class/cdc-acm.c b/drivers/usb/class/cdc-acm.c
index 183b41753c98..62f4fb9b362f 100644
--- a/drivers/usb/class/cdc-acm.c
+++ b/drivers/usb/class
Am Donnerstag, den 08.08.2019, 10:59 +0100 schrieb Russell King - ARM
Linux admin:
> On Thu, Aug 08, 2019 at 10:58:11AM +0200, Greg KH wrote:
> > But the main issue here is what exactly is this "fixing"? What is wrong
> > with the existing code that non-x86 systems have such a problem with?
> > Sh
This reverts commit d710734b06770814de2bfa2819420fb5df7f3a81.
This simplification causes a deadlock.
Reported-by: syzbot+7bbcbe9c9ff0cd495...@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum
---
drivers/usb/misc/rio500.c | 43 +++
1 file changed, 27
964bf6c71a...@syzkaller.appspotmail.com
Signed-off-by: Oliver Neukum
---
drivers/usb/misc/iowarrior.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/misc/iowarrior.c b/drivers/usb/misc/iowarrior.c
index ba05dd80a020..f5bed9f29e56 100644
--- a/drivers/usb/misc/iowarri
> process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
> > worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
> > kthread+0x313/0x420 kernel/kthread.c:253
> > ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352
> > Kernel Offset: disabled
> > Rebooting in 8640
Am Dienstag, den 06.08.2019, 14:50 +0200 schrieb Andrey Konovalov:
> On Tue, Aug 6, 2019 at 2:36 PM Oliver Neukum wrote:
> >
> > Am Donnerstag, den 01.08.2019, 14:47 -0400 schrieb Alan Stern:
> > >
> > > I think this must be caused by an unbalanced refcount. T
Am Dienstag, den 06.08.2019, 15:13 -0400 schrieb Alan Stern:
> On Thu, 1 Aug 2019, syzbot wrote:
>
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:7f7867ff usb-fuzzer: main usb gadget fuzzer driver
> > git tree: https://github.com/google/kasan.git usb-fuzzer
Am Dienstag, den 06.08.2019, 15:46 -0400 schrieb Alan Stern:
> +static int proc_wait_for_resume(struct usb_dev_state *ps)
> +{
> + int ret;
> +
> + usb_unlock_device(ps->dev);
> + ret = wait_event_interruptible(ps->wait_for_resume,
> + READ_ONCE(ps->not_yet_r
Am Dienstag, den 06.08.2019, 10:19 -0400 schrieb Alan Stern:
> In any case, I don't know if this missing "get" would cause the
> problem, but it might well.
Hi,
upon further thought, this should be automated. Checking for
refcount leaks is KASAN's job. In particular, refcounts
should not
* decr
Am Dienstag, den 06.08.2019, 10:19 -0400 schrieb Alan Stern:
> On Tue, 6 Aug 2019, Oliver Neukum wrote:
>
> > Am Donnerstag, den 01.08.2019, 14:47 -0400 schrieb Alan Stern:
> > >
> > > I think this must be caused by an unbalanced refcount. That is,
> > >
;t have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+a64a382964bf6c71a...@syzkaller.appspotmail.com
#syz test: https://github.com/google/kasan.git e96407b4
>From 973e82b3f583113e4d7fe5cd2f918a16
//github.com/google/kasan.git e96407b4
>From 06be579ae09483c7c723067f4e5bf938ad302bda Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Tue, 6 Aug 2019 15:33:35 +0200
Subject: [PATCH] iforce: add sanity checks
The endpoint type should also be checked before a device
is
otmail.com
#syz test: https://github.com/google/kmsan.git 41550654
>From 6de76fa3df8aedc7a76dc0ecdea8308e38d4dccc Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Tue, 6 Aug 2019 14:41:52 +0200
Subject: [PATCH] pcan_usb_fd: zero out the common command buffer
Lest we leak kernel memory to a device
otmail.com
#syz test: https://github.com/google/kasan.git 41550654
>From 6de76fa3df8aedc7a76dc0ecdea8308e38d4dccc Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Tue, 6 Aug 2019 14:41:52 +0200
Subject: [PATCH] pcan_usb_fd: zero out the common command buffer
Lest we leak kernel memory to a device
I cannot tell from the bug report how many and which
interfaces the emulated test device has. Hence it is unclear to me,
when exactly probe() would fail cdc-acm.
If you agree. I am attaching a putative fix.
Regards
Oliver
From 6b31904e6cf75f89441e308b9e428a1de7728fd8 Mon S
in set_bit
> include/asm-generic/bitops-instrumented.h:28 [inline]
#syz test: https://github.com/google/kasan.git e96407b4
>From 90b712f3e9b9a45996eb0dfe5f489a4502c9f843 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Mon, 5 Aug 2019 16:14:47 +0200
Subject: [PATCH] hid-lg4ff: sanity check
Am Montag, den 05.08.2019, 16:53 +0200 schrieb Andrey Konovalov:
> On Mon, Aug 5, 2019 at 4:34 PM Oliver Neukum wrote:
> >
> > Am Montag, den 05.08.2019, 05:38 -0700 schrieb syzbot:
> > > Hello,
> > >
> > > syzbot found the following crash on:
> &
in set_bit
> include/asm-generic/bitops-instrumented.h:28 [inline]
#syz test: https://github.com/google/kasan.git e96407b4
>From 7e7f8ce9108b69613f8bb4ff2f95c258e22c3228 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Mon, 5 Aug 2019 16:14:47 +0200
Subject: [PATCH] hid-lg4ff: sanity check
Am Donnerstag, den 01.08.2019, 11:52 +0100 schrieb Suzuki K Poulose:
>
> Looks like the yurex_delete() drops the ref count on the dev->udev
> way early in the function and then later tries to see if there
> are any other buffers associated with it worth releasing. So,
> I am guessing moving the us
Am Dienstag, den 30.07.2019, 16:12 +0200 schrieb Andrey Konovalov:
> On Tue, Jul 30, 2019 at 4:10 PM Alan Stern wrote:
> >
> > On Mon, 29 Jul 2019, syzbot wrote:
> >
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:6a3599ce usb-fuzzer: main usb gadget f
github.com/google/kasan.git usb-fuzzer
>From 29b755588bd353d0e10ae384c2c551dffa1b3e7b Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Tue, 30 Jul 2019 12:00:27 +0200
Subject: [PATCH] usbtouchscreen: add proper initialization
Mutexes shall be initialized before they are used.
Fixes: 12e510d
Am Montag, den 29.07.2019, 18:54 +0200 schrieb Andrey Konovalov:
Hi,
> Thanks a lot for fixing all of these USB bugs!
I fear the day we get serious about MA USB.
All these issues will turn into security issues.
> The usb-fuzzer branch is working again, so it should be possible to
> use it for t
:
Reported-by: syzbot+d93dff37e6a89431c...@syzkaller.appspotmail.com
#syz test: https://github.com/google/kasan.git 9a33b369
>From 5a34ecc6c75479a9f245a867e1ce37e6e28f58f8 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Mon, 29 Jul 2019 16:21:11 +0200
Subject: [PATCH] b2c2-flexcop-usb: add san
:
Reported-by: syzbot+d93dff37e6a89431c...@syzkaller.appspotmail.com
#syz test: https://github.com/google/kasan.git usb-fuzzer-usb-testing-2019.07.11
>From 5a34ecc6c75479a9f245a867e1ce37e6e28f58f8 Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Mon, 29 Jul 2019 16:21:11 +0200
Subject: [PA
Hi,
I am looking at this report:
Title: general protection fault in
ath6kl_usb_alloc_urb_from_pipe
Last occurred: 0 days ago
Reported: 102 days ago
Branches: Mainline (with usb-fuzzer patches)
Dashboard link: https://syzkaller.appspot.com/bug?id=cd8b9cfe5
://github.com/google/kasan.git usb-fuzzer-usb-testing-2019.07.11
>From 0b0a7f7e980973e0c0d17f1dfe2bd7742492bfcc Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Mon, 29 Jul 2019 11:49:00 +0200
Subject: [PATCH] iguanair: add sanity checks
The driver needs to check the endpoint types, too,
//github.com/google/kasan.git
usb-fuzzer-usb-testing-2019.07.11]
>From 0b0a7f7e980973e0c0d17f1dfe2bd7742492bfcc Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Mon, 29 Jul 2019 11:49:00 +0200
Subject: [PATCH] iguanair: add sanity checks
The driver needs to check the endpoint types, too,
Am Montag, den 29.07.2019, 18:05 +0800 schrieb Jia-Ju Bai:
Hi,
> In sddr55_transport(), there is an if statement on line 836 to check
> whether info->lba_to_pba is NULL:
> if (info->lba_to_pba == NULL || ...)
>
> When info->lba_to_pba is NULL, it is used on line 948:
> pba = info->lba_to
om/google/kasan.git usb-fuzzer-usb-testing-2019.07.11
>From a3455c4527bdfe86536856ea96288b7dcc36590b Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Wed, 24 Jul 2019 22:49:57 +0200
Subject: [PATCH] usbhid: test for disconnected state in raw opening
If the device has been disconnected, we should not proceed
Am Mittwoch, den 24.07.2019, 17:02 -0400 schrieb Alan Stern:
> On Wed, 24 Jul 2019, Oliver Neukum wrote:
>
> > drivers/hid/usbhid/hid-core.c | 13 +
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/h
;From a3455c4527bdfe86536856ea96288b7dcc36590b Mon Sep 17 00:00:00 2001
From: Oliver Neukum
Date: Wed, 24 Jul 2019 22:49:57 +0200
Subject: [PATCH] usbhid: test for disconnected state in raw opening
If the device has been disconnected, we should not proceed to use
runtime PM on it.
Reported-by: syzb
Am Dienstag, den 23.07.2019, 05:48 -0700 schrieb syzbot:
>
> Freed by task 243:
> save_stack+0x1b/0x80 /mm/kasan/common.c:71
> set_track /mm/kasan/common.c:79 [inline]
> __kasan_slab_free+0x130/0x180 /mm/kasan/common.c:451
> slab_free_hook /mm/slub.c:1421 [inline]
> slab_free_freelist_ho
Am Dienstag, den 09.07.2019, 21:10 +0800 schrieb Kai-Heng Feng:
> Hi Mika and Mathias,
>
> I’ve filed a bug [1] which renders docking station unusable.
>
> I am not sure it's a bug in PCI, Thunderbolt or xHCI so raise the issue to
> you both.
>
> [1] https://bugzilla.kernel.org/show_bug.cgi?id
this fix and did
> so pretty quickly before but you never know.
>
This is time for the sledge hammer. No more surgical solutions.
Could you test the attached patch?
Regards
Oliver
From 06b826bf3e2d3fb15aee676185c632b9f08a10db Mon Sep 17 00:00:00 2001
From: Oliver Neukum
D
Am Dienstag, den 02.07.2019, 22:05 +0800 schrieb JC Kuo:
Hi,
> I don't see the uas issue myself. I was trying to describe a situation that
> user having issue with UAS storage and would like to blacklist uas module when
> the user is not aware of the usb-storage quirks parameter.
>
> https://mar
Am Donnerstag, den 20.06.2019, 21:19 +0100 schrieb Aidan Thornton:
> This doesn't make much sense though. e387ef5c47dd should apply this
> quirk to all Logitech UVC webcams, and this is definitely a UVC-based
> Logitech webcam with the appropriate VID and interface descriptor.
> Surely it shouldn'
Am Montag, den 01.07.2019, 10:17 -0400 schrieb Alan Stern:
> On Mon, 1 Jul 2019, Oliver Neukum wrote:
>
> > Am Donnerstag, den 27.06.2019, 09:52 -0400 schrieb Alan Stern:
> >
> > >
> > > Or maybe the WAIT_FOR_RESUME ioctl returns because there was a remote
1 - 100 of 1943 matches
Mail list logo
