Netdev List
 help / color / mirror / Atom feed
* Re: KASAN: slab-out-of-bounds Read in bpf_skb_change_proto
From: Daniel Borkmann @ 2018-06-11 10:31 UTC (permalink / raw)
  To: Dmitry Vyukov
  Cc: syzbot, Alexei Starovoitov, David Miller, LKML, netdev,
	syzkaller-bugs
In-Reply-To: <CACT4Y+boO990R6a9kGtx-UZpZPeB2bwhgvyUjPvEFOpbzxJKrg@mail.gmail.com>

On 06/11/2018 11:52 AM, Dmitry Vyukov wrote:
> On Mon, Jun 11, 2018 at 11:42 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
>> On 06/10/2018 05:27 PM, syzbot wrote:
>>> Hello,
>>>
>>> syzbot found the following crash on:
>>>
>>> HEAD commit:    a16afaf7928b Merge tag 'for-v4.18' of git://git.kernel.org..
>>> git tree:       upstream
>>> console output: https://syzkaller.appspot.com/x/log.txt?x=1338f6bf800000
>>> kernel config:  https://syzkaller.appspot.com/x/.config?x=314f2150f36c16ca
>>> dashboard link: https://syzkaller.appspot.com/bug?extid=d2d729bdde65dee3eae6
>>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1173381f800000
>>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=171f90cf800000
>>>
>>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>>> Reported-by: syzbot+d2d729bdde65dee3eae6@syzkaller.appspotmail.com
>>
>> #syz fix: bpf: reject passing modified ctx to helper functions
> 
> On a related note, it seems that it still can unwind past
> bpf_skb_change_proto. I think the "net.core.bpf_jit_kallsyms = 1"
> sysctl should have been reached syzbot by the time of crash. Are you
> sure that's the only thing requires? We are using frame pointer
> unwinder just in case.

Nah, I know what happened; just sent a PR fix for syzkaller.

Thanks,
Daniel

^ permalink raw reply

* Re: WARNING in smc_unhash_sk
From: Davide Caratti @ 2018-06-11 10:16 UTC (permalink / raw)
  To: Dmitry Vyukov; +Cc: David Miller, netdev, syzkaller-bugs, ubraun
In-Reply-To: <CACT4Y+byLAh+RoGc-a_b446jMmR2kwkWcnDVzCB6msKeS1yZXA@mail.gmail.com>

On Fri, 2018-06-08 at 09:53 +0200, Dmitry Vyukov wrote:
> On Tue, Feb 27, 2018 at 1:23 PM, Davide Caratti <dcaratti@redhat.com> wrote:
> > On Fri, 2018-02-23 at 07:59 -0800, syzbot wrote:
> > > Hello,
> > > 
> > > syzbot hit the following crash on upstream commit
> > > 

...

> > 
> > #syz test: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
> 
> 
> Hi Davide,
> 
> Any progress on this?
> 

hi Dmitry,

I'm not working on this bug at all. The mail above was an attempt to test
commit a5dcb73b96a9 ("net/smc: fix NULL pointer dereference on
sock_create_kern() error path"), where I replied to the wrong syzbot
message. Since a single error was not enough, I also put netdev in CC:
sorry for the spam :)

regards,
-- 
davide

^ permalink raw reply

* Re: KASAN: slab-out-of-bounds Read in bpf_skb_change_proto
From: Dmitry Vyukov @ 2018-06-11  9:52 UTC (permalink / raw)
  To: Daniel Borkmann
  Cc: syzbot, Alexei Starovoitov, David Miller, LKML, netdev,
	syzkaller-bugs
In-Reply-To: <76483220-226b-bf3c-d529-ea839d6624c6@iogearbox.net>

On Mon, Jun 11, 2018 at 11:42 AM, Daniel Borkmann <daniel@iogearbox.net> wrote:
> On 06/10/2018 05:27 PM, syzbot wrote:
>> Hello,
>>
>> syzbot found the following crash on:
>>
>> HEAD commit:    a16afaf7928b Merge tag 'for-v4.18' of git://git.kernel.org..
>> git tree:       upstream
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1338f6bf800000
>> kernel config:  https://syzkaller.appspot.com/x/.config?x=314f2150f36c16ca
>> dashboard link: https://syzkaller.appspot.com/bug?extid=d2d729bdde65dee3eae6
>> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
>> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1173381f800000
>> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=171f90cf800000
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: syzbot+d2d729bdde65dee3eae6@syzkaller.appspotmail.com
>
> #syz fix: bpf: reject passing modified ctx to helper functions


On a related note, it seems that it still can unwind past
bpf_skb_change_proto. I think the "net.core.bpf_jit_kallsyms = 1"
sysctl should have been reached syzbot by the time of crash. Are you
sure that's the only thing requires? We are using frame pointer
unwinder just in case.

^ permalink raw reply

* Re: KASAN: slab-out-of-bounds Read in bpf_skb_change_proto
From: Daniel Borkmann @ 2018-06-11  9:42 UTC (permalink / raw)
  To: syzbot, ast, davem, linux-kernel, netdev, syzkaller-bugs
In-Reply-To: <000000000000c64842056e4b4326@google.com>

On 06/10/2018 05:27 PM, syzbot wrote:
> Hello,
> 
> syzbot found the following crash on:
> 
> HEAD commit:    a16afaf7928b Merge tag 'for-v4.18' of git://git.kernel.org..
> git tree:       upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=1338f6bf800000
> kernel config:  https://syzkaller.appspot.com/x/.config?x=314f2150f36c16ca
> dashboard link: https://syzkaller.appspot.com/bug?extid=d2d729bdde65dee3eae6
> compiler:       gcc (GCC) 8.0.1 20180413 (experimental)
> syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=1173381f800000
> C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=171f90cf800000
> 
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+d2d729bdde65dee3eae6@syzkaller.appspotmail.com

#syz fix: bpf: reject passing modified ctx to helper functions

^ permalink raw reply

* Re: [PATCH net] KEYS: DNS: fix parsing multiple options
From: Simon Horman @ 2018-06-11  9:40 UTC (permalink / raw)
  To: Eric Biggers
  Cc: netdev, David S . Miller, keyrings, David Howells, Wang Lei,
	Eric Biggers
In-Reply-To: <20180608162037.129802-1-ebiggers3@gmail.com>

On Fri, Jun 08, 2018 at 09:20:37AM -0700, Eric Biggers wrote:
> From: Eric Biggers <ebiggers@google.com>
> 
> My recent fix for dns_resolver_preparse() printing very long strings was
> incomplete, as shown by syzbot which still managed to hit the
> WARN_ONCE() in set_precision() by adding a crafted "dns_resolver" key:
> 
>     precision 50001 too large
>     WARNING: CPU: 7 PID: 864 at lib/vsprintf.c:2164 vsnprintf+0x48a/0x5a0
> 
> The bug this time isn't just a printing bug, but also a logical error
> when multiple options ("#"-separated strings) are given in the key
> payload.  Specifically, when separating an option string into name and
> value, if there is no value then the name is incorrectly considered to
> end at the end of the key payload, rather than the end of the current
> option.  This bypasses validation of the option length, and also means
> that specifying multiple options is broken -- which presumably has gone
> unnoticed as there is currently only one valid option anyway.
> 
> Fix it by correctly calculating the length of the option name.
> 
> Reproducer:
> 
>     perl -e 'print "#A#", "\x00" x 50000' | keyctl padd dns_resolver desc @s
> 
> Fixes: 4a2d789267e0 ("DNS: If the DNS server returns an error, allow that to be cached [ver #2]")
> Signed-off-by: Eric Biggers <ebiggers@google.com>
> ---
>  net/dns_resolver/dns_key.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/net/dns_resolver/dns_key.c b/net/dns_resolver/dns_key.c
> index 40c851693f77e..d448823d4d2ed 100644
> --- a/net/dns_resolver/dns_key.c
> +++ b/net/dns_resolver/dns_key.c
> @@ -97,7 +97,7 @@ dns_resolver_preparse(struct key_preparsed_payload *prep)
>  				return -EINVAL;
>  			}
>  
> -			eq = memchr(opt, '=', opt_len) ?: end;
> +			eq = memchr(opt, '=', opt_len) ?: next_opt;
>  			opt_nlen = eq - opt;
>  			eq++;

