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

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.