netdev - Re: [PATCH ipsec] xfrm: Fix UDP GRO handling for some corner cases

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] [day] [month] [year] [list]

Message-ID: <aAIVth5vo7BLv99f@gauss3.secunet.de>
Date: Fri, 18 Apr 2025 11:04:54 +0200
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Tobias Brunner <tobias@...ongswan.org>
CC: Herbert Xu <herbert@...dor.apana.org.au>,
	“David S. Miller” <davem@...emloft.net>,
	<netdev@...r.kernel.org>, <devel@...ux-ipsec.org>
Subject: Re: [PATCH ipsec] xfrm: Fix UDP GRO handling for some corner cases

On Tue, Apr 15, 2025 at 01:13:18PM +0200, Tobias Brunner wrote:
> This fixes an issue that's caused if there is a mismatch between the data
> offset in the GRO header and the length fields in the regular sk_buff due
> to the pskb_pull()/skb_push() calls.  That's because the UDP GRO layer
> stripped off the UDP header via skb_gro_pull() already while the UDP
> header was explicitly not pulled/pushed in this function.
> 
> For example, an IKE packet that triggered this had len=data_len=1268 and
> the data_offset in the GRO header was 28 (IPv4 + UDP).  So pskb_pull()
> was called with an offset of 28-8=20, which reduced len to 1248 and via
> pskb_may_pull() and __pskb_pull_tail() it also set data_len to 1248.
> As the ESP offload module was not loaded, the function bailed out and
> called skb_push(), which restored len to 1268, however, data_len remained
> at 1248.
> 
> So while skb_headlen() was 0 before, it was now 20.  The latter caused a
> difference of 8 instead of 28 (or 0 if pskb_pull()/skb_push() was called
> with the complete GRO data_offset) in gro_try_pull_from_frag0() that
> triggered a call to gro_pull_from_frag0() that corrupted the packet.
> 
> This change uses a more GRO-like approach seen in other GRO receivers
> via skb_gro_header() to just read the actual data we are interested in
> and does not try to "restore" the UDP header at this point to call the
> existing function.  If the offload module is not loaded, it immediately
> bails out, otherwise, it only does a quick check to see if the packet
> is an IKE or keepalive packet instead of calling the existing function.
> 
> Fixes: 172bf009c18d ("xfrm: Support GRO for IPv4 ESP in UDP encapsulation")
> Fixes: 221ddb723d90 ("xfrm: Support GRO for IPv6 ESP in UDP encapsulation")
> Signed-off-by: Tobias Brunner <tobias@...ongswan.org>

Applied, thanks Tobias!