[Bug 169048] Crashes when applying all filters on IMAP folder [KMail::ActionScheduler::actionMessage, KMail::ActionScheduler::filterMessage]

Christophe Giboudeaux cgiboudeaux at gmail.com
Thu Feb 10 10:28:01 GMT 2011


https://bugs.kde.org/show_bug.cgi?id=169048





--- Comment #44 from Christophe Giboudeaux <cgiboudeaux gmail com>  2011-02-10 11:27:55 ---
from bug 169646:

This bug is still happening.

kmail 1.13.2
KDE 4.4.2
linux kernel 2.6.33-gentoo-r1 (x86_64)
Gentoo packages.

Interestingly, my other setup with 32-bit linux on Sabayon Linux doesn't crash
using exact same rule. Not sure why.

Backtrace:
Thread 1 (Thread 0x7f457240c750 (LWP 11155)):
[KCrash Handler]
#5  0x00007f4570dbfb62 in
KMail::ActionScheduler::actionMessage(KMFilterAction::ReturnCode) () from
/usr/lib64/libkmailprivate.so.4
#6  0x00007f4570dbfe1a in KMail::ActionScheduler::filterMessage() () from
/usr/lib64/libkmailprivate.so.4
#7  0x00007f4570dc05ba in
KMail::ActionScheduler::qt_metacall(QMetaObject::Call, int, void**) () from
/usr/lib64/libkmailprivate.so.4
#8  0x00007f456ccb7147 in QMetaObject::activate(QObject*, QMetaObject const*,
int, void**) () from /usr/lib64/qt4/libQtCore.so.4
#9  0x00007f456ccb3bd3 in QObject::event(QEvent*) () from
/usr/lib64/qt4/libQtCore.so.4

Liberal sprinkling of debug statements in the area reveals that the variable
"action" is pointing at 0x21, an invalid but non-zero address which passes the
mFilterAction check in actionMessage(). This causes a segfault when accessed
later.

How does that happen? Here's the current code that checks for the end of the
action list:
498      KMFilterAction *action = mFilterAction;
499     // mFilterAction = (*mFilterIt).actions()->next();
500     if ( ++mFilterActionIt == (*mFilterIt)->actions()->end() )
501     mFilterAction = 0;
502     else mFilterAction = (*mFilterActionIt);
503     action->processAsync( *mMessageIt );
504     }

The problem is we're checking if the *NEXT* action is the end. What about the
*CURRENT* one? Sure it's supposed to be already checked when we advance the
pointer there. Except that the first action isn't assigned by this iterator
advancing code. It's initialized in filterMessage():
      mFilterActionIt = (*mFilterIt)->actions()->begin();
      mFilterAction = (*mFilterActionIt);
      actionMessage();

What's happening here is that begin() == end() since the list is empty. We
didn't verify that mFilterActionIt isn't end (and therefore invalid) before
dereferencing it. Since this is an iterator, not a pointer, we won't crash --
yet. But mFilterAction will get random garbage. If said random garbage happens
to be non-zero, actionMessage() will then try to dereference it as a pointer
and hence the crash.


Suggested patch:

--- kmail/actionscheduler.cpp.orig    2010-04-16 19:03:55.853213672 -0700
+++ kmail/actionscheduler.cpp    2010-04-16 20:07:46.071964041 -0700
@@ -659,7 +659,7 @@ void ActionScheduler::actionMessage(KMFi
     mResult = ResultCriticalError;
     finish(); //must handle critical errors immediately
   }
-  if (mFilterAction) {
+  if (mFilterActionIt != (*mFilterIt)->actions()->end()) {
     KMMessage *msg = message( *mMessageIt );
     if (msg) {
       if ( FilterLog::instance()->isLogging() ) {
@@ -668,10 +668,7 @@ void ActionScheduler::actionMessage(KMFi
         FilterLog::instance()->add( logText, FilterLog::appliedAction );
       }
       KMFilterAction *action = mFilterAction;
-//      mFilterAction = (*mFilterIt).actions()->next();
-      if ( ++mFilterActionIt == (*mFilterIt)->actions()->end() )
-        mFilterAction = 0;
-      else mFilterAction = (*mFilterActionIt);
+      mFilterAction = *(++mFilterActionIt);
       action->processAsync( msg );
     }
   } else {

Suggested workaround:
As a temporary work around, people like me who need this to set a "stop
processing here" rule with no action and matching sender =
my_boss at my_company.com to make sure important messages doesn't get filtered can
assign a sound as action.

That action will have no effect except being extremely irritating when a whole
bunch of messages matching the rule arrives. This can be avoided by recording a
wav file of silence and using it as the action.

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the Kdepim-bugs mailing list