[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