Re: [for-next v4 3/5] RDMA/ionic: map PHC state into user space

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Unconstrained ib_copy_to_udata causes out-of-bounds write in userspace memory and ABI breakage.
--

commit 92d10c24093a8b27cdd06722f8f50e627c7ca437
Author: Abhijit Gangurde <abhijit.gangurde@amd.com>

RDMA/ionic: map PHC state into user space

This commit enables user space applications to access the PHC state page
when firmware RDMA completion timestamping is supported. It maps the PHC
state into user space to allow timestamp conversion without kernel
transitions.

> diff --git a/include/uapi/rdma/ionic-abi.h b/include/uapi/rdma/ionic-abi.h
> index 7b589d3e9728e..2c70ac149c4ff 100644
> --- a/include/uapi/rdma/ionic-abi.h
> +++ b/include/uapi/rdma/ionic-abi.h
> @@ -48,6 +48,7 @@ struct ionic_ctx_resp {
>  	__u8 expdb_qtypes;
>  
>  	__u8 rsvd2[3];
> +	__aligned_u64 phc_offset;
>  };

[Severity: Critical]
Does adding phc_offset to ionic_ctx_resp break userspace ABI backward
compatibility and cause an out-of-bounds write in userspace memory?

Looking at ionic_alloc_ucontext() in ionic_controlpath.c, the driver copies
the response to userspace using the new, larger struct size:

    rc = ib_copy_to_udata(udata, &resp, sizeof(resp));

Since this commit increases the size of struct ionic_ctx_resp from 32 bytes
to 40 bytes, and the copy uses sizeof(resp) without restricting the length
to udata->outlen, won't older userspace binaries passing an outlen of 32
receive 40 bytes?

This appears to directly pass the larger length to copy_to_user() via
ib_copy_to_udata(), potentially overflowing the userspace application's
stack or heap buffer. Should the copy length be bounded by udata->outlen
to safely support older userspace clients?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260610154216.712374-1-abhijit.gangurde@amd.com?part=3