[ net-snmp-Bugs-1459665 ] DISPLAY-HINT "x" for OCTET-STRING results in infinite loop

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

Bugs item #1459665, was opened at 2006-03-27 23:23
Message generated for change (Comment added) made by dts12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1459665&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bill Fenner (fenner)
Assigned to: Nobody/Anonymous (nobody)
Summary: DISPLAY-HINT "x" for OCTET-STRING results in infinite loop

Initial Comment:
Cisco's CISCO-FLASH-MIB contains the following TC:

ChecksumString ::= TEXTUAL-CONVENTION
        DISPLAY-HINT "x"
        STATUS  current
        DESCRIPTION
                "Represents the checksum of a file.
                "
        SYNTAX  OCTET STRING

This is illegal; RFC 2579 says that the octet length is not optional.

net-snmp gamely tries to interpret this; I didn't get all the way into this 
so I'm hoping someone who understands the code better will jump in.  
My guess is that it's interpreting it as zero, so it's printing zero bytes 
with the x format, then looping back and processing the rest of the 
string.  Since it keeps processing zero bytes over and over again, it 
never finishes.

This manifests itself as an infinite loop when trying to display a CISCO-
FLASH-MIB::ciscoFlashFileChecksum value.

(The MIB is probably flat wrong, since once I changed the DISPLAY-
HINT to "1x" I got no infinite loop, but instead

CISCO-FLASH-MIB::ciscoFlashFileChecksum.1.1.1 = STRING: 
30784530354344333333
CISCO-FLASH-MIB::ciscoFlashFileChecksum.1.1.2 = STRING: 
30783532423937373831
CISCO-FLASH-MIB::ciscoFlashFileChecksum.1.1.3 = STRING: 
30783832353546344443
CISCO-FLASH-MIB::ciscoFlashFileChecksum.3.1.1 = STRING: 307830

which are hex representations of ASCII strings which are themselves 
hex strings which are presumably the actual checksums; however, that 
is obviously not net-snmp's problem.)

If it helps, this is the backtrace while in the infinite loop:

(gdb) bt
#0  snmp_strcat (buf=0xbfbfe570, buf_len=0xbfbfe56c, 
out_len=0xbfbfe568, 
    allow_realloc=1, s=0xbfbfe490 "0") at tools.c:179
#1  0x280857b4 in sprint_realloc_octet_string (buf=0xbfbfe570, 
    buf_len=0xbfbfe56c, out_len=0xbfbfe568, allow_realloc=1, 
var=0x80bbc00, 
    enums=0x0, hint=0x80c6151 "", units=0x0) at mib.c:512
#2  0x2808b464 in sprint_realloc_variable (buf=0xbfbfe570, 
buf_len=0xbfbfe56c, 
    out_len=0xbfbfe568, allow_realloc=1, objid=0x80bbc18, 
objidlen=19, 
    variable=0x80bbc00) at mib.c:3276
#3  0x2808b5c4 in fprint_variable (f=0x282f0358, objid=0x80bbc18, 
objidlen=19, 
    variable=0x80bbc00) at mib.c:3346
#4  0x2808b541 in print_variable (objid=0x80bbc18, objidlen=19, 
    variable=0x80bbc00) at mib.c:3322
#5  0x0804921b in main (argc=9, argv=0xbfbfeb7c) at snmpwalk.c:
297

(gdb) frame 2
#2  0x2808b464 in sprint_realloc_variable (buf=0xbfbfe570, 
buf_len=0xbfbfe56c, 
    out_len=0xbfbfe568, allow_realloc=1, objid=0x80bbc18, 
objidlen=19, 
    variable=0x80bbc00) at mib.c:3276
3276                return (*subtree->printomat) (buf, buf_len, out_len,
(gdb) print subtree->hint 
$42 = 0x80c6150 "x"
(gdb) p subtree->printomat
$43 = (int (*)(u_char **, size_t *, size_t *, int, 
    const netsnmp_variable_list *, const struct enum_list *, const char *, 
    const char *)) 0x28085484 <sprint_realloc_octet_string>

Since a length of zero is permitted, net-snmp is doing reasonably well 
assuming that "x" means zero - I don't really know what to suggest, 
though, if it has a zero-length value to apply to the rest of the string - 
perhaps just return a zero-length string.

----------------------------------------------------------------------

Comment By: Dave Shield (dts12)
Date: 2006-07-25 14:48

Message:
Logged In: YES 
user_id=88893

Thanks for the bug report!  We've fixed the problem in the
5.2.x and 5.3.x code branches and the main development tree,
so it should be fixed in future releases of the net-snmp package.

----------------------------------------------------------------------

Comment By: Bill Fenner (fenner)
Date: 2006-03-28 00:04

Message:
Logged In: YES 
user_id=109593

The default answer is pretty annoying, since an interested developer could try 
reproducing the problem with about 5 minutes of work (editing an object with 
an underlying type of OCTET STRING to have a DISPLAY-HINT of "x"), but 
downloading and compiling 5.3.0.1 and searching out the official patches 
took me the better part of an hour, but I'll play along.

For completeness, the patches that I downloaded were:

[ 1429059 ] 5.3.0.1: DISMAN monitoring crash -> disman.pat
[ 1421725 ] 5.3.0.x: OID lookups fail -> oid-names2_5.3.patch
[ 1420758 ] 5.3/5.3.0.1 snmptrapd: select: No such file or directory -> 
patch-snmptrapd-win32-select

[P.S. the Official Patches are not particularly obvious.  Perhaps a link from the 
download page?]

snmpwalk exhibited the same behavior: infinite loop with an unmodified 
CISCO-FLASH-MIB.

----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2006-03-27 23:42

Message:
Logged In: YES 
user_id=848638

Which raises the obvious default answer to bug reports: can
you try with the latest release (5.3.0.1 plus official
patches applied) to see whether it fixes your problems?

----------------------------------------------------------------------

Comment By: Bill Fenner (fenner)
Date: 2006-03-27 23:27

Message:
Logged In: YES 
user_id=109593

Sorry for committing the capital sin of bug reporting.  This bug is experienced in 
net-snmp 5.2.2 .

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1459665&group_id=12694