From 2589c3d47afeff01e05acc79f7e2d89b79cb16a6 Mon Sep 17 00:00:00 2001 From: Marius Ciepluch <11855163+norandom@users.noreply.github.com> Date: Wed, 9 Sep 2026 13:11:30 +0200 Subject: [PATCH] docs(contributor-scan): what c/memory covers, and what SMT covers instead libpng's library code never calls strcpy, strcat, sprintf or gets -- all twelve files that do are under contrib/. It overflows through array and pointer arithmetic and memcpy sizing, which is a different question from the one this family asks: "can this expression exceed this allocation" rather than "does tainted data reach this call". That is a constraint problem. It is what SMT is for, and what this project deliberately did not adopt -- the architecture decision was abstract interpretation as arbiter, taken because a model layer can be built from code where execution cannot be assumed. That decision was right for the flow families and it does not reach this one. The maintainer has attacked libpng exactly this way, using SMT to lay out memory and then guiding a fuzzer to the inputs that reach it, which is evidence about the shape of the problem rather than a plan to reimplement it: the honest routes to C memory safety are constraint solving or execution, and the ladder already has a rung for the second. So 2.15 now separates the cheap route (pin a C project whose CVE runs through a string function, giving the family its first true positive) from the expensive one (model the arithmetic, a different engine), instead of implying a sink-table fix would cover both. And 2.16 asks the question this spec's predecessor would have asked: c/memory has scored zero true positives and three separate classes of false one -- a substring match, a bound it could not see, an allocation sized to fit. Every one was a real engine defect and every one is fixed, but the family has never been right. Keep it scoped and labelled, or retire it; either way with a number behind it, and never leaving a silent C scan to read as a clean bill of health. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_01T7XD7x5KonMdmGRkp63EQG --- .kiro/specs/contributor-scan/tasks.md | 38 ++++++++++++++++++++++----- 1 file changed, 32 insertions(+), 6 deletions(-) diff --git a/.kiro/specs/contributor-scan/tasks.md b/.kiro/specs/contributor-scan/tasks.md index d210327..ce0fc10 100644 --- a/.kiro/specs/contributor-scan/tasks.md +++ b/.kiro/specs/contributor-scan/tasks.md @@ -272,15 +272,41 @@ and five buffer-overflow fixes checked (`png_set_quantize`, `png_image_finish_read`, `png_init_read_transformations`, `png_do_quantize`, `png_write_image_8bit`) touch no modelled sink at all. - - So there are two ways forward and they are different sizes. Pin a C project whose CVE genuinely runs - through a string function -- cheap, and it gives the memory family its first true positive. Or model how - C actually overflows: a `memcpy` whose size is computed, an index that is not bounded. That is size - arithmetic rather than sink matching, a different abstraction, and it should not be started by accident. - - Observable: a pinned checkout with an in-scope CVE found at a rung, or a recorded decision that the - memory family needs the second abstraction before any C detection claim is made. + - So there are two ways forward and they are different sizes. + - **Cheap: pin a C project whose CVE genuinely runs through a string function.** That gives the memory + family its first true positive and tells us whether the family works at all. It does not make libpng + decidable. + - **Expensive, and a different engine: model how C actually overflows.** A `memcpy` whose size is + computed, an index that is not bounded. That is *size arithmetic*, not sink matching -- "can this + expression exceed this allocation" rather than "does tainted data reach this call". It is a constraint + problem, which is what SMT is for and what this project deliberately did not adopt: the architecture + decision was abstract interpretation as arbiter, taken because a model layer can be built from code + where execution cannot be assumed. That decision was right for the flow families and it does not reach + this one. + - The maintainer has attacked libpng this way directly -- SMT to lay out memory, then guiding a fuzzer to + produce the PNGs that reach it -- which is evidence about the shape of the problem, not a suggestion to + reimplement it. It says the honest routes to C memory safety are constraint solving or execution, and + the ladder already has a rung for the second (`execution_confirmed`, built and unreachable per the + module audit). + - Observable: a pinned checkout with an in-scope CVE found at a rung, OR a recorded decision that + `c/memory` is scoped to string-function misuse and makes no claim about arithmetic overflows. Do not + leave it implying it covers a class it cannot see. - _Requirements: 4.1, 4.4_ - _Depends: 2.12_ +- [ ] 2.16 Say what `c/memory` actually covers, or retire it + - Its score so far is zero true positives and every finding a false one: 26 from a substring match, 3 from + a bound it could not see, 1 from an allocation sized to fit. Each was a real defect in the engine and + each is now fixed, but the family has never once been right, and 2.15 explains why -- it models string + functions in a codebase class that overflows through arithmetic. + - This spec's predecessor threw away parts that did not carry their weight, and the same question applies + here. The answer may well be "keep it, scoped and labelled" -- `strcpy` misuse is real in plenty of C -- + but it should be a recorded decision with a number behind it, not an assumption. + - Observable: either a measured true positive on the 2.15 checkout, or the family's declared scope + narrowed in the facts and the docs so no reader takes a silent C scan for a clean bill of health. + - _Requirements: 3.1, 8.2_ + - _Depends: 2.15_ + ## Group 3 — Ship it - [ ] 3.1 Contributor output