linux-stable.git/net/bluetooth, branch linux-2.6.33.y

Bluetooth: Prevent buffer overflow in l2cap config request

2011-11-07T21:47:40+00:00

commit 7ac28817536797fd40e9646452183606f9e17f71 upstream.

A remote user can provide a small value for the command size field in
the command header of an l2cap configuration request, resulting in an
integer underflow when subtracting the size of the configuration request
header.  This results in copying a very large amount of data via
memcpy() and destroying the kernel heap.  Check for underflow.

Signed-off-by: Dan Rosenberg 
Signed-off-by: Gustavo F. Padovan 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: l2cap and rfcomm: fix 1 byte infoleak to userspace.

2011-11-07T21:47:38+00:00

commit 8d03e971cf403305217b8e62db3a2e5ad2d6263f upstream.

Structures "l2cap_conninfo" and "rfcomm_conninfo" have one padding
byte each. This byte in "cinfo" is copied to userspace uninitialized.

Signed-off-by: Filip Palian 
Acked-by: Marcel Holtmann 
Signed-off-by: Gustavo F. Padovan 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: bnep: fix buffer overflow

2011-04-14T23:53:02+00:00

commit 43629f8f5ea32a998d06d1bb41eefa0e821ff573 upstream.

Struct ca is copied from userspace.  It is not checked whether the "device"
field is NULL terminated.  This potentially leads to BUG() inside of
alloc_netdev_mqs() and/or information leak by creating a device with a name
made of contents of kernel stack.

Signed-off-by: Vasiliy Kulikov 
Signed-off-by: Gustavo F. Padovan 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: sco: fix information leak to userspace

2011-04-14T23:53:01+00:00

commit c4c896e1471aec3b004a693c689f60be3b17ac86 upstream.

struct sco_conninfo has one padding byte in the end.  Local variable
cinfo of type sco_conninfo is copied to userspace with this uninizialized
one byte, leading to old stack contents leak.

Signed-off-by: Vasiliy Kulikov 
Signed-off-by: Gustavo F. Padovan 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix kernel crash on L2CAP stress tests

2010-04-01T23:02:13+00:00

commit c2c77ec83bdad17fb688557b5b3fdc36661dd1c6 upstream.

Added very simple check that req buffer has enough space to
fit configuration parameters. Shall be enough to reject packets
with configuration size more than req buffer.

Crash trace below

[ 6069.659393] Unable to handle kernel paging request at virtual address 02000205
[ 6069.673034] Internal error: Oops: 805 [#1] PREEMPT
...
[ 6069.727172] PC is at l2cap_add_conf_opt+0x70/0xf0 [l2cap]
[ 6069.732604] LR is at l2cap_recv_frame+0x1350/0x2e78 [l2cap]
...
[ 6070.030303] Backtrace:
[ 6070.032806] [] (l2cap_add_conf_opt+0x0/0xf0 [l2cap]) from
[] (l2cap_recv_frame+0x1350/0x2e78 [l2cap])
[ 6070.043823]  r8:dc5d3100 r7:df2a91d6 r6:00000001 r5:df2a8000 r4:00000200
[ 6070.050659] [] (l2cap_recv_frame+0x0/0x2e78 [l2cap]) from
[] (l2cap_recv_acldata+0x2bc/0x350 [l2cap])
[ 6070.061798] [] (l2cap_recv_acldata+0x0/0x350 [l2cap]) from
[] (hci_rx_task+0x244/0x478 [bluetooth])
[ 6070.072631]  r6:dc647700 r5:00000001 r4:df2ab740
[ 6070.077362] [] (hci_rx_task+0x0/0x478 [bluetooth]) from
[] (tasklet_action+0x78/0xd8)
[ 6070.087005] [] (tasklet_action+0x0/0xd8) from []

Signed-off-by: Andrei Emeltchenko 
Acked-by: Gustavo F. Padovan 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Fix potential bad memory access with sysfs files

2010-04-01T23:02:13+00:00

commit 101545f6fef4a0a3ea8daf0b5b880df2c6a92a69 upstream.

When creating a high number of Bluetooth sockets (L2CAP, SCO
and RFCOMM) it is possible to scribble repeatedly on arbitrary
pages of memory. Ensure that the content of these sysfs files is
always less than one page. Even if this means truncating. The
files in question are scheduled to be moved over to debugfs in
the future anyway.

Based on initial patches from Neil Brown and Linus Torvalds

Reported-by: Neil Brown 
Signed-off-by: Marcel Holtmann 
Signed-off-by: Greg Kroah-Hartman

Bluetooth: Keep a copy of each HID device's report descriptor

2010-02-05T17:50:05+00:00

The report descriptor is read by user space (via the Service
Discovery Protocol), so it is only available during the ioctl
to connect. However, the HID probe function that needs the
descriptor might not be called until a specific module is
loaded. Keep a copy of the descriptor so it is available for
later use.

Signed-off-by: Michael Poole 
Signed-off-by: Marcel Holtmann

Bluetooth: Enter active mode before establishing a SCO link.

2010-02-04T03:10:59+00:00

When in sniff mode with a long interval time (1.28s) it can take 4+ seconds
to establish a SCO link. Fix by requesting active mode before requesting
SCO connection. This improves SCO setup time to ~500ms.

Bluetooth headsets that use a long interval time, and exhibit the long
SCO connection time include Motorola H790, HX1 and H17. They have a
CSR 2.1 chipset.

Verified this behavior and fix with host Bluetooth chipsets: BCM4329 and
TI1271.

2009-10-13 14:17:46.183722 > HCI Event: Mode Change (0x14) plen 6
    status 0x00 handle 1 mode 0x02 interval 2048
    Mode: Sniff
2009-10-13 14:17:53.436285 < HCI Command: Setup Synchronous Connection (0x01|0x0028) plen 17
    handle 1 voice setting 0x0060
2009-10-13 14:17:53.445593 > HCI Event: Command Status (0x0f) plen 4
    Setup Synchronous Connection (0x01|0x0028) status 0x00 ncmd 1
2009-10-13 14:17:57.788855 > HCI Event: Synchronous Connect Complete 0x2c) plen 17
    status 0x00 handle 257 bdaddr 00:1A:0E:F1:A4:7F type eSCO
    Air mode: CVSD

