CVE-2024-42156

What it actually does

Failure to wipe clear-key material from kernel stack memory after unsuccessful IOCTL conversions in the s390 pkey subsystem leaves sensitive cryptographic data in reusable stack frames.

Why it matters to the business

Systems running Linux on IBM Z hardware face risk of cryptographic key leakage to local privileged users, potentially undermining data-at-rest protections and requiring accelerated kernel updates across affected fleets.

How an attack unfolds

A local attacker with root privileges triggers one of the affected pkey IOCTLs with crafted input that causes conversion failure, then inspects residual stack contents to recover the original clear-key value before it is overwritten.

How to fix it

Upgrade the Linux kernel to the commit a891938947f4427f98cb1ce54f27223501efe750 or later; rebuild and reboot all affected s390 systems. No configuration workaround exists.

How to confirm the fix worked

Confirm the running kernel contains commit a891938947f4427f98cb1ce54f27223501efe750 or verify that pkey IOCTL failure paths explicitly zero stack buffers containing clear-key structures.

Typical attack path

1. Obtain local root access on s390 Linux system
2. Invoke failing pkey IOCTL path (clear-to-protected or clear-to-secure conversion)
3. Read kernel stack memory containing uncleared key material
4. Extract and reuse recovered clear key for further cryptographic attacks

How to detect it

Review kernel audit logs and system call traces for repeated pkey IOCTL failures from privileged processes; examine memory dumps or core files from pkey-using processes for clear-key patterns post-failure.

What your security team should do

• Prioritize kernel update on all s390 production systems within the next maintenance window
• Audit any custom pkey-using applications for error-handling paths that may surface keys
• Enable kernel stack canaries and address-space layout randomization if not already active