[DPDK/ethdev Bug 2091] net/ice: get_module_eeprom() silently drops trailing bytes when read length is not a multiple of 8

[bugzilla@dpdk.org]

https://bugs.dpdk.org/show_bug.cgi?id=2091

            Bug ID: 2091
           Summary: net/ice: get_module_eeprom() silently drops trailing
                    bytes when read length is not a multiple of 8
           Product: DPDK
           Version: 25.11
          Hardware: x86
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: ethdev
          Assignee: dev@dpdk.org
          Reporter: marcel@telka.sk
  Target Milestone: ---

ice_get_module_eeprom() reads the transceiver EEPROM in fixed 8-byte blocks via
ice_aq_sff_eeprom(). The hardware read happens unconditionally for every block,
including a trailing partial one, but the copy into the caller's buffer is
gated by an all-or-nothing check:

https://github.com/DPDK/dpdk/blob/a13c1053360ee26bbacca9f883d3f3cb83a0f366/drivers/net/intel/ice/ice_ethdev.c#L6765-L6767

    /* Make sure we have enough room for the new block */
    if ((i + SFF_READ_BLOCK_SIZE) <= info->length)
        memcpy(data + i, value, SFF_READ_BLOCK_SIZE);

When info->length is not an exact multiple of SFF_READ_BLOCK_SIZE (8), the
final loop iteration reads the correct 8 bytes from the module into value[],
but the guard evaluates false (e.g. i=88, length=90: 88+8=96 > 90), so the
memcpy is skipped entirely. Since the destination buffer is memset to 0 at
function entry, the trailing length % 8 bytes are silently returned as zero
instead of the real EEPROM content, with no error indication to the caller.

This is a different (and still-open) case of the same bug class fixed in
31f15787 ("net/ice: fix module EEPROM read", Oct 2022), which only addressed
the complementary edge case where length is an exact multiple of 8 (changing
the guard from < to <=). That fix did not address non-multiple lengths at all.

The equivalent Linux kernel driver (ice_get_module_eeprom() in ice_ethtool.c)
had the same underlying bug and fixed it completely as CVE-2023-53142, by
replacing the all-or-nothing guard with a clamped partial copy:

https://github.com/torvalds/linux/commit/84cba1840e68430325ac133a11be06bfb2f7acd8

    /* Make sure we have enough room for the new block */
    copy_len = min_t(u32, SFF_READ_BLOCK_SIZE, ee->len - i);
    memcpy(data + i, value, copy_len);

The DPDK ice PMD never picked up this more complete fix.

Steps to Reproduce:
1. On a port using the ice PMD with an SFF-8472 transceiver attached, call
rte_eth_dev_get_module_eeprom() with offset=3, length=90 (deliberately not a
multiple of 8, e.g. the common "read compliance codes + vendor fields + DDM
type byte in one request, skip the padding gap before A2h" pattern).
2. Compare the returned buffer's last 2 bytes against an independent read of
the same EEPROM region (e.g. via the kernel ice driver + ethtool -m on the same
port, after temporarily unbinding from vfio-pci).

Expected: all 90 requested bytes match the module's actual EEPROM content.

Actual: the last 2 bytes (length % 8) come back as 0x00, regardless of their
real value. Confirmed concretely: byte 92 (SFF-8472 "Diagnostic Monitoring
Type," containing the DDM-implemented bit) returned 0x00 via this 90-byte read,
but 0x68 (DDM bit correctly set) via an independent ethtool -m read of the same
module. Re-running the same rte_eth_dev_get_module_eeprom() call with length=96
(a clean multiple of 8 that fully covers byte 92 within a complete block)
correctly returns 0x68, directly confirming the root cause.

Suggested fix: replace the all-or-nothing guard with a clamped partial copy,
matching the Linux kernel's fix:

    uint32_t copy_len = RTE_MIN((uint32_t)SFF_READ_BLOCK_SIZE, info->length -
i);
    memcpy(data + i, value, copy_len);

-- 
You are receiving this mail because:
You are the assignee for the bug.