Bug 243536 - snmpd crashes when snmpd.conf contains more than one "exec shelltest" line
snmpd crashes when snmpd.conf contains more than one "exec shelltest" line
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: net-snmp (Show other bugs)
7
i386 Linux
low Severity low
: ---
: ---
Assigned To: Jan Safranek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-09 11:35 EDT by Fabrice Bellet
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version: 5.4-14.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-09 11:52:56 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)

  None (edit)
Description Fabrice Bellet 2007-06-09 11:35:36 EDT
Hi, 

it fails on Fedora 7, net-snmp-5.4-13.fc7.
and it works by downgrading to the latest FC6 package (net-snmp-5.3.1-14.fc6)

my snmpd.conf contains these lines :

exec shelltest /usr/local/bin/tempstat VRM2
exec shelltest /usr/local/bin/tempstat CPU1
exec shelltest /usr/local/bin/tempstat CPU2
exec shelltest /usr/local/bin/tempstat VRM1
exec shelltest /usr/local/bin/tempstat AGP
exec shelltest /usr/local/bin/tempstat DDR

when querying ext.Outout.1, the server crashes with this backtrace:

[root@helix tmp]# gdb snmpd
GNU gdb Red Hat Linux (6.6-8.fc7rh)Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) r -a -f
Starting program: /usr/sbin/snmpd -a -f
[Thread debugging using libthread_db enabled]
[New Thread -1208916288 (LWP 11238)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208916288 (LWP 11238)]
0x00bd0390 in var_extensible_old (vp=0xbfbef028, name=0x8140faa0,
length=0x8140fa90, exact=0, 
    var_len=0xbfbef434, write_method=0xbfbef438) at mibgroup/agent/extend.c:1352
1352                netsnmp_cache_check_and_reload( exten->exec_entry->cache );
(gdb) bt
#0  0x00bd0390 in var_extensible_old (vp=0xbfbef028, name=0x8140faa0,
length=0x8140fa90, exact=0, 
    var_len=0xbfbef434, write_method=0xbfbef438) at mibgroup/agent/extend.c:1352
#1  0x0055a293 in netsnmp_old_api_helper (handler=0x81369980,
reginfo=0x81369930, reqinfo=0x813cc4e0, 
    requests=0x813a0a20) at old_api.c:281
#2  0x002882eb in netsnmp_call_handler (next_handler=0x81369980,
reginfo=0x81369930, reqinfo=0x813cc4e0, 
    requests=0x813a0a20) at agent_handler.c:435
#3  0x00288970 in netsnmp_call_handlers (reginfo=0x81369930, reqinfo=0x813cc4e0,
requests=0x813a0a20)
    at agent_handler.c:516
#4  0x00279b5a in handle_var_requests (asp=0x813ff640) at snmp_agent.c:2497
#5  0x0027b6c6 in handle_pdu (asp=0x813ff640) at snmp_agent.c:3286
#6  0x0027c4a8 in netsnmp_handle_request (asp=0x813ff640, status=0) at
snmp_agent.c:3082
#7  0x0027d2ab in handle_snmp_packet (op=1, session=0x813ff698, reqid=542456425,
pdu=0x813ff598, magic=0x0)
    at snmp_agent.c:1856
#8  0x00e8a992 in _sess_process_packet (sessp=0x813c22a0, sp=0x813ff698,
isp=0x813d0f90, transport=0x813acbf0, 
    opaque=0x813d03d0, olength=20, packetptr=0x813ff798 "0,\002\001", length=46)
at snmp_api.c:5360
#9  0x00e8bcf0 in _sess_read (sessp=0x813c22a0, fdset=0xbfbefcc8) at snmp_api.c:5779
#10 0x00e8cbe9 in snmp_sess_read (sessp=0x813c22a0, fdset=0xbfbefcc8) at
snmp_api.c:5798
#11 0x00e8cc3f in snmp_read (fdset=0xbfbefcc8) at snmp_api.c:5412
#12 0x80004a32 in main (argc=3, argv=0xbfbefe94) at snmpd.c:1173
(gdb) print exten->exec_entry
$1 = (netsnmp_extend *) 0x0

The crash doesn't occur when my snmpd.conf file contains only a single "exec
shelltest" line.

my tempstat script :

# more /usr/local/bin/tempstat 
#!/bin/sh
export PATH=/bin:/usr/bin

LOCK=/tmp/`basename $0`.lock
trap "rm -f ${LOCK} ; exit 1" 1 2 3 15
lockfile -1 -r4 ${LOCK} || exit 0

x=`sensors -u | grep -i temp | egrep ^"$1" | head -1 | sed 's/^.*: //' | sed 's/
(.*$//'`
echo $x

rm -f ${LOCK}

But the same crash occurs, even when I replace it with something more simple,
like "/bin/echo 1" for example.
Comment 1 Jan Safranek 2007-06-27 07:08:05 EDT
From some reasons net-snmp-5.4 has different implementation of exec statements.
It's not possible to have more exec statements with the same MIBOID now. You
must use following MIBOIDs like this:

exec shelltest1 /usr/local/bin/tempstat VRM2
exec shelltest2 /usr/local/bin/tempstat CPU1
exec shelltest3 /usr/local/bin/tempstat CPU2
...

I'll ask upstream if this is a bug or feature :)
Comment 2 Jan Safranek 2007-06-27 07:08:48 EDT
Additional info: in either way, I'll fix the SIGSEGV.
Comment 3 Fabrice Bellet 2007-06-27 16:17:59 EDT
(In reply to comment #1)
> From some reasons net-snmp-5.4 has different implementation of exec statements.
> It's not possible to have more exec statements with the same MIBOID now. You
> must use following MIBOIDs like this:
> 
> exec shelltest1 /usr/local/bin/tempstat VRM2
> exec shelltest2 /usr/local/bin/tempstat CPU1
> exec shelltest3 /usr/local/bin/tempstat CPU2

ack! It works with this syntax, thanks. Maybe the sample config file should be
updated to reflect this change ?
Comment 4 Fedora Update System 2007-06-28 09:18:19 EDT
net-snmp-5.4-14.fc7 has been pushed to the Fedora 7 testing repository.  If problems still persist, please make note of it in this bug report.
Comment 5 Fabrice Bellet 2007-06-28 14:05:53 EDT
With this update, snmpd doesn't crash with several "exec shelltest" statements.
Thanks.
Comment 6 Fedora Update System 2007-07-09 11:52:52 EDT
net-snmp-5.4-14.fc7 has been pushed to the Fedora 7 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 7 Jan Safranek 2007-08-17 06:54:52 EDT
just a note from upstream, why the exec must be unique:

    The reason for not allowing duplicate names is that the
    new "extend" mechanism uses it as used as an index into
    the various nsExtend* tables.  Since it's an index, it
    clearly has to be unique.
    And starting with 5.4, the "exec" directive is now
    handled as a special-case of "extend"  (at least by default,
    though it is possible to revert to the previous code).

    I think that we've always assumed that the NAME token would
    be unique anyway - if only to identify which "exec" directive
    was being activated.  It's just that nothing has relied on
    this before.

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