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: <e15a5de1-5a82-4137-8422-78306ba567e4@linux.dev>
Date: Mon, 28 Oct 2024 18:57:10 -0700
From: Martin KaFai Lau <martin.lau@...ux.dev>
To: Yonghong Song <yonghong.song@...ux.dev>,
 Cong Wang <xiyou.wangcong@...il.com>
Cc: bpf@...r.kernel.org, Cong Wang <cong.wang@...edance.com>,
 Ruan Bonan <bonan.ruan@...us.edu>, John Fastabend
 <john.fastabend@...il.com>, Jakub Sitnicki <jakub@...udflare.com>,
 netdev@...r.kernel.org
Subject: Re: [Patch bpf] sock_map: fix a NULL pointer dereference in
 sock_map_link_update_prog()

On 10/27/24 10:58 PM, Yonghong Song wrote:
> 
> On 10/26/24 11:55 AM, Cong Wang wrote:
>> From: Cong Wang <cong.wang@...edance.com>
>>
>> The following race condition could trigger a NULL pointer dereference:
>>
>> sock_map_link_detach():        sock_map_link_update_prog():
>>     mutex_lock(&sockmap_mutex);
>>     ...
>>     sockmap_link->map = NULL;
>>     mutex_unlock(&sockmap_mutex);
>>                        mutex_lock(&sockmap_mutex);
>>                    ...
>>                    sock_map_prog_link_lookup(sockmap_link->map);
>>                    mutex_unlock(&sockmap_mutex);
>>     <continue>
>>
>> Fix it by adding a NULL pointer check. In this specific case, it makes
>> no sense to update a link which is being released.
>>
>> Reported-by: Ruan Bonan <bonan.ruan@...us.edu>
>> Fixes: 699c23f02c65 ("bpf: Add bpf_link support for sk_msg and sk_skb progs")
>> Cc: Yonghong Song <yonghong.song@...ux.dev>
>> Cc: John Fastabend <john.fastabend@...il.com>
>> Cc: Jakub Sitnicki <jakub@...udflare.com>
>> Signed-off-by: Cong Wang <cong.wang@...edance.com>
>> ---
>>   net/core/sock_map.c | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/net/core/sock_map.c b/net/core/sock_map.c
>> index 07d6aa4e39ef..9fca4db52f57 100644
>> --- a/net/core/sock_map.c
>> +++ b/net/core/sock_map.c
>> @@ -1760,6 +1760,10 @@ static int sock_map_link_update_prog(struct bpf_link 
>> *link,
>>           ret = -EINVAL;
>>           goto out;
>>       }
>> +    if (!sockmap_link->map) {
>> +        ret = -EINVAL;
> 
> Thanks for the fix. Maybe we should use -ENOENT as the return error code?
> In this case, update_prog failed due to sockmap_link->map == NULL which is
> equivalent to no 'entry' to update.

The fix lgtm. Regarding the error value, the tcx/bpf_struct_ops/cgroup's 
update_prog uses -ENOLINK. I changed it to -ENOLINK for consistency. Applied. 
Thanks.

> 
>> +        goto out;
>> +    }
>>       ret = sock_map_prog_link_lookup(sockmap_link->map, &pprog, &plink,
>>                       sockmap_link->attach_type);
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