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: <53542ad28c0d27ffcfcf9ea325fb6a77eeb3d569e17a6fad9d95685b5ea25467@mail.kernel.org>
Date: Tue,  6 Jan 2026 17:44:30 +0000 (UTC)
From: bot+bpf-ci@...nel.org
To: leon.hwang@...ux.dev,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,leon.hwang@...ux.dev,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,ast@...nel.org,andrii@...nel.org,daniel@...earbox.net,martin.lau@...nel.org,eddyz87@...il.com,yonghong.song@...ux.dev,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

> 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?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