Branch: refs/heads/master
Home: https://github.com/tianocore/edk2
Commit: 95c4d1e17224ea06ccbf31acbc67c12d9c94e0c2
https://github.com/tianocore/edk2/commit/95c4d1e17224ea06ccbf31acbc67c12d9c94e0c2
Author: Mike Beaton <[email protected]>
Date: 2025-12-03 (Wed, 03 Dec 2025)
Changed paths:
M BaseTools/Source/C/Include/Common/BaseTypes.h
Log Message:
-----------
BaseTools: Update OFFSET_OF macro for use with UBSan
Without this change, the macro causes unwanted 'member access within
null pointer' warnings with UBSan.
This is the same macro definition as used in MdePkg/Include/Base.h,
except for removing the legacy `__GNUC__ >= 4` test. Ideally the
orginal macro should have this removed too, as should the several
other instances with similar tests around the codebase, but we leave
that for a separate commit.
Signed-off-by: Mike Beaton <[email protected]>
Commit: 939ebe48e6d6e157b0768368445a51172fee53b9
https://github.com/tianocore/edk2/commit/939ebe48e6d6e157b0768368445a51172fee53b9
Author: Vitaly Cheptsov <[email protected]>
Date: 2025-12-03 (Wed, 03 Dec 2025)
Changed paths:
M BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp
Log Message:
-----------
BaseTools/VfrCompile: Fix memory issues
Using GCC 13.3.0 discovers an out of bounds memory access in VfrCompile
when building DriverSampleDxe. This is also discoverable with ASan.
The issue here is that EFI_IFR_TYPE_VALUE is a flexible type and
when passed by value for string types only the header part is accessible.
Assuming the remainder is zero seems to be ok as gZeroEfiIfrTypeValue
is used as a variable source.
This change also fixes a warning for new[]/delete[] mismatch
discovered by ASan.
Co-authored-by: Vitaly Cheptsov <[email protected]>
Signed-off-by: Mike Beaton <[email protected]>
Commit: 12751d48e215de110a245151f76d3deff39bfe70
https://github.com/tianocore/edk2/commit/12751d48e215de110a245151f76d3deff39bfe70
Author: Mike Beaton <[email protected]>
Date: 2025-12-03 (Wed, 03 Dec 2025)
Changed paths:
M BaseTools/Source/C/VfrCompile/VfrFormPkg.h
M BaseTools/Source/C/VfrCompile/VfrUtilityLib.h
Log Message:
-----------
BaseTools/VfrCompile: Fix EFI_GUID unaligned access
The memmove in SetClassGuid at line 684 generates a
`store to misaligned address` runtime warning when
VfrCompile is compiled with clang UBSan.
We can avoid generating code which stores to a misaligned
address in a least a couple of other ways than done here,
including casting the destination pointer of the memmove
to (VOID *), or compiling with `-fno-builtin-memmove`.
However, maintaining an unaligned pointer to an aligned
type is, strictly speaking, undefined behaviour in the
c/c++ standard (regardless of how it is or is not then
accessed).
So here we resolve the actual incorrect semantics of this
part of the code (and thereby fix the unaligned access) by
introducing a PACKED_EFI_GUID type in VfrUtilityLib.h, and
using it for this unaligned access.
Signed-off-by: Mike Beaton <[email protected]>
Commit: 618868512e7ac0457d052fc73f670bfede15b657
https://github.com/tianocore/edk2/commit/618868512e7ac0457d052fc73f670bfede15b657
Author: Mike Beaton <[email protected]>
Date: 2025-12-03 (Wed, 03 Dec 2025)
Changed paths:
M BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp
Log Message:
-----------
BaseTools/VfrCompile: Prevent uninitialized memory access
When traversing through the field definition of a nested type, such
as "MY_EFI_BITS_VARSTORE_DATA.BitsData.NestBitCheckbox", in method
CVfrVarDataTypeDB::GetDataFieldInfo, the mBitWidth member of the
parent (e.g. BitsData) of a bitfield is accessed, even though it
is not itself a bit field and thus its mBitWidth has never been
initialised.
This is not necessary, the Size and Type of each parent object
were being calculated then overwritten by the next lower object,
so we can just avoid calculating these until the final one which
we actually need.
This behaviour was caught by clang MSan.
Signed-off-by: Mike Beaton <[email protected]>
Commit: 5701cf673d39ea15a2c632e140884c8fa241aec8
https://github.com/tianocore/edk2/commit/5701cf673d39ea15a2c632e140884c8fa241aec8
Author: Mike Beaton <[email protected]>
Date: 2025-12-03 (Wed, 03 Dec 2025)
Changed paths:
M BaseTools/Source/C/VfrCompile/VfrCompiler.h
M BaseTools/Source/C/VfrCompile/VfrSyntax.g
Log Message:
-----------
BaseTools/VfrCompile: Fix bit field access logic
The previous logic for accessing bit fields is wrong when the bit field
starts beyond the first byte, in a storage unit larger than a byte.
This caused unaligned memory accesses which can be caught
by sanitizers.
We also bump the tool minor version number to reflect a functional bugfix.
Signed-off-by: Mike Beaton <[email protected]>
Commit: f79cfc8eafa56dbc4619e2e764e5cf56a4babc6d
https://github.com/tianocore/edk2/commit/f79cfc8eafa56dbc4619e2e764e5cf56a4babc6d
Author: Mike Beaton <[email protected]>
Date: 2025-12-03 (Wed, 03 Dec 2025)
Changed paths:
M BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp
Log Message:
-----------
BaseTools/VfrCompile: Fix null pointer deref when dumping internal types
Internal types such as pFormIdField, pFormSetGuidField have
no associated field type, however the Dump command assumes
that all types do. This causes null pointer dereferencing which
can be caught by sanitizers.
De facto, the field type for these types was already
dumped as <null>, this achieves the same safely.
Signed-off-by: Mike Beaton <[email protected]>
Commit: 53cca9ed9995abdac9fed01aa54c4bf5195f48aa
https://github.com/tianocore/edk2/commit/53cca9ed9995abdac9fed01aa54c4bf5195f48aa
Author: Mike Beaton <[email protected]>
Date: 2025-12-03 (Wed, 03 Dec 2025)
Changed paths:
M BaseTools/Source/C/VfrCompile/VfrError.cpp
M BaseTools/Source/C/VfrCompile/VfrError.h
M BaseTools/Source/C/VfrCompile/VfrFormPkg.cpp
M BaseTools/Source/C/VfrCompile/VfrSyntax.g
M BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp
M BaseTools/Source/C/VfrCompile/VfrUtilityLib.h
Log Message:
-----------
BaseTools/VfrCompile: Minor code cleanup
There are no functional changes in this commit. It adds non-functional
minor code cleanups made while tracking down the bugs fixed in the
preceding commits.
- Fix spelling 'arrary' -> 'array' where it occurs in the tool code and
comments.
- When renaming ExtractFieldNameAndArrary to ExtractFieldNameAndArrayIdx,
we fix the typo and also clarify what the method does: it returns the field name
and the array index when present. Since it is always used to populate a local
variable named ArrayIdx, we stick to that spelling in the renamed method.
- Add comment clarifying that mArrayNum holds array length (but again, don't
go for a bigger global rename).
- Rename CVfrVarDataTypeDB::GetFieldWidth to GetFieldType. It is only used
once, and the new name correctly matches what it does.
Signed-off-by: Mike Beaton <[email protected]>
Compare: https://github.com/tianocore/edk2/compare/e17e5ddd14da...53cca9ed9995
To unsubscribe from these emails, change your notification settings at
https://github.com/tianocore/edk2/settings/notifications
_______________________________________________
edk2-commits mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/edk2-commits