| commit | 874cc741183ceabf107175369a92dd763d948f10 | [log] [tgz] |
|---|---|---|
| author | Björn Terelius <terelius@chromium.org> | Fri Nov 14 09:20:28 2025 |
| committer | Copybara-Service <copybara-worker@google.com> | Fri Nov 14 09:25:20 2025 |
| tree | 816bfbc622289b7d167c8b05c0936298bf074a58 | |
| parent | 88b38180c18fd58c2678ec0520b44c9bff590a64 [diff] |
Revert "fix of auto spanification for libfuzzer" This reverts commit cdd3e5c2638fc268ced4d11334133cc85e108b48. Reason for revert: Adding a //base dependency in //testing breaks downstream projects (that can't use //base) Original change's description: > fix of auto spanification for libfuzzer > > spanification: automatically spanify testing/libfuzzer/unittest_main.cc > etc. > > This is the result of running the automatic spanification on linux and > updating code to use and pass spans where size is known. > > The original patch was fully automated using script: > //tools/clang/spanify/rewrite-multiple-platforms.sh -platforms=linux > Then refined with gemini-cli > > gemini-run/batch-run-1761116551/group_104 > > BUG=439964610 > > Change-Id: I30ba2b835150041d2e8ce36eb3ef5a18d41a84d7 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7138958 > Reviewed-by: Stephen Nusko <nuskos@chromium.org> > Auto-Submit: Daniel Angulo <angdaniel@google.com> > Commit-Queue: Daniel Angulo <angdaniel@google.com> > Reviewed-by: Ali Hijazi <ahijazi@chromium.org> > Cr-Commit-Position: refs/heads/main@{#1544501} Bug: 439964610 No-Presubmit: true No-Tree-Checks: true No-Try: true Change-Id: I5f39b7a046a0e00d5e351460e659d764d438dddf Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7156575 Commit-Queue: Jeremy Leconte <jleconte@google.com> Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by: Titouan Rigoudy <titouan@chromium.org> Cr-Commit-Position: refs/heads/main@{#1544806} NOKEYCHECK=True GitOrigin-RevId: b54a82bfa3d0b4766d5bf0a52de93838c268ada3
Fuzzing is a testing technique that feeds auto-generated inputs to a piece of target code in an attempt to crash the code. It's one of the most effective methods we have for finding security and stability issues (see go/fuzzing-success). You can learn more about the benefits of fuzzing at go/why-fuzz.
This documentation covers the in-process guided fuzzing approach employed by different fuzzing engines, such as libFuzzer or [AFL]. To learn more about out-of-process fuzzers, please refer to the Blackbox fuzzing page in the ClusterFuzz documentation.
In Chromium, you can easily create and submit fuzz targets. The targets are automatically discovered by buildbots, built with different fuzzing engines, then uploaded to the distributed ClusterFuzz fuzzing system to run at scale.
You should fuzz any code which absorbs inputs from untrusted sources, such as the web. If the code parses, decodes, or otherwise manipulates that input, it's an especially good idea to fuzz it.
Create your first fuzz target and submit it by stepping through our Getting Started Guide.
Creating a fuzz target that expects a protobuf instead of a byte stream as input.
Reproducing bugs found by libFuzzer/AFL and reported by ClusterFuzz.
Fuzzing mojo interfaces using automatically generated libprotobuf-mutator fuzzers.