linux-toradex.git/net, branch v3.10.15

netfilter: ipset: Fix serious failure in CIDR tracking

2013-10-01T16:17:48+00:00

commit 2cf55125c64d64cc106e204d53b107094762dfdf upstream.

This fixes a serious bug affecting all hash types with a net element -
specifically, if a CIDR value is deleted such that none of the same size
exist any more, all larger (less-specific) values will then fail to
match. Adding back any prefix with a CIDR equal to or more specific than
the one deleted will fix it.

Steps to reproduce:
ipset -N test hash:net
ipset -A test 1.1.0.0/16
ipset -A test 2.2.2.0/24
ipset -T test 1.1.1.1           #1.1.1.1 IS in set
ipset -D test 2.2.2.0/24
ipset -T test 1.1.1.1           #1.1.1.1 IS NOT in set

This is due to the fact that the nets counter was unconditionally
decremented prior to the iteration that shifts up the entries. Now, we
first check if there is a proceeding entry and if not, decrement it and
return. Otherwise, we proceed to iterate and then zero the last element,
which, in most cases, will already be zero.

Signed-off-by: Oliver Smith 
Signed-off-by: Jozsef Kadlecsik 
Signed-off-by: Greg Kroah-Hartman

rpc: let xdr layer allocate gssproxy receieve pages

2013-10-01T16:17:48+00:00

commit d4a516560fc96a9d486a9939bcb567e3fdce8f49 upstream.

In theory the linux cred in a gssproxy reply can include up to
NGROUPS_MAX data, 256K of data.  In the common case we expect it to be
shorter.  So do as the nfsv3 ACL code does and let the xdr code allocate
the pages as they come in, instead of allocating a lot of pages that
won't typically be used.

Tested-by: Simo Sorce 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

rpc: fix huge kmalloc's in gss-proxy

2013-10-01T16:17:48+00:00

commit 9dfd87da1aeb0fd364167ad199f40fe96a6a87be upstream.

The reply to a gssproxy can include up to NGROUPS_MAX gid's, which will
take up more than a page.  We therefore need to allocate an array of
pages to hold the reply instead of trying to allocate a single huge
buffer.

Tested-by: Simo Sorce 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

rpc: comment on linux_cred encoding, treat all as unsigned

2013-10-01T16:17:48+00:00

commit 6a36978e6931e6601be586eb313375335f2cfaa3 upstream.

The encoding of linux creds is a bit confusing.

Also: I think in practice it doesn't really matter whether we treat any
of these things as signed or unsigned, but unsigned seems more
straightforward: uid_t/gid_t are unsigned and it simplifies the ngroups
overflow check.

Tested-by: Simo Sorce 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

rpc: clean up decoding of gssproxy linux creds

2013-10-01T16:17:48+00:00

commit 778e512bb1d3315c6b55832248cd30c566c081d7 upstream.

We can use the normal coding infrastructure here.

Two minor behavior changes:

	- we're assuming no wasted space at the end of the linux cred.
	  That seems to match gss-proxy's behavior, and I can't see why
	  it would need to do differently in the future.

	- NGROUPS_MAX check added: note groups_alloc doesn't do this,
	  this is the caller's responsibility.

Tested-by: Simo Sorce 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

libceph: use pg_num_mask instead of pgp_num_mask for pg.seed calc

2013-09-27T00:18:29+00:00

commit 9542cf0bf9b1a3adcc2ef271edbcbdba03abf345 upstream.

Fix a typo that used the wrong bitmask for the pg.seed calculation.  This
is normally unnoticed because in most cases pg_num == pgp_num.  It is, however,
a bug that is easily corrected.

Signed-off-by: Sage Weil 
Reviewed-by: Alex Elder 
Signed-off-by: Greg Kroah-Hartman

libceph: unregister request in __map_request failed and nofail == false

2013-09-27T00:18:29+00:00

commit 73d9f7eef3d98c3920e144797cc1894c6b005a1e upstream.

For nofail == false request, if __map_request failed, the caller does
cleanup work, like releasing the relative pages.  It doesn't make any sense
to retry this request.

Signed-off-by: Jianpeng Ma 
Reviewed-by: Sage Weil 
Signed-off-by: Greg Kroah-Hartman

net: Check the correct namespace when spoofing pid over SCM_RIGHTS

2013-09-27T00:18:05+00:00

commit d661684cf6820331feae71146c35da83d794467e upstream.

This is a security bug.

The follow-up will fix nsproxy to discourage this type of issue from
happening again.

Signed-off-by: Andy Lutomirski 
Reviewed-by: "Eric W. Biederman" 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

net: ipv6: tcp: fix potential use after free in tcp_v6_do_rcv

2013-09-14T13:54:56+00:00

[ Upstream commit 3a1c756590633c0e86df606e5c618c190926a0df ]

In tcp_v6_do_rcv() code, when processing pkt options, we soley work
on our skb clone opt_skb that we've created earlier before entering
tcp_rcv_established() on our way. However, only in condition ...

  if (np->rxopt.bits.rxtclass)
    np->rcv_tclass = ipv6_get_dsfield(ipv6_hdr(skb));

... we work on skb itself. As we extract every other information out
of opt_skb in ipv6_pktoptions path, this seems wrong, since skb can
already be released by tcp_rcv_established() earlier on. When we try
to access it in ipv6_hdr(), we will dereference freed skb.

[ Bug added by commit 4c507d2897bd9b ("net: implement IP_RECVTOS for
  IP_PKTOPTIONS") ]

Signed-off-by: Daniel Borkmann 
Cc: Eric Dumazet 
Acked-by: Eric Dumazet 
Acked-by: Jiri Benc 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

ipv6: fix null pointer dereference in __ip6addrlbl_add

2013-09-14T13:54:56+00:00

[ Upstream commit 639739b5e609a5074839bb22fc061b37baa06269 ]

Commit b67bfe0d42cac56c512dd5da4b1b347a23f4b70a ("hlist: drop
the node parameter from iterators") changed the behavior of
hlist_for_each_entry_safe to leave the p argument NULL.

Fix this up by tracking the last argument.

Reported-by: Michele Baldessari 
Cc: Hideaki YOSHIFUJI 
Cc: Sasha Levin 
Signed-off-by: Hannes Frederic Sowa 
Tested-by: Michele Baldessari 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman