netdev - Re: [PATCH] net/af_unix: don't create a path for a binded socket

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]

Message-ID: <CAOJe8K1EVPapfRrtzK1hD4_St9vqFT1aad4JvE1Ch6X-rD6=iA@mail.gmail.com>
Date:   Thu, 26 Nov 2020 17:22:08 +0300
From:   Denis Kirjanov <kda@...ux-powerpc.org>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     netdev@...r.kernel.org, davem@...emloft.net
Subject: Re: [PATCH] net/af_unix: don't create a path for a binded socket

On 11/26/20, Jakub Kicinski <kuba@...nel.org> wrote:
> On Tue, 24 Nov 2020 15:24:21 +0300 Denis Kirjanov wrote:
>> in the case of the socket which is bound to an adress
>> there is no sense to create a path in the next attempts
>
>> diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
>> index 41c3303c3357..fd76a8fe3907 100644
>> --- a/net/unix/af_unix.c
>> +++ b/net/unix/af_unix.c
>> @@ -1021,7 +1021,7 @@ static int unix_bind(struct socket *sock, struct
>> sockaddr *uaddr, int addr_len)
>>
>>  	err = -EINVAL;
>>  	if (addr_len < offsetofend(struct sockaddr_un, sun_family) ||
>> -	    sunaddr->sun_family != AF_UNIX)
>> +	    sunaddr->sun_family != AF_UNIX || u->addr)
>>  		goto out;
>>
>>  	if (addr_len == sizeof(short)) {
>> @@ -1049,10 +1049,6 @@ static int unix_bind(struct socket *sock, struct
>> sockaddr *uaddr, int addr_len)
>>  	if (err)
>>  		goto out_put;
>>
>> -	err = -EINVAL;
>> -	if (u->addr)
>> -		goto out_up;
>> -
>>  	err = -ENOMEM;
>>  	addr = kmalloc(sizeof(*addr)+addr_len, GFP_KERNEL);
>>  	if (!addr)
>
> Well, after your change the check on u->addr is no longer protected by
> u->bindlock. Is that okay?

Since we're just checking the assigned address and it's an atomic
operation I think it's okay.
A process performing binding is still protected.

Thanks!


>