linux-stable.git/net, branch linux-2.6.34.y

phonet: Check input from user before allocating

2014-02-10T21:11:38+00:00

commit bcf1b70ac6eb0ed8286c66e6bf37cb747cbaa04c upstream.

A phonet packet is limited to USHRT_MAX bytes, this is never checked during
tx which means that the user can specify any size he wishes, and the kernel
will attempt to allocate that size.

In the good case, it'll lead to the following warning, but it may also cause
the kernel to kick in the OOM and kill a random task on the server.

[ 8921.744094] WARNING: at mm/page_alloc.c:2255 __alloc_pages_slowpath+0x65/0x730()
[ 8921.749770] Pid: 5081, comm: trinity Tainted: G        W    3.4.0-rc1-next-20120402-sasha #46
[ 8921.756672] Call Trace:
[ 8921.758185]  [] warn_slowpath_common+0x87/0xb0
[ 8921.762868]  [] warn_slowpath_null+0x15/0x20
[ 8921.765399]  [] __alloc_pages_slowpath+0x65/0x730
[ 8921.769226]  [] ? zone_watermark_ok+0x1a/0x20
[ 8921.771686]  [] ? get_page_from_freelist+0x625/0x660
[ 8921.773919]  [] __alloc_pages_nodemask+0x1f8/0x240
[ 8921.776248]  [] kmalloc_large_node+0x70/0xc0
[ 8921.778294]  [] __kmalloc_node_track_caller+0x34/0x1c0
[ 8921.780847]  [] ? sock_alloc_send_pskb+0xbc/0x260
[ 8921.783179]  [] __alloc_skb+0x75/0x170
[ 8921.784971]  [] sock_alloc_send_pskb+0xbc/0x260
[ 8921.787111]  [] ? release_sock+0x7e/0x90
[ 8921.788973]  [] sock_alloc_send_skb+0x10/0x20
[ 8921.791052]  [] pep_sendmsg+0x60/0x380
[ 8921.792931]  [] ? pn_socket_bind+0x156/0x180
[ 8921.794917]  [] ? pn_socket_autobind+0x3f/0x90
[ 8921.797053]  [] pn_socket_sendmsg+0x4f/0x70
[ 8921.798992]  [] sock_aio_write+0x187/0x1b0
[ 8921.801395]  [] ? sub_preempt_count+0xae/0xf0
[ 8921.803501]  [] ? __lock_acquire+0x42c/0x4b0
[ 8921.805505]  [] ? __sock_recv_ts_and_drops+0x140/0x140
[ 8921.807860]  [] do_sync_readv_writev+0xbc/0x110
[ 8921.809986]  [] ? might_fault+0x97/0xa0
[ 8921.811998]  [] ? security_file_permission+0x1e/0x90
[ 8921.814595]  [] do_readv_writev+0xe2/0x1e0
[ 8921.816702]  [] ? do_setitimer+0x1ac/0x200
[ 8921.818819]  [] ? get_parent_ip+0x11/0x50
[ 8921.820863]  [] ? sub_preempt_count+0xae/0xf0
[ 8921.823318]  [] vfs_writev+0x46/0x60
[ 8921.825219]  [] sys_writev+0x4f/0xb0
[ 8921.827127]  [] system_call_fastpath+0x16/0x1b
[ 8921.829384] ---[ end trace dffe390f30db9eb7 ]---

Signed-off-by: Sasha Levin 
Acked-by: Rémi Denis-Courmont 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

cipso: don't follow a NULL pointer when setsockopt() is called

2014-02-10T21:11:36+00:00

commit a9d0acf8d157c30374af76d43e7f05b5b108be0c upstream.

[ Upstream commit 89d7ae34cdda4195809a5a987f697a517a2a3177 ]

As reported by Alan Cox, and verified by Lin Ming, when a user
attempts to add a CIPSO option to a socket using the CIPSO_V4_TAG_LOCAL
tag the kernel dies a terrible death when it attempts to follow a NULL
pointer (the skb argument to cipso_v4_validate() is NULL when called via
the setsockopt() syscall).

This patch fixes this by first checking to ensure that the skb is
non-NULL before using it to find the incoming network interface.  In
the unlikely case where the skb is NULL and the user attempts to add
a CIPSO option with the _TAG_LOCAL tag we return an error as this is
not something we want to allow.

