kernelCTF: add CVE-2025-40019_mitigation_2

[Shinkurt]

Summary

Adds kernelCTF submission exp505 for CVE-2025-40019_mitigation_2, a novelty-only follow-up for the mitigation-v4-6.12 target. The submission documents the huge-PUD page-table adaptation and includes the locked original.tar.gz archive.

Notes

• original.tar.gz SHA256 matches the public spreadsheet hash: 3d19a6653c1e003ad51dc3ff6c37f24607dcf97e60782cf6305fac44c41329af.
• The exploit copy includes --vuln-trigger support for vuln verification.
• This submission is novelty-only because CVE-2025-40019 was already exploited on kernelCTF.

Validation

• git diff --cached --check passed before commit.
• Local kernelctf/check-submission.py origin/master verifies the archive hash and target folder, but currently fails because public spreadsheet row exp505 has an empty CVE column while this PR is for CVE-2025-40019. The BugHunters issue already references CVE-2025-40019.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[Shinkurt]

CLA is now passing after re-running checks. The remaining structure_check failure is due to the public kernelCTF spreadsheet row for exp505 having an empty CVE column, while this PR is correctly under CVE-2025-40019_mitigation_2.

The checker verifies original.tar.gz successfully, then fails at:

The CVE on the public spreadsheet for submission `exp505` is `` but the PR is for `CVE-2025-40019`.

Could the exp505 spreadsheet row be updated to CVE-2025-40019? The accepted BugHunters/Buganizer issue references CVE-2025-40019.

[Shinkurt]

Adding more context on the structure_check failure: the current kernelCTF Google Form does not expose a CVE field for submitters to edit. It records the patch commit and related vulnerability details; the public spreadsheet/checker then expects the CVE column to be populated.

For exp505, the public row contains the correct patch commit and matching exploit hash, but the CVE column is empty. Because check-submission.py derives CVE-2025-40019 from this PR folder and compares it to the spreadsheet CVE cell, every rerun fails before build/repro.

I do not see a PR-side change that can honestly satisfy this gate while keeping the real submission ID exp505. Could a kernelCTF maintainer update the spreadsheet row or advise the correct process for novelty-only rows where the CVE column was not populated?

[Shinkurt]

Additional spreadsheet context: this appears to be isolated to the novelty-only row for exp505.

The public kernelCTF CSV already maps the same patch commit to CVE-2025-40019 on earlier rows, for example:

exp502
Patch commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6bb73db6948c2de23e407fe1b7ef94bf02b7529f
Patch commit title: crypto: essiv - Check ssize for decryption and in-place encryption
CVE: CVE-2025-40019

The current exp505 row has the same patch commit and the correct exploit hash for this PR, but its Patch commit title and CVE cells are empty. The requested spreadsheet update is therefore:

exp505 CVE = CVE-2025-40019
exp505 Patch commit title = crypto: essiv - Check ssize for decryption and in-place encryption

[Shinkurt]

I updated the Google Form edit response for exp505 to include the PR URL, CVE, NVD URL, patch title, patch commit, and BugHunters issue in the private Notes field.

The public CSV now shows the form edit was accepted:

exp505 Last modification: 2026-04-27T11:43:19.691Z

But the public checker fields are still blank:

exp505 Patch commit title: 
exp505 CVE: 

So this still appears to require a maintainer/backend update to the public spreadsheet row before structure_check can pass.

[artmetla]

Hey @Shinkurt . I fixed the CVE issue. But seems like right now there is a problem with debug build and reproduction. Could you have another look please?

[Shinkurt]

@artmetla Thanks for fixing the spreadsheet/CVE side.

I pushed the fixes on the existing PR branch rather than opening a replacement submission. The current head is 1e614f7.

What changed:

• fixed the release/debug build path so both exploit_build and exploit_build_debug pass;
• kept --vuln-trigger working for the vuln verification workflow;
• changed the repro artifact to a single static wrapper that unpacks and runs the exploit body with the matching glibc/loader, restoring the dynamic-userland layout from the original successful kCTF run while still fitting the one-file artifact flow;
• restored the original 3-candidate huge-PUD probe geometry and pointed core_pattern at the harness path (/tmp/exp/exploit) so the root callback works in CI.

The latest run is green now: structure_check, exploit_build, exploit_build_debug, vuln_verify, exploit_repro, and backup_artifacts all passed.