[all-commits] [llvm/llvm-project] c7bc3d: [scudo][standalone] Fix Secondary bug w/ freelist

[Kostya Kortchinsky via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: c7bc3db23cafee2b51c43bfbe2c02f61cf115721
      https://github.com/llvm/llvm-project/commit/c7bc3db23cafee2b51c43bfbe2c02f61cf115721
  Author: Kostya Kortchinsky <kostyak at google.com>
  Date:   2019-10-31 (Thu, 31 Oct 2019)

  Changed paths:
    M compiler-rt/lib/scudo/standalone/combined.h
    M compiler-rt/lib/scudo/standalone/secondary.h
    M compiler-rt/lib/scudo/standalone/tests/combined_test.cpp

  Log Message:
  -----------
  [scudo][standalone] Fix Secondary bug w/ freelist

Summary:
cferris@ found an issue due to the new Secondary free list behavior
and unfortunately it's completely my fault. The issue is twofold:

- I lost track of the (major) fact that the Combined assumes that
  all chunks returned by the Secondary are zero'd out apprioriately
  when dealing with `ZeroContents`. With the introduction of the
  freelist, it's no longer the case as there can be a small portion
  of memory between the header and the next page boundary that is
  left untouched (the rest is zero'd via release). So the next time
  that block is returned, it's not fully zero'd out.
- There was no test that would exercise that behavior :(

There are several ways to fix this, the one I chose makes the most
sense to me: we pass `ZeroContents` to the Secondary's `allocate`
and it zero's out the block if requested and it's coming from the
freelist. The prevents an extraneous `memset` in case the block
comes from `map`. Another possbility could have been to `memset`
in `deallocate`, but it's probably overzealous as all secondary
blocks don't need to be zero'd out.

Add a test that would have found the issue prior to fix.

Reviewers: morehouse, hctim, cferris, pcc, eugenis, vitalybuka

Subscribers: #sanitizers, llvm-commits

Tags: #sanitizers, #llvm

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