linux-kernel - Re: OOPS: Bluetooth: Store RFCOMM address information in its own socket structure

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <7410329D-F774-418E-8883-5A1171165113@holtmann.org>
Date:	Wed, 20 Nov 2013 14:53:20 +0700
From:	Marcel Holtmann <marcel@...tmann.org>
To:	Phillip Susi <psusi@...ntu.com>
Cc:	Johan Hedberg <johan.hedberg@...el.com>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: OOPS: Bluetooth: Store RFCOMM address information in its own socket structure

Hi Susi,

> Bisected an OOPS to this commit:
> 
> commit 94a86df01082557e2de45865e538d7fb6c46231c
> Author: Marcel Holtmann <marcel@...tmann.org>
> Date:   Sun Oct 13 10:34:02 2013 -0700
> 
>    Bluetooth: Store RFCOMM address information in its own socket structure
> 
>    The address information of RFCOMM sockets should be stored in its
>    own socket structure. Trying to generalize them is not helpful since
>    different transports have different address types.
> 
>    Signed-off-by: Marcel Holtmann <marcel@...tmann.org>
>    Signed-off-by: Johan Hedberg <johan.hedberg@...el.com>
> 
> OOPS looks like:
> 
> [   16.636145] BUG: unable to handle kernel paging request at 000000268333770b
> [   16.637771] IP: [<ffffffffa01d7c78>] rfcomm_sock_getsockopt+0xe8/0x220 [rfcomm]
> [   16.639350] PGD 0 
> [   16.640875] Oops: 0000 [#11] SMP 
> [   16.642394] Modules linked in: snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_intel snd_hda_codec joydev snd_hwdep snd_pcm snd_page_alloc snd_seq_midi radeon snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer snd soundcore ttm dm_multipath scsi_dh drm_kms_helper microcode(+) drm btusb i2c_algo_bit lpc_ich psmouse wmi serio_raw bnep rfcomm bluetooth binfmt_misc btrfs xor raid6_pq libcrc32c hid_generic hid_microsoft usbhid hid e1000e ahci libahci ptp pps_core
> [   16.645718] CPU: 1 PID: 968 Comm: bluetoothd Tainted: G      D      3.12.0+ #74
> [   16.647369] Hardware name: System manufacturer System Product Name/P8P67 PRO REV 3.1, BIOS 1904 08/15/2011
> [   16.649030] task: ffff8801262d8000 ti: ffff8800c772c000 task.ti: ffff8800c772c000
> [   16.650693] RIP: 0010:[<ffffffffa01d7c78>]  [<ffffffffa01d7c78>] rfcomm_sock_getsockopt+0xe8/0x220 [rfcomm]
> [   16.652372] RSP: 0018:ffff8800c772df08  EFLAGS: 00010246
> [   16.654118] RAX: 000000268333770b RBX: ffff8800c9156080 RCX: 00007fff67e9cd98
> [   16.655800] RDX: 0000000000000003 RSI: 0000000000000012 RDI: ffff8800c9156080
> [   16.657445] RBP: ffff8800c772df38 R08: 00007fff67e9cd9c R09: 00007fff67e9d018
> [   16.659055] R10: 00007fff67e9cd98 R11: 0000000000000202 R12: ffff880036dbd800
> [   16.660624] R13: 00007fff67e9cd98 R14: 0000000000000003 R15: 00007fff67e9cd9c
> [   16.662190] FS:  00007f1cfe1a1740(0000) GS:ffff88012f480000(0000) knlGS:0000000000000000
> [   16.663742] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   16.665284] CR2: 000000268333770b CR3: 00000000c746b000 CR4: 00000000000407e0
> [   16.666823] Stack:
> [   16.668353]  00038800c772df30 ffff8800c9156080 0000000000000012 0000000000000003
> [   16.669906]  00007fff67e9cd98 00007fff67e9cd9c ffff8800c772df78 ffffffff8155ff38
> [   16.671460]  0000000000000000 0000000000000001 00007fff67e9d018 0000000000000001
> [   16.673016] Call Trace:
> [   16.674562]  [<ffffffff8155ff38>] SyS_getsockopt+0x68/0xd0
> [   16.676111]  [<ffffffff81672356>] system_call_fastpath+0x1a/0x1f
> [   16.677651] Code: 00 4c 89 e7 e8 1a bf 38 e1 45 89 f1 48 83 c4 08 44 89 c8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 0f 1f 44 00 00 49 8b 84 24 e8 02 00 00 <48> 8b 18 4c 89 c0 e8 dd 91 14 e1 85 c0 49 89 d7 41 b9 f2 ff ff 
> [   16.679393] RIP  [<ffffffffa01d7c78>] rfcomm_sock_getsockopt+0xe8/0x220 [rfcomm]
> [   16.681022]  RSP <ffff8800c772df08>
> [   16.682639] CR2: 000000268333770b
> [   16.684262] ---[ end trace a5f6978e71640635 ]---

fix for this is already in John’s wireless tree. On a side note, the bisect is correct, but it is not the patch that broke it. It is just the patch that uncovered it.

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/