# DF-3936 — ena_com_set_hash_function() inverts the hash-function support check

## Finding
`sys/dev/virtual/amazon/ena/ena-com/ena_com.c:2238-2242`

```c
	if (get_resp.u.flow_hash_func.supported_func & (1 << rss->hash_func)) {
		ena_trc_err("Func hash %d isn't supported by device, abort\n",
			    rss->hash_func);
		return ENA_COM_UNSUPPORTED;
	}
```

The condition aborts exactly when the device DOES support the selected hash
function. Every reference implementation (Linux ena_com.c) uses
`if (!(get_resp.u.flow_hash_func.supported_func & (1 << rss->hash_func)))`.
Note `1 << rss->hash_func` uses enum positions (TOEPLITZ=1 → bit 1,
CRC32=2 → bit 2) consistent with the spec's funcs bitmask.

## Impact
On any compliant ENA device, `ena_com_set_hash_function()` always fails with
`ENA_COM_UNSUPPORTED == EOPNOTSUPP` (`ena_plat.h:175`).
`ena_com_fill_hash_function()` (`ena_com.c:2323-2329`) then takes its
restore path, and the caller `ena_rss_init_default` (`ena.c:3081-3087`)
treats EOPNOTSUPP as tolerable — so RSS hash-function configuration
(including the driver-chosen CRC32 init value 0xFFFFFFFF) is silently never
programmed. Result: receive-side steering stays in whatever mode the device
had (default), degrading the multi-queue RSS contract the driver advertises
(netisr steering assumes RSS hashing); no memory-safety impact. Confusion
vector (hypervisor boundary): a *malicious* device cannot exploit the
inversion for memory corruption — it is a pure functional/logic defect
(CWE-628/606-style inverted check).

## Trigger
Attach any ENA device that advertises RSS hash function support; observe
"Func hash %d isn't supported by device, abort" in the trace although the
function IS supported, and `ena_com_fill_hash_function` returning EOPNOTSUPP.

## Why inconclusive on this guest
The audit guest has no Amazon ENA PCI function (vendor 0x1d0f absent,
env.txt); the path requires the AWS Nitro hypervisor device.