[Bug 1035] __rte_raw_cksum() crash with misaligned pointer

[bugzilla at dpdk.org]

https://bugs.dpdk.org/show_bug.cgi?id=1035

            Bug ID: 1035
           Summary: __rte_raw_cksum() crash with misaligned pointer
           Product: DPDK
           Version: 21.11
          Hardware: All
                OS: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: ethdev
          Assignee: dev at dpdk.org
          Reporter: emil.berg at ericsson.com
  Target Milestone: ---

See rte_raw_cksum() in rte_ip.h, which is part of the public API. See also the
subfunction __rte_raw_cksum().

_rte_raw_cksum assumes that the buffer over which the checksum is calculated is
an even address (divisible by two). See for example this stack overflow post:
https://stackoverflow.com/questions/46790550/c-undefined-behavior-strict-aliasing-rule-or-incorrect-alignment

The post explains that there is undefined behavior in C11 when "conversion
between two pointer types produces a result that is incorrectly aligned". When
the buf argument starts on an odd address we thus have undefined behavior,
since a pointer is cast from void* to uint16_t*.

In most cases (at least on x86) that isn't a problem, but with higher
optimization levels it may break due to vector instructions. This new function
seems to be easier to optimize by the compiler, resulting in a crash when the
buf argument is odd. Please note that the undefined behavior is present in
earlier versions of dpdk as well.

Now you're probably thinking: "Just align your buffers". The problem is that we
have a packet buffer which is aligned. The checksum is calculated on a subset
of that aligned packet buffer, and that sometimes lies on odd addresses.

The question remains if this is an issue with dpdk or not. Maybe you do the
assumption that odd addresses are never passed in when calculating the
checksum, and that's all right. But perhaps a public API comment should be
added in that case. Or perhaps you use it incorrectly as well, and in that case
something should be done about it.

Triggering this bug seems to require high optimization levels as well as odd
values of buf.

Of interest may be that in older version of dpdk you added the a comment: /*
workaround gcc strict-aliasing warning */ showing that you willfully ignored
the warning.

-- 
You are receiving this mail because:
You are the assignee for the bug.