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 _______________________________________________ Net-snmp-coders mailing list Net-snmp-coders@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
