get_auxval may crash for BOTAN_TARGET_OS_HAS_AUXINFO

[mlelstv]

The file lib/utils/os_utils.cpp contains code for searching the ELF aux vector entry of a specific type. On systems that build with BOTAN_TARGET_OS_HAS_AUXINFO, the searching loop compares a pointer with AT_NULL instead of the a_type field that would mark the end of the aux vector.

for(const AuxInfo* auxinfo = static_cast<AuxInfo*>(::_dlauxinfo()); auxinfo != AT_NULL; ++auxinfo)

if the searched entry isn't found, the loop will just scan beyond the end of the vector until it finds some random memory location with the correct value or until it reaches an unmapped page and segfaults.

I think this should be corrected to:

for(const AuxInfo* auxinfo = static_cast<AuxInfo*>(::_dlauxinfo()); auxinfo->a_type != AT_NULL; ++auxinfo)

The bug seems to exist in all releases.

I noticed this when analyzing crashes of keepassxc on NetBSD for aarch64. The corresponding bug report is https://gnats.netbsd.org/59111

[randombit]

Thanks for the report. I do have access to a NetBSD aarch64 machine and was able to confirm both the crash and your fix.

There is a larger issue raised here though - the linked bug mentions "AT_HWCAP (something we do not provide)" - what is the preferred way to identify CPU features like NEON on NetBSD at runtime? We do have a SIGILL based fallback, so lacking HWCAP it still does work, but this is a scary and fragile hack.

Is AT_HWCAP generally absent on NetBSD? Or just specifically to aarch64? The reason I ask is 99% of our usage of getauxval or equivalents is precisely to read AT_HWCAP on Linux/Android/OpenBSD/FreeBSD and (I thought!) NetBSD. If this is something NetBSD does not support and doesn't plan to, it probably makes sense for us to just remove this _dlauxinfo call entirely.