csum_partial() computes num_u16 = len >> 1 and only sums that many 16-bit words, so the last byte of an odd-length buffer never gets added to the checksum. RFC 1071 says it should be padded with a zero byte and summed as one more word, not dropped. This backs build_ip_csum(), build_udp_v4_csum() and build_udp_v6_csum(), used by flow_dissector_classification.c and xdp_metadata.c to hand-build packets. No current caller builds an odd-length payload, so nothing fails today, but a future one would get a silently wrong checksum. Also bump flow_dissector_classification's TEST_PACKET_LEN from 100 to 99 so this actually gets exercised instead of staying latent. f4504af68575 wrote the len >> 1 division, but it only ever passed sizeof(iphdr), always even, so it couldn't hit the bug. Tagging bcc00987bc56 instead, since it added the first caller, build_udp_v4_csum()/build_udp_v6_csum(), that can pass an odd length. Verified with test_progs under vmtest.sh: without the fix, an odd TEST_PACKET_LEN makes the kernel drop the packet over a bad checksum and flow_dissector_classification fails; with the fix, both flow_dissector_classification and xdp_metadata pass. Signed-off-by: Madhav Khosla <madhav.khoslaa@gmail.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Link: https://patch.msgid.link/20260920085549.867099-1-madhav.khoslaa@gmail.com