# 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`:

```c
	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.