linux-kernel - Re: [RESEND PATCH bpf-next v4 7/9] bpf: Add common attr support for map

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: <db428e27fdf0110ea05cdadf8980c7758d7f4dcd61289293394db7e34ce99601@mail.kernel.org>
Date: Tue,  6 Jan 2026 17:44:31 +0000 (UTC)
From: bot+bpf-ci@...nel.org
To: leon.hwang@...ux.dev,bpf@...r.kernel.org
Cc: ast@...nel.org,daniel@...earbox.net,andrii@...nel.org,martin.lau@...ux.dev,eddyz87@...il.com,song@...nel.org,yonghong.song@...ux.dev,john.fastabend@...il.com,kpsingh@...nel.org,sdf@...ichev.me,haoluo@...gle.com,jolsa@...nel.org,shuah@...nel.org,brauner@...nel.org,oleg@...hat.com,leon.hwang@...ux.dev,sforshee@...nel.org,yuichtsu@...zon.com,aalbersh@...hat.com,willemb@...gle.com,kerneljasonxing@...il.com,paul.chaignon@...il.com,yatsenko@...a.com,memxor@...il.com,a.s.protopopov@...il.com,ameryhung@...il.com,rongtao@...tc.cn,linux-kernel@...r.kernel.org,linux-api@...r.kernel.org,linux-kselftest@...r.kernel.org,kernel-patches-bot@...com,ast@...nel.org,andrii@...nel.org,daniel@...earbox.net,martin.lau@...nel.org,eddyz87@...il.com,yonghong.song@...ux.dev,clm@...a.com,ihor.solodrai@...ux.dev
Subject: Re: [RESEND PATCH bpf-next v4 7/9] bpf: Add common attr support for map_create

> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 14fc5738f2b9..e64cc7504731 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c

[ ... ]

> @@ -6279,7 +6345,11 @@ static int __sys_bpf(enum bpf_cmd cmd, bpfptr_t uattr, unsigned int size,
>
>  	switch (cmd) {
>  	case BPF_MAP_CREATE:
> -		err = map_create(&attr, uattr);
> +		common_attrs.log_true_size = 0;
> +		err = map_create(&attr, uattr, &common_attrs);
> +		ret = copy_common_attr_log_true_size(uattr_common, size_common,
> +						     &common_attrs.log_true_size);
> +		err = ret ? ret : err;

When map_create() succeeds, it returns a file descriptor that is already
installed in the caller's fd table via bpf_map_new_fd(). If
copy_common_attr_log_true_size() then fails (e.g., user provided a
read-only buffer for uattr_common), the syscall returns -EFAULT but the
fd remains installed.

Could this leak the file descriptor? The user gets an error and has no
way to know what fd number was allocated, so they cannot close it.

The sequence would be:
  1. map_create() succeeds, returns fd (e.g., 5)
  2. copy_common_attr_log_true_size() fails, ret = -EFAULT
  3. err = ret ? ret : err = -EFAULT
  4. syscall returns -EFAULT
  5. map and fd persist, but user cannot close fd 5

> +		break;
>  	case BPF_MAP_LOOKUP_ELEM:
>  		err = map_lookup_elem(&attr);


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/20756616585