2caba086ab
__asan_region_is_poisoned() uses an exclusive end address (end = beg + size) to validate the region [beg, end) and to compute the aligned inner shadow region. This causes correctness issue near memory range upper boundary and could trigger address space overflow on 32-bit targets. 1. Incorrect handling of the last byte of a memory range The implementation checks AddrIsInMem(end) instead of the last application byte (end - 1). For regions ending at the last byte of Low/Mid/HighMem (e.g. __asan_region_is_poisoned(kHighMemEnd, 1)), this returns end (kHighMemEnd + 1) instead of the original pointer. This behavior is inconsistent with the function’s semantics and with __asan_address_is_poisoned(). 2) address space overflow and invalid shadow range If a region ends at the top of the virtual address space (kHighMemEnd), e.g. on 32-bit targets, end = beg + size could wrap to 0. This violated the invariant beg < end and could trigger the CHECK failure. Additionally, overflow in RoundUpTo alignment computations for aligned_b could produce an invalid shadow region spanning LowShadow to HighShadow across ShadowGap, leading mem_is_zero() to access unmapped memory and crash. Fix by switching to an inclusive last byte: last = beg + size - 1 All checks are now performed on beg and last. The aligned inner shadow region is also computed from [beg, last]. Additional guard for aligned_b prevents the mapping to shadow if aligned_b is wrapped (in this case the aligned inner region is also empty and doesn't require the shadow scan via mem_is_zero()). This fixes incorrect return values at memory range ends and prevents overflow related crashes on 32-bit targets. Test is extended to cover these boundary cases. --------- Co-authored-by: Vitaly Buka <vitalybuka@gmail.com>
The LLVM Compiler Infrastructure
Welcome to the LLVM project!
This repository contains the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.
The LLVM project has multiple components. The core of the project is itself called "LLVM". This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer.
C-like languages use the Clang frontend. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.
Other components include: the libc++ C++ standard library, the LLD linker, and more.
Getting the Source Code and Building LLVM
Consult the Getting Started with LLVM page for information on building and running LLVM.
For information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.
Getting in touch
Join the LLVM Discourse forums, Discord chat, LLVM Office Hours or Regular sync-ups.
The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.