CVE-2024-56699

What it actually does

The flaw is a logic error in the zPCI subsystem allowing zpci_release_device() to execute hotplug slot teardown (zpci_exit_slot) from configured or standby states instead of only the reserved state, enabling a double removal of the slot when references are dropped.

Why it matters to the business

On s390 systems this can trigger kernel warnings, instability, or crashes during PCI device removal, disrupting hardware hotplug operations and availability of dependent workloads; the low EPSS and lack of KEV status indicate limited real-world urgency but still requires patching on affected kernels.

How an attack unfolds

An attacker with local access or ability to trigger PCI device state transitions could race device release paths to hit the dead code branches, causing double slot removal; listed threat actors in espionage and ransomware campaigns have targeted similar kernel race conditions in Linux privilege-escalation efforts but no public exploitation of this specific issue is recorded.

How to fix it

Upgrade the Linux kernel to a version containing commit c1489651071ab1be46d2af1da8adb15c9fc3c069; for listed Ubuntu packages apply 1.900.1-14ubuntu3.4 (14.04 LTS) or 1.900.1-debian1-2.4ubuntu1.1 (16.04 LTS); remove or disable the dead code paths that handled non-reserved states.

How to confirm the fix worked

Confirm the presence of commit c1489651071ab1be46d2af1da8adb15c9fc3c069 in the running kernel; verify that zpci_release_device() now contains an explicit WARN_ON() for non-reserved states and no longer contains the standby/configured teardown branches; test hotplug removal only succeeds from the reserved state.

Typical attack path

1. Gain local execution or control over PCI hotplug events on a vulnerable s390 Linux kernel
2. Force a zPCI device into configured or standby state while triggering release
3. Trigger reference drop to invoke zpci_release_device() outside the reserved state
4. Observe or exploit resulting double slot removal for denial of service or further kernel corruption

How to detect it

Search kernel logs for WARN_ON messages originating from zpci_release_device when devices are not in the reserved state; inspect dmesg or journalctl for repeated hotplug slot removal events on the same device; correlate with PCI device state transitions logged by the zPCI subsystem.

• zpci_release_device.*non-reserved
• double remove of hotplug slot
• WARN_ON.*zpci_exit_slot

What your security team should do

• Prioritize kernel updates on all s390 systems within the next maintenance window given the 653 days since publication
• Monitor for future related CVEs in the zPCI hotplug code path
• Audit custom device management scripts that may trigger non-standard release sequences
• Enable kernel panic-on-warn if feasible to surface any latent double-remove attempts during testing