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

bluetooth: Validate socket address length in sco_sock_bind().

2016-01-29T21:12:43+00:00

commit 5233252fce714053f0151680933571a2da9cbfb4 upstream.

Signed-off-by: David S. Miller 
Signed-off-by: Ben Hutchings 
Signed-off-by: Willy Tarreau

net: rework recvmsg handler msg_name and msg_namelen logic

2014-05-19T05:54:00+00:00

CVE-2013-7266

BugLink: http://bugs.launchpad.net/bugs/1267081

This patch now always passes msg->msg_namelen as 0. recvmsg handlers must
set msg_namelen to the proper size <= sizeof(struct sockaddr_storage)
to return msg_name to the user.

This prevents numerous uninitialized memory leaks we had in the
recvmsg handlers and makes it harder for new code to accidentally leak
uninitialized memory.

Optimize for the case recvfrom is called with NULL as address. We don't
need to copy the address at all, so set it to NULL before invoking the
recvmsg handler. We can do so, because all the recvmsg handlers must
cope with the case a plain read() is called on them. read() also sets
msg_name to NULL.

Also document these changes in include/linux/net.h as suggested by David
Miller.

Changes since RFC:

Set msg->msg_name = NULL if user specified a NULL in msg_name but had a
non-null msg_namelen in verify_iovec/verify_compat_iovec. This doesn't
affect sendto as it would bail out earlier while trying to copy-in the
address. It also more naturally reflects the logic by the callers of
verify_iovec.

With this change in place I could remove "
if (!uaddr || msg_sys->msg_namelen == 0)
	msg->msg_name = NULL
".

This change does not alter the user visible error logic as we ignore
msg_namelen as long as msg_name is NULL.

Also remove two unnecessary curly brackets in ___sys_recvmsg and change
comments to netdev style.

Cc: David Miller 
Suggested-by: Eric Dumazet 
Signed-off-by: Hannes Frederic Sowa 
Signed-off-by: David S. Miller 
(back ported from commit f3d3342602f8bcbf37d7c46641cb9bca7618eb1c)
Signed-off-by: Luis Henriques 
Acked-by: Andy Whitcroft 
Acked-by: Stefan Bader 
Signed-off-by: Tim Gardner 
Signed-off-by: Willy Tarreau

Bluetooth: fix possible info leak in bt_sock_recvmsg()

2013-06-10T09:43:00+00:00

commit 4683f42fde3977bdb4e8a09622788cc8b5313778 upstream.

In case the socket is already shutting down, bt_sock_recvmsg() returns
with 0 without updating msg_namelen leading to net/socket.c leaking the
local, uninitialized sockaddr_storage variable to userland -- 128 bytes
of kernel stack memory.

Fix this by moving the msg_namelen assignment in front of the shutdown
test.

Cc: Marcel Holtmann 
Cc: Gustavo Padovan 
Cc: Johan Hedberg 
Signed-off-by: Mathias Krause 
Signed-off-by: David S. Miller 
[dannf: adjusted to apply to Debian's 2.6.32]
Signed-off-by: Willy Tarreau

Bluetooth: L2CAP - Fix info leak via getsockname()

2013-06-10T09:43:00+00:00

commit 792039c73cf176c8e39a6e8beef2c94ff46522ed upstream.

The L2CAP code fails to initialize the l2_bdaddr_type member of struct
sockaddr_l2 and the padding byte added for alignment. It that for leaks
two bytes kernel stack via the getsockname() syscall. Add an explicit
memset(0) before filling the structure to avoid the info leak.

Signed-off-by: Mathias Krause 
Cc: Marcel Holtmann 
Cc: Gustavo Padovan 
Cc: Johan Hedberg 
Signed-off-by: David S. Miller 
[bwh: Backported to 2.6.32: adjust filename]
Signed-off-by: Willy Tarreau

Bluetooth: RFCOMM - Fix missing msg_namelen update in rfcomm_sock_recvmsg()

2013-06-10T09:42:59+00:00

[ Upstream commit e11e0455c0d7d3d62276a0c55d9dfbc16779d691 ]

If RFCOMM_DEFER_SETUP is set in the flags, rfcomm_sock_recvmsg() returns
early with 0 without updating the possibly set msg_namelen member. This,
in turn, leads to a 128 byte kernel stack leak in net/socket.c.

Fix this by updating msg_namelen in this case. For all other cases it
will be handled in bt_sock_stream_recvmsg().

Signed-off-by: Mathias Krause 
Cc: Marcel Holtmann 
Cc: Gustavo Padovan 
Cc: Johan Hedberg 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

Bluetooth: RFCOMM - Fix info leak via getsockname()

2013-06-10T09:42:59+00:00

[ Upstream commit 9344a972961d1a6d2c04d9008b13617bcb6ec2ef ]

The RFCOMM code fails to initialize the trailing padding byte of struct
sockaddr_rc added for alignment. It that for leaks one byte kernel stack
via the getsockname() syscall. Add an explicit memset(0) before filling
the structure to avoid the info leak.

Signed-off-by: Mathias Krause 
Cc: Marcel Holtmann 
Cc: Gustavo Padovan 
Cc: Johan Hedberg 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

Bluetooth: HCI - Fix info leak in getsockopt(HCI_FILTER)

2013-06-10T09:42:58+00:00

[ Upstream commit e15ca9a0ef9a86f0477530b0f44a725d67f889ee ]

The HCI code fails to initialize the two padding bytes of struct
hci_ufilter before copying it to userland -- that for leaking two
bytes kernel stack. Add an explicit memset(0) before filling the
structure to avoid the info leak.

Signed-off-by: Mathias Krause 
Cc: Marcel Holtmann 
Cc: Gustavo Padovan 
Cc: Johan Hedberg 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau

Bluetooth: Fix incorrect strncpy() in hidp_setup_hid()

2013-06-10T09:42:58+00:00

commit 0a9ab9bdb3e891762553f667066190c1d22ad62b upstream

The length parameter should be sizeof(req->name) - 1 because there is no
guarantee that string provided by userspace will contain the trailing
'\0'.

Can be easily reproduced by manually setting req->name to 128 non-zero
bytes prior to ioctl(HIDPCONNADD) and checking the device name setup on
input subsystem:

$ cat /sys/devices/pnp0/00\:04/tty/ttyS0/hci0/hci0\:1/input8/name
AAAAAA[...]AAAAAAAAf0:af:f0:af:f0:af

("f0:af:f0:af:f0:af" is the device bluetooth address, taken from "phys"
field in struct hid_device due to overflow.)

Cc: stable@vger.kernel.org
Signed-off-by: Anderson Lizardo 
Acked-by: Marcel Holtmann 
Signed-off-by: Gustavo Padovan 

[backported to 2.6.32 jmm]
Signed-off-by: Willy Tarreau

tty: icount changeover for other main devices

2011-11-26T17:10:38+00:00

commit 0587102cf9f427c185bfdeb2cef41e13ee0264b1 upstream

Again basically cut and paste

Convert the main driver set to use the hooks for GICOUNT

Signed-off-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Dan Carpenter

Bluetooth: Prevent buffer overflow in l2cap config request

2011-11-07T20:32:51+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