Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8013140

Heap corruption with NetworkInterface.getByInetAddress() and long i/f name

    Details

    • Subcomponent:
    • Resolved In Build:
      b91
    • Verification:
      Verified

      Backports

        Description

        FULL PRODUCT VERSION :
        Java(TM) SE Runtime Environment (build 1.6.0_45-b06)
        Java HotSpot(TM) Client VM (build 20.45-b01, mixed mode, sharing)


        ADDITIONAL OS VERSION INFORMATION :
        SunOS solaris 5.11 11.1 i86pc i386 i86pc
        Oracle Solaris 11.1 SRU 4.5

        The same issue is also observed on Solaris 11.1 SPARC.

        EXTRA RELEVANT SYSTEM CONFIGURATION :
        The system has an IP interface with a name longer than 15 characters.

        andres@solaris:~$ ipadm
        NAME CLASS/TYPE STATE UNDER ADDR
        lo0 loopback ok -- --
           lo0/v4 static ok -- 127.0.0.1/8
           lo0/v6 static ok -- ::1/128
        longinterfacename0 ip down -- --
        net0 ip ok -- --
           net0/v4 dhcp ok -- 192.168.226.128/24
           net0/v6 addrconf ok -- fe80::20c:29ff:fe0d:f954/10


        A DESCRIPTION OF THE PROBLEM :
        If the system has an IP network interface with a name longer than 15 characters, any call to NetworkInterface.getByInetAddress() leads to a buffer overrun and heap corruption.

        Apart from the artificial test case given here, the issue is observed in the wild causing crashes in JBoss application server.


        STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
        Create an IP network interface with a long name, e.g.

        # dladm create-vnic -l net0 longinterfacename0
        # ipadm create-ip longinterfacename0

        Then compile & run the test case given below.

          To inspect further, enable memory debugging with libumem:

        # export UMEM_DEBUG=default UMEM_LOGGING=transaction LD_PRELOAD=libumem.so.1

        Then run the test case again and inspect the resulting core file with mdb.

        EXPECTED VERSUS ACTUAL BEHAVIOR :
        EXPECTED -
        Test case should execute producing no output and no exceptions.
        ACTUAL -
        JVM catches SIGSEGV and produces the following trace output.

        #
        # A fatal error has been detected by the Java Runtime Environment:
        #
        # SIGSEGV (0xb) at pc=0xfe631174, pid=5275, tid=2
        #
        # JRE version: 6.0_45-b06
        # Java VM: Java HotSpot(TM) Server VM (20.45-b01 mixed mode solaris-x86 )
        # Problematic frame:
        # C [libc.so.1+0x61174] _malloc_unlocked+0x184
        #
        # If you would like to submit a bug report, please visit:
        # http://java.sun.com/webapps/bugreport/crash.jsp
        # The crash happened outside the Java Virtual Machine in native code.
        # See problematic frame for where to report the bug.
        #

        --------------- T H R E A D ---------------

        Current thread (0x08070400): JavaThread " main " [_thread_in_native, id=2, stack(0xfd83f000,0xfd88f000)]

        siginfo:si_signo=SIGSEGV:
        [Output ends here, not truncated.]


        When libumem memory debugging is enabled, inspecting the core file with mdb yields the following results:

        Script started on April 24, 2013 11:46:48 AM CEST
        andres@solaris:~/src$ mdb +o pager core
        Loading modules: [ libumem.so.1 libc.so.1 ld.so.1 ]
        > ::umem_status
        Status: ready and active
        Concurrency: 2
        Logs: transaction=64k (inactive)
        Message buffer:
        umem allocator: redzone violation: write past end of buffer
        buffer=817c400 bufctl=817ddb0 cache: umem_alloc_48
        previous transaction on buffer 817c400:
        thread=2 time=T-0.000050302 slab=8092788 cache: umem_alloc_48
        libumem.so.1'umem_cache_alloc_debug+0x157
        libumem.so.1'umem_cache_alloc+0x19d
        libumem.so.1'umem_alloc+0xd0
        libumem.so.1'malloc+0x2d
        libnet.so'?? (0xfb4043e1)
        libnet.so'?? (0xfb404835)
        libnet.so'?? (0xfb404719)
        libnet.so'?? (0xfb404171)
        libnet.so'Java_java_net_NetworkInterface_getByInetAddress0+0x4e
        ?? (0xfba09c65)
        ?? (0xfba02ee7)
        ?? (0xfba02ee7)
        ?? (0xfba0035e)
        libjvm.so'?? (0xfdee10ed)
        libjvm.so'?? (0xfdee0ec7)
        umem: heap corruption detected
        stack trace:
        libumem.so.1'umem_err_recoverable+0x42
        libumem.so.1'umem_error+0x510
        libumem.so.1'umem_free+0x11b
        libumem.so.1'process_free+0x57
        libumem.so.1'free+0x1e
        libnet.so'?? (0xfb404261)
        libnet.so'Java_java_net_NetworkInterface_getByInetAddress0+0x16f
        ?? (0xfba09c65)
        ?? (0xfba02ee7)
        ?? (0xfba02ee7)
        ?? (0xfba0035e)
        libjvm.so'?? (0xfdee10ed)
        libjvm.so'?? (0xfdee0ec7)
        libjvm.so'?? (0xfdee0e97)
        libjvm.so'?? (0xfdf3a887)
        java'?? (0x8052f90)
        libc.so.1'_thrp_setup+0x9d
        libc.so.1'_lwp_start+0x0

        > 817c400::whatis
        mdb: unable to readvar " umem_internal_arena " : unknown symbol name
        817c400 is allocated from umem_alloc_48:
                    ADDR BUFADDR TIMESTAMP THREAD
                                    CACHE LASTLOG CONTENTS
                 817ddb0 817c400 1878d5c871afd 2
                                  8086210 8079578 0
                         libumem.so.1`umem_cache_alloc_debug+0x157
                         libumem.so.1`umem_cache_alloc+0x19d
                         libumem.so.1`umem_alloc+0xd0
                         libumem.so.1`malloc+0x2d
                         libnet.so`addif+0x171
                         libnet.so`enumIPvXInterfaces+0xf5
                         libnet.so`enumIPv4Interfaces+0x19
                         libnet.so`enumInterfaces+0x51
                         libnet.so`Java_java_net_NetworkInterface_getByInetAddress0+0x4e
                         0xfba09c65
                         0xfba02ee7
                         0xfba02ee7
                         0xfba0035e
                         libjvm.so`__1cJJavaCallsLcall_helper6FpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v_+0x21d
                         libjvm.so`__1cCosUos_exception_wrapper6FpFpnJJavaValue_pnMmethodHandle_pnRJavaCallArguments_pnGThread__v2468_v_+0x27

        > 817c400,40::dump
                  \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef
        817c400: 30000000 efbeadde 20c41708 03000000 0....... .......
        817c410: 00caddba d0180c08 00000000 88c41708 ................
        817c420: 6c6f6e67 696e7465 72666163 656e616d longinterfacenam
        817c430: 653000fe 112f0000 b0dd1708 5d1507a9 e0.../......]...
        >
        andres@solaris:~/src$
        script done on April 24, 2013 11:47:09 AM CEST


        Note in the hexdump above how part of the interface name overwrites the redzone starting at address 817c430.

        REPRODUCIBILITY :
        This bug can be reproduced always.

        ---------- BEGIN SOURCE ----------
        import java.net.InetAddress;
        import java.net.NetworkInterface;


        public class Test
        {
                public static void main (String[] args)
                        throws Exception
                {
                        NetworkInterface.getByInetAddress (InetAddress.getByName ( " 1.2.3.4 " ));
                }
        }

        ---------- END SOURCE ----------

        CUSTOMER SUBMITTED WORKAROUND :
        Use network interface names no longer than 15 chars.

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  khazra Kurchi Subhra Hazra
                  Reporter:
                  shadowbug Shadow Bug
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  7 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: