codeql: exclude bundled clang18 toolchain headers from extraction to fix FP alert #1881

[Copilot]

cpp/new-free-mismatch alert #1881 is a structural false positive caused by CodeQL extracting the bundled libc++ headers from bin/clang18.1.8/ as project sources (via BAZEL_LLVM_PATH). The previous paths-ignore approach in codeql-config.yml had no effect because that filter only matches an alert's primary location — for new-free-mismatch that's the allocation site in Envoy code, not <vector> which only appears as the sink in the dataflow path.

Changes

• Both codeql-push.yml and codeql-daily.yml: add env: on the Initialize CodeQL step to suppress extraction at source rather than filtering after the fact:

- name: Initialize CodeQL
  uses: github/codeql-action/init@...
  env:
    CODEQL_EXTRACTOR_CPP_OPTION_EXCLUDE_HEADER_PATTERNS: "bin/clang18.1.8/.*"
    CODEQL_EXTRACTOR_CPP_WIP_IGNORE_SYSTEM_HEADERS: "true"
  with:
    languages: cpp
    trap-caching: false
    config-file: ./.github/codeql/codeql-config.yml

EXCLUDE_HEADER_PATTERNS prevents the toolchain headers from entering the database entirely; WIP_IGNORE_SYSTEM_HEADERS is a belt-and-braces extractor flag for any system headers that slip through via other paths. The paths-ignore in codeql-config.yml is retained as a backstop.

Actual suppression of alert #1881 can only be confirmed on the next daily run against main; a green CodeQL/push on this PR validates the workflow remains functional.

Original prompt

Background

CodeQL alert #1881 (cpp/new-free-mismatch, primary location reportedly inside <vector>) is a structural false positive coming from the bundled libc++ headers in the clang toolchain that the CodeQL workflows download (bin/clang18.1.8/include/c++/v1/...).

A previous attempt to suppress it via paths-ignore in .github/codeql/codeql-config.yml (commit d7bc39f82046a525b600bf5f8cc6ee63471bfe70, PR #44609) had no effect on the alert. The most likely reason is that paths-ignore is matched against an alert's primary location only, while for cpp/new-free-mismatch the primary location is the allocation site (often re-rooted into Envoy code through templated std::vector instantiations), with <vector> only appearing as a sink in the dataflow path. paths-ignore is also known to be unreliable for C/C++ when system/standard-library headers are involved.

Goal

Stop the libc++ headers from being extracted in the first place, rather than trying to filter results after the fact. If CodeQL never indexes those headers, no path can terminate in them and the FP cannot be produced.

Changes

In both CodeQL workflows, add env: to the Initialize CodeQL step (so the variables are set during extraction) configuring the C++ extractor to:

1. Exclude the bundled clang toolchain headers from extraction.
2. Enable the (currently WIP) "ignore system headers" extractor flag as a belt-and-braces measure.

Concretely, set on the Initialize CodeQL step in both .github/workflows/codeql-push.yml and .github/workflows/codeql-daily.yml:

    - name: Initialize CodeQL
      uses: github/codeql-action/init@95e58e9a2cdfd71adc6e0353d5c52f41a045d225  # codeql-bundle-v4.35.2
      env:
        # Don't index the bundled libc++/clang toolchain headers. Alerts
        # whose dataflow terminates in <vector> et al. (e.g. cpp/new-free-mismatch)
        # are structural false positives produced when the extractor sees the
        # toolchain headers as project sources via BAZEL_LLVM_PATH.
        # paths-ignore in codeql-config.yml only matches alert *primary*
        # locations, which is not where these alerts are rooted, so we have
        # to drop the headers at extraction time instead.
        CODEQL_EXTRACTOR_CPP_OPTION_EXCLUDE_HEADER_PATTERNS: "bin/clang18.1.8/.*"
        CODEQL_EXTRACTOR_CPP_WIP_IGNORE_SYSTEM_HEADERS: "true"
      with:
        languages: cpp
        trap-caching: false
        config-file: ./.github/codeql/codeql-config.yml

Do not remove the existing paths-ignore in .github/codeql/codeql-config.yml — leave it as a backstop.

Files to change

• .github/workflows/codeql-push.yml — add the env: block to the Initialize CodeQL step.
• .github/workflows/codeql-daily.yml — add the same env: block to the Initialize CodeQL step.

Out of scope

• Do not change codeql-config.yml.
• Do not add query-filters or exclude the cpp/new-free-mismatch query.
• Do not modify the build steps.

Validation

The PR's CodeQL/push workflow should run successfully and complete a CodeQL analysis. The actual FP suppression of alert 1881 can only be confirmed once the daily run executes against main, so a green CI run on this PR is sufficient.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: this ones a fucker weve been trying to get rid of it one way or another

latest attempt was d7bc39f but that has made no difference

Assistant: Let me try to read the alert details and check whether the alert's primary location is actually inside the libc++ headers (because paths-ignore filters by primary location only).

Assistant: I can't read the alert metadata through the API directly (/code-scanning/alerts/{n} isn't exposed to me), but looking at d7bc39f and the commit message ("cpp/new-free-mismatch in <vector>") I'm fairly sure why your fix didn't move the needle. A few things stacked against you:

Why paths-ignore almost certainly isn't going to kill 1881

1. paths-ignore is matched against an alert's primary location only. For cpp/new-free-mismatch the primary location is the allocation site (the new / new[]), not where delete[] is called. If anywhere in the flow CodeQL has rooted the allocation in an Envoy .cc/.h (very likely for a templated std::vector instantiation), the primary location is in Envoy, not in include/c++/v1/vector, and your glob never matches. The <vector> you see in the alert UI is just the sink in the path, which is what makes it look like the alert lives in libc++.

2. For compiled languages, paths / paths-ignore are post-filters with known soft spots around system/third-party headers. GitHub's own docs and the CodeQL C/C++ team have repeatedly stated this filter does not reliably suppress results that touch system/standar...

This pull request was created from Copilot chat.

[repokitteh-read-only]

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #44767 was opened by Copilot.

see: more, trace.