Bug 81496 - net-snmp dies on RedHat 8.1 RC 3 when doing an initial snmpwalk through Compaq mib items.
Summary: net-snmp dies on RedHat 8.1 RC 3 when doing an initial snmpwalk through Compa...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: net-snmp
Version: 9
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 79578
TreeView+ depends on / blocked
 
Reported: 2003-01-09 22:20 UTC by Larry Troan
Modified: 2016-04-18 09:38 UTC (History)
3 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2004-02-03 14:51:18 UTC
Embargoed:


Attachments (Terms of Use)
threadtst.c (1.28 KB, text/plain)
2003-02-03 02:15 UTC, Larry Troan
no flags Details

Description Larry Troan 2003-01-09 22:20:27 UTC
Problem Description:

The net-snmp daemon dies as soon as an snmpwalk is done on the Compaq mib items.
The crash is either in cmaX (wrong arguments passed into callback) or in a
system call pertaining to memory.
The hpasm/hprsm agents do keep on running, though. 

System Configuration:

System : ML 350
Operating System: Redhat 8.1 RC 3
Management Agents: 6.20 Pass 10 hpasm & hprsm

NOTES: the hpasm and hprsm are the Health and Management agents from HP.
----------
Action by: Bryan.Leopard
Issue Registered

Comment 1 Larry Troan 2003-01-09 22:21:21 UTC
Issue Tracker 13584

Comment 2 Phil Knirsch 2003-01-14 14:06:40 UTC
I need more information to be able to at least try to reproduce this problem.
Please add a description on how to set up a machine to reproduce this problem.
Also, what version of net-snmp was used?

Thanks,

Read ya, Phil

Comment 3 Larry Troan 2003-02-03 02:15:31 UTC
Created attachment 89790 [details]
threadtst.c

Sample program to reproduce error (from HP)

Comment 4 Larry Troan 2003-02-03 02:18:31 UTC
HP entered this problem in Issue Tracker (13584) as a severity 1.

Comment 5 Larry Troan 2003-02-04 04:00:26 UTC
FROM ISSUE TRACKER 14159 WHICH MAY BE A DUP OF IT 13584....
------------
The NetSNMP has been getting more and more unstable with each new release.  This
version is no longer suitable for production.

We found that if you restrict the permissions in NetSNMP and try to walk the MIB
from a machine that should not have permission to do so, the snmpd daemon
consumes near full CPU utilization for like 20 to 30 seconds.  Since our agents
register some 1400 MIB variables into snmpd, we found (through experimentation)
that the stack appears to wind through all these registrations at every request
that fails the security pass.  This causes snmpd to use 100% CPU for 20 to 30
seconds until it recovers.  This would make it very easy for someone to cause a
denial of service on a server by simply attempting to walk its mib from an
unauthorized workstation.

This is also evident on 8.1.  HP would like to propose that red hat use the UCD
SNMP instead of the net-snmp for all of it's products.

Comment 6 Phil Knirsch 2003-02-05 11:13:34 UTC
This is not an option. ucd-snmp is not being actively developed anymore and the
switch to net-snmp has already been done. ucd-snmp is going to die sooner or
later completely, so we would be betting on a nearly dead horse. Additionally,
most of the upstream bug fixes are done to net-snmp first, too.

Now, the test program is nice, but could you please specify how to compile and
use it, too? I have no clue whatsoever how the HP health monitor and management
stuff works, where to get it etc. And without that i can't reproduce the bug and
without being able to reproduce the bug i can't even start to think about fixing it.

Read ya, Phil


Comment 7 Larry Troan 2003-02-17 16:43:30 UTC
FROM BRYAN LEOPARD VIA ISSUE TRACKER....
We understand that ucd-snmp is "legacy software". That was the whole point of
filing this issue, as it happens on *net-snmp*. Upstream bug fixes are nice if
no new bugs are introduced. This does not seem to be the case right now for
net-snmp (things break that used to work).
The test program has no dependencies on HP management stuff. If just uses
signals and setjmp/longjmp. It runs completely standalone as a programming
exercise, as it were.
It will run well on RH 8.0, but fails on RH 9.
We suspect a glibc problem. It can be argued that this technique of
setjmp/longjmp and signals is somewhat archaic, but you can find it in
textbooks, so...
Compile with
gcc -o test threadtst.c -l pthread
./test

Status set to: Waiting on Tech


Comment 8 Phil Knirsch 2003-02-19 11:45:49 UTC
Erh, i am confused now.

Was this bug about a problem in net-snmp or a thread problem in glibc? If the
later, then the bug should be assigned to glibc instead of net-snmp.

If the former, then i can assure you that i've been experiencing the same DoS
problem for restricted trees in ucd-snmp as well as in net-snmp. This has been a
long standing problem in both and net-snmp-5.0.7 (which won't make it into the
next release but will be included in the one afterwards) fixes some of the
performance problems.

Read ya, Phil

Comment 9 Bill Nottingham 2003-07-28 22:31:40 UTC
Please try with current rawhide packages.

Comment 10 Phil Knirsch 2003-11-18 14:17:58 UTC
No more response, closing bug as worksforme.

Read ya, Phil


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