netdev - Re: [RFC PATCH net] net-gro: restore check for NULL skb in napi_gro

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 2 Aug 2023 12:22:16 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: edward.cree@....com
Cc: davem@...emloft.net, kuba@...nel.org, pabeni@...hat.com, 
	Edward Cree <ecree.xilinx@...il.com>, netdev@...r.kernel.org, 
	Martin Habets <habetsm.xilinx@...il.com>
Subject: Re: [RFC PATCH net] net-gro: restore check for NULL skb in napi_gro_frags

On Wed, Aug 2, 2023 at 11:42 AM <edward.cree@....com> wrote:
>
> From: Edward Cree <ecree.xilinx@...il.com>
>
> Cited commit removed the check on the grounds that napi_gro_frags must
>  not be called by drivers if napi_get_frags failed.  But skb can also
>  be NULL if napi_frags_skb fails to pull the ethernet header ("dropping
>  impossible skb" message).  In this case return GRO_CONSUMED, as
>  otherwise continuing on would cause a NULL dereference panic in
>  dev_gro_receive().
>
> Fixes: 1d11fa696733 ("net-gro: remove GRO_DROP")
> Reviewed-by: Martin Habets <habetsm.xilinx@...il.com>
> Signed-off-by: Edward Cree <ecree.xilinx@...il.com>
> ---
> An sfc customer has encountered this panic in the wild; we're still
>  investigating exactly how it happened (we have a reproducer) but it
>  seems wise to have the core handle this check rather than requiring
>  it in every driver.

An ethernet driver feeding non-ethernet packets to the upper stacks
seems weird to me,
but given napi_frags_skb() does output a warning, I would say this
patch would be acceptable until the real bug is fixed :/

Note that eth_type_trans() does not double-check that at least
ETH_HLEN bytes are present in skb->data

skb_pull_inline(skb, ETH_HLEN);

So eth_type_trans() would definitely crash.
Not sure why a napi_gro_frags() enabled driver would be allowed to
cook arbitrary packets with length <  ETH_HLEN

Mixed feelings here, especially if for some reason the compiler would
not inline napi_frags_skb().