As noted in Marat Khalili's analysis, we identified this issue in the production environment. Meanwhile, I simplified the problematic scenario into corresponding test cases and added them to app/test/test_cksum.c
On Sat, Feb 21, 2026 at 2:35 AM Marat Khalili <[email protected]> wrote: > > I can suggest my condition to get a wrong checksum, which does not go > into the details of how it was > > observed in the wild: > > > > Function rte_raw_cksum_mbuf may produce incorrect result when multiple > segments are present in the > > checksummed range, and some of them have odd checksummed length. More > precisely, if any segment except > > the last one begins at an odd offset from the start, and arithmetic sum > of its 16-bit words overflows, > > the part that has overflown will be lost. Cases when there is only one > segment, or all of the segment > > sizes and checksum offsets are even, are not affected. > > Apologies, rushed to send. The "except the last one" condition is > unnecessary. Corrected version: > > Function rte_raw_cksum_mbuf may produce incorrect result when multiple > segments are present in the checksummed range, and some of them have odd > checksummed length. More precisely, if any segment begins at an odd offset > from the start, and arithmetic sum of its 16-bit words overflows, the part > that has overflown will be lost. Cases when there is only one segment, or > all of the segment sizes and checksum offsets are even, are not affected. >
