DF-3938 — ena_com_get_hash_function(): memcpy length = device-controlled u32 keys_num (latent OOB read+write; dead code in this port)

Finding

sys/dev/virtual/amazon/ena/ena-com/ena_com.c:2354:

    if (key)
        memcpy(key, hash_key->key, (size_t)(hash_key->keys_num) << 2);

• hash_key is rss->hash_key — a DMA-coherent buffer (ena_com_hash_key_allocate, ena_com.c:966-980) that the DEVICE fills during ena_com_get_feature_ex(RSS_HASH_FUNCTION) (ena_com.c:2291-2295, indirect control-buffer DMA). keys_num is uint32_t (ena_admin_defs.h:593-595), so the copy length is a fully device-controlled keys_num << 2 (up to ~16 GiB) —
• OOB read past the 48-byte hash_key allocation (key[10] = 40 bytes),

• OOB write into the caller's key buffer, whose size is never passed.

• sizeof(ena_admin_feature_rss_flow_hash_control.key) == 40, and the write-side sibling (ena_com_fill_hash_function, :2305-2313) correctly validates key_len <= sizeof(hash_key->key) — only the read side is unbounded.

Reachability today (honest): DEAD CODE

ena_com_get_hash_function has NO callers in this port: - ena.c never calls it (grep: only ena_com_fill_hash_function, ena_com_set_default_hash_ctrl at ena.c:3081/3088). - The only in-tree call site is the error-restore path inside ena_com_fill_hash_function itself (ena_com.c:2327) which passes key == NULL, so the memcpy is skipped (if (key)).

Filed Info (latent/hardening, pattern precedent DF-3799): the moment anyone wires RSS-key retrieval to a sysctl/ioctl (e.g. a future ena_sysctl rss_key handler, as FreeBSD's ena and Linux's ethtool get_rxfh_key do via a fixed 40/52-byte user buffer), a malicious/compromised ENA device (hypervisor) turns keys_num into an arbitrary-length kernel memcpy.

Fix

fix.diff clamps the length to sizeof(hash_key->key).

Why inconclusive on this guest

No ENA PCI function (env.txt); and the buggy line is unreachable even with one, until a caller passes a non-NULL key.

DF-3938 — VERDICT

Status: inconclusive (dead code + hardware-gated) — defect certain at source; latent OOB read/write. Info severity.

Source proof

• sys/dev/virtual/amazon/ena/ena-com/ena_admin_defs.h:593-599: struct ena_admin_feature_rss_flow_hash_control { uint32_t keys_num; uint32_t reserved; uint32_t key[10]; } — keys_num is a u32 inside the device-DMA'd control buffer.
• ena_com.c:2342-2345 — ena_com_get_feature_ex(..., rss->hash_key_dma_addr, sizeof(*rss->hash_key)): the device writes the whole 48-byte struct (keys_num included) by DMA.
• ena_com.c:2354 — memcpy(key, hash_key->key, (size_t)(hash_key->keys_num) << 2); — length device-chosen, up to 0x3FFFFFFFC bytes; source region is 40 bytes inside a 48-byte coherent alloc; destination size unknown to this function. Both directions unbounded.
• Contrast with the bounded write side: ena_com.c:2305-2313 (key_len > sizeof(hash_key->key) check before memcpy(hash_key->key, key, key_len)).

Reachability (killed honestly)

• Whole-tree grep for callers: ena_com_get_hash_function appears only at its definition (ena_com.c:2332), its header prototype (ena_com.h:715), and one internal call with key == NULL (ena_com.c:2327, error-restore inside ena_com_fill_hash_function). ena.c / ena_sysctl.c never call it. So the OOB cannot execute in this tree today — hence Info/latent, not Medium.
• Even with hardware present, the guest has no ENA device (env.txt).

Classification: Info, confidence certain (that the code is wrong), latent — the DF-3799 precedent (dead-code defect documented for the port's future).

Fix

fix.diff: clamp to sizeof(hash_key->key) using ENA_MIN32 (already defined in ena_plat.h).

fix_status

not_testable — dead code + no hardware.

Fix status (batch validation)

Applied with the 36 sibling fix.diffs of this batch in findings/poc/_batch41/all_fixes.patch; single in-guest make -j6 nativekernel KERNCONF=X86_64_GENERIC completed RC=0 with zero errors under -Werror (full log: findings/poc/_batch41/fix_build8.log). Behavior A/B intentionally skipped for this Info-tier item.