On 7/1/26 01:44, [email protected] 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
