United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-8013140 Heap corruption with NetworkInterface.getByInetAddress() and long i/f name
JDK-8013140 : Heap corruption with NetworkInterface.getByInetAddress() and long i/f name

Details
Type:
Bug
Submit Date:
2013-04-24
Status:
Closed
Updated Date:
2014-02-07
Project Name:
JDK
Resolved Date:
2013-05-02
Component:
core-libs
OS:
Sub-Component:
java.net
CPU:
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u25,6u45,7,8
Fixed Versions:

Related Reports
Backport:
Backport:
Backport:
Backport:
Backport:

Sub Tasks

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.
                                    

Comments
This is likely a dup of JDK-6931566.
                                     
2013-04-25
Although the issue is similar to the one reported in 6931566, it is reproducible on 5.11 with latest jdk7udev/8 builds. I am working on it but I suspect that this is a real bug. 
                                     
2013-04-26
URL:   http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3062bf908281
User:  khazra
Date:  2013-05-02 21:18:12 +0000

                                     
2013-05-02
verified with build: /net/rehudson/n/v2/nightlyws/jdk8-tl/b89_2013-05-07-1702_4319/ws-b89_2013-05-07-1702_4319/build/solaris-amd64/j2sdk-image/bin on a solaris jsn-sfx4200-3.
                                     
2013-05-09
URL:   http://hg.openjdk.java.net/jdk8/jdk8/jdk/rev/3062bf908281
User:  lana
Date:  2013-05-21 18:20:30 +0000

                                     
2013-05-21
The heap gets corrupted when using IFNAMSIZ(16) to allocate space for the interface name in addif() in src/solaris/native/java/net/NetworkInterface.c, when the original name could be of length LIFNAMSIZ(32).
                                     
2013-05-01



Hardware and Software, Engineered to Work Together