kernelCTF: add CVE-2025-37964_lts

[unknownhad]

This adds the public exploit submission for kernelCTF exp659 on lts-6.12.96.

The environment slot is already marked duplicate. This PR requests only the separate, discretionary novel-techniques review described in docs/novel-techniques.md; it does not claim the base slot or vulnerability-first eligibility.

Vulnerability

• CVE-2025-37964
• Target: lts-6.12.96
• Subsystem: arch/x86/mm/tlb.c
• Effective stable fix: 0650f1c8b6b02b3edd489848fb9daa325eccf42c

Included

• The immutable original archive recorded for exp659
• Schema-v3 metadata
• Vulnerability, exploitation, and novelty documentation
• Source, kernelXDK wrapper/database, Makefile, and static exploit binary
• A --vuln-trigger path for KASAN verification

Local validation

• Clean-tree check-submission.py structure, schema, archive-hash, flag-target, and exploit-target checks pass
• original.tar.gz SHA-256 matches the public exp659 record
• A clean rebuild with libxdk/v0.1 is byte-for-byte identical to the committed binary
• Parent and fixed verifier-kernel layouts were reproduced from clean builds
• No reliability percentage or stability bonus is claimed

Known external metadata blocker

The existing form response stores the correct stable patch and was resubmitted without changing the flag or exploit hash. Its public Last modification advanced to 2026-08-12T12:54:29.001Z, but the derived Patch commit, Patch commit title, CVE, and Patch commit submission time cells remain blank. The official clean-tree checker consequently fails only with:

The CVE on the public spreadsheet for submission `exp659` is `` but the PR is for `CVE-2025-37964`.

0650f1c8... is a stable-specific fix released in v6.12.97; its commit message states there is no single upstream commit to cherry-pick. The equivalent later mainline ordering fix is 83b0177a6c48..., tracked separately as CVE-2025-40174. The current verifier mirror has a v6.12.97 tag row for 0650f1c8... but no upstream row, while vuln-verify/verify.py requires get_upstream_commit() before selecting the stable fix.

Maintainer assistance is requested to populate exp659 with CVE-2025-37964 and stable patch 0650f1c8..., and to add a mirror mapping or explicit stable-only verifier path. Please do not replace the submission CVE or patch URL with CVE-2025-40174 / 83b0177a....

Related Bug Hunters issue: 545532944.

[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.

[unknownhad]

CLA now passes under the intended contributor identity (unknownhad, commit email anand.himanshu17@gmail.com). The force-update changed commit identity metadata only; both commit trees and all file bytes are unchanged.

The remaining structure_check failure is the external public-sheet condition documented in the PR body: exp659 still has blank Patch commit, Patch commit title, CVE, and Patch commit submission time cells even though the existing form response stores stable fix 0650f1c8b6b02b3edd489848fb9daa325eccf42c and its Last modification advanced to 2026-08-12T12:54:29.001Z after resubmission.

Could a kernelCTF maintainer populate exp659 as CVE-2025-37964 with that stable patch and provide the stable-only verifier mapping/handling described above, then rerun the structure check? The equivalent 83b0177a... mainline fix is CVE-2025-40174 and should not replace this submission's CVE or patch URL.

[matrizzo]

Hi, CVE-2025-37964 doesn't list any of the commit you mentioned as a fix, are you sure it's the correct CVE?

[unknownhad]

I rechecked the complete exploit and commit history and you right.
Current CVE-2025-37964 record does not list 0650f1c8 , it still treats d8739209 as the effective 6.12 fix.

0650f1c8 (gregkh/linux@0650f1c) explicitly states that the stable backports of fea4e317, the CVE-2025-37964 fix, placed the relevant blocks in the wrong order and therefore left CVE-2025-37964 unfixed. lts 6.12.96 contains exactly that ordering: tlb_gen is read before LOADED_MM_SWITCHING is published. 0650f1c8, released in 6.12.97, corrects that ordering and closes the race exercised by this exploit.

I also checked CVE-2025-40174. Its affected range begins at 6.14 and it is tied to 209954cbc7d0 , which was not backported to 6.12.y, so I do not believe CVE-2025-40174 is the correct replacement.

that's why CVE-2025-37964 is the best technical and provenance based mapping. The current CNA metadata is inconsistent because it does not include the later stable correction and presently marks 6.12.96 unaffected. Can you confirm whether kernelCTF wants this recorded as CVE-2025-37964 with the effective stable fix or this should wait for a Linux CNA update?