netdev - Re: Can someone please try...

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Tue, 16 Jan 2007 18:51:59 -0500
From:	Pavel Roskin <proski@....org>
To:	Michael Buesch <mb@...sch.de>
Cc:	bcm43xx-dev@...ts.berlios.de, netdev@...r.kernel.org
Subject: Re: Can someone please try...

On Tue, 2007-01-16 at 23:07 +0100, Michael Buesch wrote:
> On Tuesday 16 January 2007 22:50, Pavel Roskin wrote:
> > On Tue, 2007-01-16 at 20:23 +0100, Michael Buesch wrote:
> > 
> > > A patch for that is already upstream.
> > 
> > I don't see it.  It's not in your tree yet.
> 
> It is on its way upstream to linville.

Well, it's pretty cruel to ask others to test code with known fatal
bugs, IMHO.  Even it git were extremely poor at handling a patch applied
in two branches.  In fact, git is not so bad at all at handling such
situations.

> > > It's surprising that it doesn't happen for me, though.
> > > Neiter on PPC, nor on i386.
> > 
> > It did happen for me on i386, as well as on x86_64.  The dump was for
> > x86_64, as evidenced by the register size.  Maybe you have less
> > debugging options enabled?
> 
> All.

That's commendable.  I tried the 32-bit kernel without SMP and with
almost all debugging.  One thing I noticed is that scanning ignores the
pure 802.11b AP running HostAP that I was going to use for testing.
Other APs are detected.  The association didn't work, probably for that
reason.

Scanning may trigger many assertion failures:

bcm43xx_d80211: ASSERTION FAILED ((lna & ~0x7) == 0)
at: /home/proski/src/linux-2.6/drivers/net/
wireless/d80211/bcm43xx/bcm43xx_lo.c:235:lo_measure_feedthrough()

Finally, interrupting wpa_supplicant hits another bug:

BUG: unable to handle kernel paging request at virtual address c3e2cbf8
 printing eip:
e03835e1
*pde = 0000f067
*pte = 03e2c000
Oops: 0002 [#1]
DEBUG_PAGEALLOC
Modules linked in: bcm43xx_d80211 ssb
CPU:    0
EIP:    0060:[<e03835e1>]    Not tainted VLI
EFLAGS: 00210282   (2.6.20-rc3 #3)
EIP is at bcm43xx_wireless_core_init+0x5a/0x98e [bcm43xx_d80211]
eax: 00000000   ebx: c3dab740   ecx: 000000e1   edx: c3493808
esi: c34937f8   edi: c3e2cbf8   ebp: c3e60e38   esp: c3e60db8
ds: 007b   es: 007b   ss: 0068
Process wpa_supplicant (pid: 2942, ti=c3e60000 task=c3f92590 task.ti=c3e60000)
Stack: c0339db6 c0339db6 00000000 c3f92590 c0339db6 00200246 c3e60df0 c3f30000 
       c3dab740 c0339de4 c3493808 c3e60e0c c3e60e0c 00200246 c3e60e2c c0339dc0 
       00000000 00000002 c0339de4 c3e60e50 c3f92590 22222222 22222222 22222222 
Call Trace:
 [<c010335d>] show_trace_log_lvl+0x1a/0x2f
 [<c010340d>] show_stack_log_lvl+0x9b/0xa3
 [<c01035a6>] show_registers+0x191/0x267
 [<c010378f>] die+0x113/0x212
 [<c011010a>] do_page_fault+0x43a/0x50c
 [<c033b47c>] error_code+0x74/0x7c
 [<e03850bc>] bcm43xx_add_interface+0x4f/0xb7 [bcm43xx_d80211]
 [<c032022f>] ieee80211_open+0x19d/0x27e
 [<c02dbb77>] dev_open+0x2d/0x64
 [<c02da71f>] dev_change_flags+0x51/0xf1
 [<c030b67a>] devinet_ioctl+0x235/0x53a
 [<c030bc38>] inet_ioctl+0x73/0x91
 [<c02d1db8>] sock_ioctl+0x1ac/0x1c9
 [<c015dd64>] do_ioctl+0x1c/0x51
 [<c015df94>] vfs_ioctl+0x1fb/0x212
 [<c015dfdc>] sys_ioctl+0x31/0x49
 [<c0102cba>] sysenter_past_esp+0x5f/0x99
 =======================
Code: 00 80 66 0d ef 8d be 9c 01 00 00 f3 ab 8b 7a 5c 80 62 49 c5 c7 42 4c ff ff ff ff 85 ff c7 
42 50 00 00 00 00 74 13 b9 e1 00 00 00 <f3> ab 8b 42 5c 66 c7 80 76 03 00 00 ff ff 8b 4d a8 89 f
0 c7 41 
EIP: [<e03835e1>] bcm43xx_wireless_core_init+0x5a/0x98e [bcm43xx_d80211] SS:ESP 0068:c3e60db8


Then I used MadWifi on the AP side, and "iwpriv scan" picked it.
Moreover, wpa_supplicant reported connection!  I interrupted
wpa_supplicant and started it again, and then the kernel oopsed again.
Strangely, the driver is not even mentioned in the backtrace.

BUG: unable to handle kernel NULL pointer dereference at virtual address 00000004
 printing eip:
c02d8863
*pde = 00000000
Oops: 0002 [#1]
DEBUG_PAGEALLOC
Modules linked in: bcm43xx_d80211 ssb
CPU:    0
EIP:    0060:[<c02d8863>]    Not tainted VLI
EFLAGS: 00210246   (2.6.20-rc3 #3)
EIP is at datagram_poll+0xba/0xc5
eax: 00000000   ebx: cc252bf8   ecx: 00000049   edx: 00000000
esi: 00000002   edi: 00000004   ebp: cb940b70   esp: cb940b68
ds: 007b   es: 007b   ss: 0068
Process wpa_supplicant (pid: 4344, ti=cb940000 task=c2be0590 task.ti=cb940000)
Stack: c0353220 c9fedf2c cb940b7c c02d1643 00000000 cb940e30 c015ebae c033b3bd
       cb940e54 cb940e50 cb940f9c cb940f50 cb940be0 00000000 00000000 cb940e5c
       cb940e60 cb940e64 cb940e50 cb940e54 cb940e58 00000070 00000000 00000000
Call Trace:
 [<c010335d>] show_trace_log_lvl+0x1a/0x2f
 [<c010340d>] show_stack_log_lvl+0x9b/0xa3
 [<c01035a6>] show_registers+0x191/0x267
 [<c010378f>] die+0x113/0x212
 [<c011010a>] do_page_fault+0x43a/0x50c
 [<c033b47c>] error_code+0x74/0x7c
 [<c02d1643>] sock_poll+0x12/0x15
 [<c015ebae>] do_select+0x2b4/0x4cc
 [<c015f076>] core_sys_select+0x2b0/0x2d5
 [<c015f631>] sys_select+0x99/0x170
 [<c0102cba>] sysenter_past_esp+0x5f/0x99
 =======================
Code: ca 3c 02 74 2b 8b 83 7c 01 00 00 ba 02 00 00 00 89 d6 99 f7 fe 39 83 cc 00 00 00 7d 08 81
c9 04 03 00 00 eb 0b 8b 83 44 02 00 00 <0f> ba 68 04 00 5b 89 c8 5e 5d c3 55 89 e5 57 56 89 c6 5
3 83 ec
EIP: [<c02d8863>] datagram_poll+0xba/0xc5 SS:ESP 0068:cb940b68

-- 
Regards,
Pavel Roskin


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