lists.openwall.net   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  linux-cve-announce  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, 12 Nov 2019 09:56:45 +0100
From:   Adeel Sharif <madeel.sharif@...glemail.com>
To:     Cong Wang <xiyou.wangcong@...il.com>
Cc:     Linux Kernel Network Developers <netdev@...r.kernel.org>
Subject: Re: Unix domain socket missing error code

It should but it is not used when two different sockets are communicating.
This is the third check in the if statement and it is never called
because the first unlikely check was false:

if (other != sk &&
        unlikely(unix_peer(other) != sk && unix_recvq_full(other))) {

Thanks.

On Tue, Nov 12, 2019 at 1:12 AM Cong Wang <xiyou.wangcong@...il.com> wrote:
>
> On Mon, Nov 11, 2019 at 5:41 AM Adeel Sharif
> <madeel.sharif@...glemail.com> wrote:
> >
> > Hello,
> >
> > We are a group of people working on making Linux safe for everyone. In
> > hope of doing that I started testing the System Calls. The one I am
> > currently working on is send/write.
> >
> > If send() is used to send datagrams on unix socket and the receiver
> > has stopped receiving, but still connected, there is a high
> > possibility that Linux kernel could eat up the whole system memory.
> > Although there is a system wide limit on write memory from wmem_max
> > parameter but this is sometimes also increased to system momory size
> > in order to avoid packet drops.
> >
> > After having a look in the kernel implementation of
> > unix_dgram_sendmsg() it is obvious that user buffers are copied into
> > kernel socket buffers and they are queued to a linked list. This list
> > is growing without any limits. Although there is a qlen parameter but
> > it is never used to impose a limit on it. Could we perhaps impose a
> > limit on it and return an error with errcode Queue_Full or something
> > instead?
>
> Isn't unix_recvq_full() supposed to do what you said? It is called inside
> unix_dgram_sendmsg() to determine whether to wake up the dst socket.
>
> Thanks.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