Patch2Vuln: Patch-Centric Vulnerability Analysis
- Patch2Vuln is a patch-centric approach that reconstructs vulnerability semantics from Linux binary patches using a multi-layered diff and agentic audit pipeline.
- It employs deterministic ranking and tools like Ghidra to extract changed functions and infer root-cause classes from binary evidence only.
- The method informs broader patch-driven security workflows, enabling compile-time analysis, clone detection, and binary patch-state profiling for remediation.
Searching arXiv for Patch2Vuln and closely related patch-to-vulnerability work to ground the article in current papers. Patch2Vuln denotes a patch-centric research direction in which a security fix is treated as primary evidence for reconstructing vulnerability semantics, locating vulnerable code, inferring patch state, or deriving downstream remediation decisions. In the specific system "Patch2Vuln: Agentic Reconstruction of Vulnerabilities from Linux Distribution Binary Patches," the term names a local, resumable pipeline that extracts old/new ELF pairs, diffs them with Ghidra and Ghidriff, ranks changed functions, builds candidate dossiers, and asks an offline agent to produce a preliminary audit, bounded validation plan, and final audit (David et al., 7 May 2026). Related papers use "Patch2Vuln-style" to describe broader patch-driven workflows, including compile-time variant impact analysis, vulnerable clone detection, binary patch-state profiling, patch presence testing, vulnerable-function localization, and verified backporting (Paixão et al., 24 Jun 2026, Alomari et al., 5 May 2025, Xiao et al., 21 Apr 2026).
1. Definition and research scope
In its narrow sense, Patch2Vuln is an offline binary-analysis pipeline for vulnerability reconstruction from Linux distribution updates. The pipeline is evaluated under a restriction to local binary-derived evidence and is intended to infer a plausible root-cause class, input surface, and bounded validation hypothesis from paired old/new Ubuntu .deb packages without access to CVE pages, Ubuntu Security Notices, source patches, package changelogs, known PoCs, or web search (David et al., 7 May 2026).
In a broader literature sense, Patch2Vuln refers to a family of patch-centric methods that start from a disclosed fix and then derive higher-level security conclusions. In highly configurable C/C++ systems, patch analysis can recover a Vulnerability Impact Condition, a Boolean predicate over configuration options that denotes all variants that contained the original flaw (Paixão et al., 24 Jun 2026). In clone-oriented detection, patch-informed vulnerability slices can be stored as vulnerability slicing vectors and later used to detect vulnerable clones and recommend the corresponding patch (Alomari et al., 5 May 2025). In stripped BusyBox firmware, historical vulnerable and patched function states can be used for cross-architecture retrieval and binary-level patch-state profiling (Xiao et al., 21 Apr 2026). This suggests that Patch2Vuln is best understood as a unifying abstraction: the patch is not merely evidence that a defect existed, but a structured signal from which one can infer scope, location, reachability, or remediation.
2. Operational setting and threat model
The operational setting of the Patch2Vuln pipeline is the period immediately after a security update ships and before it is widely deployed. In that window, the most accessible artifacts may be binary packages rather than source patches or advisory text. For each case, the pipeline receives an old and a new .deb and a target ELF path, such as /usr/sbin/tcpdump or a shared library path, and it is explicitly constrained to binary-derived evidence only (David et al., 7 May 2026).
The threat model is realistic but not fully blinded. Package names, symbols, paths, and strings are visible to the agent, which can leak semantic hints such as protocol names or diagnostic text, but explicit advisory and CVE information is hidden and reserved for scoring. The objective is not exploit generation. Rather, the target output is a structured audit that identifies a security-relevant changed code region, infers a plausible root-cause class such as bounds_check, integer_overflow, null_deref, oob_read, uaf, parser_state_bug, or unknown, identifies the likely input medium, and proposes bounded local old/new differential validation (David et al., 7 May 2026).
Comparable operational assumptions recur across related work. PatchLens assumes a vulnerability-fixing patch to a highly configurable C/C++ system and asks which configuration variants were actually vulnerable, entirely statically and without compilation or variant enumeration (Paixão et al., 24 Jun 2026). PPT4J assumes access to upstream source or patch artifacts together with target Java binaries and asks whether a specific patch commit is present in the binaries (Pan et al., 2023). VFArchē assumes disclosed vulnerabilities in OSS libraries and treats vulnerable-function localization as a prerequisite for call-graph-based reachability analysis in SCA (Zhang et al., 22 Jun 2025). Across these settings, the common problem is patch-to-semantics inference under incomplete or indirect observability.
3. Pipeline architecture and evidence model
Patch2Vuln is organized as a local Docker pipeline with three layers: binary processing and diffing, agentic reasoning and validation planning, and sealed manual evaluation. The binary-processing layer extracts old and new packages with dpkg-deb -x, selects the target ELF, imports both versions into a Ghidra project, and computes a function-level binary diff with Ghidriff. The result is a set of changed functions with decompiler snippets and diff metadata (David et al., 7 May 2026).
Because raw binary diff output may contain hundreds of changed functions, the system applies a deterministic ranker before any model reasoning. The ranker uses heuristic scores based on memory-safety and parser-hardening cues, including new comparisons with large constants such as INT_MAX or SIZE_MAX, checks that depend on file length or buffer length before allocation or read, changed arguments to functions such as memcpy, memmove, read, fread, or snprintf, newly added parser-boundary checks or sanity conditions, and new or modified error strings such as "too large", "invalid", "truncated", or "short read". It also applies penalties to huge dispatcher functions and low-confidence matches (David et al., 7 May 2026).
The unit of evidence passed to the model is the candidate dossier. Each dossier contains target metadata, a function identifier, ranking features, diff metadata from Ghidriff, local context including nearby strings and imports, local call context, and compact decompiled old/new snippets. Dossiers are packed into JSON with context-window-aware whole-record inclusion, preserving rank order and recording omissions explicitly (David et al., 7 May 2026).
The agent runs in three stages. The preliminary audit is static reasoning over ranked changed functions, ELF metadata, candidate evidence, and a context manifest; it must hypothesize a root-cause class and propose local differential validation. The validation-plan stage selects bounded local action types such as tcpdump_filter_file, tcpdump_pcap, expat_xmlwf, expat_c_harness, libarchive_archive, generic_malformed_file, or no_local_harness, while remaining forbidden to use web knowledge or to provide weaponized exploit steps. The final audit integrates local validation outcomes and updates confidence, while explicitly distinguishing confirmed evidence from weakened hypotheses (David et al., 7 May 2026).
Other patch-centric systems instantiate different evidence models. PatchLens aligns AST-level patch hunks with source-level presence conditions and resolves building("...") placeholders through lightweight build-system analysis to derive compact Boolean Vulnerability Impact Conditions (Paixão et al., 24 Jun 2026). srcVul extracts vulnerability-related statements and variables from diff files, generates variable-level program slices, encodes them as four-dimensional vulnerability slicing vectors, and uses LSH with cosine similarity for clone detection and patch lookup (Alomari et al., 5 May 2025). PLocator builds anchor graphs from stable comparison and call values in reference binaries and then verifies patch and context paths in stripped target binaries (Dong et al., 29 Jan 2025). PPT4J extracts semantic change sets SA, SD, SM, and SX from Java source patches and then matches source-level semantic features to bytecode blocks with Jaccard-based LCS and weighted voting (Pan et al., 2023).
4. Empirical results and validation behavior
Patch2Vuln is evaluated on 25 Ubuntu .deb package pairs, consisting of 20 security-update pairs and five negative controls, all manually adjudicated against private source-patch and binary-function ground truth. Across the 20 security pairs, the agent localizes a verified security-relevant patch function in 10 and assigns an accepted final root-cause class in 11. Oracle diagnostics show that six security pairs fail before model reasoning because the binary differ or ranker omits the right function, with one additional context-export miss (David et al., 7 May 2026).
The evaluation separates localization, accepted root-cause class, explanation quality, validation-plan quality, and negative-control behavior. All five negative controls are classified as unknown and produce no validation differentials. A separate bounded validation pass produces two target-level minimized behavioral old/new differentials, both for tcpdump, but no crash, timeout, sanitizer finding, or memory-corruption proof (David et al., 7 May 2026). The emphasis is therefore on vulnerability reconstruction rather than exploit confirmation.
The ranking bottleneck is explicit in the reported top- diagnostics. On the 20 security-update pairs, raw Ghidriff order yields Top-1 hits of 2, Top-3 of 6, Top-5 of 6, and Top-25 of 12. The Patch2Vuln ranker yields Top-1 hits of 4, Top-3 of 5, Top-5 of 7, and Top-25 of 12 (David et al., 7 May 2026). This indicates that the custom ranker primarily improves the head of the candidate list rather than overall coverage.
The case studies illustrate both capability and conservatism. In tcpdump bionic, the agent localizes the relevant filter-file function, accepts integer_overflow as the root-cause class, and validation observes an old/new behavioral differential in which the old program emits a strange diagnostic while the new one rejects an oversized filter file as "too large" (David et al., 7 May 2026). In Expat, a main candidate appears at rank 1, the agent localizes the correct function family and accepts integer_overflow, yet validation yields no old/new differential, no crash, and no timeout (David et al., 7 May 2026). In libarchive, the agent localizes the relevant parser families but returns unknown as the final root-cause label after 36 probes produce no differential behavior (David et al., 7 May 2026). A plausible implication is that the system is more reliable as a triage and explanation pipeline than as a proof-producing dynamic validator.
5. Position within patch-centric security research
Patch2Vuln occupies one point in a broader design space of patch-derived security inference. The table summarizes representative systems and their outputs.
| System | Patch-derived artifact | Primary output |
|---|---|---|
| Patch2Vuln | Old/new ELF pairs, changed-function dossiers | Preliminary audit, bounded validation plan, final audit |
| PatchLens | AST-aligned patch hunks plus build predicates | Vulnerability Impact Condition |
| srcVul | Vulnerability slicing vectors from vulnerable/patched code | Vulnerable-clone detection and patch recommendation |
| EvoPatch-IoT | Historical function prototypes and patch-state evidence | Cross-architecture retrieval and patch-state profiling |
| PPT4J | Semantic change sets from Java patches | Patch presence test for Java binaries |
| PLocator | Patch and context anchor paths in binaries | Vulnerable / fixed / irrelevant classification |
| Patch2QL | Differential AST nodes plus CFG/DFG context | Auto-generated CodeQL rules for cognate defects |
| VFArchē | Patch-guided candidate functions or description-only candidates | Vulnerable-function localization |
| VeriPort | Minimal Security Patch plus exploit and test oracles | Verified backported patches across affected versions |
These systems show that patch-derived evidence can be operationalized at several granularities. PatchLens computes precise, human-readable configuration predicates for 1,192 Linux kernel, 289 FFmpeg, and 100 PHP patches, with average VIC complexity of 1.84, 3.23, and 1.04 variables respectively, and observes that CVE descriptions mention only about 1% of required configuration options (Paixão et al., 24 Jun 2026). srcVul builds a database from 65,195 diff files, 60,145 of which contained C/C++ changes, and reports 0.91 precision and 0.75 recall on 1,438 CVEs across Linux kernel, Samba, libvirt, and libgd, while also returning the patch attached to the matched vector (Alomari et al., 5 May 2025). EvoPatch-IoT evaluates on 57 BusyBox versions and 1,020 directed architecture pairs, reaching weighted Hit@1 of 34.56% and Hit@10 of 56.24% for cross-architecture retrieval, together with a CVE-2021-42386 patch-state proxy mean accuracy of 82.44% and mean F1 of 88.47% (Xiao et al., 21 Apr 2026).
At the binary patch-presence layer, PPT4J formulates patch presence testing for Java binaries as and reports an F1 score of 98.5% on binaries that include 110 vulnerabilities, improving the baseline by 14.2% (Pan et al., 2023). PLocator addresses stripped native binaries and reports an average TPR of 88.2% and FPR of 12.9% over 73 CVEs and 27,250 test cases, explicitly distinguishing vulnerable, fixed, and irrelevant functions (Dong et al., 29 Jan 2025). Patch2QL turns pre- and post-patch ASTs into CodeQL rules and reports recall of about 71.4% across eight major OSS projects and about 68.0% on a full 111-project dataset, while also discovering multiple new vulnerabilities and supply-chain cognate defects (Wang et al., 2024). VFArchē extends the patch-centric perspective to vulnerable-function localization for reachability-aware SCA, reporting MRR of 0.78 in Patch-present mode and 0.58 in Patch-absent mode on a 600-CVE Java benchmark, and reducing 78–89% false positives of SCA tools in a real-world study (Zhang et al., 22 Jun 2025). VeriPort pushes the patch-centric paradigm toward remediation, reliably resolving 95.3% of 128 backporting tasks in BackportBench and generating over 5,000 verified backported patches in deployment, while also uncovering incorrectly reported and previously unidentified affected versions (Ghebremichael et al., 21 Jun 2026).
6. Limitations and research directions
The central limitation reported for Patch2Vuln is that binary-diff coverage and local behavioral validation remain the limiting components. Six of the 20 security pairs fail before model reasoning because the binary differ or ranker omits the right function, and one more fails because the relevant context is not exported (David et al., 7 May 2026). Moreover, the validation layer produces only two minimized behavioral differentials, both for tcpdump, and no crash, timeout, sanitizer finding, or memory-corruption proof (David et al., 7 May 2026). The paper accordingly identifies adjacent-version micro-diffs, improved binary diff coverage, richer local behavioral validation, better ranking and candidate reachability tracing, prompt and architecture refinements, and expanded datasets as future directions (David et al., 7 May 2026).
Related work reveals analogous bottlenecks at other levels of abstraction. PatchLens does not fully model the transitive effect of changing header files on all including translation units and can fail or over-approximate when build-system constructs fall outside recognized patterns (Paixão et al., 24 Jun 2026). srcVul does not automatically transform or adapt the recommended patch to the new context and cannot properly handle vulnerabilities that are purely logical with no clear variable-centered pattern (Alomari et al., 5 May 2025). EvoPatch-IoT is heavily tailored to BusyBox, requires extensive historical data and unstripped builds, and notes that major refactoring can weaken geometric and prototype similarity (Xiao et al., 21 Apr 2026). PPT4J depends on Java line number tables and can suffer false negatives under major structural changes or vendor forks (Pan et al., 2023). PLocator cannot distinguish vulnerable versus fixed when the patch introduces no anchor-visible change and currently supports x86 only (Dong et al., 29 Jan 2025). Patch2QL reports difficulty with very small patches, very large patches, multi-purpose commits, and non-local vulnerabilities requiring interprocedural reasoning (Wang et al., 2024). VFArchē depends on repository mapping and manual VF labeling, and its Java-specific implementation does not directly transfer to other ecosystems (Zhang et al., 22 Jun 2025). VeriPort remains constrained by ecosystem coverage and incomplete PoC generation, so some backports are produced but marked unverified (Ghebremichael et al., 21 Jun 2026).
Taken together, these results suggest that Patch2Vuln research is bounded less by the abstract idea of using patches as evidence than by the fidelity of patch-to-code alignment, the quality of intermediate representations, and the strength of local validation. Where those components are strong, patch-derived artifacts support precise tasks ranging from configuration-scope inference and binary patch-state testing to vulnerable-function localization and verified backporting; where they are weak, the dominant failure mode is not semantic reasoning in isolation but upstream evidence loss.
