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. /MF ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
