1==========================
2UndefinedBehaviorSanitizer
3==========================
4
5.. contents::
6   :local:
7
8Introduction
9============
10
11UndefinedBehaviorSanitizer (UBSan) is a fast undefined behavior detector.
12UBSan modifies the program at compile-time to catch various kinds of undefined
13behavior during program execution, for example:
14
15* Using misaligned or null pointer
16* Signed integer overflow
17* Conversion to, from, or between floating-point types which would
18  overflow the destination
19
20See the full list of available :ref:`checks <ubsan-checks>` below.
21
22UBSan has an optional run-time library which provides better error reporting.
23The checks have small runtime cost and no impact on address space layout or ABI.
24
25How to build
26============
27
28Build LLVM/Clang with `CMake <https://llvm.org/docs/CMake.html>`_.
29
30Usage
31=====
32
33Use ``clang++`` to compile and link your program with ``-fsanitize=undefined``
34flag. Make sure to use ``clang++`` (not ``ld``) as a linker, so that your
35executable is linked with proper UBSan runtime libraries. You can use ``clang``
36instead of ``clang++`` if you're compiling/linking C code.
37
38.. code-block:: console
39
40  % cat test.cc
41  int main(int argc, char **argv) {
42    int k = 0x7fffffff;
43    k += argc;
44    return 0;
45  }
46  % clang++ -fsanitize=undefined test.cc
47  % ./a.out
48  test.cc:3:5: runtime error: signed integer overflow: 2147483647 + 1 cannot be represented in type 'int'
49
50You can enable only a subset of :ref:`checks <ubsan-checks>` offered by UBSan,
51and define the desired behavior for each kind of check:
52
53* ``-fsanitize=...``: print a verbose error report and continue execution (default);
54* ``-fno-sanitize-recover=...``: print a verbose error report and exit the program;
55* ``-fsanitize-trap=...``: execute a trap instruction (doesn't require UBSan run-time support).
56
57For example if you compile/link your program as:
58
59.. code-block:: console
60
61  % clang++ -fsanitize=signed-integer-overflow,null,alignment -fno-sanitize-recover=null -fsanitize-trap=alignment
62
63the program will continue execution after signed integer overflows, exit after
64the first invalid use of a null pointer, and trap after the first use of misaligned
65pointer.
66
67.. _ubsan-checks:
68
69Available checks
70================
71
72Available checks are:
73
74  -  ``-fsanitize=alignment``: Use of a misaligned pointer or creation
75     of a misaligned reference. Also sanitizes assume_aligned-like attributes.
76  -  ``-fsanitize=bool``: Load of a ``bool`` value which is neither
77     ``true`` nor ``false``.
78  -  ``-fsanitize=builtin``: Passing invalid values to compiler builtins.
79  -  ``-fsanitize=bounds``: Out of bounds array indexing, in cases
80     where the array bound can be statically determined.
81  -  ``-fsanitize=enum``: Load of a value of an enumerated type which
82     is not in the range of representable values for that enumerated
83     type.
84  -  ``-fsanitize=float-cast-overflow``: Conversion to, from, or
85     between floating-point types which would overflow the
86     destination. Because the range of representable values for all
87     floating-point types supported by Clang is [-inf, +inf], the only
88     cases detected are conversions from floating point to integer types.
89  -  ``-fsanitize=float-divide-by-zero``: Floating point division by
90     zero. This is undefined per the C and C++ standards, but is defined
91     by Clang (and by ISO/IEC/IEEE 60559 / IEEE 754) as producing either an
92     infinity or NaN value, so is not included in ``-fsanitize=undefined``.
93  -  ``-fsanitize=function``: Indirect call of a function through a
94     function pointer of the wrong type (Darwin/Linux, C++ and x86/x86_64
95     only).
96  -  ``-fsanitize=implicit-unsigned-integer-truncation``,
97     ``-fsanitize=implicit-signed-integer-truncation``: Implicit conversion from
98     integer of larger bit width to smaller bit width, if that results in data
99     loss. That is, if the demoted value, after casting back to the original
100     width, is not equal to the original value before the downcast.
101     The ``-fsanitize=implicit-unsigned-integer-truncation`` handles conversions
102     between two ``unsigned`` types, while
103     ``-fsanitize=implicit-signed-integer-truncation`` handles the rest of the
104     conversions - when either one, or both of the types are signed.
105     Issues caught by these sanitizers are not undefined behavior,
106     but are often unintentional.
107  -  ``-fsanitize=implicit-integer-sign-change``: Implicit conversion between
108     integer types, if that changes the sign of the value. That is, if the the
109     original value was negative and the new value is positive (or zero),
110     or the original value was positive, and the new value is negative.
111     Issues caught by this sanitizer are not undefined behavior,
112     but are often unintentional.
113  -  ``-fsanitize=integer-divide-by-zero``: Integer division by zero.
114  -  ``-fsanitize=nonnull-attribute``: Passing null pointer as a function
115     parameter which is declared to never be null.
116  -  ``-fsanitize=null``: Use of a null pointer or creation of a null
117     reference.
118  -  ``-fsanitize=nullability-arg``: Passing null as a function parameter
119     which is annotated with ``_Nonnull``.
120  -  ``-fsanitize=nullability-assign``: Assigning null to an lvalue which
121     is annotated with ``_Nonnull``.
122  -  ``-fsanitize=nullability-return``: Returning null from a function with
123     a return type annotated with ``_Nonnull``.
124  -  ``-fsanitize=object-size``: An attempt to potentially use bytes which
125     the optimizer can determine are not part of the object being accessed.
126     This will also detect some types of undefined behavior that may not
127     directly access memory, but are provably incorrect given the size of
128     the objects involved, such as invalid downcasts and calling methods on
129     invalid pointers. These checks are made in terms of
130     ``__builtin_object_size``, and consequently may be able to detect more
131     problems at higher optimization levels.
132  -  ``-fsanitize=pointer-overflow``: Performing pointer arithmetic which
133     overflows.
134  -  ``-fsanitize=return``: In C++, reaching the end of a
135     value-returning function without returning a value.
136  -  ``-fsanitize=returns-nonnull-attribute``: Returning null pointer
137     from a function which is declared to never return null.
138  -  ``-fsanitize=shift``: Shift operators where the amount shifted is
139     greater or equal to the promoted bit-width of the left hand side
140     or less than zero, or where the left hand side is negative. For a
141     signed left shift, also checks for signed overflow in C, and for
142     unsigned overflow in C++. You can use ``-fsanitize=shift-base`` or
143     ``-fsanitize=shift-exponent`` to check only left-hand side or
144     right-hand side of shift operation, respectively.
145  -  ``-fsanitize=signed-integer-overflow``: Signed integer overflow, where the
146     result of a signed integer computation cannot be represented in its type.
147     This includes all the checks covered by ``-ftrapv``, as well as checks for
148     signed division overflow (``INT_MIN/-1``), but not checks for
149     lossy implicit conversions performed before the computation
150     (see ``-fsanitize=implicit-conversion``). Both of these two issues are
151     handled by ``-fsanitize=implicit-conversion`` group of checks.
152  -  ``-fsanitize=unreachable``: If control flow reaches an unreachable
153     program point.
154  -  ``-fsanitize=unsigned-integer-overflow``: Unsigned integer overflow, where
155     the result of an unsigned integer computation cannot be represented in its
156     type. Unlike signed integer overflow, this is not undefined behavior, but
157     it is often unintentional. This sanitizer does not check for lossy implicit
158     conversions performed before such a computation
159     (see ``-fsanitize=implicit-conversion``).
160  -  ``-fsanitize=vla-bound``: A variable-length array whose bound
161     does not evaluate to a positive value.
162  -  ``-fsanitize=vptr``: Use of an object whose vptr indicates that it is of
163     the wrong dynamic type, or that its lifetime has not begun or has ended.
164     Incompatible with ``-fno-rtti``. Link must be performed by ``clang++``, not
165     ``clang``, to make sure C++-specific parts of the runtime library and C++
166     standard libraries are present.
167
168You can also use the following check groups:
169  -  ``-fsanitize=undefined``: All of the checks listed above other than
170     ``float-divide-by-zero``, ``unsigned-integer-overflow``,
171     ``implicit-conversion``, and the ``nullability-*`` group of checks.
172  -  ``-fsanitize=undefined-trap``: Deprecated alias of
173     ``-fsanitize=undefined``.
174  -  ``-fsanitize=implicit-integer-truncation``: Catches lossy integral
175     conversions. Enables ``implicit-signed-integer-truncation`` and
176     ``implicit-unsigned-integer-truncation``.
177  -  ``-fsanitize=implicit-integer-arithmetic-value-change``: Catches implicit
178     conversions that change the arithmetic value of the integer. Enables
179     ``implicit-signed-integer-truncation`` and ``implicit-integer-sign-change``.
180  -  ``-fsanitize=implicit-conversion``: Checks for suspicious
181     behavior of implicit conversions. Enables
182     ``implicit-unsigned-integer-truncation``,
183     ``implicit-signed-integer-truncation``, and
184     ``implicit-integer-sign-change``.
185  -  ``-fsanitize=integer``: Checks for undefined or suspicious integer
186     behavior (e.g. unsigned integer overflow).
187     Enables ``signed-integer-overflow``, ``unsigned-integer-overflow``,
188     ``shift``, ``integer-divide-by-zero``,
189     ``implicit-unsigned-integer-truncation``,
190     ``implicit-signed-integer-truncation``, and
191     ``implicit-integer-sign-change``.
192  -  ``-fsanitize=nullability``: Enables ``nullability-arg``,
193     ``nullability-assign``, and ``nullability-return``. While violating
194     nullability does not have undefined behavior, it is often unintentional,
195     so UBSan offers to catch it.
196
197Volatile
198--------
199
200The ``null``, ``alignment``, ``object-size``, and ``vptr`` checks do not apply
201to pointers to types with the ``volatile`` qualifier.
202
203Minimal Runtime
204===============
205
206There is a minimal UBSan runtime available suitable for use in production
207environments. This runtime has a small attack surface. It only provides very
208basic issue logging and deduplication, and does not support
209``-fsanitize=function`` and ``-fsanitize=vptr`` checking.
210
211To use the minimal runtime, add ``-fsanitize-minimal-runtime`` to the clang
212command line options. For example, if you're used to compiling with
213``-fsanitize=undefined``, you could enable the minimal runtime with
214``-fsanitize=undefined -fsanitize-minimal-runtime``.
215
216Stack traces and report symbolization
217=====================================
218If you want UBSan to print symbolized stack trace for each error report, you
219will need to:
220
221#. Compile with ``-g`` and ``-fno-omit-frame-pointer`` to get proper debug
222   information in your binary.
223#. Run your program with environment variable
224   ``UBSAN_OPTIONS=print_stacktrace=1``.
225#. Make sure ``llvm-symbolizer`` binary is in ``PATH``.
226
227Silencing Unsigned Integer Overflow
228===================================
229To silence reports from unsigned integer overflow, you can set
230``UBSAN_OPTIONS=silence_unsigned_overflow=1``.  This feature, combined with
231``-fsanitize-recover=unsigned-integer-overflow``, is particularly useful for
232providing fuzzing signal without blowing up logs.
233
234Issue Suppression
235=================
236
237UndefinedBehaviorSanitizer is not expected to produce false positives.
238If you see one, look again; most likely it is a true positive!
239
240Disabling Instrumentation with ``__attribute__((no_sanitize("undefined")))``
241----------------------------------------------------------------------------
242
243You disable UBSan checks for particular functions with
244``__attribute__((no_sanitize("undefined")))``. You can use all values of
245``-fsanitize=`` flag in this attribute, e.g. if your function deliberately
246contains possible signed integer overflow, you can use
247``__attribute__((no_sanitize("signed-integer-overflow")))``.
248
249This attribute may not be
250supported by other compilers, so consider using it together with
251``#if defined(__clang__)``.
252
253Suppressing Errors in Recompiled Code (Blacklist)
254-------------------------------------------------
255
256UndefinedBehaviorSanitizer supports ``src`` and ``fun`` entity types in
257:doc:`SanitizerSpecialCaseList`, that can be used to suppress error reports
258in the specified source files or functions.
259
260Runtime suppressions
261--------------------
262
263Sometimes you can suppress UBSan error reports for specific files, functions,
264or libraries without recompiling the code. You need to pass a path to
265suppression file in a ``UBSAN_OPTIONS`` environment variable.
266
267.. code-block:: bash
268
269    UBSAN_OPTIONS=suppressions=MyUBSan.supp
270
271You need to specify a :ref:`check <ubsan-checks>` you are suppressing and the
272bug location. For example:
273
274.. code-block:: bash
275
276  signed-integer-overflow:file-with-known-overflow.cpp
277  alignment:function_doing_unaligned_access
278  vptr:shared_object_with_vptr_failures.so
279
280There are several limitations:
281
282* Sometimes your binary must have enough debug info and/or symbol table, so
283  that the runtime could figure out source file or function name to match
284  against the suppression.
285* It is only possible to suppress recoverable checks. For the example above,
286  you can additionally pass
287  ``-fsanitize-recover=signed-integer-overflow,alignment,vptr``, although
288  most of UBSan checks are recoverable by default.
289* Check groups (like ``undefined``) can't be used in suppressions file, only
290  fine-grained checks are supported.
291
292Supported Platforms
293===================
294
295UndefinedBehaviorSanitizer is supported on the following operating systems:
296
297* Android
298* Linux
299* NetBSD
300* FreeBSD
301* OpenBSD
302* macOS
303* Windows
304
305The runtime library is relatively portable and platform independent. If the OS
306you need is not listed above, UndefinedBehaviorSanitizer may already work for
307it, or could be made to work with a minor porting effort.
308
309Current Status
310==============
311
312UndefinedBehaviorSanitizer is available on selected platforms starting from LLVM
3133.3. The test suite is integrated into the CMake build and can be run with
314``check-ubsan`` command.
315
316Additional Configuration
317========================
318
319UndefinedBehaviorSanitizer adds static check data for each check unless it is
320in trap mode. This check data includes the full file name. The option
321``-fsanitize-undefined-strip-path-components=N`` can be used to trim this
322information. If ``N`` is positive, file information emitted by
323UndefinedBehaviorSanitizer will drop the first ``N`` components from the file
324path. If ``N`` is negative, the last ``N`` components will be kept.
325
326Example
327-------
328
329For a file called ``/code/library/file.cpp``, here is what would be emitted:
330
331* Default (No flag, or ``-fsanitize-undefined-strip-path-components=0``): ``/code/library/file.cpp``
332* ``-fsanitize-undefined-strip-path-components=1``: ``code/library/file.cpp``
333* ``-fsanitize-undefined-strip-path-components=2``: ``library/file.cpp``
334* ``-fsanitize-undefined-strip-path-components=-1``: ``file.cpp``
335* ``-fsanitize-undefined-strip-path-components=-2``: ``library/file.cpp``
336
337More Information
338================
339
340* From LLVM project blog:
341  `What Every C Programmer Should Know About Undefined Behavior
342  <http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html>`_
343* From John Regehr's *Embedded in Academia* blog:
344  `A Guide to Undefined Behavior in C and C++
345  <https://blog.regehr.org/archives/213>`_
346