This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 227977 - snmpd segfaults on: snmpwalk -v2c -c public -m ALL 127.0.0.1 .1.3
snmpd segfaults on: snmpwalk -v2c -c public -m ALL 127.0.0.1 .1.3
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: net-snmp (Show other bugs)
6
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Jan Safranek
bzcl34nup
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-02-09 04:05 EST by Jens H. G.
Modified: 2008-08-02 19:40 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 15:12:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
result of snmpd -d -f (56.24 KB, text/plain)
2007-02-09 04:05 EST, Jens H. G.
no flags Details
coredump (3.48 MB, application/octet-stream)
2007-02-09 10:29 EST, Jens H. G.
no flags Details
output of smnpwalk until it segfaults (75.79 KB, text/plain)
2007-03-02 11:54 EST, Jens H. G.
no flags Details
core dump with net-snmp-debuginfo (3.47 MB, application/octet-stream)
2007-03-05 11:38 EST, Jens H. G.
no flags Details
The last lines of snmpwalk after "snmpd -Dverbose:access:tcpconn" (5.90 KB, text/plain)
2007-03-07 03:27 EST, Jens H. G.
no flags Details

  None (edit)
Description Jens H. G. 2007-02-09 04:05:50 EST
Description of problem:
"snmpwalk -v2c -c public -m ALL 127.0.0.1 .1.3" results in an segfault of snmpd
/var/log/messages: snmpd[7853]: segfault at 0000557555989a9c rip
00002aaaab6cdd76 rsp 00007fff20e91cf0 error 6

Version-Release number of selected component (if applicable):
net-snmp       x86_64     1:5.3.1-12.fc6
net-snmp-utils x86_64     1:5.3.1-12.fc6

How reproducible:
"snmpwalk -v2c -c public -m ALL 127.0.0.1 .1.3" on a intel woodcrest (64bit)

Steps to Reproduce:
1. start snmpd with pubic community for localhost
2. run snmpwalk -v2c -c public -m ALL 127.0.0.1 .1.3
3. check /var/log/messages or service snmpd restart
  
Actual results:
/var/log/messages: snmpd[7853]: segfault at 0000557555989a9c rip
00002aaaab6cdd76 rsp 00007fff20e91cf0 error 6

Expected results:
no segfault


Additional info:
I started snmpd with -d -f
The result is attached (ip-adresses changed)
Comment 1 Jens H. G. 2007-02-09 04:05:50 EST
Created attachment 147748 [details]
result of snmpd -d -f
Comment 2 Jens H. G. 2007-02-09 04:43:53 EST
I tested this on three machines, which are all of the type (Dell)PowerEdge 1950.
http://www.dell.com/content/products/productdetails.aspx/pedge_1950?c=us&cs=555&l=en&s=biz&~section=specs#tabtop
with Intel(R) Xeon(R) CPU 5160 3.00GHz.
All three behaved exactly the same.

I have installed a plain fedora 6 without extra software.
uname -a on two of these machines (one had a reboot -> updated kernel in use)
Linux woodcrest01 2.6.18-1.2869.fc6 #1 SMP Wed Dec 20 14:51:34 EST 2006 x86_64
x86_64 x86_64 GNU/Linux
Linux woodcrest04 2.6.18-1.2798.fc6 #1 SMP Mon Oct 16 14:39:22 EDT 2006 x86_64
x86_64 x86_64 GNU/Linux


Comment 3 Jens H. G. 2007-02-09 10:29:11 EST
Created attachment 147780 [details]
coredump

This is the core-dump I forgot to attach. It was created with "ulimit -c
unlimited" and "snmpd -d -f"
(I changed the included ip to 111.222.333 and the hostname - I hope there is no
checksum included)
Comment 4 Radek Vokal 2007-02-19 04:31:59 EST
Do you have debuginfo package installed because I don't see any symbols in the
core file. Also do you know which exact MIB is causing the segfault? I haven't
manage to reproduce it here, works smoothly on my x86_64 box. 
Comment 5 Jens H. G. 2007-03-02 11:54:40 EST
Created attachment 149129 [details]
output of smnpwalk until it segfaults
Comment 6 Jens H. G. 2007-03-02 11:57:34 EST
Sorry, that it took so long for me to answer... Here I am back again :)

I have searched for "debuginfo" package on fedora core 6, but cannot
find any package like that. Please tell me what exactly you mean with
"debuginfo" and where I can find them.
The MIB which causes the segfault is probably the last entry printed to
the screen when doing snmpwalk -v2c -c public -m ALL 127.0.0.1 .1.3.
I attached the output of snmpwalk in comment #5.
Comment 7 Jens H. G. 2007-03-05 11:38:19 EST
Created attachment 149267 [details]
core dump with net-snmp-debuginfo

