[Pkg-net-snmp-devel] Bug#699350: buffer overrun bug in libsnmp15-python

Mirar debian.bugs at sort.mirar.org
Wed Jan 30 14:26:22 UTC 2013


Package: libsnmp-python
Version: 5.4.3~dfsg-2

I noticed a buffer overrun problem in the python glue for libsnmp.

Sometimes, the other integers in the same SetRequest would have
overflow from the previous integers. Typical testcase: 

import netsnmp
vars = []
varlist = netsnmp.VarList(*vars)
vars.append(netsnmp.Varbind("1.2.3.42",0,421234,"INTEGER"))
vars.append(netsnmp.Varbind("1.2.3.17",0,17,"INTEGER"))
session = netsnmp.Session(DestHost="10.0.0.17", Community="public", Version=1)
result = session.set(varlist)
varlist = netsnmp.VarList(*vars)
result = session.set(varlist)

The second variable would be sent as '421234'.

This could easily be triggered on the ARM I'm using.

Suggested patch:

--- net-snmp-5.4.3/python/netsnmp/client_intf.c.old     2013-01-30 14:21:33.904761367 +0000
+++ net-snmp-5.4.3/python/netsnmp/client_intf.c 2013-01-30 11:00:30.134762736 +0000
@@ -2351,7 +2351,7 @@
   oid *oid_arr;
   int oid_arr_len = MAX_OID_LEN;
   int type;
-  u_char tmp_val_str[STR_BUF_SIZE];
+  u_char tmp_val_str[STR_BUF_SIZE]={0};
   int use_enums;
   struct enum_list *ep;
   int verbose = py_netsnmp_verbose();
@@ -2425,7 +2425,7 @@
          snmp_free_pdu(pdu);
          goto done;
        }
-       memcpy(tmp_val_str, val, tmplen);
+       memcpy(tmp_val_str, val, tmplen+1);
        if (type==TYPE_INTEGER && use_enums && tp && tp->enums) {
          for(ep = tp->enums; ep; ep = ep->next) {
            if (val && !strcmp(ep->label, val)) {

I guess someone that knows their way around python glue should
probably check if that is the correct solution. 
Works for me though...

thanks
/Mirar



More information about the Pkg-net-snmp-devel mailing list