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

    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.

DF-3936 — VERDICT

Status: inconclusive (hardware-gated) — source-level certainty: certain. Impact: logic defect on the hypervisor boundary (RSS hash function never programmed); no memory corruption.

Proof from source

• sys/dev/virtual/amazon/ena/ena-com/ena_com.c:2238: if (get_resp.u.flow_hash_func.supported_func & (1 << rss->hash_func)) immediately followed by the "isn't supported" error + return ENA_COM_UNSUPPORTED (:2239-2242). The success path (executing the SET_FEATURE at :2244-2267) is only reachable when the device does NOT support the function — i.e. the command is only ever sent for functions the device rejects (and then fails server-side), or never sent at all for the one that matters.
• Upstream reference (Linux drivers/net/ethernet/amazon/ena) has the negated form; the FreeBSD/DragonFly port dropped the !.
• Chain: ena_rss_init_default (sys/dev/virtual/amazon/ena/ena.c:3081-3087) calls ena_com_fill_hash_function(ena_dev, ENA_ADMIN_CRC32, NULL, ENA_HASH_KEY_SIZE, 0xFFFFFFFF) → ena_com_set_hash_function() → inverted check fires (device supports CRC32) → EOPNOTSUPP → caller tolerates it (rc != EOPNOTSUPP guard at ena.c:3082) → the hash function/init value are never programmed, and ena_com_get_hash_function(NULL,NULL) runs as "restore" (ena_com.c:2326-2328).

Why not reproduced

Requires an ENA PCI function (Amazon EC2 Nitro); the audit QEMU guest's pciconf -l (env.txt) shows only Intel PIIX4 + virtio devices — vendor 0x1d0f absent. Classified inconclusive per batch convention.

Fix

fix.diff adds the missing ! (one character), matching Linux.

fix_status

not_testable — no ENA hardware on the guest; the diff is a 1-token logic correction against the exact cited line.

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.