Backtrace:
#0  0x00002aaaab6cdd76 in netsnmp_hex_to_binary () from
/usr/lib64/libnetsnmp.so.10
#1  0x00002aaaaad6ace8 in netsnmp_arch_tcpconn_container_load () from
/usr/lib64/libnetsnmpmibs.so.10
#2  0x00002aaaaad6a5e7 in netsnmp_access_tcpconn_container_load () from
/usr/lib64/libnetsnmpmibs.so.10
#3  0x00002aaaaad6e785 in tcpConnectionTable_container_load () from
/usr/lib64/libnetsnmpmibs.so.10
#4  0x00002aaaab25b3d4 in netsnmp_cache_timer_start () from
/usr/lib64/libnetsnmphelpers.so.10
#5  0x00002aaaab25bb20 in netsnmp_cache_helper_handler () from
/usr/lib64/libnetsnmphelpers.so.10
#6  0x00002aaaab0277ce in netsnmp_call_handler () from
/usr/lib64/libnetsnmpagent.so.10
#7  0x00002aaaab26ae64 in table_helper_handler () from
/usr/lib64/libnetsnmphelpers.so.10
#8  0x00002aaaab0277ce in netsnmp_call_handler () from
/usr/lib64/libnetsnmpagent.so.10
#9  0x00002aaaab01ad5f in handle_var_requests () from
/usr/lib64/libnetsnmpagent.so.10
#10 0x00002aaaab01bde0 in handle_getnext_loop () from
/usr/lib64/libnetsnmpagent.so.10
#11 0x00002aaaab01d228 in netsnmp_handle_request () from
/usr/lib64/libnetsnmpagent.so.10
#12 0x00002aaaab01de07 in handle_snmp_packet () from
/usr/lib64/libnetsnmpagent.so.10
#13 0x00002aaaab6b98ca in snmpv3_parse () from /usr/lib64/libnetsnmp.so.10
#14 0x00002aaaab6ba8b1 in _sess_read () from /usr/lib64/libnetsnmp.so.10
#15 0x00002aaaab6bb319 in snmp_sess_read () from /usr/lib64/libnetsnmp.so.10
#16 0x00002aaaab6bb363 in snmp_read () from /usr/lib64/libnetsnmp.so.10
#17 0x0000555555559236 in main (argc=<value optimized out>, argv=<value
optimized out>) at snmpd.c:1152
Comment 8 Jens H. G. 2007-03-05 11:41:19 EST
I installed the packet net-snmp-debuginfo and attached the core-dump (hopefully
with symbols now) of "snmpd -d -f" after executing "snmpwalk -v2c -c public -m
ALL 127.0.0.1 .1.3"

Backtrace:
gdb /usr/lib/debug//usr/sbin/snmpd.debug core.30170
>bt
#0  0x00002aaaab6cdd76 in netsnmp_hex_to_binary () from /usr/lib64/libnetsnmp.so.10
#1  0x00002aaaaad6ace8 in netsnmp_arch_tcpconn_container_load () from
/usr/lib64/libnetsnmpmibs.so.10
#2  0x00002aaaaad6a5e7 in netsnmp_access_tcpconn_container_load () from
/usr/lib64/libnetsnmpmibs.so.10
#3  0x00002aaaaad6e785 in tcpConnectionTable_container_load () from
/usr/lib64/libnetsnmpmibs.so.10
#4  0x00002aaaab25b3d4 in netsnmp_cache_timer_start () from
/usr/lib64/libnetsnmphelpers.so.10
#5  0x00002aaaab25bb20 in netsnmp_cache_helper_handler () from
/usr/lib64/libnetsnmphelpers.so.10
#6  0x00002aaaab0277ce in netsnmp_call_handler () from
/usr/lib64/libnetsnmpagent.so.10
#7  0x00002aaaab26ae64 in table_helper_handler () from
/usr/lib64/libnetsnmphelpers.so.10
#8  0x00002aaaab0277ce in netsnmp_call_handler () from
/usr/lib64/libnetsnmpagent.so.10
#9  0x00002aaaab01ad5f in handle_var_requests () from
/usr/lib64/libnetsnmpagent.so.10
#10 0x00002aaaab01bde0 in handle_getnext_loop () from
/usr/lib64/libnetsnmpagent.so.10
#11 0x00002aaaab01d228 in netsnmp_handle_request () from
/usr/lib64/libnetsnmpagent.so.10
#12 0x00002aaaab01de07 in handle_snmp_packet () from
/usr/lib64/libnetsnmpagent.so.10
#13 0x00002aaaab6b98ca in snmpv3_parse () from /usr/lib64/libnetsnmp.so.10
#14 0x00002aaaab6ba8b1 in _sess_read () from /usr/lib64/libnetsnmp.so.10
#15 0x00002aaaab6bb319 in snmp_sess_read () from /usr/lib64/libnetsnmp.so.10
#16 0x00002aaaab6bb363 in snmp_read () from /usr/lib64/libnetsnmp.so.10
#17 0x0000555555559236 in main (argc=<value optimized out>, argv=<value
optimized out>) at snmpd.c:1152

Comment 9 Robert Story 2007-03-06 15:54:39 EST
can you start snmpd with -Dverbose:access:tcpconn and post the last few lines of
debug output?
Comment 10 Jens H. G. 2007-03-07 03:27:34 EST
Created attachment 149437 [details]
The last lines of snmpwalk after "snmpd -Dverbose:access:tcpconn"

snmpd -Dverbose:access:tcpconn
> No log handling enabled - turning on stderr logging
> registered debug token verbose:access:tcpconn, 1
> NET-SNMP version 5.3.1

The last lines of snmpwalk are attached
Comment 11 Jens H. G. 2007-03-23 13:11:51 EDT
I found the following in /var/log/messages:
    snmpd[1768]: looks like a 64bit wrap, but prev!=new

perhaps that helps....
Comment 12 Rene Cunningham 2007-03-24 21:14:17 EDT
I can reproduce this segfault everytime with a Xen guest running RHEL5 and
net-snmp-5.3.1-14.el5.
Comment 13 Jens H. G. 2007-05-02 04:05:39 EDT
I switched to the new kernel and did a "yum update" (fedora core 6) on all
machines, but snmpd still segfaults :(
Comment 14 Jan Safranek 2008-01-28 09:54:23 EST
I am sorry we failed to fix the bug. FC6 is not supported anymore. Could you
please try to reproduce the bug on Fedora 7 or 8 and attach your snmpd.conf and
snmpd output (in syslog, i.e. /var/log/messages)? 
Comment 15 Bug Zapper 2008-04-04 02:10:02 EDT
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 16 Bug Zapper 2008-05-06 15:12:10 EDT
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.