linux-stable.git/net, branch v3.19.3

netfilter: nf_tables: fix addition/deletion of elements from commit/abort

2015-03-26T12:59:49+00:00

commit 02263db00b6cb98701332aa257c07ca549c2324b upstream.

We have several problems in this path:

1) There is a use-after-free when removing individual elements from
   the commit path.

2) We have to uninit() the data part of the element from the abort
   path to avoid a chain refcount leak.

3) We have to check for set->flags to see if there's a mapping, instead
   of the element flags.

4) We have to check for !(flags & NFT_SET_ELEM_INTERVAL_END) to skip
   elements that are part of the interval that have no data part, so
   they don't need to be uninit().

Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

netfilter: nf_tables: fix transaction race condition

2015-03-26T12:59:49+00:00

commit 8670c3a55e91cb27a4b4d4d4c4fa35b0149e1abf upstream.

A race condition exists in the rule transaction code for rules that
get added and removed within the same transaction.

The new rule starts out as inactive in the current and active in the
next generation and is inserted into the ruleset. When it is deleted,
it is additionally set to inactive in the next generation as well.

On commit the next generation is begun, then the actions are finalized.
For the new rule this would mean clearing out the inactive bit for
the previously current, now next generation.

However nft_rule_clear() clears out the bits for *both* generations,
activating the rule in the current generation, where it should be
deactivated due to being deleted. The rule will thus be active until
the deletion is finalized, removing the rule from the ruleset.

Similarly, when aborting a transaction for the same case, the undo
of insertion will remove it from the RCU protected rule list, the
deletion will clear out all bits. However until the next RCU
synchronization after all operations have been undone, the rule is
active on CPUs which can still see the rule on the list.

Generally, there may never be any modifications of the current
generations' inactive bit since this defeats the entire purpose of
atomicity. Change nft_rule_clear() to only touch the next generations
bit to fix this.

Signed-off-by: Patrick McHardy 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

netfilter: xt_socket: fix a stack corruption bug

2015-03-26T12:59:49+00:00

commit 78296c97ca1fd3b104f12e1f1fbc06c46635990b upstream.

As soon as extract_icmp6_fields() returns, its local storage (automatic
variables) is deallocated and can be overwritten.

Lets add an additional parameter to make sure storage is valid long
enough.

While we are at it, adds some const qualifiers.

Signed-off-by: Eric Dumazet 
Fixes: b64c9256a9b76 ("tproxy: added IPv6 support to the socket match")
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

netfilter: nft_compat: fix module refcount underflow

2015-03-26T12:59:49+00:00

commit 520aa7414bb590f39d0d1591b06018e60cbc7cf4 upstream.

Feb 12 18:20:42 nfdev kernel: ------------[ cut here ]------------
Feb 12 18:20:42 nfdev kernel: WARNING: CPU: 4 PID: 4359 at kernel/module.c:963 module_put+0x9b/0xba()
Feb 12 18:20:42 nfdev kernel: CPU: 4 PID: 4359 Comm: ebtables-compat Tainted: G        W      3.19.0-rc6+ #43
[...]
Feb 12 18:20:42 nfdev kernel: Call Trace:
Feb 12 18:20:42 nfdev kernel: [] dump_stack+0x4c/0x65
Feb 12 18:20:42 nfdev kernel: [] warn_slowpath_common+0x9c/0xb6
Feb 12 18:20:42 nfdev kernel: [] ? module_put+0x9b/0xba
Feb 12 18:20:42 nfdev kernel: [] warn_slowpath_null+0x15/0x17
Feb 12 18:20:42 nfdev kernel: [] module_put+0x9b/0xba
Feb 12 18:20:42 nfdev kernel: [] nft_match_destroy+0x45/0x4c
Feb 12 18:20:42 nfdev kernel: [] nf_tables_rule_destroy+0x28/0x70

Reported-by: Arturo Borrero Gonzalez 
Signed-off-by: Pablo Neira Ayuso 
Tested-by: Arturo Borrero Gonzalez 
Signed-off-by: Greg Kroah-Hartman

ipvs: fix inability to remove a mixed-family RS

2015-03-26T12:59:48+00:00

commit dd3733b3e798daf778a1ec08557f388f00fdc2f6 upstream.

