On Thu, May 21, 2026 at 1:41 PM Yuyang Huang <[email protected]> wrote:
>
> >This looks like a bug fix for an out-of-bounds write vulnerability.
> >Should this include a Fixes: tag to identify which commit introduced the
> >unconditional copy_to_user() calls for query.revision without checking
> >the user-provided buffer size?
>
> > Fixes: 3fe213c040b3 ("adding ci files")
>
> I completely missed this checkpatch comment. I will add the Fixes tag
> in v2 if there is a consensus that this patch is the right approach to
> resolve the issue.
AI is wrong.
The fixes tag should probably point to 053c8e1f235dc or a subsequent patch?
bpf_mprog_query() and tcx_prog_query() were only introduced there.
How come your userspace passes shorter uatter to query newer
BPF_TCX_EGRESS attachment?
Please provide more details.
I'm still not convinced that what you're saying:
"
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)
"
is a kernel bug.
Looks like user space is querying new attachment types
with old structure.
Potentially the check can only be around:
case BPF_TCX_INGRESS:
case BPF_TCX_EGRESS:
return tcx_prog_query(attr, uattr);
to be nice to broken user space,
but, really, attr->query.attach_type shouldn't be equal to BPF_TCX_EGRESS
with a smaller uattr.
pw-bot: cr
