CVE-2026-68385

What it actually does

csum_partial() on s390 systems without the vector facility invokes the fallback cksm() with dst=NULL, causing checksums to be computed from address zero instead of the caller-supplied source buffer and producing incorrect results.

Why it matters to the business

Network traffic or data-integrity checks on affected IBM Z hardware may silently accept corrupted data or drop valid packets, degrading reliability of communications and storage operations until systems are updated.

How an attack unfolds

An attacker sends or triggers data paths that exercise the checksum routine on an unpatched s390 system lacking the vector facility; the wrong memory region is checksummed, allowing crafted payloads to evade integrity checks or cause repeated failures that disrupt service.

How to fix it

Apply the upstream kernel commit that passes the source buffer to cksm() in the non-vector fallback path; rebuild and deploy the fixed kernel on all s390 systems.

How to confirm the fix worked

Confirm the patched kernel is running, then execute unit tests that compare csum_partial() output against a known-good reference implementation on both vector and non-vector s390 hardware.

Typical attack path

1. Map reachable s390 Linux instances without the vector facility
2. Trigger network or storage code paths that invoke csum_partial()
3. Supply data whose checksum is computed from address zero rather than the real buffer
4. Observe acceptance of malformed data or systematic packet drops

How to detect it

Review kernel and network stack logs for repeated checksum mismatches or unexpected csum_partial behavior on s390 hardware; correlate with system architecture and vector-facility CPU flags.

What your security team should do

• Prioritize patching of s390 systems that lack the vector facility
• Add the fixed kernel version to the organization's approved baseline
• Monitor for checksum-related anomalies in network and storage logs until all instances are updated