
Update the documentation. It is expected the Dangling Pointer Detector to be enabled on Linux by default. Bug: chromium:1449923 Change-Id: I9dae36512c0cbe7cf2c673bb361f11b5af778f48 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4758986 Auto-Submit: Arthur Sonzogni <arthursonzogni@chromium.org> Reviewed-by: Bartek Nowierski <bartekn@chromium.org> Reviewed-by: Tom Sepez <tsepez@chromium.org> Commit-Queue: Tom Sepez <tsepez@chromium.org> Cr-Commit-Position: refs/heads/main@{#1180992}
5.0 KiB
Dangling Pointer Detector
A pointer is dangling when it references freed memory. Typical examples can be found here.
Dangling pointers are not a problem unless they are subsequently dereferenced and/or used for other purposes. Proving that pointers are unused has turned out to be difficult in general, especially in face of future modifications to the code. Hence, they are a source of UaF bugs and highly discouraged unless you are able to ensure that they can never be used after the pointed-to objects are freed.
See also the Dangling Pointers Guide for how to fix cases where dangling pointers occur.
Behind build flags, Chrome implements a dangling pointer detector. It causes Chrome to crash, whenever a raw_ptr becomes dangling:
raw_ptr<T> ptr_never_dangling;
On the other hand, we cannot simply ban all the usage of dangling pointers
because there are valid use cases. The DisableDanglingPtrDetection
option can
be used to annotate "intentional-and-safe" dangling pointers. It is meant to be
used as a last resort, only if there is no better way to re-architecture the
code.
raw_ptr<T, DisableDanglingPtrDetection> ptr_may_dangle;
The DanglingUntriaged
option has been used to annotate pre-existing dangling
pointers in Chrome:
raw_ptr<T, DanglingUntriaged> ptr_dangling_mysteriously;
Contrary to DisableDanglingPtrDetection
, we don't know yet why it dangles. It
is meant to be either refactored to avoid dangling, or turned into
"DisableDanglingPtrDetection" with a comment explaining what happens.
How to check for dangling pointers?
On Linux, it is enabled by default on most configurations.
To be precise: (is_debug
or dcheck_always_on
) and non is_official
builds.
For the other operating systems, this is gated by both build and runtime flags:
Build flags
gn args ./out/dangling/
use_goma = true
is_debug = false # Important! (*)
is_component_build = false # Important! (*)
dcheck_always_on = true
enable_backup_ref_ptr_support = true # true by default on some platforms
enable_dangling_raw_ptr_checks = true
(*) We want to emphasize that setting either is_debug = false
or
is_component_build = false
is important. It is a common mistake to set
is_debug
to true
, which in turn turns on component builds, which
disables PartitionAlloc-Everywhere. enable_backup_ref_ptr_support = true
can't
be used without PartitionAlloc-Everywhere, and is silently set to false
.
Runtime flags
./out/dangling/content_shell \
--enable-features=PartitionAllocBackupRefPtr,PartitionAllocDanglingPtr
By default, Chrome will crash on the first dangling raw_ptr detected.
Runtime flags options:
Mode parameter
Crash (default)
--enable-features=PartitionAllocBackupRefPtr,PartitionAllocDanglingPtr:mode/crash
Record a list of signatures
Example usage:
./out/dangling/content_shell \
--enable-features=PartitionAllocBackupRefPtr,PartitionAllocDanglingPtr:mode/log_only \
|& tee output
The logs can be filtered and transformed into a tab separated table:
cat output \
| grep "[DanglingSignature]" \
| cut -f2,3,4,5 \
| sort \
| uniq -c \
| sed -E 's/^ *//; s/ /\t/' \
| sort -rn
This is used to list issues and track progresses.
Type parameter
Select all dangling raw_ptr (default)
The option: type/all
selects every dangling pointer.
Example usage:
./out/dangling/content_shell \
--enable-features=PartitionAllocBackupRefPtr,PartitionAllocDanglingPtr:type/all
Select cross tasks dangling raw_ptr
The option: type/cross_task
selects dangling pointers that are released in a
different task than the one where the memory was freed. Those are more likely to
cause UAF.
Example usage:
./out/dangling/content_shell \
--enable-features=PartitionAllocBackupRefPtr,PartitionAllocDanglingPtr:type/cross_task
Combination
Both parameters can be combined, example usage:
./out/dangling/content_shell \
--enable-features=PartitionAllocBackupRefPtr,PartitionAllocDanglingPtr:mode/log_only/type/cross_task \
|& tee output
Alternative dangling pointer detector (experimental)
The dangling pointer detector above works only against certain heap allocated objects, but there is an alternate form that catches other cases such as pointers to out-of-scope stack variables or pointers to deallocated shared memory regions. The GN arguments to enable it are:
enable_backup_ref_ptr_support=false
is_asan=true
is_component_build=false
use_asan_backup_ref_ptr=false
use_asan_unowned_ptr=true
This will crash when the object containing the dangling ptr is destructed, giving the usual three-stack trace from ASAN showing where the deleted object was allocated and freed.
When running under this mode, there is no need to specify any --enable-features flag as above.