The functions FatGetDirEntInfo and FatOpenDirEnt in the file
FatPkg/EnhancedFatDxe/DirectoryManage.c contains the code statements
Cluster = (Entry->FileClusterHigh << 16) | Entry->FileCluster;
and
OFile->FileCluster = ((DirEnt->Entry.FileClusterHigh) << 16) |
The function Tcg2ConfigDriverEntryPoint at the point of creating a
private data structure makes a call to AllocateCopyPool and stores
the return value in PrivateData. Thereafter it does a check
ASSERT (PrivateData != NULL);
but this is applicable only in DEBUG mode. In Release mode, the code
The function S3ResumeExecuteBootScript at the point of preparing data
for return back makes a call to AllocatePool and stores the return
value in PeiS3ResumeState. Thereafter it does a check
if (PeiS3ResumeState == NULL) {
The if block further has ASSERT (FALSE); If PeiS3ResumeState is NULL,
In file SecurityPkg/Library/HashLibBaseCryptoRouter/
HashLibBaseCryptoRouterPei.c, the function
CheckSupportedHashMaskMismatch calls InternalGetHashInterfaceHob and
stores return value in HashInterfaceHobLast. Thereafter, it does
ASSERT (HashInterfaceHobLast != NULL);
but this comes into play
The function Dhcp6HandleStateful checks
if (Instance->Config == NULL) {
goto ON_CONTINUE;
}
At label ON_CONTINUE, UdpIoRecvDatagram function is called and if for
whatever reasons its return value is not EFI_SUCCESS, then the check
if (EFI_ERROR (Status)) at label ON_EXIT passes leading to
The function USBMouseDriverBindingStart do have
ASSERT (UsbMouseDevice != NULL);
after AllocateZeroPool, but it is applicable only in DEBUG mode.
In RELEASE mode, the code proceeds to dereference "UsbMouseDevice"
which will lead to CRASH.
Hence, for safety add NULL pointer checks always. The
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
The code can reach line 65 only through the else path above at line 53.
The else path already has the same NULL check at line 55 and hence the
duplicate code lines are totally redundant which can be deleted.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4220
Signed-off-by: Ranbir Singh
---
The function StartPciDevices has a check
ASSERT (RootBridge != NULL);
but this comes into play only in DEBUG mode. In Release mode, there
is no handling if the RootBridge value is NULL and the code proceeds
to unconditionally dereference "RootBridge" which will lead to CRASH.
Hence, for safety
The function PciHotPlugRequestNotify in
MdeModulePkg/Bus/Pci/PciBusDxe/PciEnumerator.c
has two if blocks towards the end of function both containing return.
Due to the parameter checks ensured at the beginning of the function,
one of the two if blocks is bound to come in execution flow. Hence,
The functions CoreConvertSpace and CoreAllocateSpace in
MdeModulePkg/Core/Dxe/Gcd/Gcd.c has
ASSERT (FALSE); at lines 755 and 1155 which gets hit when
Operation neither include GCD_MEMORY_SPACE_OPERATION nor include
GCD_IO_SPACE_OPERATION but this comes into play only in DEBUG mode.
In Release
The function NotifyPhase has a check
ASSERT (Index < TypeMax);
but this comes into play only in DEBUG mode. In Release mode, there is
no handling if the Index value is within array limits or not. If for
whatever reasons, the Index does not get re-assigned to Index2 at line
137, then it remains
The function UhciConvertPollRate has a check
ASSERT (Interval != 0);
but this comes into play only in DEBUG mode. In Release mode, there is
no handling if the Interval parameter value is ZERO. To avoid shifting
by a negative amount later in the code flow in this undesirable case,
it is better to
The functions UsbHcGetPciAddressForHostMem 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,
Line number 365 does contain a typecast with UINT32, but it is after
all the operations (16-bit left shift followed by OR'ing) are over.
To avoid any SIGN_EXTENSION, typecast the intermediate result after
16-bit left shift operation immediately with UINT32.
REF:
Line number 1348 does contain a typecast with UINT32, but it is after
all the operations (16-bit left shift followed by OR'ing) are over.
To avoid any SIGN_EXTENSION, typecast the intermediate result after
16-bit left shift operation immediately with UINT32.
REF:
The code can reach line 69 only through the else path above at line 57.
The else path already has the same NULL check at line 59 and hence the
duplicate code lines are totally redundant which can be deleted.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4201
Signed-off-by: Ranbir Singh
---
Copying patch contents directly in the message below ...
>From e0df5b0a34f1b96aa9610c5eef9161cbbca717d2 Mon Sep 17 00:00:00 2001
From: Ranbir Singh
Date: Thu, 22 Dec 2022 10:57:21 +0530
Subject: [PATCH] IntelFsp2Pkg/Library/BaseFspCommonLib: Fix OVERRUN Coverity
issue
FspData->PerfIdx is
Attached patch fixes the *OVERRUN* Coverity issue in the file
*IntelFsp2Pkg/Library/BaseFspCommonLib/FspCommonLib.c*
Please consider it for review and merge.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97907):
Hi All,
Attached patch contains the changes fixing the issues pointed by Coverity scan
on FatPkg component.
Please review if the changes are safe to be considered.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97759):
Hi All,
The attached patch fixes the DEADCODE issue in MdeModulePkg/Bus/Ata/AhciPei.
Please review.
Best Regards,
Ranbir Singh
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#97760): https://edk2.groups.io/g/devel/message/97760
Mute
21 matches
Mail list logo
