CVE-2024-42157

What it actually does

In the s390/pkey kernel module, sensitive data remains on the stack when copy_to_user() fails instead of being wiped, enabling potential local information disclosure of cryptographic material.

Why it matters to the business

Organizations running Linux on s390 architecture face a limited risk of exposure of sensitive key material to highly privileged local users, though low exploitability and lack of known campaigns reduce operational urgency despite the kernel's widespread use.

How an attack unfolds

A local attacker with root privileges on an s390 system triggers a pkey operation where copy_to_user() fails, then reads the unwiped stack region containing residual sensitive data; no evidence of exploitation by listed threat actors or ransomware groups exists.

How to fix it

Upgrade the Linux kernel to include commit 6e2e374403bf73140d0efc9541cb1b3bea55ac02 or later in the stable repository.

How to confirm the fix worked

Confirm the presence of the stack-wipe logic after copy_to_user() failure in the pkey source and verify the commit is present in the running kernel build.

Typical attack path

1. Obtain high-privilege local access on s390 Linux
2. Invoke pkey functions to force a copy_to_user() failure path
3. Inspect stack memory for unwiped sensitive data

How to detect it

Search kernel logs and audit trails for pkey error paths involving copy_to_user failures; examine memory dumps from affected processes for residual stack data.

What your security team should do

• Apply the referenced kernel commit on all s390 systems
• Review local privilege boundaries around cryptographic modules
• Track stable kernel updates for s390/pkey changes