CVE-2024-42158

What it actually does

In the s390 pkey subsystem, sensitive cryptographic key material was freed using separate memzero_explicit and kfree calls instead of the combined kfree_sensitive function, potentially leaving residual data in memory.

Why it matters to the business

Organizations running affected Linux kernels on s390 architecture may face increased risk of local information disclosure of cryptographic keys, though exploitation requires high privileges and is unlikely given low EPSS and no known campaigns.

How an attack unfolds

An attacker with root privileges on an s390 Linux system could potentially read freed kernel memory containing sensitive keys if the zeroing was not effective, though no public exploits or threat actors are associated with this issue.

How to fix it

Upgrade the Linux kernel to a version containing commit 62151a0acde90823bdfa991d598c85cf4b1d387d.

How to confirm the fix worked

Inspect s390 pkey source for replacement of memzero_explicit+ kfree patterns with kfree_sensitive calls at the previously warned locations.

Typical attack path

1. Obtain local root access on an s390 system
2. Trigger pkey operations that allocate and free sensitive memory
3. Attempt to recover data from recently freed kernel pages

How to detect it

Review kernel audit logs and system call traces for privileged pkey operations; look for post-fix patterns indicating proper sensitive memory handling in code reviews.

What your security team should do

• Apply the referenced upstream commit to s390 Linux kernels
• Limit use of pkey interfaces to trusted processes only
• Monitor EPSS and KEV updates for any change in exploit maturity