CVE-2024-36931

What it actually does

The flaw allocates a kernel buffer of lbuf size, copies lbuf bytes from userspace without ensuring NUL termination, then passes the buffer to scanf which can read past the allocated buffer causing an out-of-bounds read.

Why it matters to the business

On s390 systems running affected kernels, unprivileged local processes may trigger kernel memory disclosure or crashes, potentially leading to information leaks or denial of service with low likelihood of remote exploitation.

How an attack unfolds

An attacker invokes the affected s390 cio code path with a userspace buffer lacking a trailing NUL byte; the kernel copy leaves the buffer unterminated, scanf then reads beyond the allocation boundary during parsing.

How to fix it

Upgrade the Linux kernel to a version containing commit c9d48ce163305595ae20aee27774192476d5e6a5 which replaces the allocation-and-copy sequence with memdup_user_nul.

How to confirm the fix worked

Confirm the running kernel contains commit c9d48ce163305595ae20aee27774192476d5e6a5 or later; recompile with the patch and verify the memdup_user_nul call is present in the cio code path.

Typical attack path

1. Identify s390 Linux system running vulnerable kernel
2. Locate exposed cio interface accepting user-controlled buffers
3. Craft input buffer of exact lbuf size without NUL terminator
4. Invoke the interface to trigger scanf on unterminated buffer
5. Observe OOB read effects via kernel panic or leaked data

How to detect it

Search kernel logs and audit records for unexpected scanf-related faults or OOB accesses originating from s390 cio drivers; correlate with process activity invoking cio ioctls on vulnerable kernels.

What your security team should do

• Apply the referenced kernel commit immediately on all s390 systems
• Prioritize patching production s390 hosts before non-production
• Monitor for any local privilege-escalation attempts post-patch
• Review downstream distributions for backported fixes