public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Marvin Häuser" <Marvin.Haeuser@outlook.com>
To: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Subject: Re: [PATCH 2/2] ShellPkg/Shell: eliminate double-free in RunSplitCommand()
Date: Tue, 25 Apr 2017 16:00:29 +0000	[thread overview]
Message-ID: <AM5PR0601MB25798D3AFBA7E657BC1CCE40801E0@AM5PR0601MB2579.eurprd06.prod.outlook.com> (raw)

Please excuse the mistake, I suppose I was running a search for "FreePool", which of course did not find "SHELL_FREE_NON_NULL". Thanks for fixing it up!

Reviewed-by: Marvin Häuser <Marvin.Haeuser@outlook.com>

-----Ursprüngliche Nachricht-----
Von: Laszlo Ersek [mailto:lersek@redhat.com] 
Gesendet: Dienstag, 25. April 2017 15:57
An: edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Jaben Carsey <jaben.carsey@intel.com>; Marvin Häuser <Marvin.Haeuser@outlook.com>; Qiu Shumin <shumin.qiu@intel.com>; Ruiyu Ni <ruiyu.ni@intel.com>
Betreff: [PATCH 2/2] ShellPkg/Shell: eliminate double-free in RunSplitCommand()

Commit bd3fc8133b2b ("ShellPkg/App: Fix memory leak and save resources.",
2016-05-20) added a FreePool() call for Split->SplitStdIn, near end of the RunSplitCommand(), right after the same shell file was closed with CloseFile(). The argument was:

> 1) RunSplitCommand() allocates the initial SplitStdOut via
>    CreateFileInterfaceMem(). Free SplitStdIn after the swap to fix
>    the memory leak.

There is no memory leak actually, and the FreePool() call in question constitutes a double-free:

(a) This is how the handle is established:

    ConvertEfiFileProtocolToShellHandle (
      CreateFileInterfaceMem (Unicode),
      NULL
      );

    CreateFileInterfaceMem() allocates an EFI_FILE_PROTOCOL_MEM object and
    populates it fully. ConvertEfiFileProtocolToShellHandle() allocates
    some administrative structures and links the EFI_FILE_PROTOCOL_MEM
    object into "mFileHandleList".

(b) EFI_SHELL_PROTOCOL.CloseFile() is required to close the
    SHELL_FILE_HANDLE and to release all associated data. Accordingly,
    near the end of RunSplitCommand(), we have:

    EfiShellClose()
      ShellFileHandleRemove()
        //
        // undoes the effects of ConvertEfiFileProtocolToShellHandle()
        //
      ConvertShellHandleToEfiFileProtocol()
        //
        // note that this does not adjust the pointer value; it's a pure
        // type cast
        //
      FileHandleClose()
        FileInterfaceMemClose()
          //
          // tears down EFI_FILE_PROTOCOL_MEM completely, undoing the
          // effects of CreateFileInterfaceMem ()
          //

The FreePool() call added by bd3fc8133b2b conflicts with

  SHELL_FREE_NON_NULL(This);

in FileInterfaceMemClose(), so remove it.

This error can be reproduced for example with:

> Shell> map | more
> 'more' is not recognized as an internal or external command, operable 
> program, or script file.

which triggers:

> ASSERT MdeModulePkg/Core/Dxe/Mem/Pool.c(624): CR has Bad Signature

with the following stack dump:

> #0  0x000000007f6dc094 in CpuDeadLoop () at
>     MdePkg/Library/BaseLib/CpuDeadLoop.c:37
> #1  0x000000007f6dd1b4 in DebugAssert (FileName=0x7f6ed9f0
>     "MdeModulePkg/Core/Dxe/Mem/Pool.c", LineNumber=624,
>     Description=0x7f6ed9d8 "CR has Bad Signature") at
>     OvmfPkg/Library/PlatformDebugLibIoPort/DebugLib.c:153
> #2  0x000000007f6d075d in CoreFreePoolI (Buffer=0x7e232c98,
>     PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:624
> #3  0x000000007f6d060e in CoreInternalFreePool (Buffer=0x7e232c98,
>     PoolType=0x7f6bc1c4) at MdeModulePkg/Core/Dxe/Mem/Pool.c:529
> #4  0x000000007f6d0648 in CoreFreePool (Buffer=0x7e232c98) at
>     MdeModulePkg/Core/Dxe/Mem/Pool.c:552
> #5  0x000000007d49fbf8 in FreePool (Buffer=0x7e232c98) at
>     MdePkg/Library/UefiMemoryAllocationLib/MemoryAllocationLib.c:818
> #6  0x000000007d4875c3 in RunSplitCommand (CmdLine=0x7d898398,
>     StdIn=0x0, StdOut=0x0) at ShellPkg/Application/Shell/Shell.c:1813
> #7  0x000000007d487d59 in ProcessNewSplitCommandLine
>     (CmdLine=0x7d898398) at ShellPkg/Application/Shell/Shell.c:2121
> #8  0x000000007d488937 in RunShellCommand (CmdLine=0x7e233018,
>     CommandStatus=0x0) at ShellPkg/Application/Shell/Shell.c:2670
> #9  0x000000007d488b0b in RunCommand (CmdLine=0x7e233018) at
>     ShellPkg/Application/Shell/Shell.c:2732
> #10 0x000000007d4867c8 in DoShellPrompt () at
>     ShellPkg/Application/Shell/Shell.c:1349
> #11 0x000000007d48524d in UefiMain (ImageHandle=0x7e24c898,
>     SystemTable=0x7f5b6018) at ShellPkg/Application/Shell/Shell.c:631

Cc: Jaben Carsey <jaben.carsey@intel.com>
Cc: Marvin Häuser <Marvin.Haeuser@outlook.com>
Cc: Qiu Shumin <shumin.qiu@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Fixes: bd3fc8133b2b17ad2e0427d1bf6b44b08cf2f3b2
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
 ShellPkg/Application/Shell/Shell.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/ShellPkg/Application/Shell/Shell.c b/ShellPkg/Application/Shell/Shell.c
index fa958170a1db..fcf47b5c733d 100644
--- a/ShellPkg/Application/Shell/Shell.c
+++ b/ShellPkg/Application/Shell/Shell.c
@@ -1810,7 +1810,6 @@ RunSplitCommand(
   }
   if (Split->SplitStdIn != NULL) {
     ShellInfoObject.NewEfiShellProtocol->CloseFile (Split->SplitStdIn);
-    FreePool (Split->SplitStdIn);
   }
 
   FreePool(Split);
--
2.9.3


             reply	other threads:[~2017-04-25 16:00 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-25 16:00 Marvin Häuser [this message]
  -- strict thread matches above, loose matches on Subject: below --
2017-04-25 13:57 [PATCH 0/2] ShellPkg/Shell: fix double free in pipeline processing Laszlo Ersek
2017-04-25 13:57 ` [PATCH 2/2] ShellPkg/Shell: eliminate double-free in RunSplitCommand() Laszlo Ersek

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-list 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=AM5PR0601MB25798D3AFBA7E657BC1CCE40801E0@AM5PR0601MB2579.eurprd06.prod.outlook.com \
    --to=devel@edk2.groups.io \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox