From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web11.3689.1582809307695217589 for ; Thu, 27 Feb 2020 05:15:07 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=A2Ru0+vi; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1582809306; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=o37hEPX48Xu0AlrrWRpIIDjNJzzGoB0jW1WubcwhPWE=; b=A2Ru0+vi2pjfAjSnuBFdkj4un3IZLmDKSc8uyajkFkrXwJqPzxbVid9XGfAjMBz4Nurail qbR3YY15iCf9DJGmmPGgX+vZ8oUf9F3T1GmrPeWHhuIhpVUy5l1nyi+zoJdPXJwvRf360p owbLbi+eIgKqcCRdtNvzwC6Ww6ZJLns= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-99-f4JCfkyOMn-g5Ji8eU30Gg-1; Thu, 27 Feb 2020 08:14:58 -0500 X-MC-Unique: f4JCfkyOMn-g5Ji8eU30Gg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A9FB7189F764; Thu, 27 Feb 2020 13:14:56 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-46.ams2.redhat.com [10.36.116.46]) by smtp.corp.redhat.com (Postfix) with ESMTP id 83EEC60BE1; Thu, 27 Feb 2020 13:14:54 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v1] ShellPkg: Fix 'ping' command Ip4 receive flow. To: devel@edk2.groups.io, maciej.rabeda@linux.intel.com, Liming Gao , Michael Kinney , Andrew Fish , "Leif Lindholm (Linaro address)" Cc: Ray Ni , Zhichao Gao , nicholas.armour@intel.com References: <20200227110212.1070-1-maciej.rabeda@linux.intel.com> From: "Laszlo Ersek" Message-ID: Date: Thu, 27 Feb 2020 14:14:53 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200227110212.1070-1-maciej.rabeda@linux.intel.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit (+Liming and stewards; CC Nick) On 02/27/20 12:02, Maciej Rabeda wrote: > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=2032 > > 'ping' command's receive flow utilizes a single Rx token which it > attempts to reuse before recycling the previously received packet. > This causes a situation where under ICMP traffic, > Ping6OnEchoReplyReceived() function will receive an already > recycled packet with EFI_SUCCESS token status and finally > dereference invalid pointers from RxData structure. > > Cc: Ray Ni > Cc: Zhichao Gao > Signed-off-by: Maciej Rabeda > --- > ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c | 9 +++++---- > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c > index 23567fa2c1bb..a3fa32515192 100644 > --- a/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c > +++ b/ShellPkg/Library/UefiShellNetwork1CommandsLib/Ping.c > @@ -614,6 +614,11 @@ Ping6OnEchoReplyReceived ( > > ON_EXIT: > > + // > + // Recycle the packet before reusing RxToken > + // > + gBS->SignalEvent (Private->IpChoice == PING_IP_CHOICE_IP6?((EFI_IP6_RECEIVE_DATA*)Private->RxToken.Packet.RxData)->RecycleSignal:((EFI_IP4_RECEIVE_DATA*)Private->RxToken.Packet.RxData)->RecycleSignal); > + > if (Private->RxCount < Private->SendNum) { > // > // Continue to receive icmp echo reply packets. > @@ -632,10 +637,6 @@ ON_EXIT: > // > Private->Status = EFI_SUCCESS; > } > - // > - // Singal to recycle the each rxdata here, not at the end of process. > - // > - gBS->SignalEvent (Private->IpChoice == PING_IP_CHOICE_IP6?((EFI_IP6_RECEIVE_DATA*)Private->RxToken.Packet.RxData)->RecycleSignal:((EFI_IP4_RECEIVE_DATA*)Private->RxToken.Packet.RxData)->RecycleSignal); > } > > /** > (1) This patch proposes to fix one of the BZs (2032) that fall under CVE-2019-14559 (joint tracker: 2550). Consequently: (1a) Do we want to include this in the upcoming stable tag? If so, we might want to extend the hard feature freeze by a few days. (1b) Please append the string " (CVE-2019-14559)" -- note the separating space! -- to the subject line. (2) However: I remember from an earlier Bugzilla entry (can't tell off-hand, which one, sorry) that ShellPkg issues are *never* considered CVE-worthy, because the shell is not considered a "production element" of the UEFI boot path. TianoCore#2032 was originally filed for NetworkPkg, and indeed that seemed to justify the CVE assignment. However, now that Nick's and Maciej's analysis shows that NetworkPkg is unaffected (and we know, per above, that ShellPkg is not CVE-worthy), should we rather *remove* this BZ from the CVE-2019-14559 umbrella? Because, in that case, modifying the subject line on the patch is not necessary; and more importantly, we might not even want to put this into edk2-stable202002. (It's still a bugfix, but may not be important enough.) Thanks! Laszlo