On Mon, Aug 02, 2021 at 02:29:28PM +0000, Shai Malin wrote:
On Tue, Jul 31, 2021 at 07:07:00PM -0300, Kees Cook wrote:
On Tue, Jul 27, 2021 at 01:58:33PM -0700, Kees Cook wrote:
In preparation for FORTIFY_SOURCE performing compile-time and run-time field bounds checking for memset(), avoid intentionally writing across neighboring fields.
Use memset_after() 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.
Signed-off-by: Kees Cook keescook@chromium.org
The old code seems to be doing the wrong thing: starting from not the first member, but sized for the whole struct. Which is correct?
Quick ping on this question.
The old code seems to be doing the wrong thing: it starts from the second member and writes beyond int_info, clobbering qede_lock:
Thanks for highlighting the problem, but actually, the memset is redundant. We will remove it so the change will not be needed.
struct qede_dev { ... struct qed_int_info int_info;
/* Smaller private variant of the RTNL lock */ struct mutex qede_lock; ...struct qed_int_info { struct msix_entry *msix; u8 msix_cnt;
/* This should be updated by the protocol driver */ u8 used_cnt;};
Should this also clear the "msix" member, or should this not write beyond int_info? This patch does the latter.
It should clear only the msix_cnt, no need to clear the entire qed_int_info structure.
Should used_cnt be cleared too? It is currently. Better yet, what patch do you suggest I replace this proposed one with? :)
Thanks for looking at this!
-Kees