Afternoon all.

Whilst using valgrind to track down a memory leak in the LVS SNMP
module, we noticed an unrelated error report in snmpd 5.5 itself.

==26885== Invalid read of size 4
==26885==    at 0x4E6A8A3: table_helper_handler (table.c:620)
==26885==    by 0x4C34436: netsnmp_call_handlers (agent_handler.c:440)
==26885==    by 0x4C24BAE: handle_var_requests (snmp_agent.c:2611)
==26885==    by 0x4C26660: handle_pdu (snmp_agent.c:3363)
==26885==    by 0x4C28697: netsnmp_handle_request (snmp_agent.c:3203)
==26885==    by 0x4C28AF6: handle_snmp_packet (snmp_agent.c:1929)
==26885==    by 0x545088E: _sess_process_packet (snmp_api.c:5604)
==26885==    by 0x5451FB4: _sess_read (snmp_api.c:6043)
==26885==    by 0x5452898: snmp_sess_read2 (snmp_api.c:6075)
==26885==    by 0x5452952: snmp_read2 (snmp_api.c:5667)
==26885==    by 0x40486D: main (snmpd.c:1221)
==26885==  Address 0xabc7714 is 4 bytes inside a block of size 1,056 free'd
==26885==    at 0x4A05A31: free (vg_replace_malloc.c:325)
==26885==    by 0x547380F: netsnmp_free_all_list_data (data_list.c:29)
==26885==    by 0x4C32A36: netsnmp_free_request_data_sets (agent_handler.c:840)
==26885==    by 0x4E69CC0: table_helper_cleanup (table.c:1028)
==26885==    by 0x4E6A842: table_helper_handler (table.c:542)
==26885==    by 0x4C34436: netsnmp_call_handlers (agent_handler.c:440)
==26885==    by 0x4C24BAE: handle_var_requests (snmp_agent.c:2611)
==26885==    by 0x4C26660: handle_pdu (snmp_agent.c:3363)
==26885==    by 0x4C28697: netsnmp_handle_request (snmp_agent.c:3203)
==26885==    by 0x4C28AF6: handle_snmp_packet (snmp_agent.c:1929)
==26885==    by 0x545088E: _sess_process_packet (snmp_api.c:5604)
==26885==    by 0x5451FB4: _sess_read (snmp_api.c:6043)

We have seen no external symptoms, but would like to confirm that this
is an innocuous problem.

It appears that, in table_helper_handler() in agent/helpers/table.c,
tbl_req_info is being used in a test after the pointer has been freed.
The test is on line 619:
   if ((reqinfo->mode != MODE_GETNEXT) &&
      ((tbl_req_info->number_indexes != tbl_info->number_indexes) ||
      (tmp_len != -1))) {
         DEBUGMSGTL(("helper:table", "invalid index(es) for table -
skipping\n"));
         table_helper_cleanup(reqinfo, request, SNMP_NOSUCHINSTANCE);
         continue;
   }

However, it appears this memory has been freed on line 541 in the same function:
   if (reqinfo->mode != MODE_GETNEXT) {
      table_helper_cleanup(reqinfo, requests, SNMP_NOSUCHINSTANCE);
      cleaned_up = 1;
   }

Setting tbl_req_info to NULL after the call to table_helper_cleanup(),
and testing for this in the if statement, clears the valgrind error
report. However, I do not know if this is a good solution, or indeed
if a solution is required.

Thanks for your help.

Nick.

-- 
Nick Chalk.

Loadbalancer.org Ltd.
Phone: +44 (0)870 443 8779
http://www.loadbalancer.org/

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

_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Reply via email to