Load of address X with insufficient space for an object of type Y

I'm running some updates through Undefined Behavior Sanitizer. The sanitizer is producing a message I don't quite understand:

kalyna.cpp:1326:61: runtime error: load of address 0x0000016262c0 with insufficient space for an object of type 'const uint32_t'
0x0000016262c0: note: pointer points here
 20 8b c1 1f  a9 f7 f9 5c 53 c4 cf d2  2f 3f 52 be 84 ed 96 1b  b8 7a b2 85 e0 96 7d 5d  70 ee 06 07
              ^

The code in question attempts to make cache timing attacks harder by touching addresses within the range of a cache line. Line 1326 is the line with reinterpret_cast:

// In KalynaTab namespace
uint64_t S[4][256] = {
    ...
};
...

// In library's namespace
const int cacheLineSize = GetCacheLineSize();
volatile uint32_t _u = 0;
uint32_t u = _u;

for (unsigned int i=0; i<256; i+=cacheLineSize)
    u &= *reinterpret_cast<const uint32_t*>(KalynaTab::S+i);

Why is the santizier claiming a uint32_t u does not have sufficient space to hold an uint32_t?

Or maybe, am I parsing the error message correctly? Is that what the sanitzier is complaining about? If I am parsing it incorrectly, then what is the sanitzer complaining about?

$ lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch

$ gcc --version
gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)

Solution

The identifier S does not convert to a pointer of the type you think it does. As a result, your pointer arithmetic is throwing you way out of range of your data, and is best shown by example:

#include <iostream>
#include <cstdint>

uint64_t S[4][256];

int main()
{
    std::cout << static_cast<void*>(S+0) << '\n';
    std::cout << static_cast<void*>(S+1) << '\n';
    std::cout << static_cast<void*>(S+2) << '\n';
    std::cout << static_cast<void*>(S+3) << '\n';
    std::cout << '\n';

    std::cout << static_cast<void*>(*S+0) << '\n';
    std::cout << static_cast<void*>(*S+1) << '\n';
    std::cout << static_cast<void*>(*S+2) << '\n';
    std::cout << static_cast<void*>(*S+3) << '\n';
}

Output (obviously platform dependent)

0x1000020b0
0x1000028b0
0x1000030b0
0x1000038b0

0x1000020b0
0x1000020b8
0x1000020c0
0x1000020c8

Note the stride of the first sequence of numbers 0x800 per inferior row. That makes sense since each row is made up of 0x100 entries of 8 bytes each (the uint64_t elements). The type of the pointer being used in the pointer arithmetic is uint64_t (*)[256].

Now note the stride of the second sequence, which peers into only S[0]. The stride is 8 bytes, one for each slot. The type of the converted pointer in this calculation is uint64_t *.

In short, your pointer arithmetic is assuming S converts to uint64_t*, and it doesn't. Like all array-to-pointer conversions, it converts to a pointer-to-first-element, including the type of said-same. The element type in the array of arrays is uint64_t[256], so the converted pointer type is uint64_t (*)[256].