{"id":"83aa5f01-8cde-4f81-bba4-e16362667417","arxiv_id":"2411.18347","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"TransferFuzz transfers function-call and key-byte traces from a CVE-reported binary to a code-reusing target binary, and reports 1.0 precision and recall when verifying propagated vulnerabilities across 15 CVEs and 76 binaries.","lead":"TransferFuzz guides fuzzing of a new binary by replaying execution traces taken from an older, known-vulnerable binary that shares reused code, then generates proof-of-concept crashes to confirm that the bug transfers. The authors report verifying 38 propagated vulnerabilities across 15 CVE cases, expanding the reported affected-software scope from 15 to 53 binaries, with 2.5 to 26.2x speedups over existing fuzzers.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The 38/38 verification claim is not supported unless ground-truth labels are independent of TransferFuzz's own crash oracle; Section V.D contradicts the count for three cases.","rationale":"The reader's stated weakest assumption, the transferability of function-level traces and key bytes from the basic binary to the target binary, is a genuine technical risk and one I agree is load-bearing for the method's general applicability. However, the single most immediately decisive problem for the paper's headline numbers is that the evaluation's ground truth is not shown to be independent of the tool being evaluated. The manual filtering in Section V.A is unspecified; a fuzzer cannot certify true negatives, yet Table 2 attributes 108 TNs to TransferFuzz; and Section V.D explicitly admits that three of the claimed 38 could not be generated by any method (including TransferFuzz) without directly using the basic POC. That internal inconsistency means the reported 38/38 success, precision 1.0, and recall 1.0 may be inflated by shortcut POC reuse or by circular labeling. These issues do not by themselves prove the method is ineffective, and the relative TTE improvements on the 35 listed cases are still informative, so the existing CONDITIONAL verdict remains appropriate. My concern is therefore an UNCHANGED verdict: the paper should not be accepted as-is, but the path to resolving the issue is clearly reproducible independent verification of the 38 ground-truth labels and a corrected accounting of which cases were validated by TransferFuzz's trace-guided fuzzing as opposed to direct POC reuse.","tokens_in":20244,"tokens_out":9648,"duration_ms":86565,"concrete_test":"For each of the 38 entries claimed in Table 2 (including the three absent from Table 3), independently re-verify the ground truth without using TransferFuzz: build the target from source with AddressSanitizer (or an independent debugger), replay the claimed TransferFuzz-generated POC, and confirm the crash occurs at the exact vulnerable function and instruction matching the CVE root cause (e.g., TIFFVGetField with tag=0x13d for CVE-2016-10095), not merely at an address that some alignment step mapped to the same function. For each case, also record whether the basic POC was directly used as a seed; remove any such case from the 'validated by TransferFuzz' count. If any of the 38 fail this re-check, the reported 38/38 precision/recall and the 15-to-53 scope expansion are not supported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The headline claim that TransferFuzz 'successfully validated all 38 propagated vulnerability samples' (Section V.C, Table 2) depends on ground-truth labels being both correct and independent of TransferFuzz's own outputs. Section V.A states only that 146 potential vulnerabilities were 'manually filtered' to 38 true positives and 108 false positives; the filtering protocol is not described, so we cannot tell whether labels came from source-level patch analysis, independent crash reproduction, or the same GDB crash-address check that TransferFuzz uses (Section IV). This matters because fuzzing cannot establish a true negative: failure to crash within the 12-hour budget does not prove absence of a vulnerability, yet Table 2 reports TN=108 for TransferFuzz as if non-propagation had been established. Moreover, Section V.D says 'without using POCs of basic binary, none of the methods, including TransferFuzz, could generate POCs for three vulnerabilities (CVE-2017-18267, CVE-2018-11102, and CVE-2018-20330)', which contradicts Table 2 where all three appear as TransferFuzz true positives. The only way to reconcile this is that those three were validated by directly using the basic POC, the shortcut explicitly excluded from the RQ2 efficiency comparison. If the manual filtering used TransferFuzz's own generated crashes as evidence, then the reported precision and recall of 1.0 and the expansion from 15 to 53 affected binaries are circular rather than independently demonstrated.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes TransferFuzz, a framework for verifying whether vulnerabilities propagated through code reuse are actually triggerable in a target binary. It extracts two kinds of historical traces from the basic binary and its POC—function call sequences (FCS) and key bytes that influence branch conditions in the reused code—aligns these traces to the target binary via function matching, and uses them to guide fuzzing through a Key Bytes Guided Mutation strategy and a Nested Simulated Annealing energy schedule. The evaluation covers 15 CVEs and 76 binaries, and the paper reports precision 1.0 and recall 1.0, claiming that TransferFuzz 'successfully validated all 38 propagated vulnerability samples,' with verification speeds 2.5 to 26.2 times faster than existing directed fuzzing baselines, and expands the number of affected binaries from 15 to 53.","tokens_in":20415,"tokens_out":6754,"duration_ms":57504,"significance":"If the evaluation is sound, TransferFuzz addresses a real gap: code-reuse and patch-presence detectors identify potentially vulnerable code but do not establish that the vulnerability is reachable and controllable in a new binary, and prior directed fuzzing is slow on complex triggers. The idea of transferring runtime traces from a known vulnerable binary to a code-reusing target is plausible and novel, and the TTE data—10/10 successful runs on multiple cases where baselines fail, with large consistent speedups—provide credible evidence that the approach works on the studied dataset. The paper also makes its prototype and dataset available, which supports reproducibility. However, the headline accuracy claims depend on a manually constructed ground truth whose protocol is not described, and the treatment of true negatives and of three specific CVEs contains internal inconsistencies that must be resolved before the central claim can be accepted.","major_comments":[{"comment":"The note in Section V.D states that 'without using POCs of basic binary, none of the methods, including TransferFuzz, could generate POCs for three vulnerabilities (CVE-2017-18267, CVE-2018-11102, and CVE-2018-20330).' This directly contradicts the claim in Section V.C and in the abstract that TransferFuzz 'successfully validated all 38 propagated vulnerability samples,' because Table 1 lists exactly these three CVEs among the 38 propagated samples (one target each: xpdf, ffmpeg, mozjpeg). The only way to reconcile the two statements is that these three cases were validated by directly using the basic POC—the shortcut that Section V.D explicitly excludes from the RQ2 efficiency comparison. Please report the numbers separately (for example, 35/38 verified by trace-guided fuzzing and 3/38 verified by direct POC reuse) and revise the abstract, Section V.C, and the 'all 38' phrasing accordingly.","section":"Section V.D and Table 2"},{"comment":"The construction of the ground-truth labels is not described. The sentence 'After manually filtering out 108 false positives' gives no protocol: it does not state whether the manual filtering was based on source-level patch analysis, independent crash reproduction, or the same GDB crash-address check that TransferFuzz uses for verification (Section IV). If the labels and the TransferFuzz oracle share the same crash-address criterion, then the precision and recall values of 1.0 in Table 2 are circular. Please provide a detailed labeling protocol, including the evidence used for each of the 146 candidates, who performed the labeling, and confirmation that the labels were fixed before running TransferFuzz.","section":"Section V.A"},{"comment":"The TN=108 entries for TransferFuzz and for all other methods are not justified by the experimental design. A 12-hour fuzzing run without a crash does not prove that a vulnerability is not triggerable; it only shows that no crash occurred within the budget. The paper itself acknowledges in Section III.A that the outcomes 'reuse code is reached but the vulnerability is not triggered' and 'the reuse code area is not reached' imply only that the vulnerability 'cannot be or is difficult to be triggered,' and that 'further manual verification is required.' Therefore, the TN column should not be presented as 'correctly detected as non-propagated.' Please either provide independent verification for the 108 negative cases or restrict the precision/recall computation to the positive samples and label the no-crash outcomes as 'not triggered within the budget.'","section":"Table 2 and Section V.C"},{"comment":"The method's correctness rests on the transferability premise that 'the basic binary and target binary tend to have the same vulnerability triggering path in the reused code area due to having the same code,' together with the assumption that the function-level traces remain valid after FCG alignment. The evaluation does not report how many of the 15 CVEs involved stripped target binaries where function matching relied on LibAM, nor whether any alignment mismatches or reused-code modifications (e.g., recompilation, different call context) were observed. Since a misalignment would lead the fuzzer away from the vulnerability path and could affect both generated POCs and 'cannot trigger' verdicts, please report the alignment results for each case, including how often function names were present and how often LibAM was used.","section":"Section III.B.1"}],"minor_comments":[{"comment":"The term 'Path Presentation Detection methods' appears to be a typo for 'Patch Presence Detection methods'; please correct it.","section":"Section II"},{"comment":"'cann't' is a typographical error; it should be 'cannot'.","section":"Section V.D"},{"comment":"The name is spelled inconsistently as 'TrasnferFuzz' in several places; please make the spelling uniform throughout.","section":"Section V.C and Section V.F"},{"comment":"The notation '0.5Ti' in Equation (1) is ambiguous; it should be written as 0.5·T_i to make clear that the nested product multiplies 0.5 by each later temperature, and the correspondence between the equation and the loop in Algorithm 2 should be stated explicitly.","section":"Equation (1) and Algorithm 2"},{"comment":"The bottom row 'µTTE inc (all binaries)' is unclear about which binaries are included in the aggregate percentage (e.g., only those where the baseline triggered at least one run) and how the percentage is computed from the per-run µTTE values; please define this row precisely.","section":"Table 3"},{"comment":"The text refers to 'Vul-10' and similar labels, but Table 3 lists entries by number and CVE only; please align the in-text references with the numbering used in the table.","section":"Section V.D"}],"recommendation":"major_revision","confidential_remarks":"The core idea is promising and the TTE data provide genuine evidence that trace-guided fuzzing can outperform directed fuzzers on cross-binary propagation verification. However, the current manuscript contains a substantive internal contradiction about the three CVEs that cannot be generated without direct POC use, and the manual ground-truth construction is under-specified to the point where the precision/recall claim is not independently assessable. Both issues are fixable with a careful revision in which the authors separate the settings, describe the labeling protocol, and reframe the true-negative results. I would advise the editor that the paper is not acceptable in its present form but is a credible candidate after major revision."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"TransferFuzz gives the vulnerability-verification community a genuinely new tool: it extracts function-call sequences and key input bytes from the CVE-documented binary and uses them to steer a fuzzer on a different binary that reuses the vulnerable code. That is not in OCTOPOCs (which splices POC bytes) or POC migration (which moves POCs across versions of the same software). The reported speedups are large, and the ablation broadly supports the value of both the key-bytes dictionary and the nested simulated annealing scheduling.\n\nThe soft spots are real but mostly fixable. The biggest is the ground truth. The authors manually reduced 146 potential vulnerabilities to 38 true positives and 108 false positives, but they never describe the filtering protocol. Precision and recall of 1.0 therefore rest on labels whose independence from TransferFuzz's own crash oracle is unknown. Fuzzing also cannot establish a true negative, so the 108 TNs are only as good as that manual label set. Second, three CVEs (2017-18267, 2018-11102, 2018-20330) are counted as TransferFuzz true positives in Table 2, yet Section V.D says that without using the basic POC, none of the methods including TransferFuzz could generate POCs for them. The natural reading is that those three were verified by directly using the basic POC, a shortcut that RQ2 explicitly excludes. That is not fatal, but it should be stated plainly rather than buried. Third, the ablation has one case (swftoperl under 2017-11733) where removing NSA is slightly faster than the full system, contradicting the claim that NSA helps every case; and the conclusion says ten vulnerabilities while the abstract says fifteen. These are presentation defects, not evidence of a broken core.\n\nThe transferability premise—that traces stay valid in the target after function matching—is assumed rather than demonstrated across different compilers or optimization flags. The dataset mostly consists of same-project binaries, so the premise is plausible inside the evaluation, but the generality is untested.\n\nBottom line: this deserves a serious referee. The core idea is novel, the mechanism is coherent, and the evaluation is strong in scale if not in transparency. I would ask the authors to reveal the ground-truth protocol, reconcile the three shortcut cases, and fix the ablation and counting inconsistencies. With those, I'd trust the headline claims; without them, treat 38/38 as an upper bound.","headline":"TransferFuzz's trace-transfer idea is a real step forward for vulnerability verification, but the 38/38 claim needs a transparent ground-truth protocol and a clear statement about three shortcut-validated cases.","tokens_in":21122,"tokens_out":5144,"would_cite":true,"duration_ms":41988,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"TransferFuzz claims that the crash history of a known-vulnerable binary can guide fuzzing of any binary reusing its code, producing a proof-of-concept that verifies the propagated vulnerability.","keywords":["vulnerability propagation","code reuse","trace-guided fuzzing","historical trace","key bytes","simulated annealing","proof-of-concept generation","binary analysis"],"falsifier":"Recompile the same reused library with a one-line change that makes the vulnerable path unreachable but keeps function names and crash addresses identical; if TransferFuzz still emits a crashing POC or labels the patched binary as verified, the crash-address oracle and trace-transfer premise are both implicated. Conversely, take a target known to be triggerable from a CVE POC and strip its symbols; if function matching misaligns the trace and the fuzzer cannot reproduce the crash, the claimed recall of 1.0 would not transfer outside the dataset.","tokens_in":19905,"feed_emoji":"🐞","tokens_out":9594,"duration_ms":81759,"temperature":0.7,"pith_summary":"TransferFuzz tries to prove that a vulnerability spread by code reuse can be automatically verified in a new binary by transferring the original binary's execution history rather than its proof-of-concept file. The paper's claim is that two artifacts extracted from the known-vulnerable binary—the function call sequence that reaches the crash and the specific input bytes that satisfy branch checks in the reused code—are enough to guide a fuzzer of the target binary to a working proof-of-concept. If this holds, software-security teams can replace similarity-based 'this binary contains the vulnerable code' warnings with 'here is an input that crashes it,' which is what makes the affected-software scope of a CVE actionable. On the paper's dataset TransferFuzz reports perfect precision and recall, verifies all 38 propagated samples, and expands the affected binaries for 15 CVEs from 15 to 53.","feed_headline":"Trace-guided fuzzing verifies copied-code bugs in minutes","feed_subtitle":"The old POC's call path and key bytes guide the new binary's fuzzing, widening CVE impact from 15 to 53 binaries.","key_machinery":"The load-bearing object is the historical trace, defined as two runtime artifacts harvested from the basic binary: a function-level trace (the call sequence from program entry to the crashing function, enriched by fuzzing the basic binary) and key-byte traces (proof-of-concept bytes that taint analysis shows reaching conditional statements inside the reused code). The mechanism that carries the argument is the trace-guided fuzzer built on these artifacts: a Nested Simulated Annealing algorithm maintains one annealing schedule per observed state in the call sequence, so energy flows to seeds that advance along the recorded path while earlier states are never fully abandoned, and Key Bytes Guided Mutation inserts the extracted bytes as a mutation dictionary to bypass branch constraints in the reused code.","core_discovery":"The central claim is that the vulnerability-triggering behavior of reused code is portable. TransferFuzz records function-level traces by running the CVE-described binary on its proof-of-concept and by directed-fuzzing that binary for additional crash paths; it records key-byte traces by taint-tracking which proof-of-concept bytes flow into conditional branches inside the reused functions. It then aligns the function names or matched functions from the basic binary to the target binary, builds a state machine from the recorded call sequence, and uses nested simulated annealing to schedule fuzzing energy so that the target binary explores the transferred path before wasting effort elsewhere. A dictionary of extracted key bytes is applied during mutation to satisfy the branch checks that would otherwise block deep exploration. The paper's stated result is that this trace-guided process validates all 38 propagated vulnerability samples in its evaluation, matching crashes by address, and does so faster than directed-fuzzing baselines.","pith_inferences":["Beyond the paper, the key-byte dictionary is effectively a portable input-to-state map: it might transfer to fork-level regression testing or to patch-presence testing, where the same bytes could decide whether a branch behaves like the vulnerable or the patched version.","Section V.D records that without starting from the basic POC, none of the methods—TransferFuzz included—could trigger three CVEs (CVE-2017-18267, CVE-2018-11102, and CVE-2018-20330), so the reported recall of 1.0 is defined on the 38 samples actually verified, not on every propagated vulnerability in the dataset.","The negative verdicts (reused code reached but no crash) are bounded by the fuzzing budget and by the crash-address oracle; a cleaner evaluation would apply the same pipeline to known-patched binaries to measure how often it wrongly reports or wrongly clears them.","A build-level test with the same library compiled under different optimization flags and linked through different callers would isolate whether trace transferability comes from the reused code itself or from the specific binaries in the dataset."],"forward_implications":["If the trace-transfer claim is correct, verifying a propagated vulnerability reduces to replaying guiding information rather than rediscovering the path from scratch; the paper reports most verifications finishing within minutes and several previously untriggerable logic-heavy vulnerabilities becoming triggerable.","CVE impact statements can be corrected automatically: the paper reports that 15 vulnerabilities' affected binaries grew from 15 to 53 because a generated proof-of-concept, not a similarity score, confirmed each new target.","Target binaries with different input formats than the basic binary are no longer out of reach: only the trace is transferred, so a string-based proof-of-concept from one tool can guide fuzzing of an ELF-reading tool in the same library.","The approach acts as a downstream filter for code-reuse detectors, converting their high-recall low-precision findings into verified crashes; on the dataset the reported precision rises from the reuse detector's 0.26 to TransferFuzz's 1.0."],"supporting_citations":[{"why":"Supplies the code-reuse detection and function-matching step that identifies the reused vulnerable functions and aligns stripped binaries before trace transfer.","marker":"[5]"},{"why":"Supplies the directed-fuzzing baseline and simulated-annealing energy model that the nested annealing scheme extends, plus part of the evaluation dataset.","marker":"[20]"},{"why":"Used offline to enlarge the function-level traces by fuzzing the basic binary into additional crash paths; also a timing baseline.","marker":"[23]"},{"why":"Prior method that transfers proofs-of-concept between binaries; its input-format and path-explosion limits motivate the key-byte dictionary design.","marker":"[24]"},{"why":"Data-dependency directed fuzzer used as a comparison baseline and a dataset source.","marker":"[25]"},{"why":"Selective-instrumentation directed fuzzer on which TransferFuzz is built; also a comparison baseline.","marker":"[31]"}],"fun_headline_variants":["Trace-guided fuzzing verifies reused-code vulnerabilities","Historical traces speed up propagated vulnerability checks","Fuzzing with past traces pinpoints copied code bugs","Transferring crash traces to fuzz reused functions","Key bytes from old POC guide new binary fuzzing"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The traces taken from the original vulnerable binary still describe the same vulnerability-triggering path after the functions are matched into the target binary: the reused code must behave the same way when called, the key bytes that satisfied its branch checks must still satisfy them, and a crash at the same address is taken as proof of the same bug.","fun_headline_variants_meta":{"raw":{"variants":["Trace-guided fuzzing verifies reused-code vulnerabilities","Historical traces speed up propagated vulnerability checks","Fuzzing with past traces pinpoints copied code bugs","Transferring crash traces to fuzz reused functions","Key bytes from old POC guide new binary fuzzing"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000165,"raw_usage":{"total_tokens":1290,"prompt_tokens":1026,"completion_tokens":264,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":642,"completion_tokens_details":{"reasoning_tokens":189}},"tokens_in":642,"tokens_out":264,"duration_ms":2678,"temperature":1.0,"reasoning_tokens":189,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T11:17:58.670206+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Recompile the same reused library with a one-line change that makes the vulnerable path unreachable but keeps function names and crash addresses identical; if TransferFuzz still emits a crashing POC or labels the patched binary as verified, the crash-address oracle and trace-transfer premise are both implicated. Conversely, take a target known to be triggerable from a CVE POC and strip its symbols; if function matching misaligns the trace and the fuzzer cannot reproduce the crash, the claimed recall of 1.0 would not transfer outside the dataset.","supporting_citations":[{"cited_title":"LibAM: An Area Matching Framework for Detecting Third-party Libraries in Binaries","cited_arxiv_id":"2305.04026","evidence_quote":"Supplies the code-reuse detection and function-matching step that identifies the reused vulnerable functions and aligns stripped binaries before trace transfer."},{"cited_title":"Windranger: a directed greybox fuzzer driven by deviation basic blocks,","cited_arxiv_id":null,"evidence_quote":"Used offline to enlarge the function-level traces by fuzzing the basic binary into additional crash paths; also a timing baseline."},{"cited_title":"Octopocs: automatic verifica- tion of propagated vulnerable code using reformed proofs of concept,","cited_arxiv_id":null,"evidence_quote":"Prior method that transfers proofs-of-concept between binaries; its input-format and path-explosion limits motivate the key-byte dictionary design."},{"cited_title":"{DAFL}: Directed grey- box fuzzing guided by data dependency,","cited_arxiv_id":null,"evidence_quote":"Data-dependency directed fuzzer used as a comparison baseline and a dataset source."},{"cited_title":"Selectfuzz: Efficient directed fuzzing with selective path exploration,","cited_arxiv_id":null,"evidence_quote":"Selective-instrumentation directed fuzzer on which TransferFuzz is built; also a comparison baseline."}],"review_version":1}