0sec-cli 0.15.0 → 0.18.0

package/chunks/data/chromium-archetypes.json

@@ -0,0 +1,204 @@
+{
+  "provenance": "0sec-authored (NOT ported from 0verse — 0verse's archetypes.json is Linux-kernel-only, no browser registry exists). Grounded in public Chrome VRP writeups, Project Zero, v8CTF blogs, and CVE/NVD entries, several confirmed by fetching the writeup text directly, 2026-07-05. IMPORTANT HONEST CAVEAT: unlike the Linux kernel pack, this repo has NO Chromium build lane (no `out/Release` compile, no ASan/libFuzzer harness, no v8CTF live-instance submit path) today — every archetype below is SOURCE-STATIC ONLY: a grep/read hit is a hypothesis for human/skeptic review, never a proven-confirmable claim, and several entries below explicitly flag where the cited symbol name comes from a third-party writeup rather than an independently-verified read of chromium/v8 source (no local checkout existed at authoring time). Chromium/V8 C++ identifiers are PascalCase/camelCase, NOT snake_case like Linux/FreeBSD kernel C — see CHROMIUM_BARE_WORDS in archetype-catalog.ts; without it `symbolsFromDetectionSignature`'s underscore heuristic would yield zero candidates for nearly every entry here.",
+  "archetypes": [
+    {
+      "id": "V8-01",
+      "name": "TurboFan/Maglev speculative type confusion via an eliminated or unsound Map check",
+      "cwe": "CWE-843",
+      "subsystem": "v8/src/compiler (TurboFan), v8/src/maglev (Maglev) — JIT type feedback and redundancy elimination",
+      "pattern": "TurboFan/Maglev speculatively compiles JS assuming an object's Map (hidden class) and elements-kind stay unchanged for the rest of the compiled function, guarded by a CheckMap/CheckMaps node. A node that DOES mutate the Map or elements-kind (a transition, a species/prototype-triggered side effect, a call into user code) is mislabeled as side-effect-free, or its aliasing with an already-checked value is inferred unsoundly — so the compiler's redundancy-elimination pass removes the CheckMap that would have caught the runtime mismatch. Generated machine code then treats a value of one shape (e.g. a dictionary-mode object, a double-elements array) as if it still had the shape assumed at compile time, corrupting memory the moment the two disagree.",
+      "detection_signature": "Grep for `TurboFan`, `Maglev`, `CheckMap`, `TransitionElementsKind`, `InferMaps`, `JSCallReducer`, `KeyedStoreIC` (all real V8 compiler identifiers, PascalCase/camelCase — no underscores, needs CHROMIUM_BARE_WORDS). Real shape: a compiler-reducer function that infers/propagates a Map for a node without re-validating it after a node the reducer's side-effect model calls read-only (`kNoWrite`) but that actually installs a new Map (e.g. `Object.create`, an elements-kind transition, a keyed store's IC handler) — the tell is a `CheckMap`/`CheckMaps` node that a later pass proves 'redundant' against an earlier check separated by such a node.",
+      "grounding": [
+        "CVE-2025-2135 (V8CTF first-blood, zero-day found via fuzzing: TurboFan's InferMapsUnsafe() fails to handle aliasing across the newly-introduced TransitionElementsKindOrCheckMap node, confusing object-elements and double-elements arrays for arbitrary R/W within the V8 sandbox; verified via Zellic writeup https://www.zellic.io/blog/pwning-v8ctf/)",
+        "CVE-2018-17463 (V8's CreateObject operator was tagged Operator::kNoWrite instead of kNoProperties even though Object.create() forces a FastProperties->DictionaryProperties Map transition; TurboFan's redundancy pass then eliminated the subsequent CheckMap, letting compiled code treat a NameDictionary as a FixedArray — type confusion chained to addrOf/fakeObj via WebAssembly memory corruption; verified via jhalon.github.io writeup)",
+        "CVE-2023-3079 (type confusion in KeyedStoreIC::StoreElementHandler()'s fast-path handler selection — reported as an in-the-wild V8 0-day, exact handler-selection root cause per public gist analysis, no full Google RCA published at authoring time)"
+      ],
+      "confirmable": "Plausible by source inspection when the reducer/side-effect-model mismatch is directly visible (as in CVE-2018-17463's kNoWrite mislabel), but CONFIRMING that a given CheckMap elimination is unsound in general requires tracing the specific reducer's proof obligations and often a compiled-output diff — genuinely hard without a build. No V8-build/fuzz lane exists in this repo; treat every hit as a hypothesis for a human V8-compiler-literate reviewer, not an auto-confirmed finding.",
+      "domain": "chromium",
+      "uid": "chromium/V8-01",
+      "engine_lens": null,
+      "route": "source-static"
+    },
+    {
+      "id": "V8-02",
+      "name": "Maglev class-literal / prototype-chain compilation OOB",
+      "cwe": "CWE-787",
+      "subsystem": "v8/src/maglev (class heritage / FastNewObject compilation path)",
+      "pattern": "When Maglev compiles a class declaration with a parent class (`class B extends A`), it must walk the full prototype/constructor chain to size and lay out the resulting object and its property backing store. A miscount in that walk (e.g. an off-by-one in how many ancestor constructors' own-property slots get reserved, or a stale cached count reused across an inline cache) produces a JIT-compiled fast path that writes past the object it just allocated.",
+      "detection_signature": "Grep for `Maglev`, `BuildClassLiteral`, `ClassBoilerplate`, `FastNewObject` (PascalCase, no underscores — needs CHROMIUM_BARE_WORDS). Real shape: a Maglev builder function for class-literal compilation that computes an allocation size or property-slot count from a parent-class chain walk, where the size feeding the actual write does not match the size used for the allocation.",
+      "grounding": [
+        "CVE-2024-0517 (Chrome <120.0.6099.224: Maglev out-of-bounds write when compiling a class that has a parent class; publicly analyzed by Exodus Intelligence and multiple independent writeups, no single canonical Google RCA found in this pass)"
+      ],
+      "confirmable": "The size-mismatch shape is describable but confirming it requires reproducing Maglev's exact allocation-vs-write size computation for a given class shape — effectively requires reading (or stepping through) the Maglev builder itself. No build lane exists in this repo; route to a human V8-internals reviewer, do not auto-confirm from a grep hit alone.",
+      "domain": "chromium",
+      "uid": "chromium/V8-02",
+      "engine_lens": null,
+      "route": "source-static"
+    },
+    {
+      "id": "V8-03",
+      "name": "JSTypedArray/ArrayBuffer OOB via a callback- or getter-triggered backing-store change mid-builtin",
+      "cwe": "CWE-416 / CWE-125 / CWE-787",
+      "subsystem": "v8/src/builtins, v8/src/objects (JSTypedArray, ArrayBuffer, BackingStore) — any builtin that iterates a typed array/array-buffer view while user JS can run mid-iteration",
+      "pattern": "A builtin (Array.prototype method, TypedArray method, a DataView read/write, a species-constructor path) caches a TypedArray's/ArrayBuffer's length or backing-store pointer once at entry, then calls back into user JS during iteration (a getter, `valueOf`, `Symbol.species`, a comparator) that can shrink, detach, or resize (`ArrayBuffer.prototype.resize`/`transfer`) the underlying store. The builtin resumes iterating against the STALE cached length/pointer, reading or writing memory that either no longer belongs to the buffer or has moved (GC-relocated) — an OOB read/write or a use-after-free of the freed backing store.",
+      "detection_signature": "Grep for `JSTypedArray`, `BackingStore`, `ArrayBufferView`, `Detach` (PascalCase — needs CHROMIUM_BARE_WORDS; `byte_length` is the one snake_case exception, matched by the default heuristic). Real shape: a builtin/runtime function that reads `byte_length()`/`backing_store()`/`elements()` ONCE before a loop or before invoking a user-supplied callback (getter, valueOf, compare function, species constructor), then keeps using that cached value/pointer for the rest of the function without re-validating it after the callback returns.",
+      "grounding": [
+        "CVE-2016-1646 (V8 Slow_ArrayConcat: iterating a FAST_HOLEY_ELEMENTS array with a custom Object.defineProperty getter — the getter shrinks the array and forces a GC that moves the backing store; concat continues with the stale offset, producing an OOB read used to leak heap pointers and build a fake ArrayBuffer; verified via 4B5F5F4B/Exploits writeup)",
+        "Documented as a recurring V8 bug-class family in Project Zero's 'Trashing the Flow of Data' (googleprojectzero.blogspot.com/2019/05) and multiple *CTF oob-v8 writeups (faraz.faith, starctf 2019) — cited as pattern corroboration; no single additional Chromium CVE number was independently pinned to the literal `ArrayBuffer.prototype.transfer()`/detach-during-callback shape in this research pass, marked honestly."
+      ],
+      "confirmable": "The 'cache-then-callback-then-reuse' shape is grep-visible once the callback site is identified, but confirming actual OOB impact requires tracing whether the cached value is truly re-read afterward (many call sites correctly re-fetch it) — a real false-positive risk. No V8 execution/fuzz lane exists in this repo; treat as a hypothesis.",
+      "domain": "chromium",
+      "uid": "chromium/V8-03",
+      "engine_lens": null,
+      "route": "source-static"
+    },
+    {
+      "id": "V8-04",
+      "name": "V8 GC/handle-scope lifetime bug: a reachable object incorrectly collected, or a v8::Local escapes its HandleScope",
+      "cwe": "CWE-416",
+      "subsystem": "v8/src/handles (v8::Local, v8::HandleScope, v8::Persistent), v8/src/heap (garbage collector reachability analysis)",
+      "pattern": "Two related lifetime failure shapes: (1) a bug in the garbage collector's own reachability/marking logic causes it to collect an object that is still reachable from a live root, so any embedder or engine code still holding a reference (a v8::Local<>, an internal Handle<>) now points at freed/reused memory; (2) an embedder holds a v8::Local<> past the lifetime of the v8::HandleScope that created it (returning it directly instead of through an v8::EscapableHandleScope::Escape), or stores a raw v8::Local in a place that outlives the current callback frame — either way, a stale handle is dereferenced after V8 has moved on.",
+      "detection_signature": "Grep for `v8::`, `Handle<`, `Local<`, `HandleScope`, `EscapableHandleScope`, `Persistent<` (PascalCase/namespaced — needs CHROMIUM_BARE_WORDS). Real shape for (1): a GC marking-visitor change or write-barrier omission that lets a root-reachable object be swept anyway. Real shape for (2): an embedder/native (Blink/V8-API-consumer) function that returns or stashes a `v8::Local<T>` obtained inside a `v8::HandleScope` without routing it through an `EscapableHandleScope`, or that keeps a `v8::Local` alive across a call that can trigger GC.",
+      "grounding": [
+        "CVE-2021-37975 (in-the-wild V8 0-day: a logic bug in the garbage collector's implementation let reachable JS objects be collected anyway, producing an arbitrary-object UAF; verified via the GitHub Security Lab / Project Zero 0days-in-the-wild RCA)"
+      ],
+      "confirmable": "GC-reachability bugs (shape 1) are effectively unconfirmable by source-static reading alone — they require deep, bug-specific GC-algorithm reasoning that historically only Google's own engineers and a handful of external researchers have done per-bug. The escaped-handle shape (2) is more directly grep/read-confirmable (a `v8::Local` returned or stored without an EscapableHandleScope is visible in the function body), but still needs a human to confirm the value is actually used post-escape. No dynamic V8 oracle exists in this repo; every hit here is a hypothesis.",
+      "domain": "chromium",
+      "uid": "chromium/V8-04",
+      "engine_lens": null,
+      "route": "source-static"
+    },
+    {
+      "id": "BLINK-01",
+      "name": "Oilpan use-after-free via a raw C++ pointer to a GarbageCollected object",
+      "cwe": "CWE-416",
+      "subsystem": "third_party/blink/renderer/platform/heap (Oilpan) and any Blink class deriving from GarbageCollected<T>",
+      "pattern": "A class managed by Blink's Oilpan GC (derives from `GarbageCollected<T>`) is referenced from another on-heap object, a stack frame that outlives a single task, or a callback closure via a bare C++ raw pointer (`T*`) instead of `Member<T>`/`WeakMember<T>`/`Persistent<T>`. Oilpan's tracing GC only follows `Member`/`WeakMember`/`Persistent` edges to determine liveness — a raw pointer is INVISIBLE to the collector, so the referenced object can be collected out from under the pointer the moment nothing Oilpan-visible still holds it, and the next dereference is a use-after-free.",
+      "detection_signature": "Grep for `GarbageCollected`, `MakeGarbageCollected`, `Member<`, `WeakMember<`, `Persistent<` (PascalCase, no underscores — needs CHROMIUM_BARE_WORDS). Real shape: a class deriving from `GarbageCollected<T>` (or a member/field of one) stored as a raw `T*` in another Oilpan-managed class, a `base::RepeatingCallback`/`base::OnceCallback` closure, or any structure that can outlive the current GC-safepoint-free region, instead of being wrapped in `Member<T>` (strong on-heap reference) or `WeakMember<T>` (weak, nulled on collection).",
+      "grounding": [
+        "CVE-2026-13965 (Chrome 150.0.7871.47, fixed 2026-06-30: use-after-free in Chromium's Oilpan garbage collector reachable via a crafted HTML page; per Windows Forum advisory summary, exact raw-pointer-vs-Member root cause not independently re-derived from source in this pass)",
+        "Design-doc corroboration: Blink's own Oilpan documentation (chromium.googlesource.com BlinkGCAPIReference.md / cppgc README) states plainly that 'raw pointers to on-heap objects create an edge Oilpan cannot observe' and are disallowed except on the native stack — i.e. this is a documented, standing footgun class, not a one-off."
+      ],
+      "confirmable": "Plausible by source inspection — a raw `T*` field/variable holding a `GarbageCollected` type where `Member<>`/`WeakMember<>`/`Persistent<>` would be expected is directly visible once the class hierarchy is known. False-positive risk: a raw pointer confined entirely to the native C++ stack within a single non-reentrant function is Oilpan-legal (see the design doc) — a hit needs a human to check the pointer doesn't cross a safepoint or outlive its stack frame. No Blink build/ASan lane exists in this repo.",
+      "domain": "chromium",
+      "uid": "chromium/BLINK-01",
+      "engine_lens": null,
+      "route": "source-static"
+    },
+    {
+      "id": "BLINK-02",
+      "name": "Script-reentrancy use-after-free: a JS callout frees/detaches the object a C++ frame still holds",
+      "cwe": "CWE-416 / CWE-367",
+      "subsystem": "third_party/blink/renderer/core (event dispatch, promise/microtask callbacks, media/DOM attribute getters-setters that can run author JS)",
+      "pattern": "Blink C++ code holds a raw pointer/iterator into a DOM node, an observer list, or another on-heap structure, then calls out into author-controlled JavaScript (dispatching an event, resolving a promise, invoking a getter/setter defined via a JS Proxy or a custom element callback). The JS callback reenters Blink and — directly or via a chain of other callbacks — removes/detaches/frees the very object or list the C++ frame is still iterating or referencing, so control returns to C++ holding a dangling reference.",
+      "detection_signature": "Grep for `GetExecutionContext`, `ScriptState`, `MakeGarbageCollected` (needs CHROMIUM_BARE_WORDS) alongside a loop or held reference over an observer/listener list or DOM structure that a same-function call into script (event dispatch, a V8 callback invocation, a promise `Then()`) can mutate. Real shape: a `for` loop over an observer/child list that calls a listener/callback mid-iteration without having first snapshotted the list or re-validated its iterator afterward.",
+      "grounding": [
+        "Documented bug-class pattern from Blink's own engineering notes (platform-architecture-dev mailing list: 'invoking a callback might modify observers and invalidate the for loop's iterator') and multiple historical exploit-db/skylined.nl UAF writeups in Blink event/media code (e.g. PresentationAvailabilityState::UpdateAvailability, SpeechRecognitionController) — no single current (2024-2026) CVE number was independently pinned to this exact shape in this research pass; HONEST GAP flagged rather than a fabricated citation.",
+        "Cross-domain analog for the general 'callback reenters and mutates state the caller still references' shape: CVE-2016-1646 (V8 Slow_ArrayConcat, see chromium/V8-03) — same reentrancy root pattern, different subsystem."
+      ],
+      "confirmable": "Requires tracing every call-into-script site against every structure it can reach and mutate — high recall, low precision by grep alone (Blink calls into script constantly; most call sites are already hardened with snapshot-then-iterate or Member<>/WeakMember<> references). Treat any hit as a weak hypothesis requiring careful manual reachability analysis; no dynamic Blink oracle exists in this repo.",
+      "domain": "chromium",
+      "uid": "chromium/BLINK-02",
+      "engine_lens": null,
+      "route": "source-static"
+    },
+    {
+      "id": "BLINK-03",
+      "name": "Missing Trace() registration -> Oilpan under-traces a reachable field -> premature collection",
+      "cwe": "CWE-416",
+      "subsystem": "third_party/blink/renderer/platform/heap (Oilpan tracing contract: every GarbageCollected class must implement/extend Trace())",
+      "pattern": "A `GarbageCollected<T>` class holds one or more `Member<>`/`WeakMember<>` fields but its `Trace(Visitor*)` method fails to call `visitor->Trace(field)` for one of them (a new field added without updating Trace(), or a field forwarded through a base-class Trace() that was not itself updated). Oilpan's mark phase never visits that edge, so the referenced object looks unreachable and gets collected even though a live `Member<>` still points at it — the next access through that field is a use-after-free.",
+      "detection_signature": "Grep for `Trace(`, `GarbageCollectedMixin`, `MakeGarbageCollected` (needs CHROMIUM_BARE_WORDS). Real shape: a class with one or more `Member<T>`/`WeakMember<T>`/`HeapVector<Member<T>>` fields whose `Trace()` override does not visit every such field (cross-check the field list in the class body against the `visitor->Trace(...)` calls in its `Trace()` method, including any base class's `Trace()` it must chain to via `Base::Trace(visitor)`).",
+      "grounding": [
+        "Documented as one of Oilpan's canonical, named pitfalls in Blink's own 'Oilpan 101: Basics, Common Pitfalls' engineering slide deck (docs.google.com presentation referenced from chromium.googlesource.com Oilpan docs) — a standing, named footgun class rather than a single CVE-pinned bug. NO specific CVE number was found/verified for a concrete instance in this research pass; marked honestly as a documented-pattern archetype, not CVE-grounded."
+      ],
+      "confirmable": "Directly checkable by source inspection: enumerate a class's Member<>/WeakMember<> fields and diff against its Trace() body's visitor->Trace() calls — a purely mechanical, high-precision check once the class's full field list and Trace() override (including inherited chains) are both in view. The main risk is missing an inherited Trace() in a base class defined in a different file. No dynamic confirmation lane exists in this repo, but this archetype is closer to 'confirmable by careful reading' than most others here.",
+      "domain": "chromium",
+      "uid": "chromium/BLINK-03",
+      "engine_lens": null,
+      "route": "source-static"
+    },
+    {
+      "id": "MOJO-01",
+      "name": "Missing/insufficient bounds validation in generated Deserialize()/StructTraits::Read()",
+      "cwe": "CWE-787 / CWE-20",
+      "subsystem": "mojo/public/cpp/bindings (generated .mojom bindings: StructTraits<>::Read, ArrayDataView/StringDataView readers), any browser-process interface implementation that consumes renderer-supplied structs",
+      "pattern": "A `.mojom`-generated `StructTraits<MojomDataViewType, T>::Read()` (or a hand-written override of it) copies a size, count, or offset field out of the wire-format `DataView` and uses it to size a browser-side buffer or index into an existing one, without validating it against the actual received payload length or an application-level bound. Because the renderer process is untrusted (Mojo's own security model: 'validate all messages from a less-privileged process'), a compromised or malicious renderer can supply an oversized/negative/inconsistent field, and the browser-process deserializer writes out of bounds trusting it.",
+      "detection_signature": "Grep for `Deserialize`, `StructTraits`, `ArrayDataView`, `DataView` (PascalCase — needs CHROMIUM_BARE_WORDS). Real shape: a `Read()`/`Deserialize()` implementation that reads a length/count/index field from the incoming `DataView` and uses it directly in a `memcpy`, buffer allocation, or array index in the PRIVILEGED (browser/GPU) process, without a preceding range check against the view's actual `size()`/against an application-defined maximum.",
+      "grounding": [
+        "CVE-2024-9369 (Chrome <129.0.6668.89: insufficient data validation in Mojo — a renderer that has already compromised its own process can send a crafted message that triggers an out-of-bounds write in a higher-privileged process via Mojo message handling; per NVD/Rapid7/cve.news summaries, exact deserializer function not independently re-derived from source in this pass)"
+      ],
+      "confirmable": "Directly checkable by source inspection once the specific `Read()`/`Deserialize()` override is in view — the presence or absence of a range check against `size()` before use is visible in the function body. Confirming actual EXPLOITABLE impact (vs. a bounds-checked-elsewhere false positive, since Mojo's validation can also happen in generated pre-Read validation code, not just the Read() body itself) needs a careful read of the full validation chain, which the grep alone doesn't establish. No Mojo fuzz/build lane exists in this repo.",
+      "domain": "chromium",
+      "uid": "chromium/MOJO-01",
+      "engine_lens": null,
+      "route": "source-static"
+    },
+    {
+      "id": "MOJO-02",
+      "name": "Mojo handle/capability confusion — a handle scoped to one process/purpose is honored by another",
+      "cwe": "CWE-863 / CWE-284",
+      "subsystem": "mojo/core (platform handle transport, PlatformHandle/Transport broker), any privileged interface that accepts a caller-supplied handle",
+      "pattern": "Mojo's cross-process handle-passing machinery (the platform-handle broker/Transport layer on Windows in particular) delivers a handle intended for one process, scope, or capability level to a different one — a logic error at the boundary between Chrome's sandbox and OS handle semantics — letting a lower-privileged holder present a handle that the receiving (higher-privileged) side treats as if it came from a trusted broker, or letting a handle escape its intended sandbox/scope entirely.",
+      "detection_signature": "Grep for `mojo::`, `PendingRemote`, `PendingReceiver`, `Remote<`, `Receiver<` (PascalCase/namespaced — needs CHROMIUM_BARE_WORDS) alongside handle-acquisition/transport code, especially any path that accepts a serialized handle/transport descriptor from a less-trusted process and resolves it to a live OS handle without re-validating which process/scope it was actually issued for.",
+      "grounding": [
+        "CVE-2025-2783 (Windows Mojo sandbox-escape 0-day, exploited in-the-wild in 'Operation ForumTroll': an incorrect handle is provided under certain conditions at the intersection of Chrome's sandbox and Windows handle semantics, letting a compromised renderer pivot to code execution outside the sandbox; reported by Kaspersky's Boris Larin/Igor Kuznetsov, fixed in Chrome 134.0.6998.177; verified via Fidelis/SentinelOne/Armis advisory summaries)",
+        "CVE-2025-4609 (insufficient validation in the `Transport::Deserialize` function — a fake broker transport is used to acquire a handle that bypasses the intended security check, enabling privilege escalation/sandbox escape; per OX Security writeup — `Transport::Deserialize` symbol name as reported by that writeup, not independently re-derived from source in this pass)"
+      ],
+      "confirmable": "These are boundary/logic bugs at the OS-IPC layer (Windows broker semantics in both cited CVEs) — genuinely hard to confirm by source-static reading alone without deep platform-specific handle-lifecycle knowledge. Treat any static hit purely as 'this code touches the handle-transport trust boundary, worth a specialist's look', never as a confirmed finding. No Mojo/Windows-broker execution lane exists in this repo.",
+      "domain": "chromium",
+      "uid": "chromium/MOJO-02",
+      "engine_lens": null,
+      "route": "source-static"
+    },
+    {
+      "id": "MOJO-03",
+      "name": "Browser-side Mojo interface implementation trusts a renderer-supplied index/size without validation",
+      "cwe": "CWE-125 / CWE-787 / CWE-20",
+      "subsystem": "any browser-process class implementing a `.mojom` interface (a `Receiver<T>`-bound `T` implementation) whose methods take an index, offset, or size parameter from the renderer",
+      "pattern": "Distinct from MOJO-01 (which is about the GENERATED deserialization code): here the generated bindings correctly deserialize the message, but the hand-written interface IMPLEMENTATION method itself then uses a renderer-supplied integer parameter (an index into a browser-side array/vector, a byte count for a copy) directly, without an application-level bounds check — Mojo's own security doctrine ('every message from a less-privileged process is untrusted input') is violated not at the wire-format layer but at the interface's business logic layer.",
+      "detection_signature": "Grep for `Receiver<`, `Remote<`, `PendingRemote` (needs CHROMIUM_BARE_WORDS) on a class implementing a mojom interface, where a method parameter (index/offset/count) is used to index a `std::vector`/`base::span`/array or size a `memcpy`/copy operation without a preceding `< size()`-style range check.",
+      "grounding": [
+        "General doctrine grounding: chromium/src docs/security/mojo.md ('Mojo Style Guide' / security doc) states the standing rule that all Mojo messages from a less-privileged process must be treated as untrusted input and validated by the receiving implementation, not just by generated bindings.",
+        "CVE-2024-9369 as a second witness (see chromium/MOJO-01) — the same 'trust the renderer-supplied field' failure mode, whether it lands in generated Read()/Deserialize() code or in the hand-written interface method; this archetype is the interface-implementation-layer sibling of MOJO-01, intentionally kept separate because the grep-detectable code SHAPE differs (interface impl method body vs. generated StructTraits)."
+      ],
+      "confirmable": "Directly checkable by source inspection once the specific interface-implementation method is in view — presence/absence of a bounds check against the parameter before use is visible. Same false-positive risk as MOJO-01: validation may legitimately live one layer up (a caller-side check, or a mojom `[EnableIf]`/range annotation) that the grep alone won't see. No Mojo fuzz/build lane exists in this repo.",
+      "domain": "chromium",
+      "uid": "chromium/MOJO-03",
+      "engine_lens": null,
+      "route": "source-static"
+    },
+    {
+      "id": "BASE-01",
+      "name": "Unwrapped raw C++ pointer UAF — the exact bug class MiraclePtr/raw_ptr<> was built to mitigate",
+      "cwe": "CWE-416",
+      "subsystem": "base/memory (raw_ptr<>/MiraclePtr/BackupRefPtr, base::WeakPtr<>) and any Chromium C++ code that stores a bare `T*`/`T&` to a heap-allocated object across a potential free point instead of `raw_ptr<T>`/`base::WeakPtr<T>`",
+      "pattern": "A class or function stores a bare, unwrapped raw pointer (not `raw_ptr<T>`, not `base::WeakPtr<T>`) to a heap object across a region of code where that object can be freed by another path (a callback, a different sequence/task, an owner releasing it) — when `raw_ptr<T>`/BackupRefPtr is NOT in play, the freed memory is neither poisoned nor quarantined, and the dangling pointer is a live, silently exploitable use-after-free exactly like the ones MiraclePtr was deployed browser-wide specifically to suppress.",
+      "detection_signature": "Grep for `raw_ptr` (the one genuinely snake_case-shaped symbol here — matched by the DEFAULT heuristic, no bareWords needed) and `WeakPtr`/`CheckedNumeric` (needs CHROMIUM_BARE_WORDS) as CONTRAST signals: a field/variable holding a pointer to a ref-counted or singly-owned class, stored as bare `T*` where the surrounding class's OTHER pointer fields use `raw_ptr<T>`/`base::WeakPtr<T>` — an inconsistency within the same class is the strongest tell that a raw pointer was missed rather than deliberately chosen (see raw_ptr.md's documented exceptions: pointers confined to a single stack frame with no intervening free-able call are legitimately raw).",
+      "grounding": [
+        "Chromium's own `base/memory/raw_ptr.md` design document frames this directly: 'MiraclePtr is Chromium's response to its biggest security problem, a constant stream of exploitable (and exploited) Use-after-Free bugs' — i.e. the entire raw_ptr<>/BackupRefPtr system exists BECAUSE unwrapped-raw-pointer UAF was (and, wherever raw_ptr<> is still absent, remains) the dominant Chrome exploit primitive class. No single CVE is cited here by design — this archetype targets the general, still-live class of UAFs in code that has NOT yet been converted to raw_ptr<>/WeakPtr<>, which by definition includes any newly-written or not-yet-audited Chromium C++."
+      ],
+      "confirmable": "The raw-pointer-vs-raw_ptr<>/WeakPtr<> inconsistency is directly visible by source inspection once the class's full field list is in view. Confirming an ACTUAL free-then-use reachability (vs. a raw pointer that is provably safe, e.g. truly stack-scoped) requires tracing every path that can free the pointee against every path that dereferences the raw field — a real analysis burden, and BackupRefPtr's browser-wide deployment means MANY of Chromium's raw_ptr<T> fields already convert would-be-UAFs into safe no-ops elsewhere, so a hit here is only interesting where raw_ptr<> is ABSENT. No dynamic lane exists in this repo.",
+      "domain": "chromium",
+      "uid": "chromium/BASE-01",
+      "engine_lens": null,
+      "route": "source-static"
+    },
+    {
+      "id": "BASE-02",
+      "name": "Integer overflow in a size/count multiplication feeding an allocation, bypassing CheckedNumeric",
+      "cwe": "CWE-190 / CWE-787",
+      "subsystem": "base/numerics (base::CheckedNumeric<>, base::CheckMul/CheckAdd, base::saturated_cast) callers that size a heap allocation or a memcpy from renderer- or content-controlled counts",
+      "pattern": "A buffer size is computed as a raw `count * element_size` (or similar multiplication/addition of two attacker-influenced values) in plain machine arithmetic instead of via `base::CheckedNumeric<>`/`base::CheckMul()`/`base::CheckAdd()` (Chromium's own overflow-safe-arithmetic idiom, directly analogous to FreeBSD's `mallocarray()` — see freebsd/MA-01). The multiplication wraps, the resulting allocation is far smaller than the code assumes, and a subsequent count-driven or fixed-size write runs off the end of the undersized buffer.",
+      "detection_signature": "Grep for `CheckedNumeric` (needs CHROMIUM_BARE_WORDS) as the ABSENCE signal alongside a raw multiplication/addition feeding a `new[]`/`malloc`/`base::HeapArray`/similar allocation call whose size argument traces back to renderer- or network-controlled input, with no `CheckedNumeric<>`/`CheckMul`/`CheckAdd`/`saturated_cast` guarding it.",
+      "grounding": [
+        "Pattern-grounded from Chromium's own `base::CheckedNumeric<>` design intent (the documented overflow-safe-arithmetic idiom whose absence is the tell, exactly mirroring how `mallocarray()`'s absence is the tell for freebsd/MA-01) and the general, well-known class of integer-overflow-into-allocation bugs across browser codebases. NO specific current (2024-2026) Chromium `base::`-layer CVE was independently found and verified pinned to exactly this shape in this research pass — most integer-overflow CVEs found during this research landed in V8 (elements/backing-store sizing) or media/codec code rather than base:: itself; marked honestly rather than fabricating a citation."
+      ],
+      "confirmable": "The raw-multiplication-with-no-CheckedNumeric-guard shape is directly visible by source inspection. Given no confirmed historical CVE was found for exactly this base::-layer shape in this pass, treat any hit with EXTRA skepticism relative to the other archetypes here until either a matching precedent is found or the specific call site is manually traced to a real OOB write. No dynamic lane exists in this repo.",
+      "domain": "chromium",
+      "uid": "chromium/BASE-02",
+      "engine_lens": null,
+      "route": "source-static"
+    }
+  ]
+}

