From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 11569C433EF for ; Fri, 3 Jun 2022 11:40:56 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 6248684339; Fri, 3 Jun 2022 13:40:12 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=mu-ori.me Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=mu-ori.me header.i=@mu-ori.me header.b="SXBqzot8"; dkim=pass (2048-bit key) header.d=mu-ori.me header.i=@mu-ori.me header.b="SXBqzot8"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A2CB884328; Thu, 2 Jun 2022 20:33:02 +0200 (CEST) Received: from mail.mu-ori.me (mail.mu-ori.me [185.189.151.126]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 7D2E283C7B for ; Thu, 2 Jun 2022 20:33:00 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=reject dis=none) header.from=mu-ori.me Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=gerbert@mu-ori.me Received: by mail.mu-ori.me (Postfix) id 21E6E600A7; Thu, 2 Jun 2022 18:33:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mu-ori.me; s=mail; t=1654194780; bh=lHuFtbv1o2d1sXLwGp/GHgn6umGITgKJqC7hIgof7lY=; h=Date:From:To:Subject:From; b=SXBqzot8Ot3686Ei+KV0tIVfqPhoRRO8TuGGXxsaFMLzDLUzSKKLs2d7jGgClMkDr TJ4tzmbjJI7/2YPEFokJ/5EJk+u8XA/Hw5CM66Quh5vbE4cIC4Bv6lujuvyopS/1Yc d0vE9ZfS8bzVF3T7P0wqJ//Fl5zuPS7LGLFC0afqbfyGVFOqc/Mksr6KvI8RIVBSCR VHKL6IkCjKIsXg75BVAjTu9X5Xrjm3xv7Lmt5HW0VfcImlE4e//6gfwWVwQIb3TI1+ DFZrj25HSRj1zSM6xd0R6FBYXn+yrY3d7+W0lt9iarKZApHL5zQuCFqvOucEKIdusy sQPChto2fkoPg== Received: from webm.mu-ori.me (localhost [127.0.0.1]) by mail.mu-ori.me (Postfix) with ESMTPSA id 0180B60018 for ; Thu, 2 Jun 2022 18:33:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mu-ori.me; s=mail; t=1654194780; bh=lHuFtbv1o2d1sXLwGp/GHgn6umGITgKJqC7hIgof7lY=; h=Date:From:To:Subject:From; b=SXBqzot8Ot3686Ei+KV0tIVfqPhoRRO8TuGGXxsaFMLzDLUzSKKLs2d7jGgClMkDr TJ4tzmbjJI7/2YPEFokJ/5EJk+u8XA/Hw5CM66Quh5vbE4cIC4Bv6lujuvyopS/1Yc d0vE9ZfS8bzVF3T7P0wqJ//Fl5zuPS7LGLFC0afqbfyGVFOqc/Mksr6KvI8RIVBSCR VHKL6IkCjKIsXg75BVAjTu9X5Xrjm3xv7Lmt5HW0VfcImlE4e//6gfwWVwQIb3TI1+ DFZrj25HSRj1zSM6xd0R6FBYXn+yrY3d7+W0lt9iarKZApHL5zQuCFqvOucEKIdusy sQPChto2fkoPg== MIME-Version: 1.0 Date: Thu, 02 Jun 2022 21:32:59 +0300 From: gerbert To: u-boot@lists.denx.de Subject: [PATCH 1/1] CVE-2022-30767: unbounded memcpy with a failed length check Message-ID: X-Sender: gerbert@mu-ori.me User-Agent: Roundcube Webmail/1.3.16 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 03 Jun 2022 13:39:14 +0200 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.5 at phobos.denx.de X-Virus-Status: Clean This patch tries to fix a CVE-2019-14196 fix In if-condition, where NFSV2_FLAG is checked, memcpy call is performed to transfer a reply data of NFS_FHSIZE size. Since the data field in struct rpc_t structure has the size of (1024 / 4) + 26 = 282, while NFS_FHSIZE is only 32, it won't lead to out-of-bounds write (considering the size of data array won't change in the future). What concerns if-condition for NFSV3_FLAG, since filefh3_length is signed integer, it may carry negative values which may lead to memcpy failure, so in this case we need to introduce not only boundary check (filefh3_length > NFS3_FHSIZE), which exists, but also make sure that filefh3_length is not negative. Signed-off-by: gerbert --- net/nfs.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/net/nfs.c b/net/nfs.c index 9152ab742e..5186130ea9 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -566,13 +566,13 @@ static int nfs_lookup_reply(uchar *pkt, unsigned len) } if (supported_nfs_versions & NFSV2_FLAG) { - if (((uchar *)&(rpc_pkt.u.reply.data[0]) - (uchar *)(&rpc_pkt) + NFS_FHSIZE) > len) - return -NFS_RPC_DROP; memcpy(filefh, rpc_pkt.u.reply.data + 1, NFS_FHSIZE); } else { /* NFSV3_FLAG */ filefh3_length = ntohl(rpc_pkt.u.reply.data[1]); + if (filefh3_length < 0) + return -NFS_RPC_DROP; if (filefh3_length > NFS3_FHSIZE) - filefh3_length = NFS3_FHSIZE; + filefh3_length = NFS3_FHSIZE; memcpy(filefh, rpc_pkt.u.reply.data + 2, filefh3_length); } -- 2.32.0