linux-kernel - Re: [RESEND PATCH bpf-next v4 3/9] bpf: Refactor reporting log_true_size for prog

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: <372fbef8-6f47-4167-8568-eb39f9332d49@linux.dev>
Date: Wed, 7 Jan 2026 13:52:48 +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 3/9] bpf: Refactor reporting
 log_true_size for prog_load



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 8f464b847405..1739601fb7bd 100644
>> --- a/kernel/bpf/syscall.c
>> +++ b/kernel/bpf/syscall.c
> 
> [ ... ]
> 
>> @@ -6160,12 +6160,22 @@ static int prog_assoc_struct_ops(union bpf_attr *attr)
>>  	return ret;
>>  }
>>
>> +static int copy_prog_load_log_true_size(union bpf_attr *attr, bpfptr_t uattr, unsigned int size)
>> +{
>> +	if (size >= offsetofend(union bpf_attr, log_true_size) &&
>> +	    copy_to_bpfptr_offset(uattr, offsetof(union bpf_attr, log_true_size),
>> +				  &attr->log_true_size, sizeof(attr->log_true_size)))
>> +		return -EFAULT;
>> +
>> +	return 0;
>> +}
>> +
>>  static int __sys_bpf(enum bpf_cmd cmd, bpfptr_t uattr, unsigned int size,
>>  		     bpfptr_t uattr_common, unsigned int size_common)
>>  {
>>  	struct bpf_common_attr common_attrs;
>>  	union bpf_attr attr;
>> -	int err;
>> +	int err, ret;
> 
> [ ... ]
> 
>> @@ -6215,7 +6225,10 @@ static int __sys_bpf(enum bpf_cmd cmd, bpfptr_t uattr, unsigned int size,
>>  		err = map_freeze(&attr);
>>  		break;
>>  	case BPF_PROG_LOAD:
>> -		err = bpf_prog_load(&attr, uattr, size);
>> +		attr.log_true_size = 0;
>> +		err = bpf_prog_load(&attr, uattr);
>> +		ret = copy_prog_load_log_true_size(&attr, uattr, size);
>> +		err = ret ? ret : err;
>                     ^^^^^^^^^^^^^^^^^^^^
> 
> If bpf_prog_load() succeeds, it returns a positive file descriptor.
> Then if copy_prog_load_log_true_size() fails with -EFAULT, this line
> overwrites err with -EFAULT, losing the FD value.
> 
> The BPF program has already been loaded and the FD allocated at this
> point. Since the FD is never returned to userspace, the program
> remains loaded but unreachable - could this leak the BPF program?
> 

Indeed, the normal FD could be leaked if 'ret == -EFAULT'.

I'll address it in the next revision.

Thanks,
Leon

> In the previous code, the copy_to_bpfptr_offset() happened inside
> bpf_check() before the program was fully committed:
> 
>     if (uattr_size >= offsetofend(...) &&
>         copy_to_bpfptr_offset(...)) {
>             ret = -EFAULT;
>             goto err_release_maps;
>         }
> 
> This goto caused bpf_check() to return an error, preventing the FD
> allocation in bpf_prog_load(). Moving the copy outside changes the
> semantics - the FD can now be allocated before a copy failure occurs.
> 
>> +		break;
> 
> 
> ---
> 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