A simple reproducer, kindly supplied by Lin Ming, although you must
have the CIPSO DOI #3 configure on the system first or you will be
caught early in cipso_v4_validate():

	#include 
	#include 
	#include 
	#include 
	#include 

	struct local_tag {
		char type;
		char length;
		char info[4];
	};

	struct cipso {
		char type;
		char length;
		char doi[4];
		struct local_tag local;
	};

	int main(int argc, char **argv)
	{
		int sockfd;
		struct cipso cipso = {
			.type = IPOPT_CIPSO,
			.length = sizeof(struct cipso),
			.local = {
				.type = 128,
				.length = sizeof(struct local_tag),
			},
		};

		memset(cipso.doi, 0, 4);
		cipso.doi[3] = 3;

		sockfd = socket(AF_INET, SOCK_DGRAM, 0);
		#define SOL_IP 0
		setsockopt(sockfd, SOL_IP, IP_OPTIONS,
			&cipso, sizeof(struct cipso));

		return 0;
	}

CC: Lin Ming 
Reported-by: Alan Cox 
Signed-off-by: Paul Moore 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Willy Tarreau 
Signed-off-by: Paul Gortmaker

svcrpc: fix svc_xprt_enqueue/svc_recv busy-looping

2014-02-10T21:11:34+00:00

commit d10f27a750312ed5638c876e4bd6aa83664cccd8 upstream.

The rpc server tries to ensure that there will be room to send a reply
before it receives a request.

It does this by tracking, in xpt_reserved, an upper bound on the total
size of the replies that is has already committed to for the socket.

Currently it is adding in the estimate for a new reply *before* it
checks whether there is space available.  If it finds that there is not
space, it then subtracts the estimate back out.

This may lead the subsequent svc_xprt_enqueue to decide that there is
space after all.

The results is a svc_recv() that will repeatedly return -EAGAIN, causing
server threads to loop without doing any actual work.

Reported-by: Michael Tokarev 
Tested-by: Michael Tokarev 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Paul Gortmaker

svcrpc: sends on closed socket should stop immediately

2014-02-10T21:11:34+00:00

commit f06f00a24d76e168ecb38d352126fd203937b601 upstream.

svc_tcp_sendto sets XPT_CLOSE if we fail to transmit the entire reply.
However, the XPT_CLOSE won't be acted on immediately.  Meanwhile other
threads could send further replies before the socket is really shut
down.  This can manifest as data corruption: for example, if a truncated
read reply is followed by another rpc reply, that second reply will look
to the client like further read data.

Symptoms were data corruption preceded by svc_tcp_sendto logging
something like

	kernel: rpc-srv/tcp: nfsd: sent only 963696 when sending 1048708 bytes - shutting down socket

Reported-by: Malahal Naineni 
Tested-by: Malahal Naineni 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Paul Gortmaker

dccp: check ccid before dereferencing

2014-02-10T21:11:33+00:00

commit 276bdb82dedb290511467a5a4fdbe9f0b52dce6f upstream.

ccid_hc_rx_getsockopt() and ccid_hc_tx_getsockopt() might be called with
a NULL ccid pointer leading to a NULL pointer dereference. This could
lead to a privilege escalation if the attacker is able to map page 0 and
prepare it with a fake ccid_ops pointer.

Signed-off-by: Mathias Krause 
Cc: Gerrit Renker 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

Bluetooth: fix possible info leak in bt_sock_recvmsg()

2014-02-10T21:11:17+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 
Signed-off-by: Paul Gortmaker

Bluetooth: L2CAP - Fix info leak via getsockname()

2014-02-10T21:11:17+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 
[PG: net/bluetooth/l2cap_sock.c --> net/bluetooth/l2cap.c in .34]
Signed-off-by: Paul Gortmaker

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

2014-02-10T21:11:17+00:00

commit e11e0455c0d7d3d62276a0c55d9dfbc16779d691 upstream.

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().

Cc: Marcel Holtmann 
Cc: Gustavo Padovan 
Cc: Johan Hedberg 
Signed-off-by: Mathias Krause 
Signed-off-by: David S. Miller 
Signed-off-by: Paul Gortmaker

Bluetooth: RFCOMM - Fix info leak via getsockname()

2014-02-10T21:11:17+00:00

commit 9344a972961d1a6d2c04d9008b13617bcb6ec2ef upstream.

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: Paul Gortmaker

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

2014-02-10T21:11:16+00:00

commit e15ca9a0ef9a86f0477530b0f44a725d67f889ee upstream.

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: Paul Gortmaker