Re: [PATCH net-next] nfnetlink_queue: enable PID info retrieval

On Thu, 2016-06-09 at 23:50 +0300, Saeed Mahameed wrote: > From: Matthew Finlay > diff --git a/net/socket.c b/net/socket.c > index a1bd161..67de200 100644 > --- a/net/socket.c > +++ b/net/socket.c > @@ -382,6 +382,7 @@ struct file *sock_alloc_file(struct socket *sock, int >

Re: [PATCH net-next] nfnetlink_queue: enable PID info retrieval

On Fri, 2016-06-10 at 14:29 +, David Laight wrote: > From: Eric Dumazet > > Sent: 09 June 2016 22:17 > > On Thu, 2016-06-09 at 23:50 +0300, Saeed Mahameed wrote: > > > From: Matthew Finlay <m...@mellanox.com> > > > > > > > diff --git a/net/s

Re: [PATCH 4/5] ipvs: Lock socket before setting SK_CAN_REUSE

On Tue, 2016-06-14 at 02:43 +0100, Quentin Armitage wrote: > When other settings are changed in the socket it is locked, so > lock the socket before setting SK_CAN_REUSE. > > Signed-off-by: Quentin Armitage > --- > net/netfilter/ipvs/ip_vs_sync.c |2 ++ > 1 files

Re: [PATCH V2] net: Allow xt_owner in any user namespace

On Tue, 2016-06-14 at 02:02 +0200, Florian Westphal wrote: > Kevin Cernekee wrote: > > @@ -35,6 +63,7 @@ owner_mt(const struct sk_buff *skb, struct > > xt_action_param *par) > > const struct xt_owner_match_info *info = par->matchinfo; > > const struct file *filp; >

Re: [PATCH V2] netfilter: h323: avoid potential attack

On Thu, 2016-01-28 at 16:59 +0800, Zhouyi Zhou wrote: > Thanks Eric for your review and advice. > > I think hackers chould build a malicious h323 packet to overflow > the pointer p which will panic during the memcpy(addr, p, len) > > For example, he may fabricate a very large

Re: Re: [PATCH V2] netfilter: h323: avoid potential attack

On Thu, 2016-01-28 at 06:00 -0800, Eric Dumazet wrote: > On Thu, 2016-01-28 at 21:14 +0800, Zhouyi Zhou wrote: > > > My patch is intend to prevent kernel panic, to prevent reading garbage > > or read data from a prior frame and leak secrets, the prototypes of the > >

Re: [PATCH V3] netfilter: h323: avoid potential attack

t_h2x5_addr. > > > > Signed-off-by: Zhouyi Zhou <yizhouz...@ict.ac.cn> > > Signed-off-by: Eric Dumazet <eric.duma...@gmail.com> > > Reviewed-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com> > > > > --- > > net/netfilter/nf_conntr

Re: [PATCH] netfilter: x_tables: ensure e->next_offset consistency with table size

On Fri, 2016-03-18 at 22:58 +0100, Pablo Neira Ayuso wrote: > This patch introduces the generic __xt_entry_foreach() that includes a > new parameter to account for remaining entry bytes in the table that we > didn't walk so far. If the amount of remaining bytes is zero, then we > keep validating

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

On Mon, 2016-03-28 at 13:46 -0700, Eric Dumazet wrote: > We have at least 384 bytes of padding in skb->head (this is struct > skb_shared_info). > > Whatever garbage we might read, current code is fine. > > We have to deal with a false positive here. Very similar to th

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

On Mon, 2016-03-28 at 15:29 -0400, David Miller wrote: > From: Jozsef Kadlecsik > Date: Mon, 28 Mar 2016 18:48:51 +0200 (CEST) > > >> > > @@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff *skb, > >> > > length--; > >> > >

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

On Mon, 2016-03-28 at 23:11 +0200, Jozsef Kadlecsik wrote: > In net/netfilter/nf_conntrack_proto_tcp.c we copy the options into a > buffer with skb_header_pointer(), so it's not a false positive there and > the KASAN report referred to that part. > Although the out of bound could be one extra

Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

On Mon, 2016-03-28 at 19:54 -0400, David Miller wrote: > From: Eric Dumazet <eric.duma...@gmail.com> > Date: Mon, 28 Mar 2016 13:51:46 -0700 > > > On Mon, 2016-03-28 at 13:46 -0700, Eric Dumazet wrote: > > > >> We have at least 384 bytes of

Re: net/sctp: stack-out-of-bounds in sctp_getsockopt

On Thu, 2016-03-24 at 00:42 +0800, Baozeng wrote: > Thanks for your quick patch. I tested it but it still reproduce the > bug. We should limit the length of the name, > not the prefix. The following patch fixs it. > > diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c

Re: net/sctp: stack-out-of-bounds in sctp_getsockopt

On Tue, 2016-03-22 at 08:21 -0700, Eric Dumazet wrote: > On Tue, 2016-03-22 at 23:08 +0800, Baozeng Ding wrote: > > Hi all, > > > > The following program triggers an out-of-bounds bug in > > sctp_getsockopt. The kernel version is 4.5 (on Mar 16 > > commit 09fd671

Re: [PATCH v2 nf-next 7/9] netfilter: conntrack: make netns address part of hash

On Mon, 2016-05-02 at 18:39 +0200, Florian Westphal wrote: > Once we place all conntracks into a global hash table we want them to be > spread across entire hash table, even if namespaces have overlapping ip > addresses. > > +static inline u32 nf_conntrack_netns_hash(const struct net *net) > +{

Re: PROBLEM: TPROXY and DNAT broken (bisected to 079096f103fa)

I performed a git bisect using a qemu image to test my example below, and the > bisect ended at this commit: > > > commit 079096f103faca2dd87342cca6f23d4b34da8871 > > Author: Eric Dumazet <eduma...@google.com> > > Date: Fri Oct 2 11:43:32 2015 -0700 > > > &

Re: [RFC 5/7] net: Add allocation flag to rtnl_unicast()

On Wed, 2016-07-06 at 09:28 +0900, Masashi Honma wrote: > Signed-off-by: Masashi Honma > --- > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c > index a1f6b7b..2b0b994 100644 > --- a/net/ipv6/addrconf.c > +++ b/net/ipv6/addrconf.c > @@ -628,7 +628,7 @@ static int

Re: [RFC 5/7] net: Add allocation flag to rtnl_unicast()

On Fri, 2016-07-08 at 12:15 +0900, Masashi Honma wrote: = > Thanks for comment. > > I have selected GFP flags based on existing code. > > I have selected GFP_ATOMIC in inet6_netconf_get_devconf() because > skb was allocated with GFP_ATOMIC. Point is : we should remove GFP_ATOMIC uses as much as

Re: DoS attack mitigation in netfilter

On Wed, 2016-07-06 at 10:06 +0530, Vikas wrote: > Hi, > > Wanted to explore options netfilter provides to mitigate DoS/SYN attacks. > Even if there is mechanism to incorporate rate limiter solution for high > incoming volume traffic then it would help. > > Any input in this regard will be

Re: kernel panic TPROXY , vanilla 4.7.1

On Wed, 2016-08-17 at 08:42 -0700, Eric Dumazet wrote: > On Wed, 2016-08-17 at 17:31 +0300, Denys Fedoryshchenko wrote: > > Hi! > > > > Tried to run squid on latest kernel, and hit a panic > > Sometimes it just shows warning in dmesg (but doesnt work properly) >

Re: kernel panic TPROXY , vanilla 4.7.1

On Wed, 2016-08-17 at 19:44 +0300, Denys Fedoryshchenko wrote: > Yes, everything fine after patch! > Thanks a lot Perfect, thanks for testing, I am sending the official patch. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to

[PATCH net] netfilter: tproxy: properly refcount tcp listeners

From: Eric Dumazet <eduma...@google.com> inet_lookup_listener() and inet6_lookup_listener() no longer take a reference on the found listener. This minimal patch adds back the refcounting, but we might do this differently in net-next later. Fixes: 3b24d854cb35 ("tcp/dccp: do not tou

Re: net: suspicious RCU usage in nf_hook

On Wed, Feb 1, 2017 at 3:29 PM, Cong Wang wrote: > Not sure if it is better. The difference is caught up in > net_enable_timestamp(), > which is called setsockopt() path and sk_clone() path, so we could be > in netstamp_needed state for a long time too until user-space

Re: net: suspicious RCU usage in nf_hook

On Wed, 2017-02-01 at 15:48 -0800, Eric Dumazet wrote: > On Wed, Feb 1, 2017 at 3:29 PM, Cong Wang <xiyou.wangc...@gmail.com> wrote: > > > Not sure if it is better. The difference is caught up in > > net_enable_timestamp(), > > which is called setsockopt() path an

Re: net: suspicious RCU usage in nf_hook

On Wed, 2017-02-01 at 13:16 -0800, Eric Dumazet wrote: > This would permanently leave the kernel in the netstamp_needed state. > > I would prefer the patch using a process context to perform the > cleanup ? Note there is a race window, but probably not a big deal. > > net

Re: net: suspicious RCU usage in nf_hook

On Wed, 2017-02-01 at 12:51 -0800, Cong Wang wrote: > On Tue, Jan 31, 2017 at 7:44 AM, Eric Dumazet <eric.duma...@gmail.com> wrote: > > On Mon, 2017-01-30 at 22:19 -0800, Cong Wang wrote: > > > >> > >> The context is process context (TX path before hitting

Re: net: suspicious RCU usage in nf_hook

On Mon, 2017-01-30 at 22:19 -0800, Cong Wang wrote: > > The context is process context (TX path before hitting qdisc), and > BH is not disabled, so in_interrupt() doesn't catch it. Hmm, this > makes me thinking maybe we really need to disable BH in this > case for nf_hook()? But it is called in

Re: ip_rcv_finish() NULL pointer kernel panic

On Thu, 2017-01-26 at 09:32 -0600, Roy Keene wrote: > This bug appears to have existed for a long time: > > https://www.spinics.net/lists/netdev/msg222459.html > > http://www.kernelhub.org/?p=2=823752 > > Though possibly with different things not setting the "input" function >

Re: ip_rcv_finish() NULL pointer kernel panic

On Thu, 2017-01-26 at 17:24 +0100, Florian Westphal wrote: > I think it makes sense to set dst->incoming > to a stub in br_netfilter_rtable_init() to just kfree_skb()+ > WARN_ON_ONCE(), no need to add code to ip stack or crash kernel > due to brnf bug. Just kfree_skb() would hide bugs. Dropping

Re: ip_rcv_finish() NULL pointer kernel panic

On Thu, 2017-01-26 at 10:00 -0800, Eric Dumazet wrote: > On Thu, 2017-01-26 at 17:24 +0100, Florian Westphal wrote: > > > I think it makes sense to set dst->incoming > > to a stub in br_netfilter_rtable_init() to just kfree_skb()+ > > WARN_ON_ONCE(), no need to ad

Re: [PATCH 02/14] tcp: fix mark propagation with fwmark_reflect enabled

On Thu, 2017-01-26 at 17:37 +0100, Pablo Neira Ayuso wrote: > From: Pau Espin Pedrol > > Otherwise, RST packets generated by the TCP stack for non-existing > sockets always have mark 0. > The mark from the original packet is assigned to the netns_ipv4/6 > socket used to

Re: [PATCH 02/14] tcp: fix mark propagation with fwmark_reflect enabled

On Thu, 2017-01-26 at 20:19 +0100, Pablo Neira Ayuso wrote: > Right. This is not percpu as in IPv4. > > I can send a follow up patch to get this in sync with the way we do it > in IPv4, ie. add percpu socket. > > Fine with this approach? Thanks! Not really. percpu sockets are going to slow

Re: net: suspicious RCU usage in nf_hook

On Fri, 2017-01-27 at 17:00 -0800, Cong Wang wrote: > On Fri, Jan 27, 2017 at 3:35 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > > Oh well, I forgot to submit the official patch I think, Jan 9th. > > > > https://groups.google.com/forum/#!topic/syzkaller/BhyN5OFd7sQ

Re: [PATCH nf-next 2/6] netfilter: conntrack: get rid of conntrack timer

On Fri, 2016-08-19 at 18:04 +0200, Florian Westphal wrote: > Eric Dumazet <eric.duma...@gmail.com> wrote: > > On Fri, 2016-08-19 at 17:16 +0200, Florian Westphal wrote: > > > > > Hmm, nf_conntrack_find caller needs to hold rcu_read_lock, > > > in ca

Re: [PATCH nf-next 2/6] netfilter: conntrack: get rid of conntrack timer

On Fri, 2016-08-19 at 13:36 +0200, Florian Westphal wrote: > With stats enabled this eats 80 bytes on x86_64 per nf_conn entry. > > Remove it and use a 32bit jiffies value containing timestamp until > entry is valid. Great work ! ... > +/* caller must hold rcu readlock and none of the

Re: [PATCH nf-next 4/6] netfilter: conntrack: add gc worker to remove timed-out entries

On Fri, 2016-08-19 at 13:36 +0200, Florian Westphal wrote: > Conntrack gc worker to evict stale entries. ... > + > + hlist_nulls_for_each_entry_rcu(h, n, _hash[i], hnnode) { > + tmp = nf_ct_tuplehash_to_ctrack(h); > + > + if

Re: [PATCH nf-next 2/6] netfilter: conntrack: get rid of conntrack timer

On Fri, 2016-08-19 at 17:16 +0200, Florian Westphal wrote: > Hmm, nf_conntrack_find caller needs to hold rcu_read_lock, > in case object is free'd SLAB_DESTROY_BY_RCU should delay actual release > of the page. Well, point is that SLAB_DESTROY_BY_RCU means that we have no grace period, and

Re: [PATCH 5/5] net/netfilter/nf_conntrack_core: update memory barriers.

On Wed, 2016-08-31 at 15:42 +0200, Manfred Spraul wrote: > As explained in commit 51d7d5205d33 > ("powerpc: Add smp_mb() to arch_spin_is_locked()", for some architectures > the ACQUIRE during spin_lock only applies to loading the lock, not to > storing the lock state. > > nf_conntrack_lock() does

Re: error: 'struct net_device' has no member named 'nf_hooks_ingress'

On Wed, 2016-10-05 at 22:56 +0200, Michal Sojka wrote: > this commit is now in mainline as > e3b37f11e6e4e6b6f02cc762f182ce233d2c1c9d and it breaks my build: > > net/netfilter/core.c: In function 'nf_set_hooks_head': > net/netfilter/core.c:96:3: error: 'struct net_device' has no member

Re: [PATCH] netfilter: xt_socket: fix transparent match for IPv6 request sockets

On Tue, 2016-09-20 at 08:01 -0700, Eric Dumazet wrote: > > Something like : > > diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > index 3ebf45b38bc3..0fccfd6cc258 100644 > --- a/net/ipv4/tcp_input.c > +++ b/net/ipv4/tcp_input.c > @@ -6264,6 +6264,7 @@ int

Re: [PATCH] netfilter: xt_socket: fix transparent match for IPv6 request sockets

On Tue, 2016-09-20 at 15:26 +0200, KOVACS Krisztian wrote: > The introduction of TCP_NEW_SYN_RECV state, and the addition of request > sockets to the ehash table seems to have broken the --transparent option > of the socket match for IPv6 (around commit a9407000). > > Now that the socket lookup

Re: [PATCH nf v3] netfilter: seqadj: Fix the wrong ack adjust for the RST packet without ack

On Thu, 2016-09-22 at 10:22 +0800, f...@ikuai8.com wrote: > From: Gao Feng > > It is valid that the TCP RST packet which does not set ack flag, and bytes > of ack number are zero. But current seqadj codes would adjust the "0" ack > to invalid ack number. Actually seqadj need to

Re: [PATCH nf] netfilter: nf_tables: Ensure u8 attributes are loaded from u32 within the bounds

On Thu, 2016-09-22 at 16:58 +0200, Pablo Neira Ayuso wrote: > attributes") > > Always use 12 bytes commit-ids. 4da449a is too short, given the number > of changes we're getting in the kernel tree, this may become ambiguous > at some point so it won't be unique. > > You can achieve this via: git

Re: [PATCH v3 nf-next 5/7] netfilter: conntrack: add gc worker to remove timed-out entries

nge to speed up GC for the extreme > case where most entries are timed out on an otherwise idle system. > > v2: Use cond_resched_rcu_qs & add comment wrt. missing restart on > nulls value change in gc worker, suggested by Eric Dumazet. > > v3: don't call cancel_delayed_w

Re: [PATCH v2 nf-next 1/7] netfilter: don't rely on DYING bit to detect when destroy event was sent

do not have the DYING bit set. > > Once timer is gone, we can no longer use if (del_timer()) to detect > when we 'stole' the reference count owned by the timer/hash entry, so > we need some other way to avoid racing with other cpu. > > Pablo suggested to add a marker in the ecache ext

Re: [PATCH v2 nf-next 2/7] netfilter: conntrack: get rid of conntrack timer

On Wed, 2016-08-24 at 13:55 +0200, Florian Westphal wrote: > With stats enabled this eats 80 bytes on x86_64 per nf_conn entry, as > Eric Dumazet pointed out during netfilter workshop 2016. Another reason was the fact that Thomas was about to change max timer range : https://git.kernel.or

Re: [PATCH v2 nf-next 4/7] netfilter: conntrack: add gc worker to remove timed-out entries

On Wed, 2016-08-24 at 13:55 +0200, Florian Westphal wrote: > Conntrack gc worker to evict stale entries. > static struct nf_conn * > __nf_conntrack_alloc(struct net *net, >const struct nf_conntrack_zone *zone, > @@ -1527,6 +1597,7 @@ static int untrack_refs(void) > >

Re: [PATCH nf-next 7/7] netfilter: restart search if moved to other chain

On Wed, 2016-08-24 at 13:55 +0200, Florian Westphal wrote: > In case nf_conntrack_tuple_taken did not find a conflicting entry > check that all entries in this hash slot were tested and restart > in case an entry was moved to another chain. > > Reported-by: Eric Dumazet <e

Re: [PATCH v2 nf-next 4/7] netfilter: conntrack: add gc worker to remove timed-out entries

On Wed, 2016-08-24 at 22:11 +0200, Florian Westphal wrote: > Eric Dumazet <eric.duma...@gmail.com> wrote: > > On Wed, 2016-08-24 at 13:55 +0200, Florian Westphal wrote: > > > Conntrack gc worker to evict stale entries. > > > > > > > static struct nf_

Re: [PATCH] Fix link error in 32bit arch because of 64bit division

On Tue, 2016-09-27 at 03:42 -0400, Vishwanath Pai wrote: > Fix link error in 32bit arch because of 64bit division > > Division of 64bit integers will cause linker error undefined reference > to `__udivdi3'. Fix this by replacing divisions with div64_64 > > Signed-off-by: Vishwanath Pai

Re: [PATCH nf-next v3 1/2] netfilter: Fix potential null pointer dereference

On Wed, 2016-09-28 at 10:56 -0400, Aaron Conole wrote: > Eric Dumazet <eric.duma...@gmail.com> writes: > > > On Wed, 2016-09-28 at 09:12 -0400, Aaron Conole wrote: > >> It's possible for nf_hook_entry_head to return NULL. If two > >> nf_unregister_

Re: [PATCH nf-next v3 1/2] netfilter: Fix potential null pointer dereference

On Wed, 2016-09-28 at 09:12 -0400, Aaron Conole wrote: > It's possible for nf_hook_entry_head to return NULL. If two > nf_unregister_net_hook calls happen simultaneously with a single hook > entry in the list, both will enter the nf_hook_mutex critical section. > The first will successfully

Re: [PATCH 3/3] netfilter: xt_hashlimit: uses div_u64 for division

On Fri, 2016-09-30 at 18:05 +0200, Arnd Bergmann wrote: > The newly added support for high-resolution pps rates introduced multiple > 64-bit > division operations in one function, which fails on all 32-bit architectures: > > net/netfilter/xt_hashlimit.o: In function `user2credits': >

Re: [PATCH v2 nf-next 3/3] netfilter: x_tables: pack percpu counter allocations

loading because we reduce calls to the percpu > allocator. > > As Eric points out we can't use PAGE_SIZE, page_allocator would fail on > arches with 64k page size. > > Suggested-by: Eric Dumazet <eduma...@google.com> > Signed-off-by: Florian Westphal <f...@st

Re: [PATCH net-next 1/1] netfilter: xt_multiport: Fix wrong unmatch result with multiple ports

On Fri, 2016-11-25 at 11:58 +0800, f...@ikuai8.com wrote: > From: Gao Feng > > I lost one test case in the commit for xt_multiport. > For example, the rule is "-m multiport --dports 22,80,443". > When first port is unmatched and the second is matched, the curent codes > could

Re: net/sctp: vmalloc allocation failure in sctp_setsockopt/xt_alloc_table_info

On Mon, 2016-11-28 at 19:09 +0100, Florian Westphal wrote: > We should prevent OOM killer from running in first place (GFP_NORETRY should > work). Make sure that a vmalloc(8) will succeed, even if few pages need to be swapped out. Otherwise, some scripts using iptables will die while they

Re: netfilter question

On Thu, 2016-11-17 at 01:07 +0100, Florian Westphal wrote: Seems very nice ! > + > +void xt_percpu_counter_free(struct xt_counters *counters) > +{ > + unsigned long pcnt = counters->pcnt; > + > + if (nr_cpu_ids > 1 && (pcnt & (PAGE_SIZE - 1)) == 0) > + free_percpu((void

Re: netfilter question

On Wed, 2016-11-16 at 16:02 +0100, Florian Westphal wrote: > Eric Dumazet <eduma...@google.com> wrote: > > On Wed, Nov 16, 2016 at 2:22 AM, Eric Desrochers <er...@miromedia.ca> wrote: > > > Hi Eric, > > > > > > My name is Eric and I'm reaching y

Re: netfilter question

On Thu, 2016-11-17 at 01:07 +0100, Florian Westphal wrote: > + if (state->mem == NULL) { > + state->mem = __alloc_percpu(PAGE_SIZE, PAGE_SIZE); > + if (!state->mem) > + return false; > + } This will fail on arches where PAGE_SIZE=65536 percpu

Re: netfilter question

On Sun, 2016-11-20 at 12:22 -0500, Eric D wrote: > I'm currently abroad for work and will come back home soon. I will > test the solution and provide feedback to Florian by end of week. > > Thanks for jumping on this quickly. > > Eric > > > On Nov 20, 2016 7:33 AM

Re: netfilter question

On Sun, 2016-11-20 at 09:31 -0800, Eric Dumazet wrote: > Thanks Eric, I will test the patch myself, because I believe we need it > asap ;) Current net-next without Florian patch : lpaa24:~# time for f in `seq 1 2000` ; do iptables -A FORWARD ; done real0m12.856s user0m0.59

Re: [PATCH nf-next 3/3] netfilter: x_tables: pack percpu counter allocations

On Mon, 2016-11-21 at 14:57 +0100, Florian Westphal wrote: ... > #define SMP_ALIGN(x) (((x) + SMP_CACHE_BYTES-1) & ~(SMP_CACHE_BYTES-1)) > +#define XT_PCPU_BLOCK_SIZE 4096 > > struct compat_delta { > unsigned int offset; /* offset in kernel */ > @@ -1618,6 +1619,7 @@

Re: [PATCH nf-next 2/3] netfilter: x_tables: pass xt_counters struct to counter allocator

On Mon, 2016-11-21 at 14:57 +0100, Florian Westphal wrote: > Keeps some noise away from a followup patch. > > Signed-off-by: Florian Westphal <f...@strlen.de> > --- Acked-by: Eric Dumazet <eduma...@google.com> -- To unsubscribe from this list: send the line &quo

Re: [PATCH nf-next 1/3] netfilter: x_tables: pass xt_counters struct instead of packet counter

batch > chunks. > > Signed-off-by: Florian Westphal <f...@strlen.de> > --- Acked-by: Eric Dumazet <eduma...@google.com> -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majord...@vger.kernel.org More ma

Re: [PATCH nf] netfilter: conntrack: refine gc worker heuristics

On Tue, 2016-11-01 at 21:01 +0100, Florian Westphal wrote: > schedule_delayed_work(_work->dwork, next_run); > @@ -993,6 +1029,7 @@ static void gc_worker(struct work_struct *work) > static void conntrack_gc_work_init(struct conntrack_gc_work *gc_work) > { >

Re: [PATCH net-next] netfilter: nft_counter: rework atomic dump and reset

On Sat, 2016-12-10 at 15:25 +0100, Pablo Neira Ayuso wrote: > On Sat, Dec 10, 2016 at 03:16:55PM +0100, Pablo Neira Ayuso wrote: = > > - nft_counter_fetch(priv, , reset); > + nft_counter_fetch(priv, ); > + if (reset) > + nft_counter_reset(priv, ); > > if

Re: [PATCH 37/50] netfilter: nf_tables: atomic dump and reset for stateful objects

On Fri, 2016-12-09 at 11:24 +0100, Pablo Neira Ayuso wrote: > Hi Paul, Hi Pablo Given that bytes/packets counters are modified without cmpxchg64() : static inline void nft_counter_do_eval(struct nft_counter_percpu_priv *priv, struct nft_regs *regs,

Re: [PATCH 37/50] netfilter: nf_tables: atomic dump and reset for stateful objects

On Fri, 2016-12-09 at 06:24 -0800, Eric Dumazet wrote: > It looks that you want a seqcount, even on 64bit arches, > so that CPU 2 can restart its loop, and more importantly you need > to not accumulate the values you read, because they might be old/invalid. Untested patch to give genera

[PATCN v2 net-next] net_sched: gen_estimator: complete rewrite of rate estimators

From: Eric Dumazet <eduma...@google.com> 1) Old code was hard to maintain, due to complex lock chains. (We probably will be able to remove some kfree_rcu() in callers) 2) Using a single timer to update all estimators does not scale. 3) Code was buggy on 32bit kernel (WRITE_ONCE() on

[PATCN net-next] net_sched: gen_estimator: complete rewrite of rate estimators

From: Eric Dumazet <eduma...@google.com> 1) Old code was hard to maintain, due to complex lock chains. (We probably will be able to remove some kfree_rcu() in callers) 2) Using a single timer to update all estimators does not scale. 3) Code was buggy on 32bit kernel (WRITE_ONCE() on

Re: [PATCN net-next] net_sched: gen_estimator: complete rewrite of rate estimators

On Sat, 2016-12-03 at 23:07 -0800, Eric Dumazet wrote: > From: Eric Dumazet <eduma...@google.com> > > 1) Old code was hard to maintain, due to complex lock chains. >(We probably will be able to remove some kfree_rcu() in callers) > > 2) Using a single timer to up

Re: [PATCH nf-next] netfilter: xt_bpf: support ebpf

o pass the mode and path to the kernel to be > able to return it later for iptables dump and save. > > Signed-off-by: Willem de Bruijn <will...@google.com> > --- Assuming there is no simple way to get variable matchsize in iptables, this looks good to me, thanks. Revi

Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8

On Mon, 2017-04-03 at 11:10 +0300, Denys Fedoryshchenko wrote: > I modified patch a little as: > if (th->doff * 4 < sizeof(_tcph)) { > par->hotdrop = true; > WARN_ON_ONCE(!tcpinfo->option); > return false; > } > > And it did triggered WARN once at morning, and didn't hit KASAN. I will >

Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8

On Mon, 2017-04-03 at 15:14 +0300, Denys Fedoryshchenko wrote: > On 2017-04-03 15:09, Eric Dumazet wrote: > > On Mon, 2017-04-03 at 11:10 +0300, Denys Fedoryshchenko wrote: > > > >> I modified patch a little as: > >> if (th->doff * 4 < size

[PATCH net] netfilter: xt_TCPMSS: add more sanity tests on tcph->doff

From: Eric Dumazet <eduma...@google.com> Denys provided an awesome KASAN report pointing to an use after free in xt_TCPMSS I have provided three patches to fix this issue, either in xt_TCPMSS or in xt_tcpudp.c. It seems xt_TCPMSS patch has the smallest possible impact. Signed-off-by

Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8

On Sun, 2017-04-02 at 10:43 +0300, Denys Fedoryshchenko wrote: > Repost, due being sleepy missed few important points. > > I am searching reasons of crashes for multiple conntrack enabled > servers, usually they point to conntrack, but i suspect use after free > might be somewhere else, > so i

Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8

On Sun, 2017-04-02 at 13:45 +0200, Florian Westphal wrote: > Eric Dumazet <eric.duma...@gmail.com> wrote: > > - for (i = sizeof(struct tcphdr); i <= tcp_hdrlen - TCPOLEN_MSS; i += > > optlen(opt, i)) { > > + for (i = sizeof(struct tcphdr); i < tcp_hdrlen - TCP

Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8

On Sun, 2017-04-02 at 15:25 +0300, Denys Fedoryshchenko wrote: > > */ > I will add also WARN_ON_ONCE(tcp_hdrlen >= 15 * 4) before, for > curiosity, if this condition are triggered. Is it fine like that? Sure. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in

Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8

On Sun, 2017-04-02 at 04:54 -0700, Eric Dumazet wrote: > On Sun, 2017-04-02 at 13:45 +0200, Florian Westphal wrote: > > Eric Dumazet <eric.duma...@gmail.com> wrote: > > > - for (i = sizeof(struct tcphdr); i <= tcp_hdrlen - TCPOLEN_MSS; i += > > > optlen(opt,

Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8

On Sun, 2017-04-02 at 10:14 -0700, Eric Dumazet wrote: > Could that be that netfilter does not abort earlier if TCP header is > completely wrong ? > Yes, I wonder if this patch would be better, unless we replicate the th->doff sanity check in all netfilter modules dissecting TCP f

Re: KASAN, xt_TCPMSS finally found nasty use-after-free bug? 4.10.8

On Sun, 2017-04-02 at 19:52 +0300, Denys Fedoryshchenko wrote: > On 2017-04-02 15:32, Eric Dumazet wrote: > > On Sun, 2017-04-02 at 15:25 +0300, Denys Fedoryshchenko wrote: > >> > */ > >> I will add also WARN_ON_ONCE(tcp_hdrlen >= 15 * 4) before, for

Re: [PATCH nf-next] netfilter: tcp: Use TCP_MAX_WSCALE instead of literal 14

On Thu, 2017-04-20 at 08:44 +0800, Gao Feng wrote: > > On Wed, Apr 19, 2017 at 09:57:55PM +0200, Pablo Neira Ayuso wrote: > > > On Wed, Apr 19, 2017 at 09:22:08AM -0700, Eric Dumazet wrote: > > > > On Wed, 2017-04-19 at 17:58 +0200, Pablo Neira Ayuso wrote: > > &g

Re: [PATCH nf-next] netfilter: tcp: Use TCP_MAX_WSCALE instead of literal 14

On Wed, 2017-04-19 at 17:58 +0200, Pablo Neira Ayuso wrote: > On Wed, Apr 19, 2017 at 09:23:42AM +0800, gfree.w...@foxmail.com wrote: > > From: Gao Feng > > > > The window scale may be enlarged from 14 to 15 according to the itef > > draft

Re: [PATCH nf-next 0/2] netfilter: untracked object removal

On Wed, 2017-03-08 at 13:49 +0100, Florian Westphal wrote: > These patches remove the percpu untracked objects, they get replaced > with a new (kernel internal) ctinfo state. > > This avoids reference counter operations for untracked packets and > removes the need to check a conntrack for the

Re: [PATCH nf-next] netfilter: nft_set_rbtree: use seqcount to avoid lock in most cases

On Wed, 2017-07-26 at 02:09 +0200, Florian Westphal wrote: > switch to lockless lockup. write side now also increments sequence > counter. On lookup, sample counter value and only take the lock > if we did not find a match and the counter has changed. > > This avoids need to write to private

Re: [PATCH nf-next 4/4] netfilter: rt: add support to fetch path mss

On Tue, 2017-08-08 at 15:15 +0200, Florian Westphal wrote: > to be used in combination with tcp option set support to mimic > iptables TCPMSS --clamp-mss-to-pmtu. > > Signed-off-by: Florian Westphal > --- > include/uapi/linux/netfilter/nf_tables.h | 2 + >

Re: [PATCH] netfilter: nfnetlink: Improve input length sanitization in nfnetlink_rcv

On Wed, 2017-06-07 at 14:35 +0200, Mateusz Jurczyk wrote: > Verify that the length of the socket buffer is sufficient to cover the > entire nlh->nlmsg_len field before accessing that field for further > input sanitization. If the client only supplies 1-3 bytes of data in > sk_buff, then

Re: [PATCH v2] netfilter: xt_socket: Restore mark from full sockets only

On Thu, 2017-09-21 at 16:08 -0600, Subash Abhinov Kasiviswanathan wrote: > An out of bounds error was detected on an ARM64 target with > Android based kernel 4.9. This occurs while trying to > restore mark on a skb from an inet request socket. > > BUG: KASAN: slab-out-of-bounds in

Re: [PATCH] netfilter: xt_socket: Restore mark from full sockets only

On Thu, 2017-09-21 at 15:20 -0600, Subash Abhinov Kasiviswanathan wrote: > An out of bounds error was detected on an ARM64 target with > Android based kernel 4.9. This occurs while trying to > restore mark on a skb from an inet request socket. > > BUG: KASAN: slab-out-of-bounds in

[PATCH net] netfilter: x_tables: avoid stack-out-of-bounds read in xt_copy_counters_from_user

From: Eric Dumazet <eduma...@google.com> syzkaller reports an out of bound read in strlcpy(), triggered by xt_copy_counters_from_user() Fix this by using memcpy(), then forcing a zero byte at the last position of the destination, as Florian did for the non COMPAT code. Fixes: d7591f

Re: [PATCH nf-next 1/3] netfilter: convert hook list to an array

On Wed, 2017-08-23 at 17:26 +0200, Florian Westphal wrote: > From: Aaron Conole ... > -static struct nf_hook_entry __rcu **nf_hook_entry_head(struct net *net, > const struct nf_hook_ops *reg) > +static struct nf_hook_entries *allocate_hook_entries_size(u16 num) > +{ > +

Re: [PATCH nf] netfilter: xtables: add scheduling opportunity in get_counters

: Florian Westphal <f...@strlen.de> > --- > net/ipv4/netfilter/arp_tables.c | 1 + > net/ipv4/netfilter/ip_tables.c | 1 + > net/ipv6/netfilter/ip6_tables.c | 1 + > 3 files changed, 3 insertions(+) SGTM, thanks Florian ! Acked-by: Eric Dumazet <eduma...@google.com>

Re: [PATCH v3 nf-next 1/2] netfilter: x_tables: wait until old table isn't used anymore

eset > without any synchonization after xt_replace_table has completed. > > Cc: Dan Williams <d...@redhat.com> > Cc: Eric Dumazet <eduma...@google.com> > Signed-off-by: Florian Westphal <f...@strlen.de> > --- > v3: check for 'seq is uneven' OR 'has changed' since &

Re: [PATCH nf] netfilter: x_tables: ensure readers see new ->private value

On Wed, Oct 11, 2017 at 11:03 AM, Florian Westphal <f...@strlen.de> wrote: > Eric Dumazet wrote: > But it seems we need an extra smp_wmb() after > smp_wmb(); > table->private = newinfo; > > Otherwise we have no guarantee other cpus actually see the new >

Re: [PATCH v3 nf-next 1/2] netfilter: x_tables: wait until old table isn't used anymore

On Wed, Oct 11, 2017 at 11:18 AM, Florian Westphal <f...@strlen.de> wrote: > Eric Dumazet <eduma...@google.com> wrote: >> On Wed, Oct 11, 2017 at 10:48 AM, Florian Westphal <f...@strlen.de> wrote: >> > Eric Dumazet <eduma...@google.com> wrote: >

Re: [PATCH v3 nf-next 1/2] netfilter: x_tables: wait until old table isn't used anymore

On Wed, Oct 11, 2017 at 10:48 AM, Florian Westphal <f...@strlen.de> wrote: > Eric Dumazet <eduma...@google.com> wrote: >> On Wed, Oct 11, 2017 at 7:26 AM, Florian Westphal <f...@strlen.de> wrote: >> > xt_replace_table relies on table replacement counter

Re: [PATCH net-next v2] net: move decnet to staging

On Mon, 2017-11-13 at 11:32 -0800, Joe Perches wrote: > On Mon, 2017-11-13 at 09:11 -0800, Stephen Hemminger wrote: > > Support for Decnet has been orphaned for some time. > > In the interest of reducing the potential bug surface and pre-holiday > > cleaning, move the decnet protocol into staging

Re: [PATCH v2] netfilter: properly initialize xt_table_info structure

On 05/17/2018 02:34 AM, Greg Kroah-Hartman wrote: > When allocating a xt_table_info structure, we should be clearing out the > full amount of memory that was allocated, not just the "header" of the > structure. Otherwise odd values could be passed to userspace, which is > not a good thing. > >

[PATCH net] netfilter: x_tables: avoid out-of-bounds reads in xt_request_find_match()

From: Eric Dumazet <eduma...@google.com> It looks like syzbot found its way into netfilter territory. Issue here is that @name comes from user space and might not be null terminated. Out-of-bound reads happen, KASAN is not happy. Signed-off-by: Eric Dumazet <eduma...@google.com&

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

On Tue, 2018-01-30 at 11:30 -0800, a...@linux-foundation.org wrote: > From: Michal Hocko > Subject: net/netfilter/x_tables.c: make allocation less aggressive > > syzbot has noticed that xt_alloc_table_info can allocate a lot of memory. > This is an admin only interface but an

  1   2   >