It was discovered that the snmp_pdu_parse() function could leave incompletely parsed varBind variables in the list of variables in case the parsing of the SNMP PDU failed. If later processing tries to operate on the stale and incompletely processed varBind (e.g. when printing the variables), this can lead to e.g. crashes or, possibly, execution of arbitrary code (although I've only seen NULL pointer dereferences during my testing, I currently can't rule out code execution completely). The snmp_pdu_parse() function stores varBind variables in a list of netsnmp_variable_list structures. Each time the function parses a new varBind, a new netsnmp_variable_list item is allocated on the heap and linked to the list of variables. The problem is that this item is not removed from the list, even if snmp_pdu_parse() fails to complete the parsing. The "type" member of the stale netsnmp_variable_list is not properly initialized in case snmp_pdu_parse() returns early from the parsing. However, the "type" member is used to determine later code paths, which is why we see crashes in a variety of functions, although the root cause for all of these is the same. References: Upstream patch: https://sourceforge.net/p/net-snmp/code/ci/f23bcd3ac6ddee5d0a48f9703007ccc738914791/ Upstream bug: https://sourceforge.net/p/net-snmp/bugs/2615/ (possibly restricted) Reporter's mail to oss-security: http://www.openwall.com/lists/oss-security/2015/04/13/1
Acknowledgements: Red Hat would like to thank Qinghao Tang (QIHU 360) for reporting this issue. Statement: (none)
Created net-snmp tracking bugs for this issue: Affects: fedora-all [bug 1212412]
any news on this one? It seems to me that this could lead to a remote DoS and maybe even remote code execution.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 6 Via RHSA-2015:1636 https://rhn.redhat.com/errata/RHSA-2015-1636.html