It seems risky to advance eq++ in the case there the value is empty.
Its not not pointing to the value but it may be accessed twice further on
in this loop.

>  			opt_vlen = next_opt - eq; /* will be -1 if no value */
> -- 
> 2.18.0.rc1.242.g61856ae69a-goog
> 

^ permalink raw reply

* [PATCH 03/15] ipvs: register conntrack hooks for ftp
From: Pablo Neira Ayuso @ 2018-06-11  9:22 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180611092233.3219-1-pablo@netfilter.org>

From: Julian Anastasov <ja@ssi.bg>

ip_vs_ftp requires conntrack modules for mangling
of FTP command responses in passive mode.

Make sure the conntrack hooks are registered when
real servers use NAT method in FTP virtual service.
The hooks will be registered while the service is
present.

Fixes: 0c66dc1ea3f0 ("netfilter: conntrack: register hooks in netns when needed by ruleset")
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 include/net/ip_vs.h            | 30 ++++++++++++++++++++++++++++++
 net/netfilter/ipvs/ip_vs_ctl.c |  4 ++++
 2 files changed, 34 insertions(+)

diff --git a/include/net/ip_vs.h b/include/net/ip_vs.h
index eb0bec043c96..ae72d9057eda 100644
--- a/include/net/ip_vs.h
+++ b/include/net/ip_vs.h
@@ -643,6 +643,7 @@ struct ip_vs_service {
 
 	/* alternate persistence engine */
 	struct ip_vs_pe __rcu	*pe;
+	int			conntrack_afmask;
 
 	struct rcu_head		rcu_head;
 };
@@ -1620,6 +1621,35 @@ static inline bool ip_vs_conn_uses_conntrack(struct ip_vs_conn *cp,
 	return false;
 }
 
+static inline int ip_vs_register_conntrack(struct ip_vs_service *svc)
+{
+#if IS_ENABLED(CONFIG_NF_CONNTRACK)
+	int afmask = (svc->af == AF_INET6) ? 2 : 1;
+	int ret = 0;
+
+	if (!(svc->conntrack_afmask & afmask)) {
+		ret = nf_ct_netns_get(svc->ipvs->net, svc->af);
+		if (ret >= 0)
+			svc->conntrack_afmask |= afmask;
+	}
+	return ret;
+#else
+	return 0;
+#endif
+}
+
+static inline void ip_vs_unregister_conntrack(struct ip_vs_service *svc)
+{
+#if IS_ENABLED(CONFIG_NF_CONNTRACK)
+	int afmask = (svc->af == AF_INET6) ? 2 : 1;
+
+	if (svc->conntrack_afmask & afmask) {
+		nf_ct_netns_put(svc->ipvs->net, svc->af);
+		svc->conntrack_afmask &= ~afmask;
+	}
+#endif
+}
+
 static inline int
 ip_vs_dest_conn_overhead(struct ip_vs_dest *dest)
 {
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 3ecca0616d8c..ee0ab278f1f1 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -835,6 +835,9 @@ __ip_vs_update_dest(struct ip_vs_service *svc, struct ip_vs_dest *dest,
 		 *    For now only for NAT!
 		 */
 		ip_vs_rs_hash(ipvs, dest);
+		/* FTP-NAT requires conntrack for mangling */
+		if (svc->port == FTPPORT)
+			ip_vs_register_conntrack(svc);
 	}
 	atomic_set(&dest->conn_flags, conn_flags);
 
@@ -1458,6 +1461,7 @@ static void __ip_vs_del_service(struct ip_vs_service *svc, bool cleanup)
  */
 static void ip_vs_unlink_service(struct ip_vs_service *svc, bool cleanup)
 {
+	ip_vs_unregister_conntrack(svc);
 	/* Hold svc to avoid double release from dest_trash */
 	atomic_inc(&svc->refcnt);
 	/*
-- 
2.11.0

^ permalink raw reply related

* [PATCH 15/15] netfilter: remove include/net/netfilter/nft_dup.h
From: Pablo Neira Ayuso @ 2018-06-11  9:22 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180611092233.3219-1-pablo@netfilter.org>

From: Corentin Labbe <clabbe@baylibre.com>

include/net/netfilter/nft_dup.h was introduced in d877f07112f1 ("netfilter: nf_tables: add nft_dup expression")
but was never user since this date.

Furthermore, the only struct in this file is unused elsewhere.

Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 include/net/netfilter/nft_dup.h | 10 ----------
 1 file changed, 10 deletions(-)
 delete mode 100644 include/net/netfilter/nft_dup.h

diff --git a/include/net/netfilter/nft_dup.h b/include/net/netfilter/nft_dup.h
deleted file mode 100644
index 4d9d512984b2..000000000000
--- a/include/net/netfilter/nft_dup.h
+++ /dev/null
@@ -1,10 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-#ifndef _NFT_DUP_H_
-#define _NFT_DUP_H_
-
-struct nft_dup_inet {
-	enum nft_registers	sreg_addr:8;
-	enum nft_registers	sreg_dev:8;
-};
-
-#endif /* _NFT_DUP_H_ */
-- 
2.11.0

^ permalink raw reply related

* [PATCH 14/15] netfilter: x_tables: initialise match/target check parameter struct
From: Pablo Neira Ayuso @ 2018-06-11  9:22 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180611092233.3219-1-pablo@netfilter.org>

From: Florian Westphal <fw@strlen.de>

syzbot reports following splat:

BUG: KMSAN: uninit-value in ebt_stp_mt_check+0x24b/0x450
 net/bridge/netfilter/ebt_stp.c:162
 ebt_stp_mt_check+0x24b/0x450 net/bridge/netfilter/ebt_stp.c:162
 xt_check_match+0x1438/0x1650 net/netfilter/x_tables.c:506
 ebt_check_match net/bridge/netfilter/ebtables.c:372 [inline]
 ebt_check_entry net/bridge/netfilter/ebtables.c:702 [inline]

The uninitialised access is
   xt_mtchk_param->nft_compat

... which should be set to 0.
Fix it by zeroing the struct beforehand, same for tgchk.

ip(6)tables targetinfo uses c99-style initialiser, so no change
needed there.

Reported-by: syzbot+da4494182233c23a5fcf@syzkaller.appspotmail.com
Fixes: 55917a21d0cc0 ("netfilter: x_tables: add context to know if extension runs from nft_compat")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/bridge/netfilter/ebtables.c | 2 ++
 net/ipv4/netfilter/ip_tables.c  | 1 +
 net/ipv6/netfilter/ip6_tables.c | 1 +
 3 files changed, 4 insertions(+)

diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 08a65e4a77d0..ead123dab05e 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -700,6 +700,8 @@ ebt_check_entry(struct ebt_entry *e, struct net *net,
 	}
 	i = 0;
 
+	memset(&mtpar, 0, sizeof(mtpar));
+	memset(&tgpar, 0, sizeof(tgpar));
 	mtpar.net	= tgpar.net       = net;
 	mtpar.table     = tgpar.table     = name;
 	mtpar.entryinfo = tgpar.entryinfo = e;
diff --git a/net/ipv4/netfilter/ip_tables.c b/net/ipv4/netfilter/ip_tables.c
index e85f35b89c49..f6130704f052 100644
--- a/net/ipv4/netfilter/ip_tables.c
+++ b/net/ipv4/netfilter/ip_tables.c
@@ -531,6 +531,7 @@ find_check_entry(struct ipt_entry *e, struct net *net, const char *name,
 		return -ENOMEM;
 
 	j = 0;
+	memset(&mtpar, 0, sizeof(mtpar));
 	mtpar.net	= net;
 	mtpar.table     = name;
 	mtpar.entryinfo = &e->ip;
diff --git a/net/ipv6/netfilter/ip6_tables.c b/net/ipv6/netfilter/ip6_tables.c
index 97f79dc943d7..685c2168f524 100644
--- a/net/ipv6/netfilter/ip6_tables.c
+++ b/net/ipv6/netfilter/ip6_tables.c
@@ -551,6 +551,7 @@ find_check_entry(struct ip6t_entry *e, struct net *net, const char *name,
 		return -ENOMEM;
 
 	j = 0;
+	memset(&mtpar, 0, sizeof(mtpar));
 	mtpar.net	= net;
 	mtpar.table     = name;
 	mtpar.entryinfo = &e->ipv6;
-- 
2.11.0

^ permalink raw reply related

* [PATCH 13/15] netfilter: nf_conntrack: Increase __IPS_MAX_BIT with new bit IPS_OFFLOAD_BIT
From: Pablo Neira Ayuso @ 2018-06-11  9:22 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180611092233.3219-1-pablo@netfilter.org>

From: Gao Feng <gfree.wind@vip.163.com>

The __IPS_MAX_BIT is used in __ctnetlink_change_status as the max bit
value. When add new bit IPS_OFFLOAD_BIT whose value is 14, we should
increase the __IPS_MAX_BIT too, from 14 to 15.

There is no any bug in current codes, although it lost one loop in
__ctnetlink_change_status. Because the new bit IPS_OFFLOAD_BIT belongs
the IPS_UNCHANGEABLE_MASK.

Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 include/uapi/linux/netfilter/nf_conntrack_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/uapi/linux/netfilter/nf_conntrack_common.h b/include/uapi/linux/netfilter/nf_conntrack_common.h
index c712eb6879f1..336014bf8868 100644
--- a/include/uapi/linux/netfilter/nf_conntrack_common.h
+++ b/include/uapi/linux/netfilter/nf_conntrack_common.h
@@ -112,7 +112,7 @@ enum ip_conntrack_status {
 				 IPS_EXPECTED | IPS_CONFIRMED | IPS_DYING |
 				 IPS_SEQ_ADJUST | IPS_TEMPLATE | IPS_OFFLOAD),
 
-	__IPS_MAX_BIT = 14,
+	__IPS_MAX_BIT = 15,
 };
 
 /* Connection tracking event types */
-- 
2.11.0

^ permalink raw reply related

* [PATCH 05/15] ipvs: fix check on xmit to non-local addresses
From: Pablo Neira Ayuso @ 2018-06-11  9:22 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180611092233.3219-1-pablo@netfilter.org>

From: Julian Anastasov <ja@ssi.bg>

There is mistake in the rt_mode_allow_non_local assignment.
It should be used to check if sending to non-local addresses is
allowed, now it checks if local addresses are allowed.

As local addresses are allowed for most of the cases, the only
places that are affected are for traffic to transparent cache
servers:

- bypass connections when cache server is not available
- related ICMP in FORWARD hook when sent to cache server

Fixes: 4a4739d56b00 ("ipvs: Pull out crosses_local_route_boundary logic")
Signed-off-by: Julian Anastasov <ja@ssi.bg>
Acked-by: Simon Horman <horms@verge.net.au>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/netfilter/ipvs/ip_vs_xmit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/ipvs/ip_vs_xmit.c b/net/netfilter/ipvs/ip_vs_xmit.c
index 4527921b1c3a..8f7fff774283 100644
--- a/net/netfilter/ipvs/ip_vs_xmit.c
+++ b/net/netfilter/ipvs/ip_vs_xmit.c
@@ -168,7 +168,7 @@ static inline bool crosses_local_route_boundary(int skb_af, struct sk_buff *skb,
 						bool new_rt_is_local)
 {
 	bool rt_mode_allow_local = !!(rt_mode & IP_VS_RT_MODE_LOCAL);
-	bool rt_mode_allow_non_local = !!(rt_mode & IP_VS_RT_MODE_LOCAL);
+	bool rt_mode_allow_non_local = !!(rt_mode & IP_VS_RT_MODE_NON_LOCAL);
 	bool rt_mode_allow_redirect = !!(rt_mode & IP_VS_RT_MODE_RDR);
 	bool source_is_loopback;
 	bool old_rt_is_local;
-- 
2.11.0

^ permalink raw reply related

* [PATCH 09/15] netfilter: ipset: Limit max timeout value
From: Pablo Neira Ayuso @ 2018-06-11  9:22 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180611092233.3219-1-pablo@netfilter.org>

From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>

Due to the negative value condition in msecs_to_jiffies(), the real
max possible timeout value must be set to (UINT_MAX >> 1)/MSEC_PER_SEC.

Neutron Soutmun proposed the proper fix, but an insufficient one was
applied, see https://patchwork.ozlabs.org/patch/400405/.

Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
---
 include/linux/netfilter/ipset/ip_set_timeout.h | 10 ++++++----
 net/netfilter/xt_set.c                         |  8 ++++----
 2 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/include/linux/netfilter/ipset/ip_set_timeout.h b/include/linux/netfilter/ipset/ip_set_timeout.h
index 7ad8ddf9ca8a..8ce271e187b6 100644
--- a/include/linux/netfilter/ipset/ip_set_timeout.h
+++ b/include/linux/netfilter/ipset/ip_set_timeout.h
@@ -23,6 +23,9 @@
 /* Set is defined with timeout support: timeout value may be 0 */
 #define IPSET_NO_TIMEOUT	UINT_MAX
 
+/* Max timeout value, see msecs_to_jiffies() in jiffies.h */
+#define IPSET_MAX_TIMEOUT	(UINT_MAX >> 1)/MSEC_PER_SEC
+
 #define ip_set_adt_opt_timeout(opt, set)	\
 ((opt)->ext.timeout != IPSET_NO_TIMEOUT ? (opt)->ext.timeout : (set)->timeout)
 
@@ -32,11 +35,10 @@ ip_set_timeout_uget(struct nlattr *tb)
 	unsigned int timeout = ip_set_get_h32(tb);
 
 	/* Normalize to fit into jiffies */
-	if (timeout > UINT_MAX/MSEC_PER_SEC)
-		timeout = UINT_MAX/MSEC_PER_SEC;
+	if (timeout > IPSET_MAX_TIMEOUT)
+		timeout = IPSET_MAX_TIMEOUT;
 
-	/* Userspace supplied TIMEOUT parameter: adjust crazy size */
-	return timeout == IPSET_NO_TIMEOUT ? IPSET_NO_TIMEOUT - 1 : timeout;
+	return timeout;
 }
 
 static inline bool
diff --git a/net/netfilter/xt_set.c b/net/netfilter/xt_set.c
index 07af7dbf7a30..bf2890b13212 100644
--- a/net/netfilter/xt_set.c
+++ b/net/netfilter/xt_set.c
@@ -372,8 +372,8 @@ set_target_v2(struct sk_buff *skb, const struct xt_action_param *par)
 
 	/* Normalize to fit into jiffies */
 	if (add_opt.ext.timeout != IPSET_NO_TIMEOUT &&
-	    add_opt.ext.timeout > UINT_MAX / MSEC_PER_SEC)
-		add_opt.ext.timeout = UINT_MAX / MSEC_PER_SEC;
+	    add_opt.ext.timeout > IPSET_MAX_TIMEOUT)
+		add_opt.ext.timeout = IPSET_MAX_TIMEOUT;
 	if (info->add_set.index != IPSET_INVALID_ID)
 		ip_set_add(info->add_set.index, skb, par, &add_opt);
 	if (info->del_set.index != IPSET_INVALID_ID)
@@ -407,8 +407,8 @@ set_target_v3(struct sk_buff *skb, const struct xt_action_param *par)
 
 	/* Normalize to fit into jiffies */
 	if (add_opt.ext.timeout != IPSET_NO_TIMEOUT &&
-	    add_opt.ext.timeout > UINT_MAX / MSEC_PER_SEC)
-		add_opt.ext.timeout = UINT_MAX / MSEC_PER_SEC;
+	    add_opt.ext.timeout > IPSET_MAX_TIMEOUT)
+		add_opt.ext.timeout = IPSET_MAX_TIMEOUT;
 	if (info->add_set.index != IPSET_INVALID_ID)
 		ip_set_add(info->add_set.index, skb, par, &add_opt);
 	if (info->del_set.index != IPSET_INVALID_ID)
-- 
2.11.0

^ permalink raw reply related

* [PATCH 12/15] netfilter: nft_set_rbtree: fix parameter of __nft_rbtree_lookup()
From: Pablo Neira Ayuso @ 2018-06-11  9:22 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180611092233.3219-1-pablo@netfilter.org>

From: Taehee Yoo <ap420073@gmail.com>

The parameter this doesn't have a flags value. so that it can't be
used by nft_rbtree_interval_end().

test commands:
   %nft add table ip filter
   %nft add set ip filter s { type ipv4_addr \; flags interval \; }
   %nft add element ip filter s {0-1}
   %nft add element ip filter s {2-10}
   %nft add chain ip filter input { type filter hook input priority 0\; }
   %nft add rule ip filter input ip saddr @s

Splat looks like:
[  246.752502] BUG: KASAN: slab-out-of-bounds in __nft_rbtree_lookup+0x677/0x6a0 [nft_set_rbtree]
[  246.752502] Read of size 1 at addr ffff88010d9efa47 by task http/1092

[  246.752502] CPU: 1 PID: 1092 Comm: http Not tainted 4.17.0-rc6+ #185
[  246.752502] Call Trace:
[  246.752502]  <IRQ>
[  246.752502]  dump_stack+0x74/0xbb
[  246.752502]  ? __nft_rbtree_lookup+0x677/0x6a0 [nft_set_rbtree]
[  246.752502]  print_address_description+0xc7/0x290
[  246.752502]  ? __nft_rbtree_lookup+0x677/0x6a0 [nft_set_rbtree]
[  246.752502]  kasan_report+0x22c/0x350
[  246.752502]  __nft_rbtree_lookup+0x677/0x6a0 [nft_set_rbtree]
[  246.752502]  nft_rbtree_lookup+0xc9/0x2d2 [nft_set_rbtree]
[  246.752502]  ? sched_clock_cpu+0x144/0x180
[  246.752502]  nft_lookup_eval+0x149/0x3a0 [nf_tables]
[  246.752502]  ? __lock_acquire+0xcea/0x4ed0
[  246.752502]  ? nft_lookup_init+0x6b0/0x6b0 [nf_tables]
[  246.752502]  nft_do_chain+0x263/0xf50 [nf_tables]
[  246.752502]  ? __nft_trace_packet+0x1a0/0x1a0 [nf_tables]
[  246.752502]  ? sched_clock_cpu+0x144/0x180
[ ... ]

Fixes: f9121355eb6f ("netfilter: nft_set_rbtree: incorrect assumption on lower interval lookups")
Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/netfilter/nft_set_rbtree.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/nft_set_rbtree.c b/net/netfilter/nft_set_rbtree.c
index e6f08bc5f359..26fa93b23805 100644
--- a/net/netfilter/nft_set_rbtree.c
+++ b/net/netfilter/nft_set_rbtree.c
@@ -65,7 +65,7 @@ static bool __nft_rbtree_lookup(const struct net *net, const struct nft_set *set
 			parent = rcu_dereference_raw(parent->rb_left);
 			if (interval &&
 			    nft_rbtree_equal(set, this, interval) &&
-			    nft_rbtree_interval_end(this) &&
+			    nft_rbtree_interval_end(rbe) &&
 			    !nft_rbtree_interval_end(interval))
 				continue;
 			interval = rbe;
-- 
2.11.0

^ permalink raw reply related

* [PATCH 11/15] netfilter: ebtables: reject non-bridge targets
From: Pablo Neira Ayuso @ 2018-06-11  9:22 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180611092233.3219-1-pablo@netfilter.org>

From: Florian Westphal <fw@strlen.de>

the ebtables evaluation loop expects targets to return
positive values (jumps), or negative values (absolute verdicts).

This is completely different from what xtables does.
In xtables, targets are expected to return the standard netfilter
verdicts, i.e. NF_DROP, NF_ACCEPT, etc.

ebtables will consider these as jumps.

Therefore reject any target found due to unspec fallback.
v2: also reject watchers.  ebtables ignores their return value, so
a target that assumes skb ownership (and returns NF_STOLEN) causes
use-after-free.

The only watchers in the 'ebtables' front-end are log and nflog;
both have AF_BRIDGE specific wrappers on kernel side.

Reported-by: syzbot+2b43f681169a2a0d306a@syzkaller.appspotmail.com
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/bridge/netfilter/ebtables.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 5f459c8b7937..08a65e4a77d0 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -396,6 +396,12 @@ ebt_check_watcher(struct ebt_entry_watcher *w, struct xt_tgchk_param *par,
 	watcher = xt_request_find_target(NFPROTO_BRIDGE, w->u.name, 0);
 	if (IS_ERR(watcher))
 		return PTR_ERR(watcher);
+
+	if (watcher->family != NFPROTO_BRIDGE) {
+		module_put(watcher->me);
+		return -ENOENT;
+	}
+
 	w->u.watcher = watcher;
 
 	par->target   = watcher;
@@ -715,6 +721,13 @@ ebt_check_entry(struct ebt_entry *e, struct net *net,
 		goto cleanup_watchers;
 	}
 
+	/* Reject UNSPEC, xtables verdicts/return values are incompatible */
+	if (target->family != NFPROTO_BRIDGE) {
+		module_put(target->me);
+		ret = -ENOENT;
+		goto cleanup_watchers;
+	}
+
 	t->u.target = target;
 	if (t->u.target == &ebt_standard_target) {
 		if (gap < sizeof(struct ebt_standard_target)) {
-- 
2.11.0

^ permalink raw reply related

* [PATCH 07/15] netfilter: xt_set: Check hook mask correctly
From: Pablo Neira Ayuso @ 2018-06-11  9:22 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180611092233.3219-1-pablo@netfilter.org>

From: Serhey Popovych <serhe.popovych@gmail.com>

Inserting rule before one with SET target we get error with warning in
dmesg(1) output:

  # iptables -A FORWARD -t mangle -j SET --map-set test src --map-prio
  # iptables -I FORWARD 1 -t mangle -j ACCEPT
  iptables: Invalid argument. Run `dmesg' for more information.
  # dmesg |tail -n1
  [268578.026643] mapping of prio or/and queue is allowed only from \
  OUTPUT/FORWARD/POSTROUTING chains

Rather than checking for supported hook bits for SET target check for
unsupported one as done in all rest of matches and targets.

Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
---
 net/netfilter/xt_set.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/xt_set.c b/net/netfilter/xt_set.c
index 6f4c5217d835..07af7dbf7a30 100644
--- a/net/netfilter/xt_set.c
+++ b/net/netfilter/xt_set.c
@@ -470,7 +470,7 @@ set_target_v3_checkentry(const struct xt_tgchk_param *par)
 		}
 		if (((info->flags & IPSET_FLAG_MAP_SKBPRIO) |
 		     (info->flags & IPSET_FLAG_MAP_SKBQUEUE)) &&
-		     !(par->hook_mask & (1 << NF_INET_FORWARD |
+		     (par->hook_mask & ~(1 << NF_INET_FORWARD |
 					 1 << NF_INET_LOCAL_OUT |
 					 1 << NF_INET_POST_ROUTING))) {
 			pr_info_ratelimited("mapping of prio or/and queue is allowed only from OUTPUT/FORWARD/POSTROUTING chains\n");
-- 
2.11.0

^ permalink raw reply related

* [PATCH 06/15] netfilter: ebtables: fix compat entry padding
From: Pablo Neira Ayuso @ 2018-06-11  9:22 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180611092233.3219-1-pablo@netfilter.org>

From: Alin Nastac <alin.nastac@gmail.com>

On arm64, ebt_entry_{match,watcher,target} structs are 40 bytes long
while on 32-bit arm these structs have a size of 36 bytes.

COMPAT_XT_ALIGN() macro cannot be used here to determine the necessary
padding for the CONFIG_COMPAT because it imposes an 8-byte boundary
alignment, condition that is not found in 32-bit ebtables application.

Signed-off-by: Alin Nastac <alin.nastac@gmail.com>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/bridge/netfilter/ebtables.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 6ba639f6c51d..5f459c8b7937 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -1610,16 +1610,16 @@ struct compat_ebt_entry_mwt {
 		compat_uptr_t ptr;
 	} u;
 	compat_uint_t match_size;
-	compat_uint_t data[0];
+	compat_uint_t data[0] __attribute__ ((aligned (__alignof__(struct compat_ebt_replace))));
 };
 
 /* account for possible padding between match_size and ->data */
 static int ebt_compat_entry_padsize(void)
 {
-	BUILD_BUG_ON(XT_ALIGN(sizeof(struct ebt_entry_match)) <
-			COMPAT_XT_ALIGN(sizeof(struct compat_ebt_entry_mwt)));
-	return (int) XT_ALIGN(sizeof(struct ebt_entry_match)) -
-			COMPAT_XT_ALIGN(sizeof(struct compat_ebt_entry_mwt));
+	BUILD_BUG_ON(sizeof(struct ebt_entry_match) <
+			sizeof(struct compat_ebt_entry_mwt));
+	return (int) sizeof(struct ebt_entry_match) -
+			sizeof(struct compat_ebt_entry_mwt);
 }
 
 static int ebt_compat_match_offset(const struct xt_match *match,
-- 
2.11.0

^ permalink raw reply related

* [PATCH 10/15] netfilter: ipset: forbid family for hash:mac sets
From: Pablo Neira Ayuso @ 2018-06-11  9:22 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180611092233.3219-1-pablo@netfilter.org>

From: Florent Fourcot <florent.fourcot@wifirst.fr>

Userspace `ipset` command forbids family option for hash:mac type:

ipset create test hash:mac family inet4
ipset v6.30: Unknown argument: `family'

However, this check is not done in kernel itself. When someone use
external netlink applications (pyroute2 python library for example), one
can create hash:mac with invalid family and inconsistant results from
userspace (`ipset` command cannot read set content anymore).

This patch enforce the logic in kernel, and forbids insertion of
hash:mac with a family set.

Since IP_SET_PROTO_UNDEF is defined only for hash:mac, this patch has no
impact on other hash:* sets

Signed-off-by: Florent Fourcot <florent.fourcot@wifirst.fr>
Signed-off-by: Victorien Molle <victorien.molle@wifirst.fr>
Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
---
 net/netfilter/ipset/ip_set_hash_gen.h | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/net/netfilter/ipset/ip_set_hash_gen.h b/net/netfilter/ipset/ip_set_hash_gen.h
index bbad940c0137..8a33dac4e805 100644
--- a/net/netfilter/ipset/ip_set_hash_gen.h
+++ b/net/netfilter/ipset/ip_set_hash_gen.h
@@ -1234,7 +1234,10 @@ IPSET_TOKEN(HTYPE, _create)(struct net *net, struct ip_set *set,
 	pr_debug("Create set %s with family %s\n",
 		 set->name, set->family == NFPROTO_IPV4 ? "inet" : "inet6");
 
-#ifndef IP_SET_PROTO_UNDEF
+#ifdef IP_SET_PROTO_UNDEF
+	if (set->family != NFPROTO_UNSPEC)
+		return -IPSET_ERR_INVALID_FAMILY;
+#else
 	if (!(set->family == NFPROTO_IPV4 || set->family == NFPROTO_IPV6))
 		return -IPSET_ERR_INVALID_FAMILY;
 #endif
-- 
2.11.0

^ permalink raw reply related

* [PATCH 01/15] netfilter: xt_CT: Reject the non-null terminated string from user space
From: Pablo Neira Ayuso @ 2018-06-11  9:22 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180611092233.3219-1-pablo@netfilter.org>

From: Gao Feng <gfree.wind@vip.163.com>

The helper and timeout strings are from user-space, we need to make
sure they are null terminated. If not, evil user could make kernel
read the unexpected memory, even print it when fail to find by the
following codes.

pr_info_ratelimited("No such helper \"%s\"\n", helper_name);

Signed-off-by: Gao Feng <gfree.wind@vip.163.com>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/netfilter/xt_CT.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/net/netfilter/xt_CT.c b/net/netfilter/xt_CT.c
index 8790190c6feb..03b9a50ec93b 100644
--- a/net/netfilter/xt_CT.c
+++ b/net/netfilter/xt_CT.c
@@ -245,12 +245,22 @@ static int xt_ct_tg_check(const struct xt_tgchk_param *par,
 	}
 
 	if (info->helper[0]) {
+		if (strnlen(info->helper, sizeof(info->helper)) == sizeof(info->helper)) {
+			ret = -ENAMETOOLONG;
+			goto err3;
+		}
+
 		ret = xt_ct_set_helper(ct, info->helper, par);
 		if (ret < 0)
 			goto err3;
 	}
 
 	if (info->timeout[0]) {
+		if (strnlen(info->timeout, sizeof(info->timeout)) == sizeof(info->timeout)) {
+			ret = -ENAMETOOLONG;
+			goto err4;
+		}
+
 		ret = xt_ct_set_timeout(ct, par, info->timeout);
 		if (ret < 0)
 			goto err4;
-- 
2.11.0

^ permalink raw reply related

* [PATCH 00/15] Netfilter/IPVS fixes for net
From: Pablo Neira Ayuso @ 2018-06-11  9:22 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev

Hi David,

The following patchset contains Netfilter/IPVS fixes for your net tree:

1) Reject non-null terminated helper names from xt_CT, from Gao Feng.

2) Fix KASAN splat due to out-of-bound access from commit phase, from
   Alexey Kodanev.

3) Missing conntrack hook registration on IPVS FTP helper, from Julian
   Anastasov.

4) Incorrect skbuff allocation size in bridge nft_reject, from Taehee Yoo.

5) Fix inverted check on packet xmit to non-local addresses, also from
   Julian.

6) Fix ebtables alignment compat problems, from Alin Nastac.

7) Hook mask checks are not correct in xt_set, from Serhey Popovych.

8) Fix timeout listing of element in ipsets, from Jozsef.

9) Cap maximum timeout value in ipset, also from Jozsef.

10) Don't allow family option for hash:mac sets, from Florent Fourcot.

11) Restrict ebtables to work with NFPROTO_BRIDGE targets only, this
    Florian.

12) Another bug reported by KASAN in the rbtree set backend, from
    Taehee Yoo.

13) Missing __IPS_MAX_BIT update doesn't include IPS_OFFLOAD_BIT.
    From Gao Feng.

14) Missing initialization of match/target in ebtables, from Florian
    Westphal.

15) Remove useless nft_dup.h file in include path, from C. Labbe.

You can pull these changes from:

  git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git

Thanks.

----------------------------------------------------------------

The following changes since commit 664088f8d68178809b848ca450f2797efb34e8e7:

  net-sysfs: Fix memory leak in XPS configuration (2018-05-31 23:02:42 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git HEAD

for you to fetch changes up to d8e87fc6d11c31525430a388317b52f4a98a5328:

  netfilter: remove include/net/netfilter/nft_dup.h (2018-06-08 12:42:24 +0200)

----------------------------------------------------------------
Alexey Kodanev (1):
      netfilter: nf_tables: check msg_type before nft_trans_set(trans)

Alin Nastac (1):
      netfilter: ebtables: fix compat entry padding

Corentin Labbe (1):
      netfilter: remove include/net/netfilter/nft_dup.h

Florent Fourcot (1):
      netfilter: ipset: forbid family for hash:mac sets

Florian Westphal (2):
      netfilter: ebtables: reject non-bridge targets
      netfilter: x_tables: initialise match/target check parameter struct

Gao Feng (2):
      netfilter: xt_CT: Reject the non-null terminated string from user space
      netfilter: nf_conntrack: Increase __IPS_MAX_BIT with new bit IPS_OFFLOAD_BIT

Jozsef Kadlecsik (2):
      netfilter: ipset: List timing out entries with "timeout 1" instead of zero
      netfilter: ipset: Limit max timeout value

Julian Anastasov (2):
      ipvs: register conntrack hooks for ftp
      ipvs: fix check on xmit to non-local addresses

Pablo Neira Ayuso (1):
      Merge git://blackhole.kfki.hu/nf

Serhey Popovych (1):
      netfilter: xt_set: Check hook mask correctly

Taehee Yoo (2):
      netfilter: nft_reject_bridge: fix skb allocation size in nft_reject_br_send_v6_unreach
      netfilter: nft_set_rbtree: fix parameter of __nft_rbtree_lookup()

 include/linux/netfilter/ipset/ip_set_timeout.h     | 20 ++++++++++-----
 include/net/ip_vs.h                                | 30 ++++++++++++++++++++++
 include/net/netfilter/nft_dup.h                    | 10 --------
 include/uapi/linux/netfilter/nf_conntrack_common.h |  2 +-
 net/bridge/netfilter/ebtables.c                    | 25 ++++++++++++++----
 net/bridge/netfilter/nft_reject_bridge.c           |  2 +-
 net/ipv4/netfilter/ip_tables.c                     |  1 +
 net/ipv6/netfilter/ip6_tables.c                    |  1 +
 net/netfilter/ipset/ip_set_hash_gen.h              |  5 +++-
 net/netfilter/ipvs/ip_vs_ctl.c                     |  4 +++
 net/netfilter/ipvs/ip_vs_xmit.c                    |  2 +-
 net/netfilter/nf_tables_api.c                      | 11 ++++----
 net/netfilter/nft_set_rbtree.c                     |  2 +-
 net/netfilter/xt_CT.c                              | 10 ++++++++
 net/netfilter/xt_set.c                             | 10 ++++----
 15 files changed, 99 insertions(+), 36 deletions(-)
 delete mode 100644 include/net/netfilter/nft_dup.h

^ permalink raw reply

* [PATCH 08/15] netfilter: ipset: List timing out entries with "timeout 1" instead of zero
From: Pablo Neira Ayuso @ 2018-06-11  9:22 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180611092233.3219-1-pablo@netfilter.org>

From: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>

When listing sets with timeout support, there's a probability that
just timing out entries with "0" timeout value is listed/saved.
However when restoring the saved list, the zero timeout value means
permanent elelements.

The new behaviour is that timing out entries are listed with "timeout 1"
instead of zero.

Fixes netfilter bugzilla #1258.

Signed-off-by: Jozsef Kadlecsik <kadlec@blackhole.kfki.hu>
---
 include/linux/netfilter/ipset/ip_set_timeout.h | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/linux/netfilter/ipset/ip_set_timeout.h b/include/linux/netfilter/ipset/ip_set_timeout.h
index bfb3531fd88a..7ad8ddf9ca8a 100644
--- a/include/linux/netfilter/ipset/ip_set_timeout.h
+++ b/include/linux/netfilter/ipset/ip_set_timeout.h
@@ -65,8 +65,14 @@ ip_set_timeout_set(unsigned long *timeout, u32 value)
 static inline u32
 ip_set_timeout_get(const unsigned long *timeout)
 {
-	return *timeout == IPSET_ELEM_PERMANENT ? 0 :
-		jiffies_to_msecs(*timeout - jiffies)/MSEC_PER_SEC;
+	u32 t;
+
+	if (*timeout == IPSET_ELEM_PERMANENT)
+		return 0;
+
+	t = jiffies_to_msecs(*timeout - jiffies)/MSEC_PER_SEC;
+	/* Zero value in userspace means no timeout */
+	return t == 0 ? 1 : t;
 }
 
 #endif	/* __KERNEL__ */
-- 
2.11.0

^ permalink raw reply related

* [PATCH 04/15] netfilter: nft_reject_bridge: fix skb allocation size in nft_reject_br_send_v6_unreach
From: Pablo Neira Ayuso @ 2018-06-11  9:22 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180611092233.3219-1-pablo@netfilter.org>

From: Taehee Yoo <ap420073@gmail.com>

In order to allocate icmpv6 skb, sizeof(struct ipv6hdr) should be used.

Signed-off-by: Taehee Yoo <ap420073@gmail.com>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/bridge/netfilter/nft_reject_bridge.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/bridge/netfilter/nft_reject_bridge.c b/net/bridge/netfilter/nft_reject_bridge.c
index eaf05de37f75..6de981270566 100644
--- a/net/bridge/netfilter/nft_reject_bridge.c
+++ b/net/bridge/netfilter/nft_reject_bridge.c
@@ -261,7 +261,7 @@ static void nft_reject_br_send_v6_unreach(struct net *net,
 	if (!reject6_br_csum_ok(oldskb, hook))
 		return;
 
-	nskb = alloc_skb(sizeof(struct iphdr) + sizeof(struct icmp6hdr) +
+	nskb = alloc_skb(sizeof(struct ipv6hdr) + sizeof(struct icmp6hdr) +
 			 LL_MAX_HEADER + len, GFP_ATOMIC);
 	if (!nskb)
 		return;
-- 
2.11.0

^ permalink raw reply related

* [PATCH 02/15] netfilter: nf_tables: check msg_type before nft_trans_set(trans)
From: Pablo Neira Ayuso @ 2018-06-11  9:22 UTC (permalink / raw)
  To: netfilter-devel; +Cc: davem, netdev
In-Reply-To: <20180611092233.3219-1-pablo@netfilter.org>

From: Alexey Kodanev <alexey.kodanev@oracle.com>

The patch moves the "trans->msg_type == NFT_MSG_NEWSET" check before
using nft_trans_set(trans). Otherwise we can get out of bounds read.

For example, KASAN reported the one when running 0001_cache_handling_0 nft
test. In this case "trans->msg_type" was NFT_MSG_NEWTABLE:

[75517.177808] BUG: KASAN: slab-out-of-bounds in nft_set_lookup_global+0x22f/0x270 [nf_tables]
[75517.279094] Read of size 8 at addr ffff881bdb643fc8 by task nft/7356
...
[75517.375605] CPU: 26 PID: 7356 Comm: nft Tainted: G  E   4.17.0-rc7.1.x86_64 #1
[75517.489587] Hardware name: Oracle Corporation SUN SERVER X4-2
[75517.618129] Call Trace:
[75517.648821]  dump_stack+0xd1/0x13b
[75517.691040]  ? show_regs_print_info+0x5/0x5
[75517.742519]  ? kmsg_dump_rewind_nolock+0xf5/0xf5
[75517.799300]  ? lock_acquire+0x143/0x310
[75517.846738]  print_address_description+0x85/0x3a0
[75517.904547]  kasan_report+0x18d/0x4b0
[75517.949892]  ? nft_set_lookup_global+0x22f/0x270 [nf_tables]
[75518.019153]  ? nft_set_lookup_global+0x22f/0x270 [nf_tables]
[75518.088420]  ? nft_set_lookup_global+0x22f/0x270 [nf_tables]
[75518.157689]  nft_set_lookup_global+0x22f/0x270 [nf_tables]
[75518.224869]  nf_tables_newsetelem+0x1a5/0x5d0 [nf_tables]
[75518.291024]  ? nft_add_set_elem+0x2280/0x2280 [nf_tables]
[75518.357154]  ? nla_parse+0x1a5/0x300
[75518.401455]  ? kasan_kmalloc+0xa6/0xd0
[75518.447842]  nfnetlink_rcv+0xc43/0x1bdf [nfnetlink]
[75518.507743]  ? nfnetlink_rcv+0x7a5/0x1bdf [nfnetlink]
[75518.569745]  ? nfnl_err_reset+0x3c0/0x3c0 [nfnetlink]
[75518.631711]  ? lock_acquire+0x143/0x310
[75518.679133]  ? netlink_deliver_tap+0x9b/0x1070
[75518.733840]  ? kasan_unpoison_shadow+0x31/0x40
[75518.788542]  netlink_unicast+0x45d/0x680
[75518.837111]  ? __isolate_free_page+0x890/0x890
[75518.891913]  ? netlink_attachskb+0x6b0/0x6b0
[75518.944542]  netlink_sendmsg+0x6fa/0xd30
[75518.993107]  ? netlink_unicast+0x680/0x680
[75519.043758]  ? netlink_unicast+0x680/0x680
[75519.094402]  sock_sendmsg+0xd9/0x160
[75519.138810]  ___sys_sendmsg+0x64d/0x980
[75519.186234]  ? copy_msghdr_from_user+0x350/0x350
[75519.243118]  ? lock_downgrade+0x650/0x650
[75519.292738]  ? do_raw_spin_unlock+0x5d/0x250
[75519.345456]  ? _raw_spin_unlock+0x24/0x30
[75519.395065]  ? __handle_mm_fault+0xbde/0x3410
[75519.448830]  ? sock_setsockopt+0x3d2/0x1940
[75519.500516]  ? __lock_acquire.isra.25+0xdc/0x19d0
[75519.558448]  ? lock_downgrade+0x650/0x650
[75519.608057]  ? __audit_syscall_entry+0x317/0x720
[75519.664960]  ? __fget_light+0x58/0x250
[75519.711325]  ? __sys_sendmsg+0xde/0x170
[75519.758850]  __sys_sendmsg+0xde/0x170
[75519.804193]  ? __ia32_sys_shutdown+0x90/0x90
[75519.856725]  ? syscall_trace_enter+0x897/0x10e0
[75519.912354]  ? trace_event_raw_event_sys_enter+0x920/0x920
[75519.979432]  ? __audit_syscall_entry+0x720/0x720
[75520.036118]  do_syscall_64+0xa3/0x3d0
[75520.081248]  ? prepare_exit_to_usermode+0x47/0x1d0
[75520.139904]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[75520.201680] RIP: 0033:0x7fc153320ba0
[75520.245772] RSP: 002b:00007ffe294c3638 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
[75520.337708] RAX: ffffffffffffffda RBX: 00007ffe294c4820 RCX: 00007fc153320ba0
[75520.424547] RDX: 0000000000000000 RSI: 00007ffe294c46b0 RDI: 0000000000000003
[75520.511386] RBP: 00007ffe294c47b0 R08: 0000000000000004 R09: 0000000002114090
[75520.598225] R10: 00007ffe294c30a0 R11: 0000000000000246 R12: 00007ffe294c3660
[75520.684961] R13: 0000000000000001 R14: 00007ffe294c3650 R15: 0000000000000001

[75520.790946] Allocated by task 7356:
[75520.833994]  kasan_kmalloc+0xa6/0xd0
[75520.878088]  __kmalloc+0x189/0x450
[75520.920107]  nft_trans_alloc_gfp+0x20/0x190 [nf_tables]
[75520.983961]  nf_tables_newtable+0xcd0/0x1bd0 [nf_tables]
[75521.048857]  nfnetlink_rcv+0xc43/0x1bdf [nfnetlink]
[75521.108655]  netlink_unicast+0x45d/0x680
[75521.157013]  netlink_sendmsg+0x6fa/0xd30
[75521.205271]  sock_sendmsg+0xd9/0x160
[75521.249365]  ___sys_sendmsg+0x64d/0x980
[75521.296686]  __sys_sendmsg+0xde/0x170
[75521.341822]  do_syscall_64+0xa3/0x3d0
[75521.386957]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

[75521.467867] Freed by task 23454:
[75521.507804]  __kasan_slab_free+0x132/0x180
[75521.558137]  kfree+0x14d/0x4d0
[75521.596005]  free_rt_sched_group+0x153/0x280
[75521.648410]  sched_autogroup_create_attach+0x19a/0x520
[75521.711330]  ksys_setsid+0x2ba/0x400
[75521.755529]  __ia32_sys_setsid+0xa/0x10
[75521.802850]  do_syscall_64+0xa3/0x3d0
[75521.848090]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

[75521.929000] The buggy address belongs to the object at ffff881bdb643f80
 which belongs to the cache kmalloc-96 of size 96
[75522.079797] The buggy address is located 72 bytes inside of
 96-byte region [ffff881bdb643f80, ffff881bdb643fe0)
[75522.221234] The buggy address belongs to the page:
[75522.280100] page:ffffea006f6d90c0 count:1 mapcount:0 mapping:0000000000000000 index:0x0
[75522.377443] flags: 0x2fffff80000100(slab)
[75522.426956] raw: 002fffff80000100 0000000000000000 0000000000000000 0000000180200020
[75522.521275] raw: ffffea006e6fafc0 0000000c0000000c ffff881bf180f400 0000000000000000
[75522.615601] page dumped because: kasan: bad access detected

Fixes: 37a9cc525525 ("netfilter: nf_tables: add generation mask to sets")
Signed-off-by: Alexey Kodanev <alexey.kodanev@oracle.com>
Acked-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
---
 net/netfilter/nf_tables_api.c | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c
index 501e48a7965b..8d8dfe417014 100644
--- a/net/netfilter/nf_tables_api.c
+++ b/net/netfilter/nf_tables_api.c
@@ -2728,12 +2728,13 @@ static struct nft_set *nf_tables_set_lookup_byid(const struct net *net,
 	u32 id = ntohl(nla_get_be32(nla));
 
 	list_for_each_entry(trans, &net->nft.commit_list, list) {
-		struct nft_set *set = nft_trans_set(trans);
+		if (trans->msg_type == NFT_MSG_NEWSET) {
+			struct nft_set *set = nft_trans_set(trans);
 
-		if (trans->msg_type == NFT_MSG_NEWSET &&
-		    id == nft_trans_set_id(trans) &&
-		    nft_active_genmask(set, genmask))
-			return set;
+			if (id == nft_trans_set_id(trans) &&
+			    nft_active_genmask(set, genmask))
+				return set;
+		}
 	}
 	return ERR_PTR(-ENOENT);
 }
-- 
2.11.0

^ permalink raw reply related

* Re: [bug] cxgb4: vrf stopped working with cxgb4 card
From: Ganesh Goudar @ 2018-06-11  9:17 UTC (permalink / raw)
  To: David Ahern; +Cc: AMG Zollner Robert, netdev
In-Reply-To: <c8c76c2f-4c51-4260-f828-09751f73972c@cumulusnetworks.com>

On Saturday, June 06/09/18, 2018 at 18:47:55 -0600, David Ahern wrote:
> Ganesh:
> 
> On 6/4/18 9:03 AM, AMG Zollner Robert wrote:
> > I have noticed that vrf is not working with kernel v4.15.0 but was
> > working with v4.13.0 when using cxgb4 Chelsio driver (T520-cr)
> > 
> > Setup:
> > Two metal servers with a T520-cr card each, directly connected without a
> > switch in between.
> > 
> >        SVR1  only ipfwd                 SVR2     with vrf
> > .----------------------------. .----------------------------------.
> > |                            |         |             |
> > |    192.168.8.1 [  ens2f4]--|---------|--[ens1f4] 192.168.8.2   |
> > |    192.168.9.1 [ens2f4d1]--|---------|--<ens1f4d1> 192.168.9.2 VRF=10   |
> > `----------------------------' `----------------------------------'
> > 
> > When vrf is not working there are no error messages (dmesg or iproute
> > commands), tcpdump on the interface (SVR2.ens1f4d1) enslaved in vrf 10
> > shows packets(arp req/reply) coming in and going out, but outgoing
> > packets(arp reply) do not reach the other server SVR1.ens2f4d1
> > 
> > 
> > Bisect:
> > Found this commit to be the problem after doing a git bisect between
> > v4.13..v4.15:
> > 
> > commit ba581f77df23c8ee70b372966e69cf10bc5453d8
> > Author: Ganesh Goudar <ganeshgr@chelsio.com>
> > Date:   Sat Sep 23 16:07:28 2017 +0530
> > 
> >     cxgb4: do DCB state reset in couple of places
> > 
> >     reset the driver's DCB state in couple of places
> >     where it was missing.
> 
> Are you working on a fix for this or should a revert of the above patch
> be sent?
Will look into it and fix/revert it soon, Thanks for responding to Robert.
> 
> 
> > 
> > 
> > A bisect step was considered good when:
> > - successful ping from SVR1 to SVR2.ens1f4d1 vrf interface
> > - successful ping from SVR2 global to SVR2 vrf interface trough SVR1(l3
> > forwarding) (this check was redundant,both tests fail or pass simultaneous)
> > 
> > The problem is still present on recent kernels also, checked v4.16.0 and
> > v4.17.rc7
> > 
> > Disabling DCB for the card support fixes the problem ( Compiling kernel
> > with "CONFIG_CHELSIO_T4_DCB=n")
> > 
> > 
> > 
> > This is my first time reporting a bug to the linux kernel and hope I
> > have included the right amount of information. Please let me know if I
> > have missed something.
> > 
> > 
> > 
> > Thank you,
> > Zollner Robert
> > 
> > 
> > --------
> > Logs:
> > 
> > VRF configured using folowing commands:
> > 
> > #!/bin/sh
> > 
> > CHDEV=ens1f4
> > VRF=vrf-recv
> > 
> > sysctl -w net.ipv4.tcp_l3mdev_accept=1
> > sysctl -w net.ipv4.udp_l3mdev_accept=1
> > sysctl -w net.ipv4.conf.all.accept_local=1
> > 
> > ifconfig ${CHDEV}   192.168.8.2/24
> > ifconfig ${CHDEV}d1 192.168.9.2/24
> > 
> > ip link add ${VRF} type vrf table 10
> > ip link set dev ${VRF} up
> > 
> > ip rule add pref 32765 table local
> > ip rule del pref 0
> > 
> > ip route add table 10 unreachable default metric 4278198272
> > 
> > ip link set dev ${CHDEV}d1 master ${VRF}
> > 
> > ip route add table 10 default via 192.168.9.1
> > ip route add 192.168.9.0/24 via 192.168.8.1
> > 
> > 
> > 
> > 
> 

^ permalink raw reply

* Re: [PATCH 3/3 RFC] Revert "net: stmmac: fix build failure due to missing COMMON_CLK dependency"
From: Geert Uytterhoeven @ 2018-06-11  9:13 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Ungerer, Ralf Baechle, James Hogan, Giuseppe Cavallaro,
	Alexandre Torgue, Jose Abreu, Corentin Labbe, David S. Miller,
	linux-m68k, Linux MIPS Mailing List, netdev,
	Linux Kernel Mailing List
In-Reply-To: <CAK8P3a1mhVJYuQGZM+ypQ1mKbB=+5gA6L=_D7-jjPmShLarwUQ@mail.gmail.com>

Hi Arnd,

On Mon, Jun 11, 2018 at 10:59 AM Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Jun 11, 2018 at 10:44 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > This reverts commit bde4975310eb1982bd0bbff673989052d92fd481.
> >
> > All legacy clock implementations now implement clk_set_rate() (Some
> > implementations may be dummies, though).
> >
> > Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> > ---
> > Marked "RFC", as this depends on "m68k: coldfire: Normalize clk API" and
> > "MIPS: AR7: Normalize clk API".
>
> This seems reasonable. It's possible that it will cause regressions because the
> COMMON_CLK dependency hides another dependency on something else
> that not everything implements, but we should fix that properly if that happens.

Compile-testing was enabled 2 years ago, in commit 2e280c188f06b190
("stmmac: make platform drivers depend on their associated SoC"), but the
dependency on COMMON_CLK was added only recently.
That's what triggered me: the drivers were suddenly disabled in m68k
allmodconfig,
while they built fine for years before.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* Re: [PATCH 0/3] Legacy clock drivers: Normalize clk API
From: Geert Uytterhoeven @ 2018-06-11  9:09 UTC (permalink / raw)
  To: Arnd Bergmann
  Cc: Greg Ungerer, Ralf Baechle, James Hogan, Giuseppe Cavallaro,
	Alexandre Torgue, Jose Abreu, Corentin Labbe, David S. Miller,
	linux-m68k, Linux MIPS Mailing List, netdev,
	Linux Kernel Mailing List
In-Reply-To: <CAK8P3a0CJmpf0L-OXDmqP=kRLGCokR=v6jUPaCSpnFuCwHa7WA@mail.gmail.com>

Hi Arnd,

On Mon, Jun 11, 2018 at 11:02 AM Arnd Bergmann <arnd@arndb.de> wrote:
> On Mon, Jun 11, 2018 at 10:44 AM, Geert Uytterhoeven
> <geert@linux-m68k.org> wrote:
> > When seeing commit bde4975310eb1982 ("net: stmmac: fix build failure due
> > to missing COMMON_CLK dependency"), I wondered why this dependency is
> > needed, as all implementations of the clock API should implement all
> > required functionality, or provide dummies.
> >
> > It turns out there were still two implementations that lacked the
> > clk_set_rate() function: Coldfire and AR7.
> >
> > This series contains three patches:
> >   - The first two patches add dummies for clk_set_rate(),
> >     clk_set_rate(), clk_set_parent(), and clk_get_parent() to the
> >     Coldfire and AR7, like Arnd has done for other legacy clock
> >     implementations a while ago.
> >   - The second patch removes the COMMON_CLK dependency from the stmmac
> >     network drivers again, as it is no longer needed.
> >     Obviously this patch has a hard dependency on the first two patches.
>
> Yes, good idea.
>
> Acked-by: Arnd Bergmann <arnd@arnd.de>

Thanks!

> One question: what happens on machines that don't support any CLK
> interface, i.e.
> that don't have any of COMMON_CLK/HAVE_CLK/CLKDEV_LOOKUP?
>
> I guess those are already hopelessly broken for many drivers, right?

Nope, they (e.g. m68k allmodconfig) build fine, as they don't define
CONFIG_HAVE_CLK.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

^ permalink raw reply

* Re: [PATCH 0/3] Legacy clock drivers: Normalize clk API
From: Arnd Bergmann @ 2018-06-11  9:02 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: Greg Ungerer, Ralf Baechle, James Hogan, Giuseppe Cavallaro,
	Alexandre Torgue, Jose Abreu, Corentin Labbe, David S . Miller,
	linux-m68k, open list:RALINK MIPS ARCHITECTURE, Networking,
	Linux Kernel Mailing List
In-Reply-To: <1528706663-20670-1-git-send-email-geert@linux-m68k.org>

On Mon, Jun 11, 2018 at 10:44 AM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
>         Hi all,
>
> When seeing commit bde4975310eb1982 ("net: stmmac: fix build failure due
> to missing COMMON_CLK dependency"), I wondered why this dependency is
> needed, as all implementations of the clock API should implement all
> required functionality, or provide dummies.
>
> It turns out there were still two implementations that lacked the
> clk_set_rate() function: Coldfire and AR7.
>
> This series contains three patches:
>   - The first two patches add dummies for clk_set_rate(),
>     clk_set_rate(), clk_set_parent(), and clk_get_parent() to the
>     Coldfire and AR7, like Arnd has done for other legacy clock
>     implementations a while ago.
>   - The second patch removes the COMMON_CLK dependency from the stmmac
>     network drivers again, as it is no longer needed.
>     Obviously this patch has a hard dependency on the first two patches.

Yes, good idea.

Acked-by: Arnd Bergmann <arnd@arnd.de>

One question: what happens on machines that don't support any CLK
interface, i.e.
that don't have any of COMMON_CLK/HAVE_CLK/CLKDEV_LOOKUP?

I guess those are already hopelessly broken for many drivers, right?

         Arnd

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox