Bug 180175 – WTF / bmalloc: don't write to 0xbbadbeef when ASAN is looking

• Component: Web Template Framework
• Status: RESOLVED FIXED

[JF Bastien]

ASAN knows that 0xbbadbeef is a bbad aaddress, and tells us so when we write to it, say in an assert. That creates bbad error reports where ASAN thinks we write to an invalid address, instead of thinking that we hit an assertion. In some cases, tooling that use fuzzers aggregate similar issues, and think that we just have the one bug and not a bunch of different asserts.

At the same time, malloc's version of CRASH just writes to 0xbbadbeef and assumes that's invalid and will crash, which isn't necessarily true on non-Mac platforms. WTF's version then makes sure there's a crash, so bmalloc should do the same.

[JF Bastien]

Created attachment 327929 [details]
patch

[EWS Watchlist]

Attachment 327929 [details] did not pass style-queue:


ERROR: Source/WTF/ChangeLog:12:  Please consider whether the use of security-sensitive phrasing could help someone exploit WebKit: fuzzer  [changelog/unwantedsecurityterms] [3]
ERROR: Source/bmalloc/ChangeLog:12:  Please consider whether the use of security-sensitive phrasing could help someone exploit WebKit: fuzzer  [changelog/unwantedsecurityterms] [3]
ERROR: Source/bmalloc/bmalloc/BCompiler.h:29:  One space before end of line comments  [whitespace/comments] [5]
ERROR: Source/bmalloc/bmalloc/BCompiler.h:29:  Should have a space between // and comment  [whitespace/comments] [4]
Total errors found: 4 in 8 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Mark Lam]

Comment on attachment 327929 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=327929&action=review

r=me.  Make sure that you also do an ASan build and confirm that it built as expected.

> Source/bmalloc/ChangeLog:15
> +        At the same time, malloc's version of CRASH just writes to

/malloc/bmalloc/

[JF Bastien]

Created attachment 327957 [details]
patch

Address comment.

My asan build seems to do the right thing: print a stack trace, then "Illegal instruction: 4" and exit with return code 132.

[WebKit Commit Bot]

Comment on attachment 327957 [details]
patch

Clearing flags on attachment: 327957

Committed r225320: <https://trac.webkit.org/changeset/225320>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Radar WebKit Bug Importer]

<rdar://problem/35767562>