Proposal: OSS-Fuzz integration for React Native native components

[rootvector2]

Introduction

I’ve been working on adding OSS-Fuzz integration for React Native’s native C++ components (ReactCommon layer).

A pull request has been opened in OSS-Fuzz:
google/oss-fuzz#15207

Details

The integration focuses on selected native modules, including:

• MapBuffer serialization/deserialization
• CSS tokenizer and value parsing components

The fuzzers are built using libFuzzer with AddressSanitizer and are designed to exercise parsing and memory handling paths.

The setup builds and runs successfully in the OSS-Fuzz environment.

Discussion points

• Does this scope (ReactCommon components) make sense for OSS-Fuzz integration?
• Are there any additional native components that would be good candidates for fuzzing?
• Any feedback or suggestions from maintainers before proceeding further?

Happy to adjust the integration based on maintainer feedback.

[rootvector2]

Could you please take a quick look at the project.yaml in the OSS-Fuzz PR (especially the primary_contact) and confirm it looks correct from your side?

https://github.com/google/oss-fuzz/pull/15207/changes#diff-cc9973772b4341ee8c85d54178ba77fd4da7a23f92a357895a9e444079eec753

If everything looks good, it would be great if you could leave a quick LGTM comment on the PR so we can proceed.

Thanks again!

[rootvector2]

Hey folks 👋

Just a quick follow-up — it’s been a while since I opened the OSS-Fuzz PR and shared the discussion, but I haven’t received any feedback yet.

Tagging for visibility:
@cipolleschi @cortinico @huntie @kelset @lunaleaps @blakef

When you get a moment, could you please:
• Take a quick look at the scope and project.yaml (especially primary_contact)
• If everything looks good, drop an LGTM on the OSS-Fuzz PR so we can proceed

Happy to make any changes if needed — just need your guidance to move this forward.

Thanks!

[cipolleschi]

Hi @rootvector2, thanks for opening this.
However, this RFC lacks a lot of details:

• context: what problems is this trying to solve?
• benefits: why are we doing it? how can this benefit react native?
• alternatives: have we evaluate other alternatives?
• maintenance model: who will maintain this code and tests? Where do they live? What happens if we make a breaking change in React Native?
• impact for the users: what will be the final impact for the final users? What will they see? Why should they care?

In general, for RFC on React or React Native, is more beneficial to reach out to the React team at Meta or to the React Foundation, before putting some effort into making some work that we might not be able to merge or use.

[rootvector2]

Hi @cipolleschi — thanks a lot for taking the time to look at this, really appreciate the direction.

You're right that the original write-up was light on the "why" and mostly described the "what". Let me try to fill in the gaps you raised:

Context / problem being solved

The native C++ surface in ReactCommon (MapBuffer serialization, CSS tokenizer/value parsing, etc.) handles untrusted/structured input at runtime — exactly the kind of code path where parser bugs, OOB reads, or memory corruption tend to hide. Today there's no continuous fuzzing coverage for these components, so issues only surface when someone hits them in the wild. OSS-Fuzz gives us a free, always-on harness for that class of bug.

Benefits to React Native

• Continuous coverage of parser/serializer code with ASan + libFuzzer, free of charge via Google's OSS-Fuzz infrastructure.
• Automatic regression tracking + a private 90-day disclosure window for any crash found, so security issues get triaged before they're public.
• Coverage reports and corpus accumulate over time, so even non-security bugs (correctness, perf cliffs, infinite loops) tend to surface earlier.

Alternatives considered

• Keeping fuzzing in-tree only (e.g. as part of the existing CI). That works but is short-lived per run, doesn't accumulate corpus, and doesn't give us the disclosure pipeline.
• Running fuzzers locally / ad-hoc — fine for one-off investigation but not sustainable.
• OSS-Fuzz was the obvious fit here because it's already the standard for upstream C/C++ projects (libxml2, protobuf, folly, etc.) and the integration cost is small.

Maintenance model

This is the part I'd most like your guidance on. The way OSS-Fuzz typically works:

• The build script + Dockerfile + project.yaml live in the google/oss-fuzz repo (already in the open PR).
• The fuzz harnesses themselves are small (extern "C" int LLVMFuzzerTestOneInput(...)) and can either live in the OSS-Fuzz repo or be upstreamed into react-native itself — I'd lean towards upstreaming so they stay in sync with the API.
• On a breaking change in RN, the harness either compiles or it doesn't; if it doesn't, OSS-Fuzz pings the listed primary_contact and the fix is usually trivial (signature/header update).
• I'm happy to be listed as a maintainer / primary_contact for the integration itself, but for it to be sustainable long-term it really needs at least one auto-assignee from the RN side. Open to whatever model works for you.

Impact for end users

Indirect but real: fewer crashes / memory-corruption bugs reaching production apps, faster turnaround on security-class issues, and a clearer signal to the ecosystem that the native surface is being actively hardened. End users won't see anything new in the API — they should just see fewer of a certain class of bug over time.

---

On your last point — totally fair, and I should have done that first. I'll reach out to the React team at Meta / the React Foundation to make sure there's appetite on their side before pushing this further. If you have a recommended channel for that, I'd really appreciate the pointer.

Let me know what else you'd like me to expand on, and I can update the RFC body itself rather than keep it in the comment thread.

Thanks again!