CVE-2016-6130

What it actually does

Race condition in sclp_ctl_ioctl_sccb allows a local process to perform a double-fetch on a length value passed to the ioctl, leaking arbitrary kernel memory contents on s390 systems.

Why it matters to the business

On affected Linux kernels running on IBM Z mainframes, a local attacker with low privileges can read sensitive kernel memory, increasing risk of credential or key exposure in multi-tenant or shared environments; the issue is long-public with minimal exploitation signals.

How an attack unfolds

An attacker on a vulnerable s390 Linux system invokes the sclp_ctl ioctl, races the kernel's copy of the user-supplied length, alters the length between the two fetches, and receives kernel memory beyond the intended buffer.

How to fix it

Upgrade the Linux kernel to a version containing commit 532c34b5fbf1687df63b3fcd5b2846312ac943c6 or later; rebuild and reboot with the patched kernel; where immediate patching is impossible, restrict unprivileged access to /dev/sclp_ctl or equivalent device nodes.

How to confirm the fix worked

Confirm the running kernel contains commit 532c34b5fbf1687df63b3fcd5b2846312ac943c6 or is version 4.6 or newer; attempt to compile and run a minimal double-fetch test against the sclp_ctl ioctl and verify the returned buffer no longer contains out-of-bounds kernel data.

Typical attack path

1. Obtain local shell on s390 Linux host running kernel before commit 532c34b5fbf1687df63b3fcd5b2846312ac943c6
2. Locate or craft a program that calls sclp_ctl_ioctl_sccb with a user-controlled SCCB length
3. Use a separate thread or ptrace to modify the length value after the first kernel fetch but before the second
4. Read the returned buffer containing leaked kernel memory

How to detect it

Review kernel audit logs and process execution history for unusual ioctl calls to sclp_ctl; examine any custom or third-party tools that interact with SCLP character devices for signs of double-fetch patterns; because public exploit maturity remains none, focus on post-incident memory forensics if kernel memory disclosure is suspected.

What your security team should do

• Prioritize kernel updates on all s390 Linux systems within standard change windows
• Audit local user access to SCLP character devices and apply least-privilege controls
• Monitor EPSS and threat-intel feeds for any future increase in exploitation activity despite current low scores