Signed-off-by: Nick Pelly 
Signed-off-by: Marcel Holtmann

Bluetooth: Do not call rfcomm_session_put() for RFCOMM UA on closed socket

2010-02-04T00:28:44+00:00

When processing a RFCOMM UA frame when the socket is closed and we were
not the RFCOMM initiator would cause rfcomm_session_put() to be called
twice during rfcomm_process_rx(). This would cause a kernel panic in
rfcomm_session_close() then.

This could be easily reproduced during disconnect with devices such as
Motorola H270 that send RFCOMM UA followed quickly by L2CAP disconnect
request. This trace for this looks like:

2009-09-21 17:22:37.788895 < ACL data: handle 1 flags 0x02 dlen 8
   L2CAP(d): cid 0x0041 len 4 [psm 3]
     RFCOMM(s): DISC: cr 0 dlci 20 pf 1 ilen 0 fcs 0x7d
2009-09-21 17:22:37.906204 > HCI Event: Number of Completed Packets (0x13) plen 5
   handle 1 packets 1
2009-09-21 17:22:37.933090 > ACL data: handle 1 flags 0x02 dlen 8
   L2CAP(d): cid 0x0040 len 4 [psm 3]
     RFCOMM(s): UA: cr 0 dlci 20 pf 1 ilen 0 fcs 0x57
2009-09-21 17:22:38.636764 < ACL data: handle 1 flags 0x02 dlen 8
   L2CAP(d): cid 0x0041 len 4 [psm 3]
     RFCOMM(s): DISC: cr 0 dlci 0 pf 1 ilen 0 fcs 0x9c
2009-09-21 17:22:38.744125 > HCI Event: Number of Completed Packets (0x13) plen 5
   handle 1 packets 1
2009-09-21 17:22:38.763687 > ACL data: handle 1 flags 0x02 dlen 8
   L2CAP(d): cid 0x0040 len 4 [psm 3]
     RFCOMM(s): UA: cr 0 dlci 0 pf 1 ilen 0 fcs 0xb6
2009-09-21 17:22:38.783554 > ACL data: handle 1 flags 0x02 dlen 12
   L2CAP(s): Disconn req: dcid 0x0040 scid 0x0041

Avoid calling rfcomm_session_put() twice by skipping this call
in rfcomm_recv_ua() if the socket is closed.

Signed-off-by: Nick Pelly 
Signed-off-by: Marcel Holtmann

Bluetooth: Fix sleeping function in RFCOMM within invalid context

2010-02-03T23:52:18+00:00

With the commit 9e726b17422bade75fba94e625cd35fd1353e682 the
rfcomm_session_put() gets accidentially called from a timeout
callback and results in this:

BUG: sleeping function called from invalid context at net/core/sock.c:1897
in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper
Pid: 0, comm: swapper Tainted: P           2.6.32 #31
Call Trace:
   [] __might_sleep+0xf8/0xfa
 [] lock_sock_nested+0x29/0xc4
 [] lock_sock+0xb/0xd [l2cap]
 [] l2cap_sock_shutdown+0x1c/0x76 [l2cap]
 [] ? clockevents_program_event+0x75/0x7e
 [] ? tick_dev_program_event+0x37/0xa5
 [] l2cap_sock_release+0x27/0x67 [l2cap]
 [] sock_release+0x1a/0x67
 [] rfcomm_session_del+0x34/0x53 [rfcomm]
 [] rfcomm_session_put+0x14/0x16 [rfcomm]
 [] rfcomm_session_timeout+0xe/0x1a [rfcomm]
 [] run_timer_softirq+0x1e2/0x29a
 [] ? rfcomm_session_timeout+0x0/0x1a [rfcomm]
 [] __do_softirq+0xfe/0x1c5
 [] ? timer_interrupt+0x1a/0x21
 [] call_softirq+0x1c/0x28
 [] do_softirq+0x33/0x6b
 [] irq_exit+0x36/0x85
 [] do_IRQ+0xa6/0xbd
 [] ret_from_intr+0x0/0xa
   [] ? acpi_idle_enter_bm+0x269/0x294
 [] ? acpi_idle_enter_bm+0x25f/0x294
 [] ? cpuidle_idle_call+0x97/0x107
 [] ? cpu_idle+0x53/0xaa
 [] ? rest_init+0x7a/0x7c
 [] ? start_kernel+0x389/0x394
 [] ? x86_64_start_reservations+0xac/0xb0
 [] ? x86_64_start_kernel+0xe4/0xeb

To fix this, the rfcomm_session_put() needs to be moved out of
rfcomm_session_timeout() into rfcomm_process_sessions(). In that
context it is perfectly fine to sleep and disconnect the socket.

Signed-off-by: Marcel Holtmann 
Tested-by: David John