The latest tagged release. There are no long-lived release branches, so a fix ships in the next tag rather than being backported.

Use GitHub's private vulnerability reporting on this repository: https://github.com/Rethunk-Tech/go-nettrace/security/advisories/new, or the Security tab, then Report a vulnerability. The report stays private between you and us until a fix ships.

If private reporting is unavailable, email oss@rethunk.tech with [SECURITY] in the subject.

Please do not open a public issue, pull request or discussion for a suspected vulnerability.

A useful report has the affected repository and version (or commit), steps to reproduce, what an attacker gets and under which conditions, and whether anyone else knows.

A vulnerability is a flaw that lets someone cross a boundary they should not: run code, read or change data they have no right to, escape a sandbox or path restriction, or leak a credential. A bug is anything else that misbehaves, such as a crash on your own input, wrong output or a slow path; open an ordinary issue for those. If you are unsure which one you have, report it privately and we will say.

We handle the report inside the private advisory, so you see each status change and can comment on the fix. The advisory goes public when the fix ships, or 90 days after your report, whichever comes first. If a fix is close, either of us can ask for more time in the thread. You are credited in the advisory unless you would rather not be.

• We acknowledge your report within 3 business days.
• We give you an assessment (accepted, needs more information or declined, with reasons) within 10 business days.
• We aim to ship a fix within 90 days of the report.

• Parse input. A crafted nettrace must not panic or loop forever. Memory is proportional to the input but not a small multiple of it: a compressed sample event is 2 bytes on the wire and a 48-byte Sample once decoded, and a stream of nothing else measured 235 times its size in total allocation (BenchmarkParseMinimalSamples: 2,000,455 bytes in, about 470,000,000 allocated, 1,000,000 samples out; 554 times before events were appended into one slice). The caller therefore bounds the reader to the size it can afford to hold 250 times over. Block, stack and payload counts are checked against the bytes that remain before they size an allocation. FuzzParse covers it. Parse reads the whole stream, so the caller bounds an untrusted reader.
• IPC replies. A hostile or broken peer on the diagnostics endpoint must not make StartTracing or Stop panic, allocate beyond one 64 KiB frame, or outlive its context.
• Endpoint discovery. On Unix only a socket (not a link to one) owned by the user who owns the target process is dialed, and the process's own TMPDIR is searched before the shared temp directory, so a socket another user plants in a sticky /tmp is never connected to. The bytes copied to the writer are capped by Config.MaxStreamBytes (ErrStreamTooLarge). The Windows pipe name carries no owner check.

• Which process to attach to. A diagnostics endpoint is a same-user, same-host channel: attaching to it lets the caller read that process's runtime events, which is the purpose.
• Memory use proportional to the size of a stream the caller chose to read.
• The content of the writer passed to StartTracing: the bytes are the runtime's, unparsed.

We will not pursue legal action against good-faith research that avoids privacy violations, data destruction and disruption of services, stops at a proof of concept, and keeps the details private until the advisory is published. Rethunk.Tech, LLC maintains this repository.