cpu: fail closed when --max_cpus exceeds available CPUs

[h1-mrz]

Summary

When --max_cpus is larger than the number of available CPUs, initCpu() used to log a warning and return success WITHOUT setting any CPU affinity mask. The sandbox then ran on all available CPUs, silently defeating the user-requested CPU cap. Convert the warning to an error and fail closed so nsjail aborts loudly instead of launching with a less-restrictive cap than requested.

Repro (before fix)

$ nsjail --max_cpus 9999 -- /usr/bin/bash -c 'taskset -p $$'
[W] initCpu(): Number of requested CPUs is bigger than number of available CPUs (9999 > 6)
pid 1's current affinity mask: 3f            # all 6 CPUs, not 9999

Repro (after fix)

$ nsjail --max_cpus 9999 -- /usr/bin/bash -c 'taskset -p $$'
[E] initCpu(): Number of requested CPUs is bigger than number of available CPUs (9999 > 6)
[F] runChild(): Launching child process failed
$                                              # nsjail exits 255

Runtime-verified on nsjail HEAD (f100fd9) on 6-core Linux.

Fix

 	if (nsj->njc.max_cpus() > available_cpus) {
-		LOG_W(
+		LOG_E(
 		    "Number of requested CPUs is bigger than number of available CPUs (%zu > %zu)",
 		    (size_t)nsj->njc.max_cpus(), available_cpus);
-		return true;
+		return false;
 	}

2 insertions, 2 deletions. cpu.cc only. No behavior change for valid operator use cases.

Impact

Defense-in-depth hardening. A silent downgrade of a user-requested resource cap is the same family of defect as the silent zero-filter seccomp launch fixed in PR #285. Same threat model: the user requested a stronger isolation than nsjail actually delivered, and nsjail reported success.

Notes

• This is a follow-up to PRs mnt: mount the auto-provisioned /proc nosuid,nodev,noexec #283, mnt: apply per-mount nosuid/nodev/noexec recursively to recursive binds #284, sandbox: fail loudly when seccomp_unotify is requested but unusable #285 (already merged 2026-08-26), which closed similar silent-downgrade / missing-standard-hardening gaps.
• The fix is intentionally narrow: one file, two lines, no operator-visible change for valid configs.

[h1-mrz]

Following up on this PR — it's been open for two weeks without review. The change is narrow (two lines, one file) and introduces no behavior change for valid configurations; it follows the same silent-downgrade hardening pattern as #285, which was merged on 2026-08-26. Please let me know if any changes are needed, or if this can be reviewed when convenient.

[h1-mrz]

Hi, just checking in on this. It's been open since Sep 3.