Re: Net-SNMP 5.8.rc2 available for testing

On 2018/05/19 10:26, Magnus Fromreide wrote:
> On Fri, May 18, 2018 at 08:46:40PM -0700, Bart Van Assche wrote:
> > On 05/18/18 18:05, Stuart Henderson wrote:
> > > On 2018/05/18 18:36, Robert Story wrote:
> > > >      snmplib:
> > > >        - [BUG 2815]: Display UTF-8 characters again
> > > >        - [BUG 3444939]: BUG: 1796886: snmplib: Avoid that
> > > >          sprint_realloc_octet_string() embeds unprintable control characters
> > > >          or binary zeroes in its output. This behavior could cause truncated
> > > >          output in snmptrapd.")
> > > 
> > > I think there's a problem with this change, with rc2 I'm seeing frequent
> > > segfaults in walk/bulkwalk (one out of every 3 or 4 attempts to run it),
> > > these don't occur with rc1 and sprint_realloc_octet_string() is in the
> > > backtrace.
> > > 
> > > $ snmpwalk -v2c -c public 10.15.5.1
> > > <...snip...>
> > > SNMPv2-MIB::sysORDescr.3 = STRING: iso.org.dod.internet.mgmt.mib_2.ipMIB.ipfMIB
> > > SNMPv2-MIB::sysORDescr.4 = STRING: iso.org.dod.internet.mgmt.mib_2.snmp
> > > SNMPv2-MIB::sysORDescr.5 = STRING: iso.org.dod.internet.mgmt.mib_2.dot1dBridge
> > > SNMPv2-MIB::sysORDescr.6 = STRING: iso.org.dod.internet.mgmt.mib_2.host
> > > SNMPv2-MIB::sysORDescr.7 = STRING: iso.org.dod.internet.mgmt.mib_2.ifMIB
> > > 
> > > Program received signal SIGSEGV, Segmentation fault.
> > > _libc_strlcpy (dst=0x15ddceaf3070 "", src=0x15de4bd9e000 <error: Cannot access memory at address 0x15de4bd9e000>,
> > >      dsize=<optimized out>) at /usr/src/lib/libc/string/strlcpy.c:45
> > > 45                      while (*src++)
> > > (gdb) bt
> > > #0  _libc_strlcpy (dst=0x15ddceaf3070 "",
> > >      src=0x15de4bd9e000 <error: Cannot access memory at address 0x15de4bd9e000>, dsize=<optimized out>)
> > >      at /usr/src/lib/libc/string/strlcpy.c:45
> > > #1  0x000015de2f559fdc in sprint_realloc_octet_string (buf=0x7f7ffffe7220, buf_len=0x7f7ffffe7218,
> > >      out_len=0x7f7ffffe7210, allow_realloc=1, var=0x15de238e7800, enums=0x0, hint=0x15de50e25274 "", units=0x0)
> > >      at mib.c:589
> > > #2  0x000015de2f566028 in sprint_realloc_variable (buf=0x7f7ffffe7220, buf_len=0x7f7ffffe7218,
> > >      out_len=0x7f7ffffe7210, allow_realloc=1, objid=0x15de238e7830, objidlen=11, variable=0x15de238e7800)
> > >      at mib.c:3581
> > > #3  0x000015de2f56626d in fprint_variable (f=0x15dd9e658308 <__sF+152>, objid=0x15de238e7830, objidlen=11,
> > >      variable=0x15de238e7800) at mib.c:3653
> > > #4  0x000015de2f5661c5 in print_variable (objid=0x15de238e7830, objidlen=11, variable=0x15de238e7800) at mib.c:3629
> > > #5  0x000015db58a00fd1 in main (argc=3, argv=0x7f7ffffe81f8) at snmpwalk.c:338
> > 
> > With which operating system, compiler and C library did you encounter this?
> > There is no guarantee that the 'str' argument passed from that code path to
> > strlcpy() will be '\0'-terminated. I'm surprised to see a while (*src++)
> > loop in strlcpy() - I doubt that that is correct.
> 
> I think a while(*src++) in strlcpy is reasonable.
> 
> Strlcpy does after all return strlen(src) and that is hard to achive without
> such a loop.
> 
> If there is no guarantee that src is '\0'-terminated then strlcpy is the wrong
> function to use.

This is on OpenBSD (where strlcpy originated, actually). Our own libc,
clang 6.0 (same behaviour with -O0).

strlcpy is definitely only meant for C strings (i.e. \0-terminated).


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot