CVE-2024-43819

What it actually does

Null pointer dereference in KVM s390 code path when KVM_SET_USER_MEMORY_REGION or KVM_SET_USER_MEMORY_REGION2 ioctls are invoked on a ucontrol VM (kvm->arch.gmap == NULL).

Why it matters to the business

Potential kernel crash or denial of service on s390 Linux systems that run ucontrol VMs; low exploitability limits widespread operational disruption.

How an attack unfolds

An attacker with sufficient privileges to issue the memory-region ioctls against a ucontrol VM triggers the dereference inside the KVM memory-management handler, resulting in a kernel panic.

How to fix it

Upgrade the Linux kernel to commit 49c9945c054df4c22008e2bf87ca74d3e2507aa6 or later; apply the equivalent stable or distribution kernel update that contains the fix. Use KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP for memory management on ucontrol VMs.

How to confirm the fix worked

Confirm the running kernel contains commit 49c9945c054df4c22008e2bf87ca74d3e2507aa6; attempt the rejected ioctls on a ucontrol VM and verify they now return an error instead of dereferencing.

Typical attack path

1. Obtain local access or privileges on an s390 host running a vulnerable kernel
2. Create or attach to a ucontrol VM
3. Invoke KVM_SET_USER_MEMORY_REGION or KVM_SET_USER_MEMORY_REGION2 ioctl
4. Trigger null dereference and kernel crash

How to detect it

Review kernel logs for oops/panic entries mentioning s390 KVM, gmap, or the rejected ioctls; inspect audit logs for calls to KVM_SET_USER_MEMORY_REGION on ucontrol VMs.

What your security team should do

• Prioritize kernel updates on all s390 systems that use KVM ucontrol VMs
• Audit any custom tooling that calls KVM_SET_USER_MEMORY_REGION on s390
• Monitor for kernel oops or panic logs referencing gmap or s390 KVM memory regions