On Tue, 2026-11-10 at 14:08 +0000, netdev-bot+sashiko@kernel.org wrote:
[Medium] The code change looks right, but does this paragraph describe
the trigger and the root cause accurately? Can a second datagram in the
same NTB reach this check at all?
You are right, my description of the trigger was wrong. I re-read the
code and your analysis holds on every point:
- cdc_ncm_ndp16() returns the NDP it finds in the chain when the
signature matches, so on plain cdc_ncm, which always uses the same
signature, the create path here is normally reached for the first
datagram of an NTB only. An additional NDP for an NTB that already
holds datagrams comes from cdc_mbim_tx_fixup(), which uses a
different signature per MBIM session.
- cdc_ncm_setup() clamps tx_max through cdc_ncm_update_rxtx_max()
before cdc_ncm_set_dgram_size() runs, so cdc_ncm_check_tx_max()
computes its lower bound with ctx->max_datagram_size still 0. The
bound is therefore max_ndp_size plus the NTH header only, not one
datagram plus one NDP.
- In the report, end 0x140 = 320 is tx_max derived from a device
dwNtbOutMaxSize of 320, and the 256 bytes already in the skb are the
12 byte NTH header padded by cdc_ncm_align_tail() to the 256 byte
wNdpOutAlignment that cdc_ncm_fix_modulus() accepts because it is
smaller than tx_max.
So the reachable triggers are the device controlled
dwNtbOutMaxSize/wNdpOutAlignment combination, or MBIM multi-session
NDPs, and not a second datagram on plain cdc_ncm.
v3 keeps the code unchanged and only fixes the commit message:
https://lore.kernel.org/all/20261111124156.637661-1-xujiahao@cmss.chinamobile.com/ (local)
The Fixes: tags you asked for are already part of it.
pw-bot: cr