[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <dc84f39f-5b13-4a7d-a26c-598227fd9a42@gmail.com>
Date: Mon, 18 Sep 2023 11:49:02 -0700
From: Kui-Feng Lee <sinquersw@...il.com>
To: Ma Ke <make_ruc2021@....com>, john.fastabend@...il.com,
jakub@...udflare.com, davem@...emloft.net, edumazet@...gle.com,
kuba@...nel.org, pabeni@...hat.com
Cc: netdev@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH] bpf, sockmap: fix deadlocks in the sockhash and sockmap
On 9/18/23 02:36, Ma Ke wrote:
> It seems that elements in sockhash are rarely actively
> deleted by users or ebpf program. Therefore, we do not
> pay much attention to their deletion. Compared with hash
> maps, sockhash only provides spin_lock_bh protection.
> This causes it to appear to have self-locking behavior
> in the interrupt context, as CVE-2023-0160 points out.
>
> Signed-off-by: Ma Ke <make_ruc2021@....com>
> ---
> net/core/sock_map.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/net/core/sock_map.c b/net/core/sock_map.c
> index cb11750b1df5..1302d484e769 100644
> --- a/net/core/sock_map.c
> +++ b/net/core/sock_map.c
> @@ -928,11 +928,12 @@ static long sock_hash_delete_elem(struct bpf_map *map, void *key)
> struct bpf_shtab_bucket *bucket;
> struct bpf_shtab_elem *elem;
> int ret = -ENOENT;
> + unsigned long flags;
Keep reverse xmas tree ordering?
>
> hash = sock_hash_bucket_hash(key, key_size);
> bucket = sock_hash_select_bucket(htab, hash);
>
> - spin_lock_bh(&bucket->lock);
> + spin_lock_irqsave(&bucket->lock, flags);
> elem = sock_hash_lookup_elem_raw(&bucket->head, hash, key, key_size);
> if (elem) {
> hlist_del_rcu(&elem->node);
> @@ -940,7 +941,7 @@ static long sock_hash_delete_elem(struct bpf_map *map, void *key)
> sock_hash_free_elem(htab, elem);
> ret = 0;
> }
> - spin_unlock_bh(&bucket->lock);
> + spin_unlock_irqrestore(&bucket->lock, flags);
> return ret;
> }
>
Powered by blists - more mailing lists