[Net-snmp-patches] [ net-snmp-Patches-3066862 ] large indexes on extErrFixCmd causes segmentation violations

[SourceForge.net <no...@so...>]

Patches item #3066862, was opened at 2010-09-15 06:39
Message generated for change (Settings changed) made by hardaker
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3066862&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: fhew (fhew)
Assigned to: Nobody/Anonymous (nobody)
Summary: large indexes on extErrFixCmd causes segmentation violations

Initial Comment:
Accessing some standard tables with (unusually large index values) causes snmpd to core dump
This has been tested against versions 5.6rc2 and 5.4.2.1.

Using the following command to reproduce the problem:

snmpgetnext -v1 -cpublic -Ir localhost 1.3.6.1.4.1.2021.8.1.103.4294967295

using some other indexes such as results in other return values::

snmpget -v1 -cpublic -Ir localhost 1.3.6.1.4.1.2021.8.1.103.1000000
Error in packet
Reason: (noSuchName) There is no such variable name in this MIB.
Failed object: UCD-SNMP-MIB::extErrFixCmd.1000000


snmpget -v1 -cpublic -Ir localhost 1.3.6.1.4.1.2021.8.1.103.4294967294
UCD-SNMP-MIB::extErrFixCmd.4294967294 = STRING:


----------------------------------------------------------------------

Comment By: fhew (fhew)
Date: 2010-09-15 11:39

Message:
My original suggested patch comment was too simplistic.
Refer to the attached files for better suggestions

The same style of problem exists and I've attached a similar set of
patches for

./agent/mibgroup/ucd-snmp/disk.c

tested with: snmpgetnext -v1 -cpublic -Ir localhost
1.3.6.1.4.1.2021.9.1.101.4294967294

A similar problem may exist elsewhere, but these have been the
only two I've stumbled across using my automated client tester.

Although the submitted patches may not be the 'correct' or best solution,
they address the issue of this bug submission.


----------------------------------------------------------------------

Comment By: fhew (fhew)
Date: 2010-09-15 07:34

Message:
Applying a debugger to the problem, I have narrowed it down to line 1397 of
./net-snmp-5.6.rc2/agent/mibgroup/agent/extend.c
where it performs a strlen() on a non-existent memory location (where a
command string
is supposed to reside).

But since the index is so large, the code at line 1363 blindly follows the
index given.

There should be some check in here to prevent the code from continuing and
instead return
the appropriate indication to upper levels to 'go to the next variable'.

    idx = name[*length-1] -1;
    exten = &compatability_entries[ idx ];
    if (exten) {
        switch (vp->magic) {
...
        case ERRORFIXCMD:
            if (exten->efix_entry) {
                *var_len = strlen(exten->efix_entry->command);
                return ((u_char *) exten->efix_entry->command);
            } else {
                *var_len = 0;
                return ((u_char *) &long_return);  /* Just needs to be
non-null! */
            }

Further investigation reveals that there is a variable called
max_compatability_entries = 50
that appears to define the number of entries that can appear in the table.

Perhaps the following code snippet could avoid the issue:

    idx = name[*length-1] -1;
    if (idx > max_compatability_entries)       <-- new
        return NULL;                                            <- new
    exten = &compatability_entries[ idx ];


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312694&aid=3066862&group_id=12694