All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heinrich Schuchardt <xypron.glpk@gmx.de>
To: gerbert <gerbert@mu-ori.me>
Cc: u-boot@lists.denx.de
Subject: Re: [PATCH 1/1] CVE-2022-30767: unbounded memcpy with a failed length check
Date: Sat, 4 Jun 2022 19:44:13 +0200	[thread overview]
Message-ID: <ba643b78-d31b-c981-dcb1-8c61ad20b78c@gmx.de> (raw)
In-Reply-To: <d8d3a606ddd1857c5659becf8cb54409@mu-ori.me>

On 6/2/22 20:32, gerbert wrote:
> 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 <gerbert@users.noreply.github.com>
> ---
>   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)

This is the definition:

static unsigned int filefh3_length
The value cannot be negative.

Cf.
bdbf7a05e26f3c5 ("net: nfs: Fix CVE-2022-30767 (old CVE-2019-14196)")


> +            return -NFS_RPC_DROP;
>           if (filefh3_length > NFS3_FHSIZE)
> -            filefh3_length  = NFS3_FHSIZE;
> +            filefh3_length = NFS3_FHSIZE;

This seems to be an unrelated change.

Best regards

Heinrich

>           memcpy(filefh, rpc_pkt.u.reply.data + 2, filefh3_length);
>       }
>


  reply	other threads:[~2022-06-04 17:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-02 18:32 [PATCH 1/1] CVE-2022-30767: unbounded memcpy with a failed length check gerbert
2022-06-04 17:44 ` Heinrich Schuchardt [this message]
2022-06-04 18:07   ` gerbert
  -- strict thread matches above, loose matches on Subject: below --
2022-06-02 18:18 gerbert
2022-06-06 14:43 ` Tom Rini
2022-06-06 15:10   ` gerbert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ba643b78-d31b-c981-dcb1-8c61ad20b78c@gmx.de \
    --to=xypron.glpk@gmx.de \
    --cc=gerbert@mu-ori.me \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.