bugzilla-daemon at bugzilla
Jul 2, 2009, 2:29 AM
Post #2 of 4
(325 views)
Permalink
|
|
[Bug 6143] Various messages are causing spamassassin to segfault.
[In reply to]
|
|
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6143
--- Comment #5 from Justin Mason <jm [at] jmason> 2009-07-02 02:29:51 PST ---
here's the users@ thread:
http://mail-archives.apache.org/mod_mbox/spamassassin-users/200907.mbox/%3C4A4A4EC6.2000301 [at] fastmail%3E
cut and paste of Matt's mail:
I stumbled upon an odd issue the other day that I'm having trouble
tracking down. Namely, a certain rule in the sought rule set, when
compiled for use with Rule2XSBody is causing the processing of *some*
emails to, well, never really end. Piping the mail through spamassassin
or into spamd just results in the process hanging and the memory usage
going higher and higher (2+ gigs, easily) and seemingly ignoring any
sort of timeouts. The process finally gets killed only when the OS
notices it's out of memory and starts killing processes or when I'm able
to sneak in and kill -9 it. There's nothing in the debug of SA whatsoever.
I was wondering if anyone else has seen this or if it's some quirk of my
environment. I admit that I'm no expert in this sort of thing, but
(hopefully) some useful information is below the dotted line.
-----
This happened on four of my machines which have the following configuration:
RHEL5.2 / SA 3.2.5 / Perl 5.8.8 / gcc 4.1.2
RHEl5.2 / SA 3.2.4 / Perl 5.8.8 / gcc 4.1.2
RHELAS 4 (Update 6) / SA 3.2.4 / Perl 5.8.5 / gcc 3.4.6
RHELAS 4 (Update 6) / SA 3.2.4 / Perl 5.8.5 / gcc 3.4.6
The SA is built from source off the main website, and the perl is just
stock redhat.
If I copy down all my rules/configuration to my Debian desktop using its
packaging, the problem doesn't emerge (sa 3.2.5/perl 5.10.0/gcc 4.3.3 there)
Removing the compiled rulesets works around the issue fairly handily.
I'm stubborn though, so after I did so, I dug around a bit and it seems
one specific body rule was causing the issue, namely:
body __SEEK_1R0JFS /\x{ff}\x{fe} \x{00} \x{00} \x{00}
\x{00}<\x{00}m\x{00}e\x{00}t\x{00}a\x{00}
\x{00}h\x{00}t\x{00}t\x{00}p\x{00}-\x{00}e\x{00}q\x{00}u\x{00}i\x{00}v\x{00}=\x{00}\'\x{00}R\x{00}e\x{00}f\x{00}r\x{00}e\x{00}s\x{00}h\x{00}\'\x{00}
\x{00}c\x{00}o\x{00}n\x{00}t\x{00}e\x{00}n\x{00}t\x{00}=\x{00}\'\x{00}0\x{00};\x{00}
\x{00}u\x{00}r\x{00}l\x{00}=\x{00}h\x{00}t\x{00}t\x{00}p\x{00}:\x{00}\/\x{00}\/\x{00}.\x{00}.\x{00}.\x{00}.\x{00}.\x{00}.\x{00}.\x{00}.\x{00}.\x{00}.\x{00}.\x{00}.\x{00}.\x{00}.\x{00}.\x{00}.\x{00}.\x{00}.\x{00}/
Once I comment out the rule, compiled rulesets work fine again. I don't
know enough to know what the heck that regex even is, or why it would be
causing problems (I basically found which rule was causing a problem by
commenting out anything that looked scary to me, running sa-compile, and
testing to see if I the "hanging" behavior went away)
I'm not sure the best way to post up a sample of the mail that was
choking the system without it getting mangled (though I'll gladly post
it if someone can show me where), but fooling around, it seemed to come
down to the message containing this as one of its parts:
-
Content-Type: text/html;
Content-Transfer-Encoding: quoted-printable
(Any content could go here)
=00
-
Removing =00 OR Content-Transfer-Encoding: quoted-printable causes the
mail to pass through without a problem. It seems to only be both
combined that resulted in the behavior I saw.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
|
