From: Leon Hwang <leon.hwang@linux.dev>
To: bot+bpf-ci@kernel.org, bpf@vger.kernel.org
Cc: ast@kernel.org, daniel@iogearbox.net, andrii@kernel.org,
martin.lau@linux.dev, eddyz87@gmail.com, song@kernel.org,
yonghong.song@linux.dev, john.fastabend@gmail.com,
kpsingh@kernel.org, sdf@fomichev.me, haoluo@google.com,
jolsa@kernel.org, shuah@kernel.org, brauner@kernel.org,
oleg@redhat.com, sforshee@kernel.org, yuichtsu@amazon.com,
aalbersh@redhat.com, willemb@google.com,
kerneljasonxing@gmail.com, paul.chaignon@gmail.com,
yatsenko@meta.com, memxor@gmail.com, a.s.protopopov@gmail.com,
ameryhung@gmail.com, rongtao@cestc.cn,
linux-kernel@vger.kernel.org, linux-api@vger.kernel.org,
linux-kselftest@vger.kernel.org, kernel-patches-bot@fb.com,
martin.lau@kernel.org, clm@meta.com, ihor.solodrai@linux.dev
Subject: Re: [RESEND PATCH bpf-next v4 7/9] bpf: Add common attr support for map_create
Date: Wed, 7 Jan 2026 13:56:51 +0800 [thread overview]
Message-ID: <28ace50f-9ae6-46da-a05d-eab31f33f9cb@linux.dev> (raw)
In-Reply-To: <db428e27fdf0110ea05cdadf8980c7758d7f4dcd61289293394db7e34ce99601@mail.kernel.org>
On 7/1/26 01:44, bot+bpf-ci@kernel.org wrote:
>> 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.
>
Good catch — you’re right.
If 'map_create()' succeeds and 'copy_common_attr_log_true_size()' later
fails (e.g. returning -EFAULT), the newly created file descriptor would
remain installed and could be leaked.
I’ll fix this in the next revision by explicitly closing the fd when
ret is non-zero.
Thanks,
Leon
> 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
next prev parent reply other threads:[~2026-01-07 5:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-06 17:20 [RESEND PATCH bpf-next v4 0/9] bpf: Extend bpf syscall with common attributes support Leon Hwang
2026-01-06 17:20 ` [RESEND PATCH bpf-next v4 1/9] " Leon Hwang
2026-01-06 17:20 ` [RESEND PATCH bpf-next v4 2/9] libbpf: Add support for extended bpf syscall Leon Hwang
2026-01-06 17:20 ` [RESEND PATCH bpf-next v4 3/9] bpf: Refactor reporting log_true_size for prog_load Leon Hwang
2026-01-06 17:44 ` bot+bpf-ci
2026-01-07 5:52 ` Leon Hwang
2026-01-06 17:20 ` [RESEND PATCH bpf-next v4 4/9] bpf: Add common attr support " Leon Hwang
2026-01-06 17:20 ` [RESEND PATCH bpf-next v4 5/9] bpf: Refactor reporting btf_log_true_size for btf_load Leon Hwang
2026-01-06 17:20 ` [RESEND PATCH bpf-next v4 6/9] bpf: Add common attr support " Leon Hwang
2026-01-06 17:20 ` [RESEND PATCH bpf-next v4 7/9] bpf: Add common attr support for map_create Leon Hwang
2026-01-06 17:44 ` bot+bpf-ci
2026-01-07 5:56 ` Leon Hwang [this message]
2026-01-07 6:20 ` Alexei Starovoitov
2026-01-07 6:31 ` Leon Hwang
2026-01-09 21:08 ` Alexei Starovoitov
2026-01-06 17:20 ` [RESEND PATCH bpf-next v4 8/9] libbpf: " Leon Hwang
2026-01-06 17:20 ` [RESEND PATCH bpf-next v4 9/9] selftests/bpf: Add tests to verify map create failure log Leon Hwang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=28ace50f-9ae6-46da-a05d-eab31f33f9cb@linux.dev \
--to=leon.hwang@linux.dev \
--cc=a.s.protopopov@gmail.com \
--cc=aalbersh@redhat.com \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bot+bpf-ci@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=brauner@kernel.org \
--cc=clm@meta.com \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=haoluo@google.com \
--cc=ihor.solodrai@linux.dev \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kernel-patches-bot@fb.com \
--cc=kerneljasonxing@gmail.com \
--cc=kpsingh@kernel.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=martin.lau@kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=oleg@redhat.com \
--cc=paul.chaignon@gmail.com \
--cc=rongtao@cestc.cn \
--cc=sdf@fomichev.me \
--cc=sforshee@kernel.org \
--cc=shuah@kernel.org \
--cc=song@kernel.org \
--cc=willemb@google.com \
--cc=yatsenko@meta.com \
--cc=yonghong.song@linux.dev \
--cc=yuichtsu@amazon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.