Build pw_fuzzer FuzzTest targets for OSS-Fuzz (libFuzzer-compatibility mode) (#72573)

* [pw_fuzzer] Build FuzzTest targets in libFuzzer-compatibility mode for OSS-Fuzz

Wires pw_fuzzer / Google FuzzTest targets to build as libFuzzer-compatible
binaries so they can run on OSS-Fuzz (b/295961502).

- build/toolchain/pw_fuzzer: apply FUZZTEST_COMPATIBILITY_MODE=libfuzzer
  toolchain-wide and link the no-main libFuzzer runtime (fuzzer_no_main, resolved
  via clang -print-file-name, no hardcoded version); under oss_fuzz use the
  OSS-Fuzz-provided compiler + $CFLAGS instrumentation.
- build/config/compiler: do not link $LIB_FUZZING_ENGINE (carries its own main)
  for the chip_pw_fuzztest toolchain -- FuzzTest provides main and calls
  LLVMFuzzerRunDriver. Legacy chip_fuzz_target libFuzzer targets still link it.
- build/chip/fuzz_test.gni: drop the per-target compatibility-mode define; it must
  reach the FuzzTest library (compatibility_mode.cc), not only the harness TU.
- scripts/build: add gen_pw_fuzztest_oss_fuzz_wrappers.sh, which emits one OSS-Fuzz
  fuzz target per FUZZ_TEST case (mirrors oss-fuzz compile_fuzztests.sh).

* [pw_fuzzer] Gate libFuzzer-compatibility mode behind chip_pw_fuzz_libfuzzer_compat

Local pw-fuzztest builds keep FuzzTest's native engine by default; libFuzzer-compat
mode (FUZZTEST_COMPATIBILITY_MODE + no-main libFuzzer runtime) is now opt-in via
chip_pw_fuzz_libfuzzer_compat=true, and remains forced on under oss_fuzz for OSS-Fuzz.

* [pw_fuzzer] Disable UBSan vptr check for the FuzzTest toolchain

Pigweed modules compile with -fno-rtti, which is incompatible with UBSan's
-fsanitize=vptr (present in $CFLAGS under SANITIZER=undefined). Append -fno-sanitize=vptr
for the chip_pw_fuzztest toolchain only (legacy libFuzzer targets keep full UBSan). No-op
for non-undefined sanitizers.

* [pw_fuzzer] FuzzChipCert: tolerate a missing seed directory

The seed directory (credentials/test/operational-certificates-error-cases) ships in the
source tree but is absent in the OSS-Fuzz runner, which runs fuzzers from a temp dir without
the build tree (check_build does this deliberately). ReadFilesFromDirectory aborts on a
missing dir, so guard it with std::filesystem::is_directory and run without file seeds when
absent. On OSS-Fuzz the seeds are supplied via <target>_seed_corpus.zip instead.

* [pw_fuzzer] build_examples: add 'compat' modifier for libFuzzer mode

Adds a 'compat' build_examples modifier (valid only with -pw-fuzztest) that sets
chip_pw_fuzz_libfuzzer_compat=true, so e.g. linux-x64-tests-clang-pw-fuzztest-compat builds
the FuzzTest targets locally in libFuzzer-compatibility mode (default remains native
FuzzTest). Verified: the target gens with pw_enable_fuzz_test_targets=true and
chip_pw_fuzz_libfuzzer_compat=true.

* [pw_fuzzer] Add local ASan options config for FuzzTest builds

Layers extra ASan options on the chip_pw_fuzztest toolchain's base -fsanitize=address for
local (non-oss_fuzz) builds: -fsanitize-address-use-after-return=always and
-fsanitize-address-use-after-scope. Only build-activated options (no runtime ASAN_OPTIONS) are
included; pointer-compare/pointer-subtract are intentionally omitted as they require
ASAN_OPTIONS=detect_invalid_pointer_pairs=2. Under OSS-Fuzz the engine's $CFLAGS own the
sanitizer flags, so this applies to local builds only.

* [pw_fuzzer] Support ASan+UBSan for local FuzzTest builds (-pw-fuzztest-ubsan)

The 'ubsan' build_examples modifier on a -pw-fuzztest target now adds UBSan alongside the
default ASan: host.py sets chip_pw_fuzz_ubsan=true, and the chip_pw_fuzztest toolchain layers
a fuzztest_ubsan config (-fsanitize=undefined -fno-sanitize=vptr -fno-sanitize-recover=undefined)
on local builds. vptr is disabled because pigweed builds -fno-rtti; -fno-sanitize-recover makes
UB fatal so libFuzzer records it. Composes with 'compat' (-pw-fuzztest-compat-ubsan). OSS-Fuzz
is unaffected (it drives sanitizers via $CFLAGS). Verified: tlv target builds + links clean
with address+undefined, no vptr conflict.

* [pw_fuzzer] Quiet defined-behavior UBSan noise; drop redundant use-after-scope

fuzztest_ubsan: disable -fsanitize=unsigned-integer-overflow and unsigned-shift-base --
these are DEFINED behavior (not UB) and fire constantly on intentional wraps (e.g. abseil's
PRNG in low_level_alloc.cc), which is pure noise for fuzzing. Verified the abseil report is gone.
fuzztest_asan_options: drop -fsanitize-address-use-after-scope, which is ASan-default-on in
modern clang (redundant); keep -fsanitize-address-use-after-return=always (a real, no-env knob).

* [build] Add UBSan ignorelist for vendored/stdlib false positives

The sanitize_undefined_behavior config enables opt-in checks beyond
-fsanitize=undefined (unsigned-integer-overflow, implicit-conversion,
nullability) that are not themselves undefined behavior. Vendored libraries
(abseil, fuzztest) and libc++ internals rely on defined unsigned modular
arithmetic and narrowing, so they trip these checks as false positives; under
-fno-sanitize-recover (the OSS-Fuzz UBSan engine) each report becomes a bogus
crash.

Add build/config/compiler/ubsan_ignorelist.txt to exclude the vendored and
stdlib code we do not own (matched by src:* so header code inlined into
first-party TUs is covered too), wired in via -fsanitize-ignorelist=.
First-party src/ stays fully instrumented.

* [pw_fuzzer] Resolve FuzzTest compiler via pw_toolchain_clang_tools

Resolve the compiler used to locate the libFuzzer runtime archive
(libclang_rt.fuzzer_no_main.a) via pw_toolchain_clang_tools.cxx -- the same
clang++ the chip_pw_fuzztest toolchain actually compiles with -- instead of
hardcoding //.environment/cipd/packages/pigweed/bin/clang++.

The hardcoded path silently breaks if pigweed/CIPD relocate clang; the pigweed
variable tracks the CIPD location and any pw_toolchain_CLANG_PREFIX override.
Both spellings resolve the identical archive today, so the build is unchanged.

* [pw_fuzzer] Drop redundant FuzzTest ASan/UBSan flags covered by global configs

The chip_pw_fuzztest toolchain inherits chip's global sanitizer configs, so
several local additions were redundant:

- Remove fuzztest_asan_options entirely. Its only flag,
  -fsanitize-address-use-after-return=always, is redundant: modern clang detects
  stack-use-after-return by default (mode=runtime + detect_stack_use_after_return=1),
  no ASAN_OPTIONS needed.

- Slim fuzztest_ubsan to the fuzzing-specific deltas. The global
  sanitize_undefined_behavior config reaches this toolchain via is_ubsan and already
  supplies -fsanitize=undefined, the ubsan ignorelist, and (for -fno-rtti)
  -fno-sanitize=vptr, so drop those duplicates. Keep -fno-sanitize-recover=undefined
  (make UB abort so FuzzTest records it as a crash rather than recovering) and the
  unsigned-overflow/shift noise suppressions (defined behavior, not UB; the ignorelist
  only covers vendored/stdlib, not first-party code).

No effective change to a fuzztest TU's flags beyond dropping the redundant
-fsanitize-address-use-after-return=always; stack-use-after-return is still detected
via the compiler default.

* [pw_fuzzer] Trim verbose/redundant toolchain comments

Comment-only cleanup of the pw_fuzzer toolchain: tighten the libFuzzer-compat
and sanitizer comments, drop the toolchain_args comment that just restated the
section header, and remove external references (Buganizer ticket, pigweed
discord link, FuzzTest CMake pointer). No build behavior change.

* Remove unneeded comments

* [pw_fuzzer] Fix CI: executable bit, build_examples golden, shellharden

- Make build/toolchain/pw_fuzzer/print_file_name.py executable (flake8 EXE001:
  shebang present but file not executable).
- Regenerate scripts/build/testdata/all_targets_linux_x64.txt for the new `compat`
  modifier (build_examples test_linux64_targets).
- shellharden: drop unneeded braces in gen_pw_fuzztest_oss_fuzz_wrappers.sh.

* [pw_fuzzer] Address review feedback: $OUT/bin wrapper layout, error_code, $CXX

- gen_pw_fuzztest_oss_fuzz_wrappers.sh: place the shared FuzzTest binary in
  $OUT/bin/ (OSS-Fuzz scans only the root of $OUT for fuzz targets) and exec it
  directly, dropping the chmod -x/+x toggling that fails on read-only mounts.
- FuzzChipCertPW.cpp: use the non-throwing std::filesystem::is_directory(path, ec)
  overload so a permission/I/O error cannot abort the harness (exceptions off).
- print_file_name.py: shlex-split the compiler and catch exec failures, so a $CXX
  with a launcher or flags (e.g. ccache clang++) works and failures print a clean
  error instead of a Python traceback.

* [pw_fuzzer] Document compat/ubsan modifiers and OSS-Fuzz integration in BUILDING.md

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

* [pw_fuzzer] CI: build FuzzTests in compat mode in the Linux build workflow

* [pw_fuzzer] Keep shared FuzzTest binary in $OUT root (revert $OUT/bin layout)

OSS-Fuzz check_build copies the root-level fuzz targets into an isolated dir
and runs each; a $OUT/bin/ subdirectory is not copied alongside the wrappers,
so every wrapper's shared binary resolved to "No such file" and ~80% of
targets were reported broken.

Keep the shared binary in $OUT root, non-executable, with the wrappers doing
chmod +x at runtime -- the exact layout OSS-Fuzz's own compile_fuzztests.sh
uses (check_build copies root-level files, and the run dir is writable). The
error_code and print_file_name $CXX-splitting review fixes are unaffected.

* [pw_fuzzer] Rename pw-fuzztest libFuzzer-compat modifier: -compat -> -ossfuzz

Reviewer feedback: `-compat` was too vague. Repurpose the vestigial `ossfuzz`
build_examples modifier -- it set oss_fuzz=true but had no consumers (the
OSS-Fuzz automation drives oss_fuzz=true from its own build.sh; nothing invoked
the modifier) -- to denote pw-fuzztest's libFuzzer-compatibility build:

- `ossfuzz` now sets chip_pw_fuzz_libfuzzer_compat=true, scoped to -pw-fuzztest;
  drop the now-redundant `compat` modifier.
- Let pw-fuzztest + ossfuzz combine (drop ossfuzz from pw-fuzztest's exclusion).
- Remove the now-unused HostFuzzingType.OSS_FUZZ and its oss_fuzz=true branch.
- Update BUILDING.md, the golden target list, and the CI step.

Local target is now linux-x64-tests-clang-pw-fuzztest-ossfuzz (composes with
-ubsan/-coverage). Keeping the engine as a modifier leaves room for a future
-centipede sibling without new base targets.

* [pre-commit.ci] auto fixes from pre-commit.com hooks

for more information, see https://pre-commit.ci

---------

Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com>
11 files changed
tree: 6ac8d515f655b5065671ddf343786316a92b465c
  1. .agents/
  2. .claude/
  3. .devcontainer/
  4. .gemini/
  5. .githooks/
  6. .github/
  7. .vscode/
  8. build/
  9. build_overrides/
  10. config/
  11. credentials/
  12. data_model/
  13. docs/
  14. examples/
  15. integrations/
  16. scripts/
  17. src/
  18. third_party/
  19. zzz_generated/
  20. .actrc
  21. .clang-format
  22. .clang-tidy
  23. .default-version.min
  24. .dir-locals.el
  25. .editorconfig
  26. .gitattributes
  27. .gitignore
  28. .gitmodules
  29. .gn
  30. .matterlint
  31. .mergify.yml
  32. .pre-commit-config.yaml
  33. .prettierrc.json
  34. .pullapprove.yml
  35. .restyled.yaml
  36. .shellcheck_tree
  37. .spellcheck.yml
  38. AGENTS.md
  39. BUILD.gn
  40. CODE_OF_CONDUCT.md
  41. CODEOWNERS
  42. CONTRIBUTING.md
  43. GEMINI.md
  44. gn_build.sh
  45. iwyu.imp
  46. kotlin-detect-config.yaml
  47. lgtm.yml
  48. LICENSE
  49. NOTICE
  50. pigweed.json
  51. pyproject.toml
  52. README.md
  53. REVIEWERS.md
  54. SECURITY.md
  55. SPECIFICATION_VERSION
README.md

Documentation links

Matter

Builds

Builds

Android Ameba ASR BouffaloLab Darwin TI CC26X2X7 TI CC32XX EFR32 ESP32 Infineon i.MX Linux NXP FreeRTOS/Zephyr Linux ARM Linux Standalone nRF Connect SDK QPG STM32 Telink Tizen

Tests

Tests-Master Tests-LTS Unit / Integration Tests Cirque QEMU Nightly Run

Tools

ZAP Templates

Documentation

Documentation Build

About

Matter (formerly Project CHIP) creates more connections between more objects, simplifying development for manufacturers and increasing compatibility for consumers, guided by the Connectivity Standards Alliance.

What is Matter?

Matter is a unified, open-source application-layer connectivity standard built to enable developers and device manufacturers to connect and build reliable, and secure ecosystems and increase compatibility among connected home devices. It is built with market-proven technologies using Internet Protocol (IP) and is compatible with Thread and Wi-Fi network transports. Matter was developed by a Working Group within the Connectivity Standards Alliance (Alliance). This Working Group develops and promotes the adoption of the Matter standard, a royalty-free connectivity standard to increase compatibility among smart home products, with security as a fundamental design tenet. The vision that led major industry players to come together to build Matter is that smart connectivity should be simple, reliable, and interoperable.

Matter simplifies development for manufacturers and increases compatibility for consumers.

The standard was built around a shared belief that smart home devices should be secure, reliable, and seamless to use. By building upon Internet Protocol (IP), Matter enables communication across smart home devices, mobile apps, and cloud services and defines a specific set of IP-based networking technologies for device certification.

The Matter specification details everything necessary to implement a Matter application and transport layer stack. It is intended to be used by implementers as a complete specification.

The Alliance officially opened the Matter Working Group on January 17, 2020, and the specification is available for adoption now.

Visit buildwithmatter.com to learn more and read the latest news and updates about the project.

Project Overview

Development Goals

Matter is developed with the following goals and principles in mind:

Unifying: Matter is built with and on top of market-tested, existing technologies.

Interoperable: The specification permits communication between any Matter-certified device, subject to users’ permission.

Secure: The specification leverages modern security practices and protocols.

User Control: The end user controls authorization for interaction with devices.

Federated: No single entity serves as a throttle or a single point of failure for root of trust.

Robust: The set of protocols specifies a complete lifecycle of a device — starting with the seamless out-of-box experience, through operational protocols, to device and system management specifications required for proper function in the presence of change.

Low Overhead: The protocols are practically implementable on low compute-resource devices, such as MCUs.

Pervasive: The protocols are broadly deployable and accessible, by leveraging IP and being implementable on low-capability devices.

Ecosystem-Flexible: The protocol is flexible enough to accommodate deployment in ecosystems with differing policies.

Easy to Use: The protocol provides smooth, cohesive, integrated provisioning and out-of-box experience.

Open: The Project’s design and technical processes are open and transparent to the general public, including non-members wherever possible.

Architecture Overview

Matter aims to build a universal IPv6-based communication protocol for smart home devices. The protocol defines the application layer that will be deployed on devices and the different link layers to help maintain interoperability. The following diagram illustrates the normal operational mode of the stack: Matter Architecture Overview

The architecture is divided into layers to help separate the different responsibilities and introduce a good level of encapsulation among the various pieces of the protocol stack. The vast majority of interactions flow through the stack captured in the following Figure:

Matter Stack Architecture

  1. Application: High-order business logic of a device. For example, an application that is focused on lighting might contain logic to handle turning on/off the bulb as well as its color characteristics.
  1. Data Model: The data layer corresponds to the data and verb elements that help support the functionality of the application. The Application operates on these data structures when there is an intent to interact with the device.
  1. Interaction Model: The Interaction Model layer defines a set of interactions that can be performed between a client and server device. For example, reading or writing attributes on a server device would correspond to application behavior on the device. These interactions operate on the elements defined at the data model layer.
  1. Action Framing: Once an action is constructed using the Interaction Model, it is serialized into a prescribed packed binary format to encode for network transmission.
  1. Security: An encoded action frame is then sent down to the Security Layer to encrypt and sign the payload to ensure that data is secured and authenticated by both sender and receiver of a packet.

  2. Message Framing & Routing: With an interaction encrypted and signed, the Message Layer constructs the payload format with required and optional header fields; which specify the message's properties and some routing information.

  1. IP Framing & Transport Management: After the final payload has been constructed, it is sent to the underlying transport protocol for IP management of the data.

Current Status of Matter

Matter’s design and technical processes are intended to be open and transparent to the general public, including to Working Group non-members wherever possible. The availability of this GitHub repository and its source code under an Apache v2 license is an important and demonstrable step to achieving this commitment. Matter endeavors to bring together the best aspects of market-tested technologies and redeploy them as a unified and cohesive whole-system solution. The overall goal of this approach is to bring the benefits of Matter to consumers and manufacturers as quickly as possible. As a result, what you observe in this repository is an implementation-first approach to the technical specification, vetting integrations in practice. The Matter repository is growing and evolving to implement the overall architecture. The repository currently contains the security foundations, message framing and dispatch, and an implementation of the interaction model and data model. The code examples show simple interactions, and are supported on multiple transports -- Wi-Fi and Thread -- starting with resource-constrained (i.e., memory, processing) silicon platforms to help ensure Matter’s scalability.

How to Contribute

We welcome your contributions to Matter. Read our contribution guidelines here.

Building and Developing in Matter

Instructions about how to build Matter can be found here .

Directory Structure

The Matter repository is structured as follows:

File/FolderContent
buildBuild system support content and built output directories
build_overridesBuild system parameter customization for different platforms
configProject configurations
credentialsDevelopment and test credentials
docsDocumentation, including guides. Visit the Matter SDK documentation page to read it.
examplesExample firmware applications that demonstrate use of Matter
integrations3rd party integrations
scriptsScripts needed to work with the Matter repository
srcImplementation of Matter
third_party3rd party code used by Matter
zzz_generatedZAP generated template code - Revolving around cluster information
BUILD.gnBuild file for the GN build system
CODE_OF_CONDUCT.mdCode of conduct for Matter and contribution to it
CONTRIBUTING.mdGuidelines for contributing to Matter
LICENSEMatter license file
REVIEWERS.mdPR reviewers
gn_build.shBuild script for specific projects such as Android, EFR32, etc.
README.mdThis file

License

Matter is released under the Apache 2.0 license.