mbox series

[0/3] net: Cleanups for FORTIFY_SOURCE

Message ID 20210819202825.3545692-1-keescook@chromium.org
Headers show
Series net: Cleanups for FORTIFY_SOURCE | expand

Message

Kees Cook Aug. 19, 2021, 8:28 p.m. UTC
Hi,

In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.

These three changes have been living in my memcpy() series[1], but have
no external dependencies. It's probably better to have these go via
netdev.

Thanks!

-Kees

[1] https://lore.kernel.org/lkml/20210818060533.3569517-1-keescook@chromium.org/

Kees Cook (3):
  ipw2x00: Avoid field-overflowing memcpy()
  net/mlx5e: Avoid field-overflowing memcpy()
  pcmcia: ray_cs: Split memcpy() to avoid bounds check warning

 drivers/net/ethernet/mellanox/mlx5/core/en.h  |  4 +-
 .../net/ethernet/mellanox/mlx5/core/en/xdp.c  |  4 +-
 .../net/wireless/intel/ipw2x00/libipw_rx.c    | 56 ++++++-------------
 drivers/net/wireless/ray_cs.c                 |  4 +-
 4 files changed, 25 insertions(+), 43 deletions(-)

Comments

Jakub Kicinski Aug. 20, 2021, 5:01 p.m. UTC | #1
On Thu, 19 Aug 2021 13:28:22 -0700 Kees Cook wrote:
> Hi,
> 
> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field bounds checking for memcpy(), memmove(), and memset(), avoid
> intentionally writing across neighboring fields.
> 
> These three changes have been living in my memcpy() series[1], but have
> no external dependencies. It's probably better to have these go via
> netdev.

Thanks.

Kalle, Saeed - would you like to take the relevant changes? Presumably
they would get into net-next anyway by the time the merge window opens.
Kalle Valo Aug. 21, 2021, 10:11 a.m. UTC | #2
Jakub Kicinski <kuba@kernel.org> writes:

> On Thu, 19 Aug 2021 13:28:22 -0700 Kees Cook wrote:
>> Hi,
>> 
>> In preparation for FORTIFY_SOURCE performing compile-time and run-time
>> field bounds checking for memcpy(), memmove(), and memset(), avoid
>> intentionally writing across neighboring fields.
>> 
>> These three changes have been living in my memcpy() series[1], but have
>> no external dependencies. It's probably better to have these go via
>> netdev.
>
> Thanks.
>
> Kalle, Saeed - would you like to take the relevant changes? Presumably
> they would get into net-next anyway by the time the merge window opens.

Ok, I'll take patch 1 to wireless-drivers-next.
Kalle Valo Aug. 21, 2021, 10:13 a.m. UTC | #3
Kalle Valo <kvalo@codeaurora.org> writes:

> Jakub Kicinski <kuba@kernel.org> writes:

>

>> On Thu, 19 Aug 2021 13:28:22 -0700 Kees Cook wrote:

>>> Hi,

>>> 

>>> In preparation for FORTIFY_SOURCE performing compile-time and run-time

>>> field bounds checking for memcpy(), memmove(), and memset(), avoid

>>> intentionally writing across neighboring fields.

>>> 

>>> These three changes have been living in my memcpy() series[1], but have

>>> no external dependencies. It's probably better to have these go via

>>> netdev.

>>

>> Thanks.

>>

>> Kalle, Saeed - would you like to take the relevant changes? Presumably

>> they would get into net-next anyway by the time the merge window opens.

>

> Ok, I'll take patch 1 to wireless-drivers-next.


Correction: I'll take patches 1 and 3 to wireless-drivers-next.

-- 
https://patchwork.kernel.org/project/linux-wireless/list/

https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Kees Cook Aug. 22, 2021, 5:16 a.m. UTC | #4
On Sat, Aug 21, 2021 at 01:13:37PM +0300, Kalle Valo wrote:
> Kalle Valo <kvalo@codeaurora.org> writes:

> 

> > Jakub Kicinski <kuba@kernel.org> writes:

> >

> >> On Thu, 19 Aug 2021 13:28:22 -0700 Kees Cook wrote:

> >>> Hi,

> >>> 

> >>> In preparation for FORTIFY_SOURCE performing compile-time and run-time

> >>> field bounds checking for memcpy(), memmove(), and memset(), avoid

> >>> intentionally writing across neighboring fields.

> >>> 

> >>> These three changes have been living in my memcpy() series[1], but have

> >>> no external dependencies. It's probably better to have these go via

> >>> netdev.

> >>

> >> Thanks.

> >>

> >> Kalle, Saeed - would you like to take the relevant changes? Presumably

> >> they would get into net-next anyway by the time the merge window opens.

> >

> > Ok, I'll take patch 1 to wireless-drivers-next.

> 

> Correction: I'll take patches 1 and 3 to wireless-drivers-next.


Great; thanks!

-- 
Kees Cook