Re: [edk2-devel] [PATCH v2 1/2] MdeModulePkg/Bus/Pci/XhciDxe: Fix FORWARD_NULL Coverity issues

["Laszlo Ersek" <lersek@redhat.com>]

On 11/7/23 06:57, Ranbir Singh wrote:
> From: Ranbir Singh <Ranbir.Singh3@Dell.com>
> 
> The functions UsbHcGetHostAddrForPciAddr, UsbHcGetPciAddrForHostAddr
> and UsbHcFreeMem do have
> 
>     ASSERT ((Block != NULL));
> 
> statements after for loop, but these are applicable only in DEBUG mode.
> In RELEASE mode, if for whatever reasons there is no match inside for
> loop and the loop exits because of Block != NULL; condition, then there
> is no "Block" NULL pointer check afterwards and the code proceeds to do
> dereferencing "Block" which will lead to CRASH.
> 
> Hence, for safety add NULL pointer checks always.
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4221
> 
> Cc: Ray Ni <ray.ni@intel.com>
> Co-authored-by: Veeresh Sangolli <veeresh.sangolli@dellteam.com>
> Signed-off-by: Ranbir Singh <Ranbir.Singh3@Dell.com>
> Signed-off-by: Ranbir Singh <rsingh@ventanamicro.com>
> ---
>  MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c | 14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c b/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
> index b54187ec228e..b0654f148c4f 100644
> --- a/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
> +++ b/MdeModulePkg/Bus/Pci/XhciDxe/UsbHcMem.c
> @@ -267,6 +267,11 @@ UsbHcGetPciAddrForHostAddr (
>    }
>  
>    ASSERT ((Block != NULL));
> +
> +  if (Block == NULL) {
> +    return 0;
> +  }
> +
>    //
>    // calculate the pci memory address for host memory address.
>    //
> @@ -322,6 +327,11 @@ UsbHcGetHostAddrForPciAddr (
>    }
>  
>    ASSERT ((Block != NULL));
> +
> +  if (Block == NULL) {
> +    return 0;
> +  }
> +
>    //
>    // calculate the pci memory address for host memory address.
>    //

The above two changes are not good.

There is a large number of call sites for these functions, and they
never error-check the returned value. In effect, these functions must
always succeed, or else there is a programming error somewhere in the
driver (potentially the caller supplying incorrect inputs), or the
hardware is broken. If the address mapping fails, we cannot do anything;
we certainly cannot proceed with null pointers (either device zero
addresses or host null pointers). Therefore, I suggest

  if (Block == NULL) {
    CpuDeadLoop ();
  }

instead.

> @@ -603,6 +613,10 @@ UsbHcFreeMem (
>    //
>    ASSERT (Block != NULL);
>  
> +  if (Block == NULL) {
> +    return;
> +  }
> +
>    //
>    // Release the current memory block if it is empty and not the head
>    //

I'm not happy about this either, but at least this one doesn't directly
make things worse than they are.

Note the comment in the context:

  //
  // If Block == NULL, it means that the current memory isn't
  // in the host controller's pool. This is critical because
  // the caller has passed in a wrong memory point
  //
  ASSERT (Block != NULL);

It says "critical", so I'd prefer a CpuDeadLoop() here too...

Laszlo



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#110860): https://edk2.groups.io/g/devel/message/110860
Mute This Topic: https://groups.io/mt/102438127/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/leave/12367111/7686176/1913456212/xyzzy [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-