Re: [Patch net] xt_RATEEST: acquire xt_rateest_mutex for hash insert

On Wed, 2018-01-31 at 16:26 -0800, Cong Wang wrote: > rateest_hash is supposed to be protected by xt_rateest_mutex. > > Reported-by: > Fixes: 5859034d7eb8 ("[NETFILTER]: x_tables: add RATEEST target") > Cc: Pablo Neira Ayuso

[Patch net] xt_RATEEST: acquire xt_rateest_mutex for hash insert

rateest_hash is supposed to be protected by xt_rateest_mutex. Reported-by: Fixes: 5859034d7eb8 ("[NETFILTER]: x_tables: add RATEEST target") Cc: Pablo Neira Ayuso Signed-off-by: Cong Wang ---

[Patch net] xt_cgroup: initialize info->priv in cgroup_mt_check_v1()

xt_cgroup_info_v1->priv is an internal pointer only used for kernel, we should not trust what user-space provides. Reported-by: Fixes: c38c4597e4bf ("netfilter: implement xt_cgroup cgroup2 path match") Cc: Pablo Neira Ayuso

[PATCH nf] netfilter: flowtable infrastructure depends on NETFILTER_INGRESS

config NF_FLOW_TABLE depends on NETFILTER_INGRESS. If users forget to enable this toggle, flowtable registration fails with EOPNOTSUPP. Moreover, turn 'select NF_FLOW_TABLE' in every flowtable family flavour into dependency instead, otherwise this new dependency on NETFILTER_INGRESS causes a

Re: [PATCH net] netfilter: on sockopt() acquire sock lock only in the required scope

On Tue, Jan 30, 2018 at 07:01:40PM +0100, Paolo Abeni wrote: > Syzbot reported several deadlocks in the netfilter area caused by > rtnl lock and socket lock being acquired with a different order on > different code paths, leading to backtraces like the following one: [...] > The problem, as

Re: [PATCH] netfilter: fix out-of-bounds accesses in clusterip_tg_check()

On Tue, Jan 30, 2018 at 03:21:34PM +0100, Dmitry Vyukov wrote: > Commit 136e92bbec0a switched local_nodes from an array to a bitmask > but did not add proper bounds checks. As the result > clusterip_config_init_nodelist() can both over-read > ipt_clusterip_tgt_info.local_nodes and over-write >

Re: [PATCH] netfilter: fix pointer leaks to userspace

On Mon, Jan 29, 2018 at 01:21:20PM +0100, Dmitry Vyukov wrote: > Several netfilter matches and targets put kernel pointers into > info objects, but don't set usersize in descriptors. > This leads to kernel pointer leaks if a match/target is set > and then read back to userspace. > > Properly set

Re: [PATCH 1/1] Fix wraparound bug introduced in commit 48596a8ddc46

On Fri, Jan 12, 2018 at 11:16:50AM +0100, Jozsef Kadlecsik wrote: > The patch "netfilter: ipset: Fix adding an IPv4 range containing > more than 2^31 addresses" introduced a wraparound bug, which could > lead to memory exhaustion when adding an x.x.x.x-255.255.255.255 > range to any hash:*net*

[PATCH nf-next] netfilter: ipv6: nf_defrag: Kill frag queue on RFC2460 failure

Failures were seen in ICMPv6 fragmentation timeout tests if they were run after the RFC2460 failure tests. Kernel was not sending out the ICMPv6 fragment reassembly time exceeded packet after the fragmentation reassembly timeout of 1 minute had elapsed. This happened because the frag queue was

Re: [netfilter-core] kernel panic: Out of memory and no killable processes... (2)

On Tue 30-01-18 11:27:45, Andrew Morton wrote: > On Tue, 30 Jan 2018 15:01:04 +0100 Michal Hocko wrote: > > > > Well, this is not about syzkaller, it merely pointed out a potential > > > DoS... And that has to be addressed somehow. > > > > So how about this? > > --- > > argh

Re: [patch 1/1] net/netfilter/x_tables.c: make allocation less aggressive

On Tue 30-01-18 11:53:58, Eric Dumazet wrote: [...] > How is __GFP_NORETRY working exactly ? this is what the documentation says. * __GFP_NORETRY: The VM implementation will try only very lightweight * memory direct reclaim to get some memory under memory pressure (thus * it can sleep). It