NACK: [SRU][F][PATCH v2 1/1] bpf: Allow delete from sockmap/sockhash only if update is allowed

Juerg Haefliger juerg.haefliger at canonical.com
Wed Feb 5 11:24:59 UTC 2025


On Wed, 27 Nov 2024 16:13:27 +0100
Massimiliano Pellizzer <massimiliano.pellizzer at canonical.com> wrote:

> From: Jakub Sitnicki <jakub at cloudflare.com>
> 
> We have seen an influx of syzkaller reports where a BPF program attached to
> a tracepoint triggers a locking rule violation by performing a map_delete
> on a sockmap/sockhash.
> 
> We don't intend to support this artificial use scenario. Extend the
> existing verifier allowed-program-type check for updating sockmap/sockhash
> to also cover deleting from a map.
> 
> From now on only BPF programs which were previously allowed to update
> sockmap/sockhash can delete from these map types.
> 
> Fixes: ff9105993240 ("bpf, sockmap: Prevent lock inversion deadlock in map delete elem")
> Reported-by: Tetsuo Handa <penguin-kernel at i-love.sakura.ne.jp>
> Reported-by: syzbot+ec941d6e24f633a59172 at syzkaller.appspotmail.com
> Signed-off-by: Jakub Sitnicki <jakub at cloudflare.com>
> Signed-off-by: Daniel Borkmann <daniel at iogearbox.net>
> Tested-by: syzbot+ec941d6e24f633a59172 at syzkaller.appspotmail.com
> Acked-by: John Fastabend <john.fastabend at gmail.com>
> Closes: https://syzkaller.appspot.com/bug?extid=ec941d6e24f633a59172
> Link: https://lore.kernel.org/bpf/20240527-sockmap-verify-deletes-v1-1-944b372f2101@cloudflare.com
> (backported from commit 98e948fb60d41447fd8d2d0c3b8637fc6b6dc26d)
> [mpellizzer: the fix commit depends on the function may_update_sockmap(),
> which was introduced by 0126240f448d in mainline in v5.10. Other than
> may_update_sockmap(), commit 0126240f448d introduces also a new bpf
> feature which is not affecting the patch and which is not worth
> backporting. Therefore, while backporting the fix commit I also backpoerted
> the function may_update_sockmap() considering the differences in
> context.]

This looks incorrect. The code is mostly from 0126240f448d but you're calling
it a backport of 98e948fb60d41447fd8d2d0c3b8637fc6b6dc26d. You need to add a
dedicated patch (partial backport of 0126240f448d) as a prereq. It's easier
to review/read and it also puts the sha 0126240f448d in the git log so that
we'll notice if there's a follow up fix for 0126240f448d.

With your current patch we'll never notice if there's fixup for
may_update_sockmap().

...Juerg


> CVE-2024-38662
> Signed-off-by: Massimiliano Pellizzer <massimiliano.pellizzer at canonical.com>
> ---
>  kernel/bpf/verifier.c | 40 ++++++++++++++++++++++++++++++++++++----
>  1 file changed, 36 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> index 7776b1a6a24c..318f9c267ff4 100644
> --- a/kernel/bpf/verifier.c
> +++ b/kernel/bpf/verifier.c
> @@ -3535,6 +3535,38 @@ static int check_func_arg(struct bpf_verifier_env *env, u32 regno,
>  	return -EACCES;
>  }
>  
> +static bool may_update_sockmap(struct bpf_verifier_env *env, int func_id)
> +{
> +	enum bpf_attach_type eatype = env->prog->expected_attach_type;
> +	enum bpf_prog_type type = env->prog->type;
> +
> +	if (func_id != BPF_FUNC_map_delete_elem)
> +		return false;
> +
> +	/* It's not possible to get access to a locked struct sock in these
> +	 * contexts, so updating is safe.
> +	 */
> +	switch (type) {
> +	case BPF_PROG_TYPE_SOCK_OPS:
> +		/* map_update allowed only via dedicated helpers with event type checks */
> +		if (func_id == BPF_FUNC_map_delete_elem)
> +			return true;
> +		break;
> +	case BPF_PROG_TYPE_SOCKET_FILTER:
> +	case BPF_PROG_TYPE_SCHED_CLS:
> +	case BPF_PROG_TYPE_SCHED_ACT:
> +	case BPF_PROG_TYPE_XDP:
> +	case BPF_PROG_TYPE_SK_REUSEPORT:
> +	case BPF_PROG_TYPE_FLOW_DISSECTOR:
> +		return true;
> +	default:
> +		break;
> +	}
> +
> +	verbose(env, "cannot update sockmap in this context\n");
> +	return false;
> +}
> +
>  static int check_map_func_compatibility(struct bpf_verifier_env *env,
>  					struct bpf_map *map, int func_id)
>  {
> @@ -3593,15 +3625,15 @@ static int check_map_func_compatibility(struct bpf_verifier_env *env,
>  	case BPF_MAP_TYPE_SOCKMAP:
>  		if (func_id != BPF_FUNC_sk_redirect_map &&
>  		    func_id != BPF_FUNC_sock_map_update &&
> -		    func_id != BPF_FUNC_map_delete_elem &&
> -		    func_id != BPF_FUNC_msg_redirect_map)
> +		    func_id != BPF_FUNC_msg_redirect_map &&
> +		    !may_update_sockmap(env, func_id))
>  			goto error;
>  		break;
>  	case BPF_MAP_TYPE_SOCKHASH:
>  		if (func_id != BPF_FUNC_sk_redirect_hash &&
>  		    func_id != BPF_FUNC_sock_hash_update &&
> -		    func_id != BPF_FUNC_map_delete_elem &&
> -		    func_id != BPF_FUNC_msg_redirect_hash)
> +		    func_id != BPF_FUNC_msg_redirect_hash &&
> +		    !may_update_sockmap(env, func_id))
>  			goto error;
>  		break;
>  	case BPF_MAP_TYPE_REUSEPORT_SOCKARRAY:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20250205/e2a90275/attachment.sig>


More information about the kernel-team mailing list