CVE-2024-42155

What it actually does

In the s390/pkey subsystem, copies of protected- and secure-key material are left on the stack after use or on error paths instead of being wiped, allowing residual key bytes to remain visible beyond the calling process lifetime.

Why it matters to the business

Low operational risk on most systems; in high-security s390 deployments handling cryptographic material, the flaw requires patching to preserve strict key isolation and meet compliance expectations for memory confidentiality.

How an attack unfolds

An attacker with local root privileges triggers pkey operations that place protected or secure keys on the stack, then inspects the process address space or performs memory forensics to recover the uncleared key copies.

How to fix it

Apply the upstream fix present in commit c746f7ced4ad88ee48d0b6c92710e4674403185b or later; rebuild and deploy an updated kernel image containing the wipe logic on all s390 systems.

How to confirm the fix worked

Confirm the patch commit is present in the running kernel source tree or verify the installed kernel package contains the stack-wipe changes in the pkey code path.

Typical attack path

1. Obtain local root access on an s390 Linux system
2. Invoke pkey functions that handle protected or secure keys
3. Inspect stack or process memory for residual key material

How to detect it

Review kernel source or binary for the absence of explicit stack-wipe calls after pkey operations; memory forensic tools can be used to search process stacks for patterns consistent with protected or secure key structures.

What your security team should do

• Apply the referenced kernel commit to all s390 systems handling protected or secure keys
• Prioritize patching in environments with strict cryptographic key-handling requirements
• Rebuild and test custom kernels to ensure the wipe logic is active before production deployment