>The whole thing sounds like a user space bug.
Could you please clarify why you consider this a userspace bug?
>From our perspective, this is a binary backward compatibility issue.
An older binary compiled against older UAPI headers has no way of
knowing about newer fields. If it passes size = 40 (the correct size
at the time), the kernel violates the ABI contract by writing beyond
that declared size.
> Please demonstrate a case where this issue is seen by using libbpf APIs.
Our old project does not use libbpf; we interface directly with the
raw BPF syscall.
For example, our Android net_test suite uses this legacy 40-byte
Python ctypes struct layout:
# legacy 40-byte layout (pre-revision field)
BpfAttrProgQuery = cstruct.Struct(
"bpf_attr_prog_query", "=IIIIQI4xQ",
"target_fd attach_type query_flags attach_flags prog_ids_ptr
prog_cnt prog_attach_flags"
)
# Invoked via: syscall(__NR_bpf, BPF_PROG_QUERY, &attr, 40)
As shown in the original discussion thread, without this fix, a newer
kernel unconditionally writes the optional revision field at offset
56. Since copy_to_user doesn't fault on adjacent mapped memory, this
silently corrupts 8 bytes of the caller's heap (corrupting the Python
interpreter).
This size-gating pattern in this patch should be identical to the
pattern introduced by commit 47a71c1f9af0 in btf.c.
I am not 100% sure but, it seems running a binary statically linked
with an older libbpf version (or directly using raw BPF syscalls)
might face a similar issue? Do we expect those binaries to be broken
in the newer kernel version?
On Mon, May 18, 2026 at 12:30 PM Alexei Starovoitov
<[email protected]> wrote:
>
> On Fri, May 15, 2026 at 12:15 AM Yuyang Huang <[email protected]> wrote:
> >
> > The bpf(cmd, attr, size) syscall copies up to 'size' bytes on input, but
> > several commands write outputs back to userspace unconditionally. If the
> > caller passes a short buffer, this can lead to out-of-bounds writes,
> > potentially overwriting adjacent userspace memory.
>
> The whole thing sounds like a user space bug.
> Please demonstrate a case where this issue is seen
> by using libbpf APIs.
