RFR: 8374755: ML-KEM's 12-bit decompression uses incorrect assertions [v2]

Ferenc Rakoczi duke at openjdk.org
Wed Jan 14 13:12:34 UTC 2026


On Wed, 14 Jan 2026 10:43:23 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 6217:
>> 
>>> 6215:     __ sub(parsedLength, parsedLength, 64);
>>> 6216:     __ cmp(parsedLength, (u1)0);
>>> 6217:     __ br(Assembler::GE, L_loop);
>> 
>> Should this be GT now?
>
> Yes, I believe it should. That makes me wonder why the test did not fail. I would have expected it to loop back to the top and try to consume an extra 96 bytes of non-existent input and write it to 64 bytes of of non-existent output buffer? Did this erroneous computation not happen? or was the error simply not manifest?

It is a buffer overflow, so if the memory after the arrays is there, it would be read/written, if you are lucky, it doesn't overwrite anything that is used later, so it might be able to pass a test program (which definitely had happened here).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29141#discussion_r2690369308


More information about the security-dev mailing list