Re: [PATCH] tty: mxser: Remove __counted_by from mxser_board.ports[]

Gustavo A. R. Silva
2024-06-28T02:51:38Z

On 27/06/24 11:14, Kees Cook wrote:
> On Wed, May 29, 2024 at 02:29:42PM -0700, Nathan Chancellor wrote:
>> Work for __counted_by on generic pointers in structures (not just
>> flexible array members) has started landing in Clang 19 (current tip of
>> tree). During the development of this feature, a restriction was added
>> to __counted_by to prevent the flexible array member's element type from
>> including a flexible array member itself such as:
>>
>> struct foo {
>> int count;
>> char buf[];
>> };
>>
>> struct bar {
>> int count;
>> struct foo data[] __counted_by(count);
>> };
>>
>> because the size of data cannot be calculated with the standard array
>> size formula:
>>
>> sizeof(struct foo) * count
>>
>> This restriction was downgraded to a warning but due to CONFIG_WERROR,
>> it can still break the build. The application of __counted_by on the
>> ports member of 'struct mxser_board' triggers this restriction,
>> resulting in:
>>
>> drivers/tty/mxser.c:291:2: error: 'counted_by' should not be applied to an array with element of unknown size because 'struct mxser_port' is a struct type with a flexible array member. This will be an error in a future compiler version [-Werror,-Wbounds-safety-counted-by-elt-type-unknown-size]
>> 291 | struct mxser_port ports[] __counted_by(nports);
>> | ^~~~~~~~~~~~~~~~~~~~~~~~~
>> 1 error generated.
>>
>> Remove this use of __counted_by to fix the warning/error. However,
>> rather than remove it altogether, leave it commented, as it may be
>> possible to support this in future compiler releases.
>>
>> Cc: stable@vger.kernel.org
>> Closes: https://github.com/ClangBuiltLinux/linux/issues/2026
>> Fixes: f34907ecca71 ("mxser: Annotate struct mxser_board with __counted_by")
>> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
>
> Since this fixes a build issue under Clang, can we please land this so
> v6.7 and later will build again? Gustavo is still working on the more
> complete fix (which was already on his radar, so it won't be lost).
>
> If it's easier/helpful, I can land this via the hardening tree? I was
> the one who sent the bad patch originally. :)

+1 (It'd be great if you take it.)

Also, it'd be great if somebody can confirm this is an acceptable fix
for the issue:

https://lore.kernel.org/linux-hardening/c80e41e6-793e-4311-8e15-f5eda91e723e@embeddedor.com/

Thanks
--
Gustavo