[all-commits] [llvm/llvm-project] dcf23e: [GWP-ASan] Fix up bad report for in-page underflow...

[Mitch Phillips via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: dcf23e13615f88bdd4975058595ee60cf1d5811c
      https://github.com/llvm/llvm-project/commit/dcf23e13615f88bdd4975058595ee60cf1d5811c
  Author: Mitch Phillips <31459023+hctim at users.noreply.github.com>
  Date:   2023-01-10 (Tue, 10 Jan 2023)

  Changed paths:
    M compiler-rt/lib/gwp_asan/crash_handler.cpp
    M compiler-rt/lib/gwp_asan/optional/segv_handler_posix.cpp
    A compiler-rt/test/gwp_asan/free_then_overflow.cpp
    A compiler-rt/test/gwp_asan/free_then_underflow.cpp
    M compiler-rt/test/gwp_asan/heap_buffer_overflow.cpp
    M compiler-rt/test/gwp_asan/heap_buffer_underflow.cpp

  Log Message:
  -----------
  [GWP-ASan] Fix up bad report for in-page underflow w/ UaF

Complex scenario, but reports when there's both a use-after-free and
buffer-underflow that is in-page (i.e. doesn't touch the guard page)
ended up generating a pretty bad report:

'Use After Free at 0x7ff392e88fef (18446744073709551615 bytes into a
1-byte allocation at 0x7ff392e88ff0) by thread 3836722 here:'

(note the 2^64-bytes-into-alloc, very cool and good!)

Fix up that case, and add a diagnostic about when you have both a
use-after-free and a buffer-overflow that it's probably a bogus report
(assuming the developer didn't *really* screw up and have a uaf+overflow
bug at the same time).

Reviewed By: vitalybuka

Differential Revision: https://reviews.llvm.org/D139885