The current code prevents any operation with a mixed-family dest
unless IP_VS_CONN_F_TUNNEL flag is set. The problem is that it's impossible
for the client to follow this rule, because ip_vs_genl_parse_dest does
not even read the destination conn_flags when cmd = IPVS_CMD_DEL_DEST
(need_full_dest = 0).

Also, not every client can pass this flag when removing a dest. ipvsadm,
for example, does not support the "-i" command line option together with
the "-d" option.

This change disables any checks for mixed-family on IPVS_CMD_DEL_DEST command.

Signed-off-by: Alexey Andriyanov 
Fixes: bc18d37f676f ("ipvs: Allow heterogeneous pools now that we support them")
Acked-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Greg Kroah-Hartman

ipvs: add missing ip_vs_pe_put in sync code

2015-03-26T12:59:48+00:00

commit 528c943f3bb919aef75ab2fff4f00176f09a4019 upstream.

ip_vs_conn_fill_param_sync() gets in param.pe a module
reference for persistence engine from __ip_vs_pe_getbyname()
but forgets to put it. Problem occurs in backup for
sync protocol v1 (2.6.39).

Also, pe_data usually comes in sync messages for
connection templates and ip_vs_conn_new() copies
the pointer only in this case. Make sure pe_data
is not leaked if it comes unexpectedly for normal
connections. Leak can happen only if bogus messages
are sent to backup server.

Fixes: fe5e7a1efb66 ("IPVS: Backup, Adding Version 1 receive capability")
Signed-off-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Greg Kroah-Hartman

can: add missing initialisations in CAN related skbuffs

2015-03-26T12:59:41+00:00

commit 969439016d2cf61fef53a973d7e6d2061c3793b1 upstream.

When accessing CAN network interfaces with AF_PACKET sockets e.g. by dhclient
this can lead to a skb_under_panic due to missing skb initialisations.

Add the missing initialisations at the CAN skbuff creation times on driver
level (rx path) and in the network layer (tx path).

Reported-by: Austin Schuh 
Reported-by: Daniel Steer 
Signed-off-by: Oliver Hartkopp 
Signed-off-by: Marc Kleine-Budde 
Signed-off-by: Greg Kroah-Hartman

net: validate the range we feed to iov_iter_init() in sys_sendto/sys_recvfrom

2015-03-26T12:59:35+00:00

commit 4de930efc23b92ddf88ce91c405ee645fe6e27ea upstream.

Signed-off-by: Al Viro 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: compat: Update get_compat_msghdr() to match copy_msghdr_from_user() behaviour

2015-03-26T12:59:35+00:00

[ Upstream commit 91edd096e224941131f896b86838b1e59553696a ]

Commit db31c55a6fb2 (net: clamp ->msg_namelen instead of returning an
error) introduced the clamping of msg_namelen when the unsigned value
was larger than sizeof(struct sockaddr_storage). This caused a
msg_namelen of -1 to be valid. The native code was subsequently fixed by
commit dbb490b96584 (net: socket: error on a negative msg_namelen).

In addition, the native code sets msg_namelen to 0 when msg_name is
NULL. This was done in commit (6a2a2b3ae075 net:socket: set msg_namelen
to 0 if msg_name is passed as NULL in msghdr struct from userland) and
subsequently updated by 08adb7dabd48 (fold verify_iovec() into
copy_msghdr_from_user()).

This patch brings the get_compat_msghdr() in line with
copy_msghdr_from_user().

Fixes: db31c55a6fb2 (net: clamp ->msg_namelen instead of returning an error)
Cc: David S. Miller 
Cc: Dan Carpenter 
Signed-off-by: Catalin Marinas 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

tcp: fix tcp fin memory accounting

2015-03-26T12:59:35+00:00

[ Upstream commit d22e1537181188e5dc8cbc51451832625035bdc2 ]

tcp_send_fin() does not account for the memory it allocates properly, so
sk_forward_alloc can be negative in cases where we've sent a FIN:

ss example output (ss -amn | grep -B1 f4294):
tcp    FIN-WAIT-1 0      1            192.168.0.1:45520         192.0.2.1:8080
	skmem:(r0,rb87380,t0,tb87380,f4294966016,w1280,o0,bl0)
Acked-by: Eric Dumazet 

Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman