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

2016-07-07 Thread Eric Dumazet
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: DoS attack mitigation in netfilter

2016-07-06 Thread Eric Dumazet
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: [PATCH 4/5] ipvs: Lock socket before setting SK_CAN_REUSE

2016-06-13 Thread Eric Dumazet
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

2016-06-13 Thread Eric Dumazet
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 net-next] nfnetlink_queue: enable PID info retrieval

2016-06-10 Thread Eric Dumazet
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 net-next] nfnetlink_queue: enable PID info retrieval

2016-06-09 Thread Eric Dumazet
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 v2 nf-next 7/9] netfilter: conntrack: make netns address part of hash

2016-05-02 Thread Eric Dumazet
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: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

2016-03-28 Thread Eric Dumazet
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: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet

2016-03-28 Thread Eric Dumazet
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

2016-03-28 Thread Eric Dumazet
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

2016-03-28 Thread Eric Dumazet
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: net/sctp: stack-out-of-bounds in sctp_getsockopt

2016-03-23 Thread Eric Dumazet
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

2016-03-22 Thread Eric Dumazet
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] netfilter: x_tables: ensure e->next_offset consistency with table size

2016-03-18 Thread Eric Dumazet
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: [PATCH V3] netfilter: h323: avoid potential attack

2016-02-01 Thread Eric Dumazet
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 V2] netfilter: h323: avoid potential attack

2016-01-28 Thread Eric Dumazet
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

2016-01-28 Thread Eric Dumazet
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 > >

<    1   2