On Wed, May 01, 2024 at 05:02:42PM +0200, Erick Archer wrote:
The "struct batadv_tvlv_tt_data" uses a dynamically sized set of trailing elements. Specifically, it uses an array of structures of type "batadv_tvlv_tt_vlan_data". So, use the preferred way in the kernel declaring a flexible array [1].
At the same time, prepare for the coming implementation by GCC and Clang of the __counted_by attribute. Flexible array members annotated with __counted_by can have their accesses bounds-checked at run-time via CONFIG_UBSAN_BOUNDS (for array indexing) and CONFIG_FORTIFY_SOURCE (for strcpy/memcpy-family functions). In this case, it is important to note that the attribute used is specifically __counted_by_be since variable "num_vlan" is of type __be16.
The following change to the "batadv_tt_tvlv_ogm_handler_v1" function:
- tt_vlan = (struct batadv_tvlv_tt_vlan_data *)(tt_data + 1);
- tt_change = (struct batadv_tvlv_tt_change *)(tt_vlan + num_vlan);
- tt_change = (struct batadv_tvlv_tt_change *)((void *)tt_data
+ flex_size);
is intended to prevent the compiler from generating an "out-of-bounds" notification due to the __counted_by attribute. The compiler can do a pointer calculation using the vlan_data flexible array memory, or in other words, this may be calculated as an array offset, since it is the same as:
&tt_data->vlan_data[num_vlan]
Therefore, we go past the end of the array. In other "multiple trailing flexible array" situations, this has been solved by addressing from the base pointer, since the compiler either knows the full allocation size or it knows nothing about it (this case, since it came from a "void *" function argument).
The order in which the structure batadv_tvlv_tt_data and the structure batadv_tvlv_tt_vlan_data are defined must be swap to avoid an incomplete type error.
Also, avoid the open-coded arithmetic in memory allocator functions [2] using the "struct_size" macro and use the "flex_array_size" helper to clarify some calculations, when possible.
Moreover, the new structure member also allow us to avoid the open-coded arithmetic on pointers in some situations. Take advantage of this.
This code was detected with the help of Coccinelle, and audited and modified manually.
Link: https://www.kernel.org/doc/html/next/process/deprecated.html#zero-length-and... [1] Link: https://www.kernel.org/doc/html/next/process/deprecated.html#open-coded-arit... [2] Signed-off-by: Erick Archer erick.archer@outlook.com
Thanks for the tweak!
Reviewed-by: Kees Cook keescook@chromium.org