linux-stable.git/net/netfilter, branch v3.10.90

netfilter: Zero the tuple in nfnl_cthelper_parse_tuple()

2015-07-04T02:48:08+00:00

commit 78146572b9cd20452da47951812f35b1ad4906be upstream.

nfnl_cthelper_parse_tuple() is called from nfnl_cthelper_new(),
nfnl_cthelper_get() and nfnl_cthelper_del().  In each case they pass
a pointer to an nf_conntrack_tuple data structure local variable:

    struct nf_conntrack_tuple tuple;
    ...
    ret = nfnl_cthelper_parse_tuple(&tuple, tb[NFCTH_TUPLE]);

The problem is that this local variable is not initialized, and
nfnl_cthelper_parse_tuple() only initializes two fields: src.l3num and
dst.protonum.  This leaves all other fields with undefined values
based on whatever is on the stack:

    tuple->src.l3num = ntohs(nla_get_be16(tb[NFCTH_TUPLE_L3PROTONUM]));
    tuple->dst.protonum = nla_get_u8(tb[NFCTH_TUPLE_L4PROTONUM]);

The symptom observed was that when the rpc and tns helpers were added
then traffic to port 1536 was being sent to user-space.

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

netfilter: nfnetlink_cthelper: Remove 'const' and '&' to avoid warnings

2015-07-04T02:48:08+00:00

commit b18c5d15e8714336365d9d51782d5b53afa0443c upstream.

The related code can be simplified, and also can avoid related warnings
(with allmodconfig under parisc):

    CC [M]  net/netfilter/nfnetlink_cthelper.o
  net/netfilter/nfnetlink_cthelper.c: In function ‘nfnl_cthelper_from_nlattr’:
  net/netfilter/nfnetlink_cthelper.c:97:9: warning: passing argument 1 o ‘memcpy’ discards ‘const’ qualifier from pointer target type [-Wdiscarded-array-qualifiers]
    memcpy(&help->data, nla_data(attr), help->helper->data_len);
           ^
  In file included from include/linux/string.h:17:0,
                   from include/uapi/linux/uuid.h:25,
                   from include/linux/uuid.h:23,
                   from include/linux/mod_devicetable.h:12,
                   from ./arch/parisc/include/asm/hardware.h:4,
                   from ./arch/parisc/include/asm/processor.h:15,
                   from ./arch/parisc/include/asm/spinlock.h:6,
                   from ./arch/parisc/include/asm/atomic.h:21,
                   from include/linux/atomic.h:4,
                   from ./arch/parisc/include/asm/bitops.h:12,
                   from include/linux/bitops.h:36,
                   from include/linux/kernel.h:10,
                   from include/linux/list.h:8,
                   from include/linux/module.h:9,
                   from net/netfilter/nfnetlink_cthelper.c:11:
  ./arch/parisc/include/asm/string.h:8:8: note: expected ‘void *’ but argument is of type ‘const char (*)[]’
   void * memcpy(void * dest,const void *src,size_t count);
          ^

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

netfilter: conntrack: disable generic tracking for known protocols

2015-04-29T08:33:59+00:00

commit db29a9508a9246e77087c5531e45b2c88ec6988b upstream.

Given following iptables ruleset:

-P FORWARD DROP
-A FORWARD -m sctp --dport 9 -j ACCEPT
-A FORWARD -p tcp --dport 80 -j ACCEPT
-A FORWARD -p tcp -m conntrack -m state ESTABLISHED,RELATED -j ACCEPT

One would assume that this allows SCTP on port 9 and TCP on port 80.
Unfortunately, if the SCTP conntrack module is not loaded, this allows
*all* SCTP communication, to pass though, i.e. -p sctp -j ACCEPT,
which we think is a security issue.

This is because on the first SCTP packet on port 9, we create a dummy
"generic l4" conntrack entry without any port information (since
conntrack doesn't know how to extract this information).

All subsequent packets that are unknown will then be in established
state since they will fallback to proto_generic and will match the
'generic' entry.

Our originally proposed version [1] completely disabled generic protocol
tracking, but Jozsef suggests to not track protocols for which a more
suitable helper is available, hence we now mitigate the issue for in
tree known ct protocol helpers only, so that at least NAT and direction
information will still be preserved for others.

 [1] http://www.spinics.net/lists/netfilter-devel/msg33430.html

Joint work with Daniel Borkmann.

Fixes CVE-2014-8160.

Signed-off-by: Florian Westphal 
Signed-off-by: Daniel Borkmann 
Acked-by: Jozsef Kadlecsik 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Zhiqiang Zhang 
Signed-off-by: Greg Kroah-Hartman

core, nfqueue, openvswitch: fix compilation warning

2015-04-19T08:10:50+00:00

Stable commit "core, nfqueue, openvswitch: Orphan frags in
skb_zerocopy and handle errors", upstream commit
36d5fe6a000790f56039afe26834265db0a3ad4c, was not correctly backported
and missed to change a const 'from' parameter to non-const.  This
results in a new batch of warnings:

net/netfilter/nfnetlink_queue_core.c: In function ‘nfqnl_zcopy’:
net/netfilter/nfnetlink_queue_core.c:272:2: warning: passing argument 1 of ‘skb_orphan_frags’ discards ‘const’ qualifier from pointer target type [enabled by default]
  if (unlikely(skb_orphan_frags(from, GFP_ATOMIC))) {
  ^
In file included from net/netfilter/nfnetlink_queue_core.c:18:0:
include/linux/skbuff.h:1822:19: note: expected ‘struct sk_buff *’ but argument is of type ‘const struct sk_buff *’
 static inline int skb_orphan_frags(struct sk_buff *skb, gfp_t gfp_mask)
                   ^
net/netfilter/nfnetlink_queue_core.c:273:3: warning: passing argument 1 of ‘skb_tx_error’ discards ‘const’ qualifier from pointer target type [enabled by default]
   skb_tx_error(from);
   ^
In file included from net/netfilter/nfnetlink_queue_core.c:18:0:
include/linux/skbuff.h:630:13: note: expected ‘struct sk_buff *’ but argument is of type ‘const struct sk_buff *’
 extern void skb_tx_error(struct sk_buff *skb);

Remove const from the 'from' parameter, the same as in the upstream
commit.

As far as I can see, this leaked into 3.10, 3.12, and 3.13 already.

Cc: Zoltan Kiss 
Cc: David S. Miller 
Cc: Ben Hutchings 
Cc: Greg Kroah-Hartman 
Cc: Kamal Mostafa 
Signed-off-by: Jiri Slaby 
Signed-off-by: Greg Kroah-Hartman

ipvs: rerouting to local clients is not needed anymore

2015-03-26T14:01:01+00:00

commit 579eb62ac35845686a7c4286c0a820b4eb1f96aa upstream.

commit f5a41847acc5 ("ipvs: move ip_route_me_harder for ICMP")
from 2.6.37 introduced ip_route_me_harder() call for responses to
local clients, so that we can provide valid rt_src after SNAT.
It was used by TCP to provide valid daddr for ip_send_reply().
After commit 0a5ebb8000c5 ("ipv4: Pass explicit daddr arg to
ip_send_reply()." from 3.0 this rerouting is not needed anymore
and should be avoided, especially in LOCAL_IN.

Fixes 3.12.33 crash in xfrm reported by Florian Wiessner:
"3.12.33 - BUG xfrm_selector_match+0x25/0x2f6"

Reported-by: Smart Weblications GmbH - Florian Wiessner 
Tested-by: Smart Weblications GmbH - Florian Wiessner 
Signed-off-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-26T14:01:01+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

ipvs: uninitialized data with IP_VS_IPV6

2015-01-30T01:40:56+00:00

commit 3b05ac3824ed9648c0d9c02d51d9b54e4e7e874f upstream.

The app_tcp_pkt_out() function expects "*diff" to be set and ends up
using uninitialized data if CONFIG_IP_VS_IPV6 is turned on.

The same issue is there in app_tcp_pkt_in().  Thanks to Julian Anastasov
for noticing that.

Signed-off-by: Dan Carpenter 
Acked-by: Julian Anastasov 
Signed-off-by: Simon Horman 
Signed-off-by: Greg Kroah-Hartman

netfilter: ipset: small potential read beyond the end of buffer

2015-01-27T15:52:33+00:00

commit 2196937e12b1b4ba139806d132647e1651d655df upstream.

We could be reading 8 bytes into a 4 byte buffer here.  It seems
harmless but adding a check is the right thing to do and it silences a
static checker warning.

Signed-off-by: Dan Carpenter 
Acked-by: Jozsef Kadlecsik 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman

netfilter: nf_nat: fix oops on netns removal

2014-11-21T17:22:54+00:00

commit 945b2b2d259d1a4364a2799e80e8ff32f8c6ee6f upstream.

Quoting Samu Kallio:

 Basically what's happening is, during netns cleanup,
 nf_nat_net_exit gets called before ipv4_net_exit. As I understand
 it, nf_nat_net_exit is supposed to kill any conntrack entries which
 have NAT context (through nf_ct_iterate_cleanup), but for some
 reason this doesn't happen (perhaps something else is still holding
 refs to those entries?).

 When ipv4_net_exit is called, conntrack entries (including those
 with NAT context) are cleaned up, but the
 nat_bysource hashtable is long gone - freed in nf_nat_net_exit. The
 bug happens when attempting to free a conntrack entry whose NAT hash
 'prev' field points to a slot in the freed hash table (head for that
 bin).

We ignore conntracks with null nat bindings.  But this is wrong,
as these are in bysource hash table as well.

Restore nat-cleaning for the netns-is-being-removed case.

bug:
https://bugzilla.kernel.org/show_bug.cgi?id=65191

Fixes: c2d421e1718 ('netfilter: nf_nat: fix race when unloading protocol modules')
Reported-by: Samu Kallio 
Debugged-by: Samu Kallio 
Signed-off-by: Florian Westphal 
Tested-by: Samu Kallio 
Signed-off-by: Pablo Neira Ayuso 
[samu.kallio@aberdeencloud.com: backport to 3.10-stable]
Signed-off-by: Samu Kallio 
Signed-off-by: Greg Kroah-Hartman

netfilter: nf_log: release skbuff on nlmsg put failure

2014-11-21T17:22:54+00:00

commit b51d3fa364885a2c1e1668f88776c67c95291820 upstream.

The kernel should reserve enough room in the skb so that the DONE
message can always be appended.  However, in case of e.g. new attribute
erronously not being size-accounted for, __nfulnl_send() will still
try to put next nlmsg into this full skbuf, causing the skb to be stuck
forever and blocking delivery of further messages.

Fix issue by releasing skb immediately after nlmsg_put error and
WARN() so we can track down the cause of such size mismatch.

[ fw@strlen.de: add tailroom/len info to WARN ]

Signed-off-by: Houcheng Lin 
Signed-off-by: Florian Westphal 
Signed-off-by: Pablo Neira Ayuso 
Signed-off-by: Greg Kroah-Hartman