On Fri, Mar 01, 2024 at 12:37:45PM -0600, Gustavo A. R. Silva wrote:
> -Wflex-array-member-not-at-end is coming in GCC-14, and we are getting
> ready to enable it globally.
>
> There are currently a couple of objects (`alloc_head` and `bundle`) in
> `struct bundle_priv` that contain a couple of flexible structures:
>
> struct bundle_priv {
> /* Must be first */
> struct bundle_alloc_head alloc_head;
>
> ...
>
> /*
> * Must be last. bundle ends in a flex array which overlaps
> * internal_buffer.
> */
> struct uverbs_attr_bundle bundle;
> u64 internal_buffer[32];
> };
>
> So, in order to avoid ending up with a couple of flexible-array members
> in the middle of a struct, we use the `struct_group_tagged()` helper to
> separate the flexible array from the rest of the members in the flexible
> structures:
>
> struct uverbs_attr_bundle {
> struct_group_tagged(uverbs_attr_bundle_hdr, hdr,
> ... the rest of the members
> );
> struct uverbs_attr attrs[];
> };
>
> With the change described above, we now declare objects of the type of
> the tagged struct without embedding flexible arrays in the middle of
> another struct:
>
> struct bundle_priv {
> /* Must be first */
> struct bundle_alloc_head_hdr alloc_head;
>
> ...
>
> struct uverbs_attr_bundle_hdr bundle;
> u64 internal_buffer[32];
> };
>
> We also use `container_of()` whenever we need to retrieve a pointer
> to the flexible structures.
>
> Notice that the `bundle_size` computed in `uapi_compute_bundle_size()`
> remains the same.
>
> So, with these changes, fix the following warnings:
>
> drivers/infiniband/core/uverbs_ioctl.c:45:34: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> 45 | struct bundle_alloc_head alloc_head;
> | ^~~~~~~~~~
> drivers/infiniband/core/uverbs_ioctl.c:67:35: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> 67 | struct uverbs_attr_bundle bundle;
> | ^~~~~~
>
> Signed-off-by: Gustavo A. R. Silva <gustavoars@xxxxxxxxxx>
This looks complex, but I think it's simpler that other changes that
would have much more collateral impact. Thanks for figuring out a
workable solution!
Reviewed-by: Kees Cook <keescook@xxxxxxxxxxxx>
--
Kees Cook
