CVE-2025-38700

What it actually does

Unconditional assignment of iscsi_conn->dd_data pointer during iSER fast registration descriptor allocation failure (when dd_size==0) results in an invalid pointer that is later dereferenced on connection teardown, triggering a kernel page fault and panic.

Why it matters to the business

Local users or processes triggering iSER connection setup and teardown on affected Linux kernels can cause immediate system crashes, leading to denial of service for storage workloads and potential data plane disruption in container or VM environments using the affected packages.

How an attack unfolds

An attacker with local access triggers an ib_fast_reg_mr allocation failure during iSER RX descriptor setup; the kernel then stores a null/invalid dd_data pointer. On subsequent iscsi_conn_stop or teardown via netlink, the invalid pointer is dereferenced inside swake_up_locked, crashing the system. Related kernel privilege-escalation patterns in Container-Optimized OS environments may be chained by the same actors.

How to fix it

Upgrade affected Linux kernel packages to the commit f53af99f441ee79599d8df6113a7144d74cf9153 or later. For MinimOS harbor images update to 2.13.2-r1 or newer. Reboot systems after kernel updates and verify iSER functionality under memory pressure.

How to confirm the fix worked

Confirm the fix commit is present in the running kernel; reproduce the allocation-failure scenario and ensure no panic occurs on teardown; monitor kernel logs for absence of the swake_up_locked BUG and the iser_create_fastreg_desc failure messages.

Typical attack path

1. Obtain local code execution or user access on a system using iSER over InfiniBand
2. Force ib_fast_reg_mr allocation failure (e.g., memory pressure) during iscsi_iser_conn setup
3. Trigger connection stop or teardown through netlink or userspace iscsi tools
4. Kernel dereferences invalid dd_data pointer during swake_up_locked/complete, causing panic

How to detect it

Search kernel logs and dmesg for the strings 'iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr', 'iser: iser_alloc_rx_descriptors: failed allocating rx descriptors', and the BUG address fffffffffffffff8 followed by the swake_up_locked trace; correlate with netlink_unicast activity from iscsi_if_rx.

• iser: iser_create_fastreg_desc: Failed to allocate ib_fast_reg_mr err=-12
• iser: iser_alloc_rx_descriptors: failed allocating rx descriptors / data buffers
• BUG: unable to handle page fault for address: fffffffffffffff8
• RIP: 0010:swake_up_locked.part.5+0xa/0x40
• Call Trace: complete+0x31/0x40 iscsi_iser_conn_stop+0x88/0xb0

What your security team should do

• Prioritize kernel updates on any systems exposing iSER/InfiniBand storage paths within the next maintenance window
• Apply the listed fixed versions (harbor-2.13 series to 2.13.2-r1, kernel to f53af99f...) and reboot
• Add kernel panic and iser allocation failure alerts to existing monitoring
• Review local user access controls on storage nodes given the local attack vector