sparc64/114349: When executing snmpd it immediately stops with a segmentation fault in disman/event/mteObjects.c

[Patrick Donnelly]

The following reply was made to PR sparc64/114349; it has been noted by GNATS.

From: Patrick Donnelly <phd at oceancomputer.com>
To: bug-followup at FreeBSD.org,
 freebsd-lists-1 at thismonkey.com
Cc:  
Subject: Re: sparc64/114349: When executing snmpd it immediately stops with a segmentation fault in disman/event/mteObjects.c
Date: Mon, 24 Mar 2008 13:08:17 -0400

 This issue is still present on FreeBSD 7-RELEASE; I just ran into  
 myself converting a Netra box from OpenSolaris to FreeBSD. I did some  
 debugging and discovered a workaround, the faulting component is in  
 the disman/events MIB, so simply adding "-I -mteObjects" to  
 snmpd_flags in rc.conf allows snmpd to start up and function, although  
 presumably without mteObjects functionality, whatever that is.
 
 The following patch also *appears* to rectifiy the problem without  
 disabling mteObjects:
 
 --- table_tdata.c.orig  2008-03-24 12:28:45.062698182 -0400
 +++ table_tdata.c       2008-03-24 12:21:04.111822058 -0400
 @@ -464,6 +464,9 @@
       if (!table)
           return NULL;
 
 +    if (!searchfor)
 +       return  NULL;
 +
       index.oids = searchfor;
       index.len  = searchfor_len;
       return CONTAINER_FIND( table->container, &index );
 
 
 The actual error occurs in mteObjects.c when the code tries to  
 dereference a null pointer. I'm somewhat perplexed as to why this bug  
 appears to only manifest on FreeBSD (Same hardware running Solaris  
 10/11 with net-snmp compiled from source has no such issue) and only  
 on sparc64. The problem arises because the netsnmp_tdata_row_get_byoid  
 function is matching newly created netsnmpt_tdata_rows which have null  
 oid_index.oids pointers to objects in the objects_table_data global,  
 which in turn is causing a branch in the code to be taken, which  
 attempts to increment oid_index.oids[row->oid_index.len] on the row  
 that has just been matched; since this is NULL, the problem segfaults.
 
 I'm unsure if the problem is because rows are being matched when they  
 shouldn't be, or if oid_index.oids is just not being initialized  
 properly somewhere. I can't see any initialization code being run in  
 the codepath leading up to here (the new row is malloc'd and zeroed  
 out just 30 lines before netsnmp_tdata_row_get_byoid is called) so my  
 naive solution was to change the netsnmp_tdata_row_get_byoid function  
 to immediately exit if given a null OID to search for, which appears  
 to work for me, but I'm not familiar enough with the codebase to tell  
 if that's the right thing to do in the long run.
 
 This appears to be an upstream issue that just got shaken out by the  
 combination of architecture and compiler on sparc64, so I'm submitting  
 it as a bug there as well, as it doesn't seem to exist in their bug  
 tracker yet.
 
 Patrick Donnelly
 Enterprise Network Engineer
 Ocean Computer Group
 90 Matawan Rd
 Suite 105
 Matawan New Jersey, 07747
 Office 732-493-1900 x245
 phd at oceancomputer.com