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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox