lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 08 Sep 2020 10:46:13 +0200
From:   Paolo Abeni <>
        "David S . Miller" <>,
        Eric Dumazet <>
Subject: Re: [PATCH] net/sock: don't drop udp packets if udp_mem[2] not


On Tue, 2020-09-08 at 11:15 +0800, wrote:
> Actually, with more udp sockets, I can always make it large
> enough to exceed udp_mem[0], and drop packets before udp_mem[1]
> and udp_mem[2].

Sure, but with enough sockets you can also exceeeds any limits ;).

> diff --git a/net/core/sock.c b/net/core/sock.c
> index 6c5c6b18eff4..fed8211d8dbe 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -2648,6 +2648,12 @@ int __sk_mem_raise_allocated(struct sock *sk, int size, int amt, int kind)
>                                  atomic_read(&sk->sk_rmem_alloc) +
>                                  sk->sk_forward_alloc))
>                         return 1;
> +       } else {
> +               /* for prots without memory_pressure callbacks, we should not
> +                * drop until hard limit reached
> +                */
> +               if (allocated <= sk_prot_mem_limits(sk, 2))
> +                       return 1;

At this point, the above condition is always true, due to an earlier
check. Additionally, accepting any value below udp_mem[2] would make
the previous checks to allow a minimum per socket memory useless.

You can obtain the same result setting udp_mem[0] = udp_mem[2], without
any kernel change. 

But with this change applied you can't guarantee anymore a minimum per
socket amount of memory.

I think you are possibly mislead by your own comment: the point is that
we should never allow allocation above the hard limit, but the protocol
is allowed to drop as soon as the memory allocated raises above the
lower limit.

Note that the current behavior is correctly documented
in Documentation/networking/ip-sysctl.rst.

Your problem must be solved in another way e.g. raising udp_mem[0] -
and keeping udp_mem[2] above that value.



Powered by blists - more mailing lists