On Mon, Aug 02, 2021 at 07:23:00PM +0300, Kees Cook wrote:

On Mon, Aug 02, 2021 at 02:29:28PM +0000, Shai Malin wrote:

quoted

On Tue, Jul 31, 2021 at 07:07:00PM -0300, Kees Cook wrote:

quoted

On Tue, Jul 27, 2021 at 01:58:33PM -0700, Kees Cook wrote:

quoted

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 <redacted>
---
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.

quoted

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? :)

In qede_sync_free_irqs(), just after:
  edev->int_info.used_cnt = 0;
Please add:
  edev->int_info.msix_cnt = 0;

Thanks!

Thanks for looking at this!

-Kees

--
Kees Cook