Bug: MemorySegment bounds check doesn't work for some values and allows segmentation fault

[Maurizio Cimadamore]

I've fixed this in the Panama repo.

I will also make sure that the fix is included in: 
https://github.com/openjdk/jdk/pull/3699

Thanks again for the report.

Maurizio

On 30/04/2021 14:23, Maurizio Cimadamore wrote:
>
> On 30/04/2021 13:57, Marcel Käufler wrote:
>> Hi Maurizio,
>>
>> with the SmallSegments=false flag I get an IndexOutOfBoundsException 
>> as it should be:
>>
>> Exception in thread "main" java.lang.IndexOutOfBoundsException: Out 
>> of bound access on segment MemorySegment{ id=0xa886412 limit: 
>> 2147479552 }; new offset = 8223372036854705800; new length = 8
>
> Yeah - it seems like the optimized 
> AbstractMemorySegmentImpl::checkBoundsSmall doesn't check for overflow.
>
> I'll see if adding that check will throw optimizations out of the 
> window; if not, I'll fix this. If yes, I think it's better to leave as 
> is, and wait for the "real" fix (which is to remove all such hacks and 
> just enable long loop optimizations - we're pretty close there).
>
> Maurizio
>
>>
>>
>> Best Regards,
>> Marcel
>>
>>
>> On 30.04.21 14:05, Maurizio Cimadamore wrote:
>>> Hi,
>>> thanks for the report - I suspect this is caused by the long vs. int 
>>> workaround we have scattered all over the place.
>>>
>>> Can you try running with 
>>> "-Djdk.incubator.foreign.SmallSegments=false" and see what happens?
>>>
>>> Cheers
>>> Maurizio
>>>
>>> On 30/04/2021 12:45, Marcel Käufler wrote:
>>>> Hi,
>>>>
>>>> I've encountered a bug with the MemorySegment bounds check. For 
>>>> some values, instead of throwing and IndexOutOfBoundsException, the 
>>>> access goes through and causes a segmentation fault. I didn't dig 
>>>> into it but I expect some kind of overflow / casting error that 
>>>> makes the address appear to be in a valid range.
>>>>
>>>> Tested with both the JDK 16 release and the current panama main 
>>>> branch.
>>>>
>>>> To reproduce:
>>>>
>>>> import jdk.incubator.foreign.MemoryAccess;
>>>> import jdk.incubator.foreign.MemorySegment;
>>>> import jdk.incubator.foreign.ResourceScope;
>>>>
>>>> public class SIGSEGV {
>>>>     public static void main(String[] args) {
>>>>         MemorySegment memorySegment = 
>>>> MemorySegment.allocateNative(2147479552, ResourceScope.globalScope());
>>>>         MemoryAccess.getLongAtOffset(memorySegment, 
>>>> 8223372036854705800L);
>>>>     }
>>>> }
>>>>
>>>>
>>>>
>>>> #
>>>> # A fatal error has been detected by the Java Runtime Environment:
>>>> #
>>>> #  SIGSEGV (0xb) at pc=0x00007f345fc19053, pid=224993, tid=224996
>>>> #
>>>> # JRE version: OpenJDK Runtime Environment (17.0) (build 
>>>> 17-internal+0-adhoc..panama-foreign)
>>>> # Java VM: OpenJDK 64-Bit Server VM 
>>>> (17-internal+0-adhoc..panama-foreign, mixed mode, sharing, tiered, 
>>>> compressed oops, compressed class ptrs, g1 gc, linux-amd64)
>>>> # Problematic frame:
>>>> # V  [libjvm.so+0xf0a053]  Unsafe_GetLong+0x133
>>>> #
>>>> # Core dump will be written. Default location: Core dumps may be 
>>>> processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c 
>>>> %h" (or dumping to /home/marcel/IdeaProjects/BoundsCheck/core.224993)
>>>> #
>>>> # An error report file with more information is saved as:
>>>> # /home/marcel/IdeaProjects/BoundsCheck/hs_err_pid224993.log
>>>> #
>>>> # If you would like to submit a bug report, please visit:
>>>> # 
>>>> https://urldefense.com/v3/__https://bugreport.java.com/bugreport/crash.jsp__;!!GqivPVa7Brio!MUuIDtpQbzxeIlw90rUObOEf0qyv1gcu8_KacA-pW1Rdrj2WRVUxZ3tJ4N8s09w92C8ZnkI$ 
>>>> #
>>>>
>>>> Process finished with exit code 134 (interrupted by signal 6: SIGABRT)
>>>>
>>>>
>>>> Best Regards,
>>>> Marcel
>>>>
>>