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
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
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
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;
>
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
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
>
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)
> +{
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
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
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
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--;
> >> > >
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
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
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
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
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
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
> >
101 - 117 of 117 matches
Mail list logo