Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-26 Thread Malcolm Priestley 



On 26/09/16 19:23, Oliver Neukum wrote:

On Mon, 2016-09-26 at 18:57 +0100, Malcolm Priestley wrote:


On 26/09/16 09:48, Oliver Neukum wrote:

On Sat, 2016-09-24 at 01:21 +0100, Malcolm Priestley wrote:


On 22/09/16 20:50, Malcolm Priestley wrote:



On 22/09/16 15:25, Oliver Neukum wrote:

On Thu, 2016-09-22 at 14:46 +0300, Binyamin Sharet wrote:


-- Binyamin


I compiled the kernel without BPF and still got an issue (attached)
How can I verify the BPF is not enabled/part of the kernel?

-- Binyamin


Could you test the attached patch?

ieee80211_free_hw frees the priv.

usb_set_intfdata is set to hw_>priv, If vt6656_disconnect is called
there is a null check.

I was wrong ieee80211_free_hw does not null the ieee80211_hw->priv offset.

I have replicated this bug with the hardware.

This patch fixes the bug.


Which patch? It seems there's a potential for confusion here.


Your attached patch
[PATCH] vt6656: avoid double free


Thanks for clearing up the confusion. May I submit it with your
"Tested-by"?

Yes

Tested-by: Malcolm Priestley 

Regards

Malcolm
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-26 Thread Oliver Neukum 
On Mon, 2016-09-26 at 18:57 +0100, Malcolm Priestley wrote:
> 
> On 26/09/16 09:48, Oliver Neukum wrote:
> > On Sat, 2016-09-24 at 01:21 +0100, Malcolm Priestley wrote:
> >>
> >> On 22/09/16 20:50, Malcolm Priestley wrote:
> >>>
> >>>
> >>> On 22/09/16 15:25, Oliver Neukum wrote:
>  On Thu, 2016-09-22 at 14:46 +0300, Binyamin Sharet wrote:
> 
> >> -- Binyamin
> >
> > I compiled the kernel without BPF and still got an issue (attached)
> > How can I verify the BPF is not enabled/part of the kernel?
> >
> > -- Binyamin
> 
>  Could you test the attached patch?
> >>> ieee80211_free_hw frees the priv.
> >>>
> >>> usb_set_intfdata is set to hw_>priv, If vt6656_disconnect is called
> >>> there is a null check.
> >> I was wrong ieee80211_free_hw does not null the ieee80211_hw->priv offset.
> >>
> >> I have replicated this bug with the hardware.
> >>
> >> This patch fixes the bug.
> >
> > Which patch? It seems there's a potential for confusion here.
> 
> Your attached patch
> [PATCH] vt6656: avoid double free

Thanks for clearing up the confusion. May I submit it with your
"Tested-by"?

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-26 Thread Oliver Neukum 
On Sat, 2016-09-24 at 01:21 +0100, Malcolm Priestley wrote:
> 
> On 22/09/16 20:50, Malcolm Priestley wrote:
> >
> >
> > On 22/09/16 15:25, Oliver Neukum wrote:
> >> On Thu, 2016-09-22 at 14:46 +0300, Binyamin Sharet wrote:
> >>
>  -- Binyamin
> >>>
> >>> I compiled the kernel without BPF and still got an issue (attached)
> >>> How can I verify the BPF is not enabled/part of the kernel?
> >>>
> >>> -- Binyamin
> >>
> >> Could you test the attached patch?
> > ieee80211_free_hw frees the priv.
> >
> > usb_set_intfdata is set to hw_>priv, If vt6656_disconnect is called
> > there is a null check.
> I was wrong ieee80211_free_hw does not null the ieee80211_hw->priv offset.
> 
> I have replicated this bug with the hardware.
> 
> This patch fixes the bug.

Which patch? It seems there's a potential for confusion here.

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-25 Thread Binyamin Sharet 
On Sat, Sep 24, 2016 at 3:21 AM, Malcolm Priestley  wrote:
>
>
> On 22/09/16 20:50, Malcolm Priestley wrote:
>>
>>
>>
>> On 22/09/16 15:25, Oliver Neukum wrote:
>>>
>>> On Thu, 2016-09-22 at 14:46 +0300, Binyamin Sharet wrote:
>>>
> -- Binyamin


 I compiled the kernel without BPF and still got an issue (attached)
 How can I verify the BPF is not enabled/part of the kernel?

 -- Binyamin
>>>
>>>
>>> Could you test the attached patch?
>>
>> ieee80211_free_hw frees the priv.
>>
>> usb_set_intfdata is set to hw_>priv, If vt6656_disconnect is called
>> there is a null check.
>
> I was wrong ieee80211_free_hw does not null the ieee80211_hw->priv offset.
>
> I have replicated this bug with the hardware.
>
> This patch fixes the bug.
>
> Good catch.
>
> Regards
>
>
> Malcolm

Is this still need to be tested?

-- Binyamin
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-23 Thread Malcolm Priestley 



On 22/09/16 20:50, Malcolm Priestley wrote:



On 22/09/16 15:25, Oliver Neukum wrote:

On Thu, 2016-09-22 at 14:46 +0300, Binyamin Sharet wrote:


-- Binyamin


I compiled the kernel without BPF and still got an issue (attached)
How can I verify the BPF is not enabled/part of the kernel?

-- Binyamin


Could you test the attached patch?

ieee80211_free_hw frees the priv.

usb_set_intfdata is set to hw_>priv, If vt6656_disconnect is called
there is a null check.

I was wrong ieee80211_free_hw does not null the ieee80211_hw->priv offset.

I have replicated this bug with the hardware.

This patch fixes the bug.

Good catch.

Regards


Malcolm
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Malcolm Priestley 



On 22/09/16 15:25, Oliver Neukum wrote:

On Thu, 2016-09-22 at 14:46 +0300, Binyamin Sharet wrote:


-- Binyamin


I compiled the kernel without BPF and still got an issue (attached)
How can I verify the BPF is not enabled/part of the kernel?

-- Binyamin


Could you test the attached patch?

ieee80211_free_hw frees the priv.

usb_set_intfdata is set to hw_>priv, If vt6656_disconnect is called 
there is a null check.


I think the order is wrong in vt6656_disconnect.

Regards


Malcolm
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Oliver Neukum 
On Thu, 2016-09-22 at 14:46 +0300, Binyamin Sharet wrote:

> > -- Binyamin
> 
> I compiled the kernel without BPF and still got an issue (attached)
> How can I verify the BPF is not enabled/part of the kernel?
> 
> -- Binyamin

Could you test the attached patch?

Regards
Oliver

From e0f6d09babd9f30d952389ff98a2a25df9a158a5 Mon Sep 17 00:00:00 2001
From: Oliver Neukum 
Date: Thu, 22 Sep 2016 16:22:06 +0200
Subject: [PATCH] vt6656: avoid double free

This data structure is fred in disconnect(). It must not
be freed earlier.

Signed-off-by: Oliver Neukum 
---
 drivers/staging/vt6656/wcmd.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/vt6656/wcmd.c b/drivers/staging/vt6656/wcmd.c
index 95faaeb..17f2723 100644
--- a/drivers/staging/vt6656/wcmd.c
+++ b/drivers/staging/vt6656/wcmd.c
@@ -110,7 +110,6 @@ void vnt_run_command(struct work_struct *work)
 		if (vnt_init(priv)) {
 			/* If fail all ends TODO retry */
 			dev_err(>usb->dev, "failed to start\n");
-			ieee80211_free_hw(priv->hw);
 			return;
 		}
 
