summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorScott Moser <[email protected]>2026-07-28 12:33:28 -0700
committerHeinrich Schuchardt <[email protected]>2026-07-31 11:06:37 +0200
commitd78ba22ab2df094a659a7ffa85e0787037f7e3a7 (patch)
tree942b8792e7ea70d5f88e15601df7b9af4eabbd29 /include
parentc9baa7611b2a00f31dc5855b9b3572bfac1fd0a8 (diff)
efi_loader: fix use of uninitialized guid in variable enumeration loops
efi_bootmgr_delete_invalid_boot_option(), eficonfig_show_boot_selection(), and eficonfig_create_change_boot_order_entry() each enumerate all EFI variables by repeatedly calling efi_next_variable_name() in a loop, passing the same efi_guid_t as both input and output. GetNextVariableName() needs the vendor GUID returned by the previous call, together with the variable name it returned, to know where to resume. In each of these loops the efi_guid_t was declared inside the loop body, so a new instance comes into scope on every iteration. Relying on it to still hold the previous iteration's value depends on the compiler reusing the same stack slot across iterations, which is undefined behavior. With a compiler that zero-initializes locals by default (e.g. clang, or gcc configured with -ftrivial-auto-var-init=zero), the GUID is cleared on every iteration, so the lookup of the variable name returned by the previous call fails and efi_init_obj_list() aborts: Cannot initialize UEFI sub-system ** Booting bootflow ... with efi Boot failed (err=-22) Move the efi_guid_t declarations out of the loops so the value written by the previous efi_next_variable_name() call is preserved across iterations. Fixes: 140a8959d48f ("eficonfig: use efi_get_next_variable_name_int()") Signed-off-by: Scott Moser <[email protected]> Reviewed-by: Heinrich Schuchardt <[email protected]>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions