wireshark[16059]: segfault at 600000043 ip 00007f37db33e450 sp 00007fff010497f0 error 4 in libsmi.so.2.0.27[7f37db329000+5a000]

stracing wireshark shows that it tries to read may MIBS and does not find them and then crashes.

OoO En  ce début  d'après-midi nuageux du  jeudi 10 décembre  2009, vers
14:14, Meelis Roos <mroos@linux.ee> disait :

Which version of Wireshark are you using? Does it crash at start or when
inspecting trafic? I am unable to reproduce this bug.

starting wireshark causes a segfault before the main window opens. it happens durring the splash screen.

"[26646.019934] wireshark[20652]: segfault at 322d6269ad ip 00007f7d65d3f450 sp 00007fff745d32e0 error 4 in libsmi.so.2.0.27[7f7d65d2a000+5a000]"

i was able to get a backtrace:

(gdb) run
Starting program: /home/david/Applications/Source/wireshark/wireshark-1.2.4/.libs/lt-wireshark
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
getNextChildObject (startNodePtr=0x322d62696d, modulePtr=0x14d49b0, nodekind=65535) at smi.c:163
163     smi.c: No such file or directory.
        in smi.c
(gdb) bt
#0  getNextChildObject (startNodePtr=0x322d62696d, modulePtr=0x14d49b0, nodekind=65535) at smi.c:163
#1  0x00007ffff111449f in getNextChildObject (startNodePtr=<value optimized out>, modulePtr=0x14d49b0,
    nodekind=65535) at smi.c:172
#2  0x00007ffff1114a91 in smiGetFirstNode (smiModulePtr=0x14d49b0, nodekind=65535) at smi.c:1387
#3  0x00007ffff5bdd2b8 in register_mibs () at oids.c:587
#4  0x000000000044b881 in main (argc=1, argv=0x7fffffffe038) at main.c:2106


Wireshark version: 1.2.4-3
note: if i compile wireshark without libsmi2 it works fine.

OoO Pendant  le repas  du vendredi 18  décembre 2009, vers  19:22, David
Steiner <doodydexter@yahoo.com> disait :

Thanks for the strace!

Comparing with  my system, I  see that the  problem resides in  the fact
that you don't  have RFC1155-SMI MIB which is  needed by RFC1213-MIB. In
this case, libsmi2  is very weak and build an  incomplete tree that will
cause the  segfault. This  is not  easy to fix  since libsmi  builds its
internal tree as the MIB is parsed and it cannot just undo those changes
when there is a problem (like missing dependencies).

I don't  know why you  don't have RFC1155-SMI.  I suppose that  your MIB
were downloaded  by libsnmp-base (which is  not done any  more) and that
RFC  was not  included in  the list.  As a  workaround,  please download
RFC1155-SMI and apply smistrip on it to get the MIB :
 wget -O - http://www.ietf.org/rfc/rfc1155.txt | smistrip

You'll get RFC1155-SMI that you can put in /usr/share/mibs/ietf.

OoO En ce  début de soirée du vendredi 18 décembre  2009, vers 21:58, je
disais:

You can  also apply this patch  to wireshark. I think  this should solve
the issue (silently).

wireshark 1.2.4-3

It crashes during startup, when the splashscreen gauge has covered about
1cm.

It does not crash on i386, there it displays only a large messagebox
about missing MIBS. But it crashes on amd64 repeatably on 2 machines
tested.

Hi Werner,

I suspect it crashed because of #560325 [1].
An strace log would tell that.

#560325 contains a potential workaround for wireshark, but i think the
bug should be fixed in libsmi
as there are more packages depending on it.

Cheers,
Balint

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325


2009/12/23 Werner Thal <wt@krzn.de>:

clone 560325 -1
reassign -1 wireshark
thanks

Dear Wireshark maintainers,

As you know,  bug #560325 affects some Wireshark users.  In fact, when a
MIB cannot be loaded because, for example, not all dependencies are met,
this MIB  is still present  in memory but  is incoherent. This  leads to
some segfault when trying to use it.

This bug seems difficult to fix in libsmi. Therefore, it would be better
to  fix the  problem in  wireshark by  checking the  conformance  of the
module before using it. I attach the simple patch to this mail.

To track this  problem, I clone the original bug  report (since it needs
to be fixed in libsmi too).

Thanks.

Hi Vincent,

I'have added your patch to the wireshark package with some additional
error reporting [1].

Now wireshark/tshark complains about three MIBs:
tshark: Stopped processing module SNMP-COMMUNITY-MIB due to error(s)
to prevent potential crash in libsmi.
Module's conformance level: 0.
See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325

tshark: Stopped processing module SNMP-MPD-MIB due to error(s) to
prevent potential crash in libsmi.
Module's conformance level: 0.
See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325

tshark: Stopped processing module SNMP-PROXY-MIB due to error(s) to
prevent potential crash in libsmi.
Module's conformance level: 0.
See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325

Related packages installed:
snmp-mibs-downloader 1.0
libsmi2ldbl 0.4.7+dfsg-0.1

Could we somehow refine the workaround to not complain about those
false positives?
Wireshark did not crash even without the workaround with the same MIBs
installed.

Cheers,
Balint

[1] http://svn.debian.org/wsvn/collab-maint/?op=comp&compare[]=%2Fext-maint%2Fwireshark%2Ftrunk@15544&compare[]=%2Fext-maint%2Fwireshark%2Ftrunk@15557


2010/1/31 Vincent Bernat <bernat@luffy.cx>:
...

OoO Peu avant le début de l'après-midi du vendredi 26 février 2010, vers
13:21, Bálint Réczey <balint@balintreczey.hu> disait :

I  have ran  smilint  on  my system  on  those MIB  and  it reported  no
error. It  seems that  there exists some  cases where no  conformance is
computed  and in this  case, conformance  level is  0. This  should mean
"Internal error,  no recovery possible", but  I suppose this  is not the
case here.

Therefore,  a  workaround would  be  to  use (smiModule->conformance  &&
smiModule->conformance    <=   1)   which    can   be    translated   as
(smiModule->conformance == 1). This is roughly what smidump does:

 if ((smiModule->conformance) && (smiModule->conformance < 3)) {

It  will still  catches  MIB that  may  not crash  Wireshark  but it  is
difficult to guess if a MIB will crash or not. For example, if libsmi is
not able  to compute the  OID of a  root node (because it  needs another
module which does not exist), it will crash wireshark. If it is not able
to compute the OID of a node that is never used, it will not crash. Some
old MIB also defines OBJECT-TYPE as RFC-1212. This MIB is not shipped on
my system but  everything is fine because libsmi  knows what OBJECT-TYPE
is but  it will issue  an error  because it will  not be able  to import
RFC-1212 MIB.

I hope that libsmi upstream will be able to fix this issue in libsmi.

Hi,

After Enabling OID resolution in Wireshark Preferences -->Name Resolution we started seeing this error in Wireshark:
Stopped processing module SNMPv2-SMI due to error(s) to prevent potential crash in libsmi.
Module’s conformance level:1.
See details at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325

We use WireShark ( Version 1.4.0 (S ) ).
In Vista C:\Program Files\Wireshark\snmp\mibs directory we have all posible MIBS available ( 309 items) including SNMPv2-SMI, RFC1155-SMI,
SNMP-COMMUNITY-MIB , SNMP-MPD-MIB, SNMP-PROXY-MIB etecetera
However when looking closely in Wireshark SMI(MIB and PIB) modules to check which modules are loaded we see only a few.
We don’t see here SNMPv2-SMI, RFC1155-SMI, SNMP-COMMUNITY-MIB , SNMP-MPD-MIB, SNMP-PROXY-MIB etecetera. See attachment.

This in contrast to the number of MIB files present in the C:\Program Files\Wireshark\snmp\mibs directory.

What do we need to configure to sidetrack abovementioned error?


Best regards,


Hemant Kumar Dewnarain

OoO En ce début d'après-midi  ensoleillé du mercredi 20 avril 2011, vers
15:25, Hemant Dewnarain <hemant_dewnarain@hotmail.com> disait :

On  Linux, you  would run  smilint against  your MIB  to check  what the
problem is. On Windows, I don't really know how you would check this.

Dear Friend,

My name is Dr.Jack.Rufon; I got your address in Burkina Faso chamber
of commerce through details. I need your urgent assistance in
Transferring the sum of (22.5, 000,000) Million Dollars fund which
Belongs to our deceased customer who died in A plane crash, since the
Death of this our customer the money has been in our bank without
Claim. I want to release the money to you as the deceased NEXT OF KIN
For the benefit of both of us. By indicating your interest I will send
you the full details on how the business will be executed. I need to
Hear from you urgent so that I will give you more information
regarding this transaction.

Waiting for your urgent response so that we will starts immediately.

Thanks,
Dr.Jack.Rufon.

مرحباً ، أنا المحامي برايت ويت وأريد مناقشة مسألة مهمة
معك ، راسلني هنا لمزيد من التفاصيل ؛
  ( brightwitte0012393@gmail.com  )


 Hello, i am  Barrister Bright Witte, I want to discuss an important issue
 with you,write back to me here for more details;
  ( brightwitte0012393@gmail.com  )

Hi everyone,
I have hada similar case to the latter one raised by Hemant Dewnarain in Apr 2011.

At least, Iwas using Wireshark on Windows 10 and I have got a similar message :

“Stopped processingmodules <module_name> due to error(s) to prevent potential crash inlibsmi.

Module’sconformance level:1.

See detailsat: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=560325

 

As the errorpointed this thread, I naturally read it but I did not find a solution for my case.
A difference was that the module impacted in Hemant post was SNMPv2-SMI while in mycase it was a MIB created and maintained by my company for our devices.
 
After parsing the MIB with a syntax-verifier tool, itappeared we had some syntaxes / forbidden values in the MIB that Wireshark / libsmido not allow.
However,the MIB has been in use for years with various SNMP client (both Linux and Windows based) and no issues raised from our customers thus it seems only libsmi / Wiresahrk raises it as a CRITICAL issue.

 

Wecorrected the MIB and now theerror does not appear anymore in Wireshark.

 

Julien APPAIX