Re: [PATCH net] hinic3: bound the Rx fragment count to MAX_SKB_FRAGS

[Yehyeong Lee]

Thanks for the review.

A well-behaved device can't reach it. rx_buf_len is fixed at 2048
regardless of MTU, so the frag count is ceil(pkt_len / 2048): a max-MTU
frame (9600) is 5 frags, and LRO -- off by default, capped at 32K when
enabled -- is at most 16, both below the 17 the array holds. Only the
16-bit length field in the completion descriptor (RQ_CQE_SGE_LEN_MASK)
lets a device claim up to 65535 bytes, i.e. 32 frags. So it takes a
device reporting a bogus length, i.e. broken or malicious firmware,
which is why I treated it as a robustness fix -- I should have said so
in the changelog.

I found it by code inspection, not in the field, and I don't have a
hinic3 card, so it's untested on real hardware; I reproduced it by
injecting an out-of-range length to get the KASAN splat in the
changelog. The netdev bot asked for these same two things, so this
answers it as well.

You're right that the bare drop is unhelpful. It only surfaces as
rx_dropped via ndo_get_stats64, not in ethtool -S -- hinic3 has no
get_ethtool_stats, and the stats series in net-next doesn't export
dropped either. I'm happy to add a net_warn_ratelimited() on the
discard path in v2; it only fires for a misbehaving device, so it won't
spam a healthy system. Let me know if you'd like that.

For reference, eea does the same thing -- it drops once nr_frags
reaches MAX_SKB_FRAGS.

Thanks,
Yehyeong