UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.113 Safari/537.36

Steps to reproduce the problem:
1. On Linux, trigger a CRASH() somehow.
2. Look at 'dmesg | grep segfault'.

What is the expected behavior?
Chrome should terminate safely.

What went wrong?
In dmesg:

[87568.538035] chrome[23293]: segfault at fbadbeef ip 000055e98e040812 sp 00007ffcc2e99bb0 error 6 in chrome[55e98a195000+631d000]

This is triggered by CRASH():

#ifndef CRASH
#if COMPILER(MSVC)
#define CRASH() (__debugbreak(), IMMEDIATE_CRASH())
#else
#define CRASH() \
    (WTFReportBacktrace(), (*(int*)0xfbadbeef = 0), IMMEDIATE_CRASH())
#endif
#endif

CRASH() first calls WTFReportBacktrace(), then attempts to kill the process by writing to 0xfbadbeef, and if that wasn't enough, kills the process through __builtin_trap() via IMMEDIATE_CRASH().

There are two issues with this:

 - With 32-bit Chromium on a 64-bit kernel (and with x32, which I think Chromium doesn't support
   yet, and theoretically also in a normal 64-bit binary on a 64-bit kernel), 0xfbadbeef can be
   a valid userland address. (On a 64-bit Linux kernel, the limit for allocations by 32-bit binaries is
   0xFFFFe000 unless the ADDR_LIMIT_3GB personality flag is active, see IA32_PAGE_OFFSET in the
   kernel sources.)
 - The access is a write, not just a read.

This means that four bytes of random memory might be zeroed before the process exits. If there are other threads, this could theoretically permit an attacker to exploit this as a memory corruption on another thread, especially when you keep in mind that the operating system might need some time to stop all threads after a crash.

Did this work before? N/A 

Chrome version: 53.0.2785.113  Channel: stable
OS Version: 
Flash Version: Shockwave Flash 23.0 r0

I think that it would make sense to change `(*(int*)0xfbadbeef = 0)` to `(*(volatile int*)((sizeof(int*)==8) ? 0xFFFFFFFFFFFFFBAD : 0xFFFFFBAD))`. This way, the crash address doesn't depend on whether something happens to be mapped at 0xfbadbeef, and even if something can somehow be mapped at the magic address, at least it won't be overwritten. `volatile` prevents the compiler from compiling out the dereference.

This issue is probably not exploitable on many machines because:
 - 32-bit Chromium on a 64-bit kernel is probably a relatively uncommon
   configuration, at least on Linux. (Although maybe it happens if 32-bit
   Android apps on 64-bit devices use webviews or so?)
 - On 64-bit Linux, I don't think anything is allocated below 0x550000000000 or
   so, at least unless all the address space above that address is filled up
   first.