XMLoadUNibble4, XMLoadU555 can cause crash at memory boundary

[Kyung-Kook Park]

Functions are using _mm_load_ps1(const float*) for SSE implementation.
But at the end of a memory block, this can access over as much as two bytes since XMUNIBBLE4 and XMU555 are packed types.

I bumped into a crash while converting a tightly packed RGBA4444 image to a RGBA8888 image using DirectXTex and it looks like it's happening while loading the final scanline of the source image. I ended up with reaching this SSE code.

inline XMVECTOR XM_CALLCONV XMLoadUNibble4
(
     const XMUNIBBLE4* pSource
)
{
    assert(pSource);
    static const XMVECTORI32 UNibble4And = { { { 0xF, 0xF0, 0xF00, 0xF000 } } };
    static const XMVECTORF32 UNibble4Mul = { { { 1.0f, 1.0f / 16.f, 1.0f / 256.f, 1.0f / 4096.f } } };
    // Get the 32 bit value and splat it
    XMVECTOR vResult = _mm_load_ps1(reinterpret_cast<const float *>(&pSource->v));
    // Mask off x, y and z
    vResult = _mm_and_ps(vResult,UNibble4And);
    // Convert to float
    vResult = _mm_cvtepi32_ps(_mm_castps_si128(vResult));
    // Normalize x, y, and z
    vResult = _mm_mul_ps(vResult,UNibble4Mul);
    return vResult;
}

[Kyung-Kook Park]

I am just writing a new comment to check if this is a bug or not. Is Microsoft still maitaining the code?

[Chuck Walbourn]

Sorry, I missed this bug report. I'll take a look at it for a future release.

[Chuck Walbourn]

Same problem exists in load functions for XMUNIBBLE4, XMU555, XMU565, XMBYTEN2, XMBYTE2, XMUBYTEN2, and XMUBYTE2

[Chuck Walbourn]

Note the _mm_loadu_si16 intrinsic is the right choice here, but it's only defined in VS 2017, clang v8, and GNUC 11 or later This will cause problems with GNUC 9/10 scenarios on WSL.

[Chuck Walbourn]

Addressed the issue with GNUC 9, 10 in this commit