-- 
2.6.2

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Oliver Neukum 
On Thu, 2016-09-22 at 14:46 +0300, Binyamin Sharet wrote:
> On Thu, Sep 22, 2016 at 11:18 AM, Binyamin Sharet  
> wrote:
> > On Thu, Sep 22, 2016 at 11:02 AM, Oliver Neukum  wrote:
> >> On Thu, 2016-09-22 at 10:50 +0300, Binyamin Sharet wrote:
> >>> On Thu, Sep 22, 2016 at 10:35 AM, Oliver Neukum  wrote:
> >>> > On Thu, 2016-09-22 at 09:53 +0300, Binyamin Sharet wrote:
> >>> >> On Wed, Sep 21, 2016 at 11:09 PM, Malcolm Priestley 
> >>> >>  wrote:
> >>> >> >
> >>> >> Malcolm, just to make it clear, this bug was not found with an
> >>> >> actual device, but with emulation.
> >>> >
> >>> > It was quite peculiar a bug, though. Could you prepare a test kernel
> >>> > without BPF?
> >>> >
> >>> > Regards
> >>> > Oliver
> >>> >
> >>> >
> >>>
> >>> Oliver,
> >>>
> >>> If this question was directed to me, I will need some clarification
> >>> of what is needed (and also - what's BPF?)
> >>
> >> BPF = Berkeley Packet Filter (a mechanism to filter packets going over a
> >> socket)
> >>
> >> The oops you reproduced was in the BPF. That is rather generic code
> >> without connection to the driver in question. That raises the question
> >> whether you've accidentally triggered a generic bug.
> >> To rule that out a rerun on a kernel compiled without CONFIG_BPF would
> >> be useful. Or you could build an initrd with the BPF modules
> >> blacklisted, so we are sure the test system does not use BPF.
> >>
> >> Regards
> >> Oliver
> >>
> >>
> >>
> >
> > Thanks Oliver, will do.
> >
> > -- Binyamin
> 
> I compiled the kernel without BPF and still got an issue (attached)
> How can I verify the BPF is not enabled/part of the kernel?

Do you have CONFIG_BPF_JIT enabled?

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Binyamin Sharet 
On Thu, Sep 22, 2016 at 11:18 AM, Binyamin Sharet  wrote:
> On Thu, Sep 22, 2016 at 11:02 AM, Oliver Neukum  wrote:
>> On Thu, 2016-09-22 at 10:50 +0300, Binyamin Sharet wrote:
>>> On Thu, Sep 22, 2016 at 10:35 AM, Oliver Neukum  wrote:
>>> > On Thu, 2016-09-22 at 09:53 +0300, Binyamin Sharet wrote:
>>> >> On Wed, Sep 21, 2016 at 11:09 PM, Malcolm Priestley  
>>> >> wrote:
>>> >> >
>>> >> Malcolm, just to make it clear, this bug was not found with an
>>> >> actual device, but with emulation.
>>> >
>>> > It was quite peculiar a bug, though. Could you prepare a test kernel
>>> > without BPF?
>>> >
>>> > Regards
>>> > Oliver
>>> >
>>> >
>>>
>>> Oliver,
>>>
>>> If this question was directed to me, I will need some clarification
>>> of what is needed (and also - what's BPF?)
>>
>> BPF = Berkeley Packet Filter (a mechanism to filter packets going over a
>> socket)
>>
>> The oops you reproduced was in the BPF. That is rather generic code
>> without connection to the driver in question. That raises the question
>> whether you've accidentally triggered a generic bug.
>> To rule that out a rerun on a kernel compiled without CONFIG_BPF would
>> be useful. Or you could build an initrd with the BPF modules
>> blacklisted, so we are sure the test system does not use BPF.
>>
>> Regards
>> Oliver
>>
>>
>>
>
> Thanks Oliver, will do.
>
> -- Binyamin

I compiled the kernel without BPF and still got an issue (attached)
How can I verify the BPF is not enabled/part of the kernel?

-- Binyamin
[   70.514366] usb 1-1.2: new full-speed USB device number 6 using ehci-pci
[   70.815709] usb 1-1.2: New USB device found, idVendor=160a, idProduct=3184
[   70.815713] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[   70.815715] usb 1-1.2: Product: UMAP2. PID:0x3184
[   70.815717] usb 1-1.2: Manufacturer: UMAP2. VID:0x160a
[   70.815719] usb 1-1.2: SerialNumber: 123456
[   70.995314] vt6656_stage: module is from the staging directory, the quality is unknown, you have been warned.
[   70.995843] usb 1-1.2: VIA Networking Wireless LAN USB Driver Ver. mac80211
[   70.995844] usb 1-1.2: Copyright (c) 2004 VIA Networking Technologies, Inc.
[   71.073733] usb 1-1.2: reset full-speed USB device number 6 using ehci-pci
[   71.316005] usb 1-1.2: Starting mac80211
[   71.316051] usb 1-1.2: VIA Networking Wireless LAN USB Driver Ver. mac80211
[   71.316053] usb 1-1.2: Copyright (c) 2004 VIA Networking Technologies, Inc.
[   71.319384] usb 1-1.2: Direct firmware load for vntwusb.fw failed with error -2
[   71.319389] usb 1-1.2: firmware file vntwusb.fw request failed (-2)
[   71.319396] usb 1-1.2: failed to start
[   71.346203] usb 1-1.2: VIA Networking Wireless LAN USB Driver Ver. mac80211
[   71.346206] usb 1-1.2: Copyright (c) 2004 VIA Networking Technologies, Inc.
[   71.346222] usb 1-1.2: usb_device_reset fail status=-22
[   71.346232] usb 1-1.2: usb_device_reset fail status=-19
[   71.346283] usbcore: registered new interface driver vt6656
[   71.347035] usb 1-1.2: Starting mac80211
[   71.347052] usb 1-1.2: Direct firmware load for vntwusb.fw failed with error -2
[   71.347055] usb 1-1.2: firmware file vntwusb.fw request failed (-2)
[   71.347058] usb 1-1.2: failed to start
[   71.347068] usb 1-1.2: Starting mac80211
[   71.347077] usb 1-1.2: Direct firmware load for vntwusb.fw failed with error -2
[   71.347079] usb 1-1.2: firmware file vntwusb.fw request failed (-2)
[   71.347081] usb 1-1.2: failed to start
[   71.347376] usb 1-1.2: USB disconnect, device number 6
[   71.393522] BUG: unable to handle kernel paging request at be2280a05fe8
[   71.393581] IP: [] find_vmap_area+0x25/0x60
[   71.393613] PGD 13348f067 PUD 133494067 PMD 12d762067 PTE 0
[   71.393648] Oops:  [#1] SMP
[   71.393663] Modules linked in: vt6656_stage(C) rfcomm bnep arc4 iwldvm snd_hda_codec_hdmi intel_powerclamp coretemp snd_hda_codec_conexant mac80211 snd_hda_codec_generic kvm_intel snd_hda_intel kvm snd_hda_codec snd_hda_core uvcvideo btusb irqbypass crct10dif_pclmul btrtl videobuf2_vmalloc crc32_pclmul videobuf2_memops videobuf2_v4l2 btbcm ghash_clmulni_intel snd_hwdep joydev btintel videobuf2_core iwlwifi bluetooth thinkpad_acpi videodev aesni_intel snd_pcm input_leds aes_x86_64 media lrw gf128mul nvram snd_seq_midi glue_helper snd_seq_midi_event cfg80211 snd_rawmidi snd_seq ablk_helper snd_seq_device serio_raw snd_timer cryptd mei_me mei snd intel_ips lpc_ich shpchp soundcore mac_hid parport_pc ppdev lp parport autofs4 i915 psmouse i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops
[   71.394087]  ahci drm libahci e1000e ptp pps_core wmi fjes video
[   71.394134] CPU: 2 PID: 23 Comm: kworker/2:0 Tainted: G C  4.8.0-rc2-nobpf+ #14
[   71.394162] Hardware name: LENOVO 4492A56/4492A56, BIOS 6QET44WW (1.14 ) 04/20/2010
[   71.394192] Workqueue: events bpf_prog_free_deferred
[

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Binyamin Sharet 
On Thu, Sep 22, 2016 at 11:02 AM, Oliver Neukum  wrote:
> On Thu, 2016-09-22 at 10:50 +0300, Binyamin Sharet wrote:
>> On Thu, Sep 22, 2016 at 10:35 AM, Oliver Neukum  wrote:
>> > On Thu, 2016-09-22 at 09:53 +0300, Binyamin Sharet wrote:
>> >> On Wed, Sep 21, 2016 at 11:09 PM, Malcolm Priestley  
>> >> wrote:
>> >> >
>> >> Malcolm, just to make it clear, this bug was not found with an
>> >> actual device, but with emulation.
>> >
>> > It was quite peculiar a bug, though. Could you prepare a test kernel
>> > without BPF?
>> >
>> > Regards
>> > Oliver
>> >
>> >
>>
>> Oliver,
>>
>> If this question was directed to me, I will need some clarification
>> of what is needed (and also - what's BPF?)
>
> BPF = Berkeley Packet Filter (a mechanism to filter packets going over a
> socket)
>
> The oops you reproduced was in the BPF. That is rather generic code
> without connection to the driver in question. That raises the question
> whether you've accidentally triggered a generic bug.
> To rule that out a rerun on a kernel compiled without CONFIG_BPF would
> be useful. Or you could build an initrd with the BPF modules
> blacklisted, so we are sure the test system does not use BPF.
>
> Regards
> Oliver
>
>
>

Thanks Oliver, will do.

-- Binyamin
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Oliver Neukum 
On Thu, 2016-09-22 at 10:50 +0300, Binyamin Sharet wrote:
> On Thu, Sep 22, 2016 at 10:35 AM, Oliver Neukum  wrote:
> > On Thu, 2016-09-22 at 09:53 +0300, Binyamin Sharet wrote:
> >> On Wed, Sep 21, 2016 at 11:09 PM, Malcolm Priestley  
> >> wrote:
> >> >
> >> Malcolm, just to make it clear, this bug was not found with an
> >> actual device, but with emulation.
> >
> > It was quite peculiar a bug, though. Could you prepare a test kernel
> > without BPF?
> >
> > Regards
> > Oliver
> >
> >
> 
> Oliver,
> 
> If this question was directed to me, I will need some clarification
> of what is needed (and also - what's BPF?)

BPF = Berkeley Packet Filter (a mechanism to filter packets going over a
socket)

The oops you reproduced was in the BPF. That is rather generic code
without connection to the driver in question. That raises the question
whether you've accidentally triggered a generic bug.
To rule that out a rerun on a kernel compiled without CONFIG_BPF would
be useful. Or you could build an initrd with the BPF modules
blacklisted, so we are sure the test system does not use BPF.

Regards
Oliver



--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Binyamin Sharet 
On Thu, Sep 22, 2016 at 10:35 AM, Oliver Neukum  wrote:
> On Thu, 2016-09-22 at 09:53 +0300, Binyamin Sharet wrote:
>> On Wed, Sep 21, 2016 at 11:09 PM, Malcolm Priestley  
>> wrote:
>> >
>> Malcolm, just to make it clear, this bug was not found with an
>> actual device, but with emulation.
>
> It was quite peculiar a bug, though. Could you prepare a test kernel
> without BPF?
>
> Regards
> Oliver
>
>

Oliver,

If this question was directed to me, I will need some clarification
of what is needed (and also - what's BPF?)

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Oliver Neukum 
On Thu, 2016-09-22 at 09:53 +0300, Binyamin Sharet wrote:
> On Wed, Sep 21, 2016 at 11:09 PM, Malcolm Priestley  
> wrote:
> > 
> Malcolm, just to make it clear, this bug was not found with an
> actual device, but with emulation.

It was quite peculiar a bug, though. Could you prepare a test kernel
without BPF?

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-22 Thread Binyamin Sharet 
On Wed, Sep 21, 2016 at 11:09 PM, Malcolm Priestley  wrote:
> On 21/09/16 17:44, Greg KH wrote:
>>
>> On Wed, Sep 21, 2016 at 06:34:03PM +0200, Oliver Neukum wrote:
>>>
>>> On Thu, 2016-08-18 at 13:50 +0300, Binyamin Sharet wrote:

 On 08/18/2016 01:31 PM, Oliver Neukum wrote:
>
> On Wed, 2016-08-17 at 14:34 +0300, Binyamin Sharet wrote:
>>>
>>> After connecting such a device, NULL pointer dereference in the
>>
>> kernel.
>>>
>>> You may need to connect another device or two after this one to
>>
>> trigger
>>>
>>> the oops.
>>>
>>> Binyamin Sharet
>>> Cisco, STARE-C
>>>
>>> << Attached:  160a_3184_dmesg_1.log >>
>>> << Attached:  160a_3184_dmesg_2.log >>
>>
>> kernel: 4.8-rc2
>> result: reproduced
>>>
>>> [..]
>
>
 Attached.

>>>
>>> Hi,
>>>
>>> this fell through the cracks somehow. Does anybody know how
>>> these devices should be to work with the driver?
>>
>>
>> Which device was this?  I'm slowly working on a patchset to move this
>> type of checking to the USB core to hopefully prevent this type of thing
>> from have to be added to each USB driver individually.
>
>
> It's the VT6656.
>
> The problem cannot be reproduced here on the Raspberry PI 2.
>
> Looking at those logs it looks like the device reset during firmware
> downloading.
>
> Is the PSU for PI up to job?
>
> The device is power hungry, I am using a 2.4A @5v power supply.
>
> Regards
>
>
> Malcolm
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Malcolm, just to make it clear, this bug was not found with an
actual device, but with emulation.

-- Binyamin
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-21 Thread Malcolm Priestley 

On 21/09/16 17:44, Greg KH wrote:

On Wed, Sep 21, 2016 at 06:34:03PM +0200, Oliver Neukum wrote:

On Thu, 2016-08-18 at 13:50 +0300, Binyamin Sharet wrote:

On 08/18/2016 01:31 PM, Oliver Neukum wrote:

On Wed, 2016-08-17 at 14:34 +0300, Binyamin Sharet wrote:

After connecting such a device, NULL pointer dereference in the

kernel.

You may need to connect another device or two after this one to

trigger

the oops.

Binyamin Sharet
Cisco, STARE-C

<< Attached:  160a_3184_dmesg_1.log >>
<< Attached:  160a_3184_dmesg_2.log >>

kernel: 4.8-rc2
result: reproduced

[..]



Attached.



Hi,

this fell through the cracks somehow. Does anybody know how
these devices should be to work with the driver?


Which device was this?  I'm slowly working on a patchset to move this
type of checking to the USB core to hopefully prevent this type of thing
from have to be added to each USB driver individually.


It's the VT6656.

The problem cannot be reproduced here on the Raspberry PI 2.

Looking at those logs it looks like the device reset during firmware 
downloading.


Is the PSU for PI up to job?

The device is power hungry, I am using a 2.4A @5v power supply.

Regards


Malcolm
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-21 Thread Greg KH 
On Wed, Sep 21, 2016 at 06:34:03PM +0200, Oliver Neukum wrote:
> On Thu, 2016-08-18 at 13:50 +0300, Binyamin Sharet wrote:
> > On 08/18/2016 01:31 PM, Oliver Neukum wrote:
> > > On Wed, 2016-08-17 at 14:34 +0300, Binyamin Sharet wrote:
> > >>> After connecting such a device, NULL pointer dereference in the
> > >> kernel.
> > >>> You may need to connect another device or two after this one to
> > >> trigger
> > >>> the oops.
> > >>>
> > >>> Binyamin Sharet
> > >>> Cisco, STARE-C
> > >>>
> > >>> << Attached:  160a_3184_dmesg_1.log >>
> > >>> << Attached:  160a_3184_dmesg_2.log >>
> > >> kernel: 4.8-rc2
> > >> result: reproduced
> [..]
> > >
> > Attached.
> > 
> 
> Hi,
> 
> this fell through the cracks somehow. Does anybody know how
> these devices should be to work with the driver?

Which device was this?  I'm slowly working on a patchset to move this
type of checking to the USB core to hopefully prevent this type of thing
from have to be added to each USB driver individually.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-09-21 Thread Oliver Neukum 
On Thu, 2016-08-18 at 13:50 +0300, Binyamin Sharet wrote:
> On 08/18/2016 01:31 PM, Oliver Neukum wrote:
> > On Wed, 2016-08-17 at 14:34 +0300, Binyamin Sharet wrote:
> >>> After connecting such a device, NULL pointer dereference in the
> >> kernel.
> >>> You may need to connect another device or two after this one to
> >> trigger
> >>> the oops.
> >>>
> >>> Binyamin Sharet
> >>> Cisco, STARE-C
> >>>
> >>> << Attached:  160a_3184_dmesg_1.log >>
> >>> << Attached:  160a_3184_dmesg_2.log >>
> >> kernel: 4.8-rc2
> >> result: reproduced
[..]
> >
> Attached.
> 

Hi,

this fell through the cracks somehow. Does anybody know how
these devices should be to work with the driver?

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-08-18 Thread Oliver Neukum 
On Wed, 2016-08-17 at 14:34 +0300, Binyamin Sharet wrote:
> > After connecting such a device, NULL pointer dereference in the
> kernel.
> > You may need to connect another device or two after this one to
> trigger
> > the oops.
> >
> > Binyamin Sharet
> > Cisco, STARE-C
> >
> > << Attached:  160a_3184_dmesg_1.log >>
> > << Attached:  160a_3184_dmesg_2.log >>
> kernel: 4.8-rc2
> result: reproduced
> 
> this bug triggers different behaviors, but each time, it ended up with
> hanged
> system and I was not able to retrieve the dmesg log.
> I took a photo of the screen, should I send it as an attachment?

Yes, that is better than nothing at all.

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [Umap2][7/11][160a:3184] NULL pointer dereference

2016-08-17 Thread Binyamin Sharet 
On 08/16/2016 04:48 PM, Binyamin Sharet wrote:
> Kernel version: raspberrypi 4.4.6-v7+ #871
> Driver source file: drivers/staging/vt6656/main_usb.c
> Related file: drivers/staging/comedi/drivers/usbduxsigma.c
> Umap2 command line: umap2vsscan -P  -s 160a:3184
>
> After connecting such a device, NULL pointer dereference in the kernel.
> You may need to connect another device or two after this one to trigger
> the oops.
>
> Binyamin Sharet
> Cisco, STARE-C
>
> << Attached:  160a_3184_dmesg_1.log >>
> << Attached:  160a_3184_dmesg_2.log >>
kernel: 4.8-rc2
result: reproduced

this bug triggers different behaviors, but each time, it ended up with
hanged
system and I was not able to retrieve the dmesg log.
I took a photo of the screen, should I send it as an attachment?

-- 
Binyamin Sharet,
Cisco, STARE-C

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Umap2][7/11][160a:3184] NULL pointer dereference

2016-08-16 Thread Binyamin Sharet 
Kernel version: raspberrypi 4.4.6-v7+ #871
Driver source file: drivers/staging/vt6656/main_usb.c
Related file: drivers/staging/comedi/drivers/usbduxsigma.c
Umap2 command line: umap2vsscan -P  -s 160a:3184

After connecting such a device, NULL pointer dereference in the kernel.
You may need to connect another device or two after this one to trigger
the oops.

Binyamin Sharet
Cisco, STARE-C

<< Attached:  160a_3184_dmesg_1.log >>
<< Attached:  160a_3184_dmesg_2.log >>
[  291.754550] usb 1-1.4: new high-speed USB device number 17 using dwc_otg
[  291.869191] usb 1-1.4: New USB device found, idVendor=160a, idProduct=3184
[  291.869211] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  291.869222] usb 1-1.4: Product: UMAP2. PID:0x3184
[  291.869233] usb 1-1.4: Manufacturer: UMAP2. VID:0x160a
[  291.869243] usb 1-1.4: SerialNumber: 123456
[  293.016056] vt6656_stage: module is from the staging directory, the quality is unknown, you have been warned.
[  293.018042] usb 1-1.4: VIA Networking Wireless LAN USB Driver Ver. mac80211
[  293.018068] usb 1-1.4: Copyright (c) 2004 VIA Networking Technologies, Inc.
[  293.094648] usb 1-1.4: reset high-speed USB device number 17 using dwc_otg
[  293.204645] usb 1-1.4: Starting mac80211
[  293.204928] usbcore: registered new interface driver vt6656
[  293.210276] usb 1-1.4: Direct firmware load for vntwusb.fw failed with error -2
[  293.210308] usb 1-1.4: firmware file vntwusb.fw request failed (-2)
[  293.210325] usb 1-1.4: failed to start
[  293.314884] usb 1-1.4: USB disconnect, device number 17
[  296.624625] usb 1-1.4: new high-speed USB device number 18 using dwc_otg
[  296.743301] Unable to handle kernel NULL pointer dereference at virtual address 0002
[  296.751396] pgd = 80004000
[  296.754100] [0002] *pgd=
[  296.757686] Internal error: Oops: 17 [#1] SMP ARM
[  296.762383] Modules linked in: vt6656_stage(C) mac80211 r8188eu(C) bnep bluetooth cfg80211 rfkill bcm2835_gpiomem snd_bcm2835 bcm2835_wdt snd_pcm snd_timer snd uio_pdrv_genirq uio i2c_dev fuse
[  296.779626] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G C  4.4.6-v7+ #871
[  296.787181] Hardware name: BCM2709
[  296.790579] task: 808a2568 ti: 8089c000 task.ti: 8089c000
[  296.795980] PC is at __kmalloc+0x90/0x238
[  296.799986] LR is at __kmalloc+0x30/0x238
[  296.803992] pc : [<80147b24>]lr : [<80147ac4>]psr: 2193
[  296.803992] sp : 8089dc88  ip : 8089dc88  fp : 8089dcc4
[  296.815452] r10: b8c9c000  r9 : af9c2a00  r8 : 8043ab50
[  296.820669] r7 : 02088020  r6 : 000c  r5 : b9401f00  r4 : 0002
[  296.827187] r3 :   r2 : 8089dc88  r1 : 8089c820  r0 : 3a714000
[  296.833706] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
[  296.841091] Control: 10c5387d  Table: 35c9c06a  DAC: 0055
[  296.846828] Process swapper/0 (pid: 0, stack limit = 0x8089c210)
[  296.852825] Stack: (0x8089dc88 to 0x8089e000)
[  296.857181] dc80:   8089dcbc 8089dc98 80431314 000149a7 805ecfa4 af9c2980
[  296.865353] dca0: b5fa0680 f3980500 af9c2a00  af9c2a00 b8c9c000 8089dcd4 8089dcc8
[  296.873524] dcc0: 8043ab50 80147aa0 8089dd04 8089dcd8 804307fc 8043ab38  af9c2980
[  296.881695] dce0: b8c9a200 f3980500 b8c9c000 0002 af9c2a00 af9c2980 8089dd44 8089dd08
[  296.889865] dd00: 804325e4 804307d8 0001 8089dd18 804328f0 8043a588 8089dd3c 
[  296.898036] dd20: 0002 0002 b8c9c000 f3980500 b8c9a200 af9c2980 8089dd94 8089dd48
[  296.906207] dd40: 804339f4 80432310 b8c9c000 b8c9c01c 8089dd9c 8089dd60 0001 f398050c
[  296.914378] dd60: 0023 0002   0001 b8c9c000  0208
[  296.922549] dd80: f301080e 0002 8089ddb4 8089dd98 80433dc0 80433668 b8c9c000 b9651000
[  296.930719] dda0: 808ec7d8 0001 8089dde4 8089ddb8 80434098 80433d18 80430564 b8c98900
[  296.938890] ddc0: b9480f5c 003e   805f1e54  8089ddf4 8089dde8
[  296.947061] dde0: 80430580 80433e0c 8089de04 8089ddf8 804038f4 80430570 8089de4c 8089de08
[  296.955232] de00: 80071748 804038cc edeeb793 2193 80902f78 80902f94 b9480f00 8089c008
[  296.963403] de20: 8089de3c b9480f00 b9480f5c    80903758 bafff740
[  296.971573] de40: 8089de6c 8089de50 80071938 80071694 0002 b9480f00 b9480f10 
[  296.979744] de60: 8089de84 8089de70 80074d78 800718f0 8089faf0  8089de94 8089de88
[  296.987915] de80: 80070cc4 80074cd4 8089deac 8089de98 80344ae4 80070c9c 80344aa8 808973ec
[  296.996086] dea0: 8089debc 8089deb0 80070cc4 80344ab4 8089dee4 8089dec0 80070fd0 80070c9c
[  297.004256] dec0: 8089df08 80010b38 6013  8089df3c 805f1e54 8089def4 8089dee8
[  297.012422] dee0: 80010a74 80070f70 8089df04 8089def8 8000951c 80010a54 8089df64 8089df08
[  297.020585] df00: 805ed3c4 80009470  bafa9348   8089c000 8089e5dc
[  297.028748] df20: 8089e500 8089e580 805f1e54 80903758 bafff740 8089df64 8089f4f8 8089df58
[