package/chunks/data/freebsd-archetypes.json

@@ -0,0 +1,171 @@
+{
+  "provenance": "0sec-authored (NOT ported from 0verse — 0verse's archetypes.json is Linux-only, no FreeBSD registry exists). Grounded independently in public FreeBSD-SA advisories / CVEs, several confirmed by fetching the advisory text directly, 2026-07-05. IMPORTANT HONEST CAVEAT: unlike the Linux pack, this repo has NO FreeBSD build+boot+KASAN kernel-verify lane today — every 'kernel-verify' route entry below is a hypothesis that needs a human/skeptic read (or a future FreeBSD prover lane), not a proven-confirmable claim.",
+  "archetypes": [
+    {
+      "id": "CP-01",
+      "name": "copyout() of an uninitialized stack/heap struct -> kernel infoleak",
+      "cwe": "CWE-908 / CWE-200",
+      "subsystem": "kern/ (syscalls that copyout a fixed-size struct: setlogin/getlogin, get/swapcontext, ktrace, elf image activation)",
+      "pattern": "A struct or buffer is declared on the stack (or malloc'd without M_ZERO) and only some fields are written before the whole thing is copyout()'d to userland. Padding bytes, unwritten trailing fields, or a 'copy full size even though only N bytes are valid' shortcut leak adjacent kernel stack/heap contents to an unprivileged caller.",
+      "detection_signature": "Grep for `copyout(` (bare word — FreeBSD's copy-to-user primitive has no underscore, unlike Linux's copy_to_user) where the source argument is a local `struct`/`ucontext_t`/`sockaddr_storage` variable that was NOT preceded by `bzero(&var, sizeof(var))`, `explicit_bzero`, or a `M_ZERO`-flagged `malloc`/`mallocarray`. Real shape: a function declares `ucontext_t uc;`, writes a handful of fields, then `copyout(&uc, ..., UC_COPY_SIZE)`'s the whole struct; or a variable-length `sockaddr` is copied out at its FULL storage size (`sizeof(struct sockaddr_storage)`) instead of its actual `sa_len`.",
+      "grounding": [
+        "CVE-2014-8476 / FreeBSD-SA-14:25.setlogin (login name copied into an uninitialized stack buffer, then the whole buffer returned by getlogin(2))",
+        "CVE-2018-17155 (getcontext(2)/swapcontext(2): ucontext_t declared on the stack, only some fields written, then copyout()'d at UC_COPY_SIZE)",
+        "CVE-2025-0662 / FreeBSD-SA-25:04.ktrace (ktrace(2) copies the full sockaddr_storage even when the real sockaddr is shorter -> up to 14 uninitialized kernel heap bytes leaked; verified via advisory fetch)",
+        "CVE-2018-6924 / FreeBSD-SA-18:12 (ELF header parsing kernel memory disclosure to an unprivileged local user)"
+      ],
+      "confirmable": "Plausible by source inspection alone — absence of a bzero/M_ZERO call before the copyout is directly visible in the diff/function body. Still needs skeptic review to rule out an out-of-line initializer earlier in the call chain (e.g. a caller that already zeroed the struct) before treating a hit as confirmed; no dynamic oracle exists in this repo yet to prove the leaked bytes are non-zero/sensitive.",
+      "domain": "freebsd",
+      "uid": "freebsd/CP-01",
+      "engine_lens": null,
+      "route": "kernel-static"
+    },
+    {
+      "id": "CP-02",
+      "name": "copyin() double-fetch / TOCTOU on a user-controlled length or header field",
+      "cwe": "CWE-367 / CWE-787",
+      "subsystem": "kern/uipc_syscalls.c, kern/uipc_syscalls_compat*.c (sendmsg/recvmsg control-message and cmsg-header handling)",
+      "pattern": "A length or header field is fetched from userland once to validate it fits a kernel buffer (\"first loop\"), the kernel buffer is allocated based on that validated length, and then a SECOND copyin()/re-read of the same user memory (\"second loop\") trusts the field again — but a racing thread can mutate the user page between the two reads, so the second read sees a larger/different value than what was validated -> heap/stack overflow.",
+      "detection_signature": "Grep for `copyin(` (bare word) appearing more than once against the same user pointer within one function, especially near `cmsg_len` / `cmsghdr` fields: a first pass that sums/validates `cmsg_len` against `MLEN`/a buffer cap, followed by a second pass that does `copyin()` using a length re-derived from the (attacker-writable) user buffer instead of the already-validated value.",
+      "grounding": [
+        "CVE-2020-7460 (freebsd32_copyin_control(): TOCTOU between the length-validation loop and the copy loop over cmsg_len fields -> kernel heap overflow, 90%-reliable local root PoC per ZDI writeup; verified via ZDI blog)",
+        "CVE-2016-1887 (sendmsg(2) kernel heap overflow, same control-message handling area, precursor bug in the same code family)"
+      ],
+      "confirmable": "NO static oracle for the race window itself (this is a TOCTOU — reachability of the second, stale read depends on timing). The two-copyin() shape is grep-visible and worth flagging, but confirming exploitability needs either a kernel-verify build+boot lane (which does not yet exist for FreeBSD in this repo) or careful skeptic-only reasoning about whether the two fetches can genuinely observe different values.",
+      "domain": "freebsd",
+      "uid": "freebsd/CP-02",
+      "engine_lens": null,
+      "route": "kernel-verify"
+    },
+    {
+      "id": "MA-01",
+      "name": "integer overflow in a mallocarray()/malloc(9) size derived from user-controlled count*size",
+      "cwe": "CWE-190 / CWE-787",
+      "subsystem": "kern/kern_malloc.c callers (ioctl/sysctl handlers that size a kernel buffer from a user-supplied count or length)",
+      "pattern": "An attacker-controlled count or size value (from an ioctl argument or sysctl input) is multiplied against an element size and passed straight to `malloc(9)` without an overflow check; the multiplication wraps, `malloc` returns a heap allocation far SMALLER than the code assumes, and a subsequent fixed-size or count-driven write runs off the end of the undersized buffer.",
+      "detection_signature": "Grep for `malloc(` / `mallocarray(` (bare words — no underscore, unlike Linux's kmalloc) where the size argument is a multiplication of two values, at least one of which traces back to an ioctl/sysctl input, with no preceding overflow-safe check (no `mallocarray()` in place of a raw `count * size`, no explicit `if (count > MAX)` cap). `mallocarray()` itself is the FIXED idiom (checks overflow internally) — its ABSENCE where `malloc(count * size, ...)` appears instead is the tell.",
+      "grounding": [
+        "CVE-2026-49416 / FreeBSD-SA-26:34.vt (vt(4) CONS_HISTORY ioctl: an attacker-supplied history size overflows the buffer-size calculation, producing a heap allocation smaller than expected; the subsequent buffer initialization then writes past the end of the undersized allocation — verified via advisory fetch)"
+      ],
+      "confirmable": "Plausible by source inspection — a raw `count * size` feeding `malloc()` with no cap is directly visible. Reaching the actual OOB write requires tracing the buffer's subsequent use, which is easy in-source but still benefits from a dynamic replay; no FreeBSD kernel-verify lane exists yet in this repo to do that replay.",
+      "domain": "freebsd",
+      "uid": "freebsd/MA-01",
+      "engine_lens": null,
+      "route": "kernel-static"
+    },
+    {
+      "id": "PRIV-01",
+      "name": "missing priv_check()/securelevel_gt() gate on a privileged ioctl or sysctl write",
+      "cwe": "CWE-862 / CWE-284",
+      "subsystem": "kern/kern_priv.c callers; any cdevsw d_ioctl or SYSCTL_PROC handler that mutates privileged state",
+      "pattern": "An ioctl or sysctl-write handler mutates privileged kernel/device state (console history size, debug/trace enable, a device configuration register) without first calling `priv_check(td, PRIV_*)` / `priv_check_cred()` / `securelevel_gt()`, OR the gate exists but is trivially bypassed by an insecure default sysctl (e.g. a `security.bsd.*` knob defaulting to permissive) — letting an unprivileged local user reach a root-only operation.",
+      "detection_signature": "Grep for `priv_check`, `priv_check_cred`, `securelevel_gt` (all real, underscored FreeBSD privilege APIs) — the tell is an ioctl/sysctl handler that reaches a sensitive write/state-change WITHOUT any of these three appearing on the path, or where the only gate is a `sysctl` default that ships insecure-by-default.",
+      "grounding": [
+        "CVE-2016-1886 (SETFKEY / genkbd_commonioctl(): the shared keyboard-driver ioctl handler was reachable by an unprivileged user because of a poor default sysctl, present since 1999)",
+        "CVE-2013-2171 / FreeBSD-SA-13:06.mmap (procfs `mem` node access gated only by the insecure-by-default `security.bsd.unprivileged_proc_debug` sysctl, allowing arbitrary-code-as-another-user)"
+      ],
+      "confirmable": "Plausible by source inspection — the absence of any priv_check()/securelevel_gt() call on the privileged path is directly visible in the function body. Still needs skeptic review to rule out a caller-side gate (e.g. the device node's own file permissions already restrict access) before treating a hit as a real privilege-escalation path.",
+      "domain": "freebsd",
+      "uid": "freebsd/PRIV-01",
+      "engine_lens": null,
+      "route": "kernel-static"
+    },
+    {
+      "id": "IOC-01",
+      "name": "d_ioctl_t handler OOB: caller-specified buffer size vs. a fixed-size struct copied into it",
+      "cwe": "CWE-787 / CWE-125",
+      "subsystem": "cdevsw / d_ioctl_t handlers (storage-controller and other char-device drivers)",
+      "pattern": "A `d_ioctl_t` handler allocates or references a buffer sized from a CALLER-SUPPLIED length field, but then copies in/out a FIXED-size header/struct into that buffer without checking the caller's length is at least that big -> heap OOB write when the caller under-specifies the buffer size relative to the fixed header.",
+      "detection_signature": "Grep for `d_ioctl_t` (the real, underscored cdevsw ioctl-handler typedef) alongside `copyout(`/`copyin(` (bare words) where the destination/source length used is a CONSTANT `sizeof(some_fixed_header)` rather than the caller-specified buffer-size field from the ioctl request struct.",
+      "grounding": [
+        "CVE-2022-23086 / FreeBSD-SA-22:06.ioctl (mpr(4)/mps(4)/mpt(4) *_CFG_PAGE ioctl handlers: allocated a buffer of the caller-specified size but copied a FIXED-size header into it, overflowing the buffer when the caller's size was smaller than the header — verified via advisory fetch)"
+      ],
+      "confirmable": "Plausible by source inspection — the size mismatch between the allocation and the copy is directly visible once both sites are found. Confirming actual heap corruption impact (vs. a harmless small overflow into padding) still benefits from a dynamic run; no FreeBSD kernel-verify lane exists yet in this repo.",
+      "domain": "freebsd",
+      "uid": "freebsd/IOC-01",
+      "engine_lens": null,
+      "route": "kernel-static"
+    },
+    {
+      "id": "UAF-01",
+      "name": "uma_zfree() / free(9) double-free or use-after-free on a racing ioctl/setsockopt path",
+      "cwe": "CWE-415 / CWE-416",
+      "subsystem": "net/bpf.c (bpf_setf race), netinet6/in6_pktinfo / ip6_setpktopt (missing setsockopt lock)",
+      "pattern": "Two threads/processes race a device ioctl or socket-option setter that reads a pointer to an owned object, then frees it: both racers copy the SAME pointer to their kernel stacks before either free happens, so both free it -> double-free; or a socket-option setter frees an option struct with no lock while another thread/read path still holds a reference to the now-freed struct -> UAF.",
+      "detection_signature": "Grep for `uma_zfree`, `bd_wfilter`, `bd_rfilter` (all real, underscored symbols) in bpf.c-style filter-install code: a copy-to-stack of the current filter pointer followed by `uma_zfree`/`free` with NO lock held across the read-then-free window. Same shape in socket-option setters: a pointer read (e.g. from `ip6_pktopts`) and a `free(9)` of the old value with no mutex around the compare-and-swap.",
+      "grounding": [
+        "BPF bd_wfilter/bd_rfilter concurrent bpf_setf() race -> double-free (documented in the PS4 5.05 jailbreak research by qwertyoruiopz; the underlying bpf(4) locking gap also exists in mainline FreeBSD, not just the PS4 fork — treat the exact current-mainline fix status as unverified until re-checked against bench:/root/freebsd-src)",
+        "CVE-2020-7457 (missing synchronization lock in the IPV6_2292PKTOPTIONS setsockopt handler allows racing ip6_setpktopt() access to a freed ip6_pktopts struct)"
+      ],
+      "confirmable": "NO static oracle — both are races (concurrency-dependent). A source hit here is a hypothesis only; proving it needs a build+boot+KASAN replay under concurrent syscalls, which does not exist yet as a FreeBSD lane in this repo (unlike Linux's bench kernel-verify path). Route this to human/skeptic-only review, not auto-confirmation.",
+      "domain": "freebsd",
+      "uid": "freebsd/UAF-01",
+      "engine_lens": null,
+      "route": "kernel-verify"
+    },
+    {
+      "id": "REFCNT-01",
+      "name": "reference-count imbalance (missing fdrop()/fput()-equivalent) -> premature free -> UAF",
+      "cwe": "CWE-911 / CWE-416",
+      "subsystem": "kern/uipc_usrreq.c (UNIX-domain socket control-message file-descriptor passing)",
+      "pattern": "A file-descriptor reference is incremented (`fget()`-equivalent) on a success path but the matching decrement is missing on an ERROR or cleanup path (e.g. \"close the received fd because the receiver's buffer was too small\"); repeating the trigger overflows the `f_count` refcount field, wraps it to a small value, and a subsequent close/dup frees the underlying `struct file` while another descriptor still references it.",
+      "detection_signature": "Grep for `f_count`, `m_dispose_extcontrolm` (both real, underscored symbols from the actual advisory) — the tell is a cleanup path that calls `fdclose()`-style close logic on a received/duplicated fd WITHOUT a matching `fdrop()` to release the earlier `fget()`-style reference, so `f_count` is decremented once instead of twice.",
+      "grounding": [
+        "CVE-2019-5596 / FreeBSD-SA-19:02.fd (m_dispose_extcontrolm() lacks the fdrop() call after fdclose() when discarding over-limit received file descriptors from a UNIX-domain control message -> f_count reference-count overflow -> UAF on the freed struct file; verified via advisory fetch)"
+      ],
+      "confirmable": "The missing-decrement shape is visible by pairing every increment with its decrement along each path — doable by source inspection, but proving the counter actually wraps and the freed object is reachable from a second descriptor needs a dynamic replay. No FreeBSD kernel-verify lane exists yet in this repo; route to skeptic-only review.",
+      "domain": "freebsd",
+      "uid": "freebsd/REFCNT-01",
+      "engine_lens": null,
+      "route": "kernel-verify"
+    },
+    {
+      "id": "SYSCTL-01",
+      "name": "sysctl handler OOB read/write via mishandled req->newptr/req->oldptr length",
+      "cwe": "CWE-787 / CWE-125",
+      "subsystem": "kern/kern_sysctl.c callers (custom SYSCTL_PROC / SYSCTL_HANDLER_ARGS handlers)",
+      "pattern": "A custom sysctl handler (`SYSCTL_HANDLER_ARGS`) trusts `req->newlen` or an internal buffer size without checking it against the destination buffer before calling `sysctl_handle_opaque`/doing a manual copy, or writes MORE than `req->oldlen` bytes into `req->oldptr` on the read side -> heap/stack OOB read or write reachable by any local user who can query/set that sysctl node.",
+      "detection_signature": "Grep for `sysctl_handle_int`, `sysctl_handle_long`, `sysctl_handle_opaque`, `sysctl_handle_string` (all real, underscored FreeBSD sysctl(9) helper functions) — the tell is a handler that reads `req->newlen` or writes to `req->oldptr` with a length NOT clamped against the actual destination buffer size, especially in a handler that manually memcpy's instead of delegating to one of the `sysctl_handle_*` helpers.",
+      "grounding": [
+        "Pattern-grounded from the documented sysctl(9) SYSCTL_HANDLER_ARGS contract (req->newptr/req->oldptr/req->newlen/req->oldlen — a handler that doesn't respect these is a well-known FreeBSD driver-review class). NO specific historical FreeBSD-SA/CVE was found and verified in this research pass — marked honestly as an unverified-by-precedent archetype; corroborate with a specific advisory before citing this class externally or in a disclosure."
+      ],
+      "confirmable": "Plausible by source inspection — the length-check omission is visible in the handler body. Given no confirmed historical CVE was found for this exact class in this pass, treat any hit with EXTRA skepticism until either a matching precedent is found or the class is dynamically reproduced; no FreeBSD kernel-verify lane exists yet in this repo.",
+      "domain": "freebsd",
+      "uid": "freebsd/SYSCTL-01",
+      "engine_lens": null,
+      "route": "kernel-static"
+    },
+    {
+      "id": "MBUF-01",
+      "name": "mbuf-chain traversal with an unchecked/user-influenced length crossing an mbuf boundary",
+      "cwe": "CWE-125 / CWE-787",
+      "subsystem": "netinet6/ (ICMPv6/MLDv2 input path), sys/mbuf.h helpers",
+      "pattern": "A packet-parsing function computes an offset/length into an mbuf chain (e.g. an MLDv2 listener-query option) and reads/writes at that offset via `mtod()`/pointer arithmetic WITHOUT first calling `m_pullup()`/`m_pulldown()` to guarantee the needed bytes are contiguous in the current mbuf -> the read/write crosses into an adjacent mbuf's memory or past the chain's actual length when the packet is fragmented across mbuf boundaries in a way the parser didn't anticipate.",
+      "detection_signature": "Grep for `m_pullup`, `m_pulldown` (real, underscored mbuf-chain-linearization functions) — the tell is a parser that computes a length/offset from packet contents and dereferences it via `mtod()` WITHOUT a preceding `m_pullup()`/`m_pulldown()` call sized to that length, so a chain fragmented at an unexpected boundary is read/written out of bounds.",
+      "grounding": [
+        "CVE-2019-5608 / FreeBSD-SA-19:19.mldv2 (the ICMPv6 input path mishandles MLDv2 listener-query packets fragmented across mbufs, producing an OOB read/write that can panic the kernel)"
+      ],
+      "confirmable": "NO static oracle for whether a given packet shape actually straddles an mbuf boundary at runtime — reachability depends on how the mbuf chain was built (device driver, fragmentation), which is a runtime property. Needs a crafted-packet replay to confirm; no FreeBSD kernel-verify lane exists yet in this repo.",
+      "domain": "freebsd",
+      "uid": "freebsd/MBUF-01",
+      "engine_lens": null,
+      "route": "kernel-verify"
+    },
+    {
+      "id": "SBUF-01",
+      "name": "sbuf/ps_strings OOB read from an unhandled sbuf_len() sentinel (0 / -1)",
+      "cwe": "CWE-125 / CWE-200",
+      "subsystem": "kern/kern_proc.c (proc_getargv/proc_getenvv and other ps_strings/sbuf consumers)",
+      "pattern": "`proc_getargv()`-style helpers return an `sbuf` built from a target process's `ps_strings` region; callers that don't handle `sbuf_len()` returning 0 or -1 (a crafted/corrupt `ps_strings` in the target) can read past the sbuf's actual data when copying it out, or misinterpret the sentinel as a valid length -> kernel OOB read reachable by any local user who can inspect another process's argv (procstat/ps-style tools).",
+      "detection_signature": "Grep for `proc_getargv`, `ps_strings`, `sbuf_len` (all real, underscored FreeBSD symbols) — the tell is a consumer of `proc_getargv()`/`proc_getenvv()` that uses the returned sbuf's data/length WITHOUT checking `sbuf_len(sb) <= 0` first, or a crafted `ps_strings` structure in the target process that a reader trusts at face value.",
+      "grounding": [
+        "Documented FreeBSD kernel bug class: proc_getargv() can return an sbuf with sbuf_len() of 0 or -1 when a process's ps_strings is corrupted/crafted, which callers historically did not handle, allowing an OOB read via a crafted ps_string. NO specific CVE number was confirmed in this research pass — marked honestly; corroborate the exact advisory before citing this class externally."
+      ],
+      "confirmable": "Plausible by source inspection — the missing sbuf_len() sentinel check is visible in the consumer function. Given the CVE for this exact bug was not confirmed in this pass, treat any hit with extra skepticism until a precedent or dynamic reproduction confirms it; no FreeBSD kernel-verify lane exists yet in this repo.",
+      "domain": "freebsd",
+      "uid": "freebsd/SBUF-01",
+      "engine_lens": null,
+      "route": "kernel-static"
+    }
+  ]
+}