On Sat, Aug 21, 2021 at 01:17:36PM +0300, Kalle Valo wrote: > Kees Cook <keescook@xxxxxxxxxxxx> writes: > > > On Thu, Aug 19, 2021 at 04:19:37PM +0300, Kalle Valo wrote: > >> Kees Cook <keescook@xxxxxxxxxxxx> writes: > >> > >> > In preparation for FORTIFY_SOURCE performing compile-time and run-time > >> > field bounds checking for memset(), avoid intentionally writing across > >> > neighboring fields. > >> > > >> > Use memset_startat() so memset() doesn't get confused about writing > >> > beyond the destination member that is intended to be the starting point > >> > of zeroing through the end of the struct. Additionally split up a later > >> > field-spanning memset() so that memset() can reason about the size. > >> > > >> > Cc: Kalle Valo <kvalo@xxxxxxxxxxxxxx> > >> > Cc: "David S. Miller" <davem@xxxxxxxxxxxxx> > >> > Cc: Jakub Kicinski <kuba@xxxxxxxxxx> > >> > Cc: ath11k@xxxxxxxxxxxxxxxxxxx > >> > Cc: linux-wireless@xxxxxxxxxxxxxxx > >> > Cc: netdev@xxxxxxxxxxxxxxx > >> > Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx> > >> > >> To avoid conflicts I prefer taking this via my ath tree. > > > > The memset helpers are introduced as part of this series, so that makes > > things more difficult. Do you want me to create a branch with the > > helpers that you can merge? > > Is this patch really worth the extra complexity? Why can't I apply this > ath11k patch after the helpers have landed Linus' tree? That would be > very simple. Not singularly, no. But I have a bit of a catch-22 in that I can't turn on greater FORTIFY strictness without first fixing the false positives, and I can't fix the false positives in "other" trees without those trees first having the helpers that get introduced by the FORTIFY series. :) Anyway, since we're close to the merge window anyway, the FORTIFY series won't land in 1 release at this point regardless, so I'll just get the helpers landed and we can do the individual pieces once the merge window closes. Wheee :) -- Kees Cook
