lsm/exec: freshly regenerated object fails verifier on uninitialized path read

[sixtoad]

Problem

A credential-free native release-parity run with an exec policy rule passes with an older embedded manager artifact, but a manager containing freshly regenerated LSM objects fails before workload start under --require-lsm:

program lsm_exec: invalid read from stack R3 off=0 size=1

Fresh generation from public commits 0932ecb21903e23bbf1848a4715cb581b6924bbe and 6fa496e6db4ef7c220a7b478b72d377d6499a0e0 produces byte-identical exec objects, proving the hard-link change did not alter this separate object

• bpfel: 541998f6243e4edbb1137a959e8ba4865ecbd5c07cdcaad943c3265003ae0bb5
• bpfeb: 32ee93d9479064dc0cdedab757e7ef7c1c1e5b8dcdafe585f2cae5b6876cc6c0

Likely cause

lsm_exec declares a 256-byte path buffer without complete initialization. If bpf_d_path fails, its fallback probe reads are not all checked, so policy matching can receive bytes the verifier cannot prove initialized. The older embedded artifact appears to hide this latent source defect through an earlier generated/toolchain result.

Acceptance

• Initialize the complete exec-path buffer before any resolution attempt.
• If every path-resolution fallback fails, deny/fail closed without evaluating uninitialized bytes.
• Preserve existing exec policy semantics and audit shape.
• Regenerate and inspect both little- and big-endian objects.
• Prove on a real kernel that lsm_exec loads with an exec rule under --require-lsm.
• Rerun the identical older-artifact/fresh-object control and affected/full tests.

Discovered while validating the exact Leash #29 candidate; kept separate because the generated exec objects are identical before and after that change.