Bug 81496 - net-snmp dies on RedHat 8.1 RC 3 when doing an initial snmpwalk through Compaq mib items.
net-snmp dies on RedHat 8.1 RC 3 when doing an initial snmpwalk through Compa...
Product: Red Hat Linux
Classification: Retired
Component: net-snmp (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
Depends On:
Blocks: 79578
  Show dependency treegraph
Reported: 2003-01-09 17:20 EST by Larry Troan
Modified: 2016-04-18 05:38 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-02-03 09:51:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

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

  None (edit)
Description Larry Troan 2003-01-09 17:20:27 EST
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 17:21:21 EST
Issue Tracker 13584
Comment 2 Phil Knirsch 2003-01-14 09:06:40 EST
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?


Read ya, Phil
Comment 3 Larry Troan 2003-02-02 21:15:31 EST
Created attachment 89790 [details]

Sample program to reproduce error (from HP)
Comment 4 Larry Troan 2003-02-02 21:18:31 EST
HP entered this problem in Issue Tracker (13584) as a severity 1.
Comment 5 Larry Troan 2003-02-03 23:00:26 EST
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 06:13:34 EST
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 11:43:30 EST
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

Status set to: Waiting on Tech
Comment 8 Phil Knirsch 2003-02-19 06:45:49 EST
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 18:31:40 EDT
Please try with current rawhide packages.
Comment 10 Phil Knirsch 2003-11-18 09:17:58 EST
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.