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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org