Read access violation in CBlurEngine worker: motion vector offsets are not clamped to the buffer

This report was written and filed by Claude on @malard's behalf, moved here from xbmc/xbmc#27003.

Summary

Kodi crashes on Windows shortly after FishBMC is selected as the music visualisation. Reported at xbmc/xbmc#27003 in July 2025 by @Michellehdr, still reproducible on Kodi 21.3.0.0 as of June 2026. @Rechi diagnosed it there on 2025-09-06 as a read access violation in blurengine.cpp, but the report stayed on the Kodi core tracker where nothing could act on it. Closing it there and filing here so it has a home.

Steps to reproduce

1. Windows 11 x64, Kodi 21.2 or 21.3, default settings
2. Add a music source and play a track
3. Options -> the visualisation icon -> Settings -> Visualisation
4. "Get More" -> install and select FishBMC
5. Continue using music playback

Crash logs attached to the original report: https://github.com/user-attachments/files/21922453/Kodi_Crash_Logs.zip

Where it faults

@Rechi's reference was to src/blurengine.cpp#L68 at 783fb7d. The file has since moved to src/fische/blurengine.cpp; the code is unchanged in substance and 783fb7d is an ancestor of Piers, Omega and Nexus, so this affects all of them.

The blur worker (src/fische/blurengine.cpp:113-144 on Piers):

vector_x = *(vector_pointer + 0);
vector_y = *(vector_pointer + 1);

// point to the pixel at [present + motion vector]
source_pixel = source + (y + vector_y) * m_width + x + vector_x;

source_component[0] = (*(source_pixel + one_line - two_columns) >> 2) & 0x3f3f3f3f;
source_component[1] = (*(source_pixel + one_line + two_columns) >> 2) & 0x3f3f3f3f;
source_component[2] = (*(source_pixel - two_lines) >> 2) & 0x3f3f3f3f;
source_component[3] = (*(source_pixel) >> 2) & 0x3f3f3f3f;

vector_x and vector_y are int_fast8_t taken straight from the vector field, and neither (y + vector_y) nor (x + vector_x) is clamped to the buffer. The four dereferences then add a further ± one_line, ± two_columns and - two_lines on top. So source_pixel and its neighbours can address outside the source buffer, and the reads go out of bounds.

That is consistent with a read AV rather than a write corruption, and it explains the platform split: whether an out-of-bounds read faults depends on whether the address happens to be mapped, so it crashes on Windows while @neo1973 saw no problem with the Linux Flatpak.

This is analysis from reading the code, not a verified reproduction — I have not run it under a debugger. @Rechi's access violation is the observed evidence; the mechanism above is the most likely explanation for it and should be confirmed before a fix is written.

Suggested direction

Clamping the sampled coordinates to the buffer, or padding the source buffer by the maximum reach (two_lines vertically, two_columns horizontally) so the neighbourhood reads always land inside an allocation. The second avoids a per-pixel branch in what is clearly a hot loop.

@Michellehdr is on the original report and has offered to test.

Start with the blur worker in src/fische/blurengine.cpp:113-144 and reproduce the FishBMC crash on Windows using the listed Kodi steps. Confirm the out-of-bounds reads under a debugger, then inspect the existing source-buffer and neighbourhood-read assumptions before choosing a bounds-safe fix. Done means the sampled pixels remain within the buffer and the Windows reproduction no longer crashes.