[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Zw4Lak7LOwfW32NJ@gauss3.secunet.de>
Date: Tue, 15 Oct 2024 08:27:54 +0200
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Petr Vaganov <p.vaganov@...co.ru>
CC: Herbert Xu <herbert@...dor.apana.org.au>, "David S. Miller"
<davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski
<kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, Stephan Mueller
<smueller@...onox.de>, Antony Antony <antony.antony@...unet.com>,
<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
<lvc-project@...uxtesting.org>, <stable@...r.kernel.org>, Boris Tonofa
<b.tonofa@...co.ru>
Subject: Re: [PATCH ipsec v3] xfrm: fix one more kernel-infoleak in algo
dumping
On Tue, Oct 08, 2024 at 02:02:58PM +0500, Petr Vaganov wrote:
> During fuzz testing, the following issue was discovered:
>
> BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x598/0x2a30
...
>
> Bytes 328-379 of 732 are uninitialized
> Memory access of size 732 starts at ffff88800e18e000
> Data copied to user address 00007ff30f48aff0
>
> CPU: 2 PID: 18167 Comm: syz-executor.0 Not tainted 6.8.11 #1
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
>
> Fixes copying of xfrm algorithms where some random
> data of the structure fields can end up in userspace.
> Padding in structures may be filled with random (possibly sensitve)
> data and should never be given directly to user-space.
>
> A similar issue was resolved in the commit
> 8222d5910dae ("xfrm: Zero padding when dumping algos and encap")
>
> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
>
> Fixes: c7a5899eb26e ("xfrm: redact SA secret with lockdown confidentiality")
> Cc: stable@...r.kernel.org
> Co-developed-by: Boris Tonofa <b.tonofa@...co.ru>
> Signed-off-by: Boris Tonofa <b.tonofa@...co.ru>
> Signed-off-by: Petr Vaganov <p.vaganov@...co.ru>
Applied, thanks a lot!
Powered by blists - more mailing lists