Fix out-of-bounds read in shuftiDoubleExecReal tail handling#381
Fix out-of-bounds read in shuftiDoubleExecReal tail handling#381Jongy wants to merge 1 commit intoVectorCamp:developfrom
Conversation
Commit 9e9a10a ("Fix double shufti's vector end false positive", VectorCamp#325) changed the tail code in shuftiDoubleExecReal to read a full vector from the current pointer (loadu(d)), which can overread past buf_end by up to S-1 bytes. When the buffer ends at a page boundary followed by unmapped memory, this causes a SIGSEGV. Fix by reading the last S bytes backward from buf_end (matching the approach used in shuftiExecReal), and falling back to memcpy for buffers shorter than one vector width. Signed-off-by: Yonatan Goldschmidt <yonatan.goldschmidt@wiz.io>
|
hi, this seems to be a duplicate of #368. I will release 5.4.13 by the end of this month. However, adding the extra unit test is not a bad idea. For small pieces of code, AI assistance is not a problem, if it was a whole component that would be a different issue and I would probably not accept it. |
|
I'm not sure #368 fixes the bug. I cherry-picked this commit on top of that PR ( |
|
ok, thanks for the extra test. I will check it myself this week. |
|
Great, thanks! |
|
I've not reviewed #368 yet, but I did review this one and it looks good to me. Thanks for catching that mistake. |
|
It is not a duplicate of #368. |
4 participants
Commit 9e9a10a ("Fix double shufti's vector end false positive", #325) changed the tail code in shuftiDoubleExecReal to read a full vector from the current pointer (loadu(d)), which can overread past buf_end by up to S-1 bytes. When the buffer ends at a page boundary followed by unmapped memory, this causes a SIGSEGV.
Fix by reading the last S bytes backward from buf_end (matching the approach used in shuftiExecReal), and falling back to memcpy for buffers shorter than one vector width.
Full disclosure - this change is entirely AI generated (but I understand the bug it tries to fix :) So I'm unsure if this is the correct way to fix it, I'm not acquainted with this project enough. Feel free to overtake this PR, or to close it and fix it someway else.
We've hit this crash in one of our apps after upgrading to 5.4.12 and this seems to be the root cause. Due to the bug's nature I wasn't able to verify that this fix eliminates the problem (this is statistical, depends on whether we try to scan buffers that happen to end on a page boundary followed by an unmapped page).
The added test segfaults without the fix, and the code bytes provided by the kernel match the code bytes the kernel reported when our app crashed.