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: <28ace50f-9ae6-46da-a05d-eab31f33f9cb@linux.dev>
Date: Wed, 7 Jan 2026 13:56:51 +0800
From: Leon Hwang <leon.hwang@...ux.dev>
To: bot+bpf-ci@...nel.org, 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, 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,
 martin.lau@...nel.org, clm@...a.com, ihor.solodrai@...ux.dev
Subject: Re: [RESEND PATCH bpf-next v4 7/9] bpf: Add common attr support for
 map_create



On 7/1/26 01:44, bot+bpf-ci@...nel.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