<div dir="ltr">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<br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sat, Feb 21, 2026 at 2:35 AM Marat Khalili <<a href="mailto:marat.khalili@huawei.com">marat.khalili@huawei.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> I can suggest my condition to get a wrong checksum, which does not go into the details of how it was<br>
> observed in the wild:<br>
> <br>
> Function rte_raw_cksum_mbuf may produce incorrect result when multiple segments are present in the<br>
> checksummed range, and some of them have odd checksummed length. More precisely, if any segment except<br>
> the last one begins at an odd offset from the start, and arithmetic sum of its 16-bit words overflows,<br>
> the part that has overflown will be lost. Cases when there is only one segment, or all of the segment<br>
> sizes and checksum offsets are even, are not affected.<br>
<br>
Apologies, rushed to send. The "except the last one" condition is unnecessary. Corrected version:<br>
<br>
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. <br>
</blockquote></div>