Hardware-assisted AddressSanitizer (HWASan) is a memory error detection tool similar to AddressSanitizer. HWASan uses a lot less RAM compared to ASan, which makes it suitable for whole system sanitization. HWASan is only available on Android 10 and higher, and only on AArch64 hardware.

Although primarily useful for C/C++ code, HWASan can also help debug Java code that causes crashes in C/C++ used to implement Java interfaces. It's helpful because it catches memory errors when they happen, pointing you directly at the responsible code.

You can flash prebuilt HWASan images to supported Pixel devices from ci.android.com (detailed setup instructions).

Compared to classic ASan, HWASan has:

  • Similar CPU overhead (~2x)
  • Similar code size overhead (40 – 50%)
  • Much smaller RAM overhead (10% – 35%)

HWASan detects the same set of bugs as ASan:

  • Stack and heap buffer overflow/underflow
  • Heap use after free
  • Stack use outside scope
  • Double free/wild free

Additionally, HWASan detects stack use after return.

Implementation details and limitations

HWASan is based on the memory tagging approach, where a small random tag value is associated both with pointers and with ranges of memory addresses. For a memory access to be valid, the pointer and memory tags have to match. HWASan relies on ARMv8 feature top byte ignore (TBI), also called virtual address tagging, to store the pointer tag in the highest bits of the address.

You can read more about the design of HWASan on the Clang documentation site.

By design, HWASan doesn't have ASan's limited-size redzones for detecting overflows or ASan's limited-capacity quarantine for detecting use after free. For this reason, HWASan can detect a bug no matter how large the overflow is or how long ago the memory was deallocated. This gives HWASan a big advantage over ASan.

However, HWASan has a limited number of possible tag values (256), which means that there is a 0.4% probability of missing any bug during one execution of the program.


HWASan requires the Linux kernel to accept tagged pointers in system call arguments. Support for this was implemented in the following upstream patchsets:

These patches are available as backports in the common Android kernel in android-4.14 and higher branches, but not in Android 10-specific branches such as android-4.14-q.

Userspace support for HWASan is available starting with Android 11.

If you are building with a custom toolchain, make sure that it includes everything up to LLVM commit c336557f.

Using HWASan

Use the following commands to build the entire platform using HWASan:

lunch aosp_walleye-userdebug # (or any other product)
export SANITIZE_TARGET=hwaddress
m -j

For convenience, you can add the SANITIZE_TARGET setting to a product definition, similar to aosp_coral_hwasan.

Unlike ASan, with HWASan there's no need to build twice. Incremental builds just work, there are no special flashing instructions or wiping requirement, static executables are supported, and it's okay to skip sanitization of any library other than libc. There's also no requirement that if a library is sanitized, any executable that links to it must also be sanitized.

To skip sanitization of a module, use LOCAL_NOSANITIZE := hwaddress or sanitize: { hwaddress: false }.

Individual modules may be sanitized with HWASan, with the caveat that libc is also HWASan-ified. This can be done by adding sanitize: { hwaddress: true } to the respective Android.bp module definition. The entire Android platform is built with HWASan when using a _hwasan-suffixed build (including libc), and as such manually sanitizing libc is not necessary for HWASan builds.

Better stack traces

HWASan uses a fast, frame-pointer-based unwinder to record a stack trace for every memory allocation and deallocation event in the program. Android enables frame pointers in AArch64 code by default, so this works great in practice. If you need to unwind through managed code, set HWASAN_OPTIONS=fast_unwind_on_malloc=0 in the process environment. Note that bad memory access stack traces use the "slow" unwinder by default; this setting only affects allocation and deallocation traces. This option can be very CPU-intensive, depending on the load.


See Symbolization in ASan documentation.

HWASan in apps

Similar to AddressSanitizer, HWASan can't see into Java code, but it can detect bugs in the JNI libraries. Unlike ASan, running HWASan apps on a non-HWASan device is not supported.

On a HWASan device, apps can be checked with HWASan by building their code with SANITIZE_TARGET:=hwaddress in Make, or -fsanitize=hwaddress in compiler flags. See the app developer documentation for more details.