From b8adbbe5bf4928e53b19df0de01a39a7ce182a3b Mon Sep 17 00:00:00 2001 From: EylonKrause Date: Thu, 2 Jul 2026 01:09:34 +0300 Subject: [PATCH] hwcaps: don't return an uninitialized hwcap on elf_aux_info failure On FreeBSD/OpenBSD, GetElfHwcapFromElfAuxInfo left `hwcap` uninitialized and ignored the elf_aux_info() return value. elf_aux_info() only writes the output buffer on success; when the requested entry is absent (e.g. AT_HWCAP2, which CpuFeatures_GetHardwareCapabilities requests unconditionally, on arch/kernel combinations that lack it) it returns non-zero and leaves the buffer untouched, so the function returned an indeterminate stack value that is then bit-tested for CPU features. Initialize to 0 and return 0 on failure, matching the Linux getauxval path. --- src/hwcaps_freebsd_or_openbsd.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/src/hwcaps_freebsd_or_openbsd.c b/src/hwcaps_freebsd_or_openbsd.c index db90297c..775afe74 100644 --- a/src/hwcaps_freebsd_or_openbsd.c +++ b/src/hwcaps_freebsd_or_openbsd.c @@ -30,7 +30,10 @@ const char* CpuFeatures_GetBasePlatformPointer(void); #include static unsigned long GetElfHwcapFromElfAuxInfo(int hwcap_type) { - unsigned long hwcap; + unsigned long hwcap = 0; + // elf_aux_info() leaves the output buffer untouched when the requested entry + // is absent (e.g. AT_HWCAP2 on some arch/kernel combos), so initializing + // hwcap to 0 avoids returning an indeterminate value on failure. elf_aux_info(hwcap_type, &hwcap, sizeof(hwcap)); return hwcap; }