René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Rust: slice elements do not flow to `for_each` closure parameters","articleBody":"**Description of the issue**\n\nData flow does not reach the parameter of a closure passed to `for_each` on a slice iterator, as in `a.iter().for_each(|x| sink(x))`. The equivalent `for x in a.iter() { sink(x) }` loop works. The cause appears to be the model precedence rule: the callback summary added in #22287 hides the manual `Iterator::for_each` model for this method.\n\n### Example\n\n```rust\nfn source() -> String {\n    String::from(\"secret\")\n}\n\nfn sink(s: &String) {\n    println!(\"{s}\");\n}\n\nfn main() {\n    let a = [source()];\n    a.iter().for_each(|x| sink(x)); // A\n    for x in a.iter() {\n        sink(x); // B\n    }\n}\n```\n\nThe program prints `secret` twice: in both A and B, `x` is the element of `a`.\n\nQuery: taint tracking from each `source()` call to each `sink` argument.\n\n```ql\nimport rust\nimport codeql.rust.dataflow.DataFlow\nimport codeql.rust.dataflow.TaintTracking\n\nmodule Config implements DataFlow::ConfigSig {\n  predicate isSource(DataFlow::Node n) {\n    exists(Call c | c.getStaticTarget().getName().getText() = \"source\" | n.asExpr() = c)\n  }\n\n  predicate isSink(DataFlow::Node n) {\n    exists(Call c | c.getStaticTarget().getName().getText() = \"sink\" |\n      n.asExpr() = c.getPositionalArgument(0)\n    )\n  }\n}\n\nmodule Flow = TaintTracking::Global\u003cConfig>;\n\nfrom DataFlow::Node source, DataFlow::Node sink\nwhere Flow::flow(source, sink)\nselect sink, source\n```\n\nResult, the same on CodeQL 2.27.4 (`codeql/rust-all` 0.2.25) and 2.27.2 (0.2.23):\n\n| sink | source |\n|---|---|\n| `x` at line 13 (B) | `source()` at line 10 |\n\nThere is no row for A (line 11).\n\n### Cause (our reading of the source)\n\n1. `core::slice::iter::Iter` has its own `for_each` (it overrides the trait's default method), so the call resolves to `\u003ccore::slice::iter::Iter as core::iter::traits::iterator::Iterator>::for_each`.\n2. The manual model `\u003ccore::iter::traits::iterator::Iterator>::for_each`: `Argument[self].Element` -> `Argument[0].Parameter[0]` (`rust/ql/lib/codeql/rust/frameworks/stdlib/core.model.yml`) reaches that method only as an inherited model. `interpretPath` in `ModelsAsData.qll` gives inherited models provenance `hq-generated` and `isExact = false`.\n3. `SummarizedCallableWithCallback` in `ModelsAsData.qll` (#22287) gives the same method a `heuristic-callback` summary, `Argument[0]` -> `Argument[0].Parameter[closure-self]`, with provenance `hq-generated` and `isExact = true`.\n4. `RelevantModel::isRelevantModel` in the shared `FlowSummaryImpl.qll` drops an inexact model when the same callable has an exact model with the same verification. So the inherited `Element` -> `Parameter[0]` model is dropped. The only summary left says that the closure is called, but not with what.\n\nThe comment in `interpretPath` says inherited models are generated \"so that source code definitions and exact generated models take precedence\". That fits generated models of the method itself. The callback summary carries no element flow, though, so here it hides the only model that does.\n\n### Confirming the cause\n\nAdding a manual model for the exact method restores the flow at A. The first row restores the missing element-to-parameter flow. The second row is not needed for this query; it keeps the closure edge from #22287, which a manual model on the method would otherwise suppress:\n\n```yaml\nextensions:\n  - addsTo:\n      pack: codeql/rust-all\n      extensible: summaryModel\n    data:\n      - [\"\u003ccore::slice::iter::Iter as core::iter::traits::iterator::Iterator>::for_each\", \"Argument[self].Element\", \"Argument[0].Parameter[0]\", \"value\", \"manual\"]\n      - [\"\u003ccore::slice::iter::Iter as core::iter::traits::iterator::Iterator>::for_each\", \"Argument[0]\", \"Argument[0].Parameter[closure-self]\", \"value\", \"manual\"]\n```\n\nWith these two rows (tested on CodeQL 2.27.2), the query finds both A (`x` at line 11) and B (`x` at line 13), each from `source()` at line 10.\n\n### Possible fix\n\nA suggestion only; we have not tested it. Don't let the exact `heuristic-callback` summary cause other, inexact summaries of the same callable to be discarded. The callback summary itself can stay subject to the normal manual and neutral-model precedence rules.\n\nChanging the callback summary to `isExact = false` instead is not enough: an exact generated summary could then suppress it, losing the captured-variable flow added by #22287.\n\n### Scope\n\nWe reproduced this only for `for_each` on `core::slice::iter::Iter`. Other iterator types that override a closure-taking `Iterator` method may have the same problem; we have not tested them.\n","author":{"url":"https://github.com/bdrodes","@type":"Person","name":"bdrodes"},"datePublished":"2026-11-09T18:23:11Z","url":"https://github.com/github/codeql/issues/23064"}