[Brandon Myers (bmyerz0)]

Security scans reveal that driver.py of the CPU backend executes code from the disk without checks on ownership, permissions, signature, or hash. An attacker could thereby enable arbitrary code execution by priming the cache.

Mitigation

Use ownership and permissions.

The CPU backend now builds and loads launchers from private temporary directories instead of reusing libraries from Triton’s shared disk cache. Generated artifacts are checked for ownership and file type, then made owner-read-only before loading; Windows support is removed to limit the burden of maintenance. Loaded modules are reused within each process, while a new process recompiles its launchers on first use.

Other changes

Another code injection vector is also mitigated.
launcher_src.replace(kernel_placeholder_name, kernel_name) potentially allows an attacker to use kernel_name to inject code into the generated source before compilation. Mitigate by checking that the name looks like an identifier.

[Copilot]

🟡 Changes recommended

Concurrent first launches can retain duplicate libraries, and fork-based workers can leave build artifacts behind.

2 open findings

• Synchronize concurrent kernel cache builds and loads · New
• Clean up worker artifacts when multiprocessing workers exit · New

What changed in this PR

Hardens CPU launcher loading by replacing Triton’s shared disk cache with private builds and process-local module reuse.

Changes:

• Builds launchers in private directories and validates artifact ownership, type, and permissions.
• Validates kernel names and removes Windows support.
• Registers cleanup for retained build directories.

File	Description
backend/​driver.py	Adds private launcher builds, artifact checks, process-local reuse, and cleanup.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.