[prev in list] [next in list] [prev in thread] [next in thread]
List: net-snmp-bugs
Subject: [ net-snmp-Bugs-1259049 ] snmpd segfaults in IP-MIB during snmpwalk
From: "SourceForge.net" <noreply () sourceforge ! net>
Date: 2006-02-13 3:20:23
Message-ID: 200602130320.k1D3KNYI005908 () sc8-sf-db2-new-b ! sourceforge ! net
[Download RAW message or body]
Bugs item #1259049, was opened at 08/14/05 08:28
Message generated for change (Settings changed) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1259049&group_id=12694
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: agent
Group: linux
>Status: Closed
Resolution: Accepted
Priority: 8
Submitted By: Jochen (jochen2)
Assigned to: Robert Story (rstory)
Summary: snmpd segfaults in IP-MIB during snmpwalk
Initial Comment:
This bug is forwarded from
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=323038:
From: Julien BLACHE <jblache@debian.org>
Hi,
% snmpwalk [...] 10.0.1.2
[...]
IP-MIB::ip.34.1.11.1.4.127.0.0.1 = INTEGER: 2
IP-MIB::ip.34.1.11.2.16.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1
= INTEGER: 2
IP-MIB::ip.34.1.11.2.16.32.1.7.168.24.94.0.1.0.0.0.0.0.0.0.16
= INTEGER: 2
IP-MIB::ip.34.1.11.2.16.254.128.0.0.0.0.0.0.2.0.180.255.254.185.115.222
= INTEGER: 2
IP-MIB::ip.34.1.11.2.16.254.128.0.0.0.0.0.0.2.5.93.255.254.162.102.34
= INTEGER: 2
IP-MIB::ip.35.1.4.1.4.4.10.10.10.1 = Hex-STRING: 00 10
A7 11 F9 3F
Timeout: No Response from 10.0.1.2
Happens on all my machines, not architecture-specific.
*** glibc detected *** free(): invalid pointer:
0x0000000000649dd8 ***
Program received signal SIGABRT, Aborted.
0x00002aaaab772dd0 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00002aaaab772dd0 in raise () from /lib/libc.so.6
#1 0x00002aaaab774280 in abort () from /lib/libc.so.6
#2 0x00002aaaab7a853e in __fsetlocking () from
/lib/libc.so.6
#3 0x00002aaaab7ae29b in malloc_usable_size () from
/lib/libc.so.6
#4 0x00002aaaab7ae57e in free () from /lib/libc.so.6
#5 0x00002aaaab1e7d16 in snmp_free_var (var=0x6764a0)
at snmp_api.c:4861
#6 0x00002aaaab1e7dc7 in snmp_free_varbind
(var=0x6764a0) at snmp_api.c:4881
#7 0x00002aaaab1e7e31 in snmp_free_pdu (pdu=0x65ac90)
at snmp_api.c:4921
#8 0x00002aaaab1e7ba7 in _sess_async_send
(sessp=0x62aa60, pdu=0x65ac90, callback=0, cb_data=0x0)
at snmp_api.c:4815
#9 0x00002aaaab1e7c0b in snmp_sess_async_send
(sessp=0x62aa60, pdu=0x65ac90, callback=0, cb_data=0x0)
at snmp_api.c:4833
#10 0x00002aaaab1e70ab in snmp_async_send
(session=0x65a520, pdu=0x65ac90, callback=0,
cb_data=0x0) at snmp_api.c:4565
#11 0x00002aaaab1e7046 in snmp_send (session=0x65a520,
pdu=0x65ac90) at snmp_api.c:4551
#12 0x00002aaaaae4be4c in netsnmp_wrap_up_request
(asp=0x677350, status=0) at snmp_agent.c:1627
#13 0x00002aaaaae4f08d in netsnmp_handle_request
(asp=0x677350, status=0) at snmp_agent.c:2996
#14 0x00002aaaaae4c48d in handle_snmp_packet (op=1,
session=0x65a520, reqid=20857002, pdu=0x65aa70,
magic=0x0) at snmp_agent.c:1792
#15 0x00002aaaab1e89f2 in _sess_process_packet
(sessp=0x62aa60, sp=0x65a520, isp=0x65a9a0,
transport=0x658970, opaque=0x657f90, olength=16,
packetptr=0x65dee0
"0@\002\001\001\004\004mrtg¡5\002\004\001>@ª\002\001",
length=66) at snmp_api.c:5213
#16 0x00002aaaab1e9fef in _sess_read (sessp=0x62aa60,
fdset=0x7fffffcdf940) at snmp_api.c:5610
#17 0x00002aaaab1ea040 in snmp_sess_read
(sessp=0x62aa60, fdset=0x7fffffcdf940) at snmp_api.c:5629
#18 0x00002aaaab1e8b90 in snmp_read
(fdset=0x7fffffcdf940) at snmp_api.c:5265
#19 0x00000000004050a8 in receive () at snmpd.c:1149
#20 0x0000000000404615 in main (argc=7,
argv=0x7fffffce0ca8) at snmpd.c:993
So, this segfault is obviously caused by a double-free,
as the pointer
passed to free() is, indeed, a valid pointer.
snmpd crashes at this point:
.1.3.6.1.2.1.4.35.1.4.1.4.4.10.0.1.1 = Hex-STRING: 00
C1 97 AB AA 2A
So the crash happens after querying the very first
object of
.1.3.6.1.2.1.4.35.1.4.*, when the data structure gets
freed. As the
pointer is a valid pointer, the problem lies when the
structure is
created/populated.
This is handled in
agent/mibgroup/ip-mib/inetNetToMediaTable/inetNetToMediaTable.c
(surprise, surprise, this IP-MIB code is definitely
buggy as hell).
311 int
312
inetNetToMediaPhysAddress_get(inetNetToMediaTable_rowreq_ctx
* rowreq_ctx,
...
327 (*inetNetToMediaPhysAddress_val_ptr_ptr) =
328 rowreq_ctx->data->arp_physaddress;
...
The Hex-STRING looks very much like a MAC address, and
it indeed
is. This is where the data structure is populated with
the MAC address
string.
It relies on the query context, and chances are this
context gets
freed automagically by something else before the data
structure gets freed (I don't remember the magic of
snmpd query contexts -- but the context gets freed
before the data structure for sure).
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 02/12/06 19:20
Message:
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 180 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Robert Story (rstory)
Date: 08/16/05 16:57
Message:
Logged In: YES
user_id=76148
well, any machine isn't right, as I have have no problem on
my machine. However, I think I see the issue. Here is a
proposed patch. Let me know if it works.
deleting submitters proposed patch, as strdup is definiately
not the right thing for a MAC address.
----------------------------------------------------------------------
Comment By: Jochen (jochen2)
Date: 08/16/05 09:26
Message:
Logged In: YES
user_id=85147
The bug can still be confirmed on V5-2-patches.
According to the original submitter:
- the segfault during the snmpwalk will trigger on any
machine, whatever the architecture (might depend on the
routing table of the machine)
- segfault during snmpwalk: not fixed, happens at the same
place. Proposed fix fixes it; upstream should validate it,
there may be something better to do.
----------------------------------------------------------------------
Comment By: Thomas Anders (tanders)
Date: 08/14/05 15:26
Message:
Logged In: YES
user_id=848638
Can this be reproduced with V5-2-patches from CVS? This has
many fixes over 5.2.1.2.
----------------------------------------------------------------------
Comment By: Jochen (jochen2)
Date: 08/14/05 08:35
Message:
Logged In: YES
user_id=85147
Version: 5.2.1.2
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=1259049&group_id=12694
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Net-snmp-bugs mailing list
Net-snmp-bugs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-bugs
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic