netdev - Re: [PATCH ipsec-next] esp4/6: Fix GSO path for non-GSO SW-crypto packets

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: <20170420051645.GA3976@secunet.com>
Date:   Thu, 20 Apr 2017 07:16:46 +0200
From:   Steffen Klassert <steffen.klassert@...unet.com>
To:     <ilant@...lanox.com>
CC:     <netdev@...r.kernel.org>, Boris Pismenny <borisp@...lanox.com>,
        "Yevgeny Kliteynik" <kliteyn@...lanox.com>,
        Yossi Kuperman <yossiku@...lanox.com>
Subject: Re: [PATCH ipsec-next] esp4/6: Fix GSO path for non-GSO SW-crypto
 packets

On Wed, Apr 19, 2017 at 08:41:01AM +0300, ilant@...lanox.com wrote:
> From: Ilan Tayari <ilant@...lanox.com>
> 
> If esp*_offload module is loaded, outbound packets take the
> GSO code path, being encapsulated at layer 3, but encrypted
> in layer 2. validate_xmit_xfrm calls esp*_xmit for that.
> 
> esp*_xmit was wrongfully detecting these packets as going
> through hardware crypto offload, while in fact they should
> be encrypted in software, causing plaintext leakage to
> the network, and also dropping at the receiver side.
> 
> Perform the encryption in esp*_xmit, if the SA doesn't have
> a hardware offload_handle.
> 
> Also, align esp6 code to esp4 logic.
> 
> Fixes: fca11ebde3f0 ("esp4: Reorganize esp_output")
> Fixes: 383d0350f2cc ("esp6: Reorganize esp_output")
> Signed-off-by: Ilan Tayari <ilant@...lanox.com>

Applied to ipsec-next, thanks Ilan!