Dear Debian folks,


AI disclaimer: Drafted with claude-opus-5.5 from the upstream commits
and the Debian source of rspamd 3.12.1-1, and reviewed by me.

The MIME parser of rspamd 3.12.1 limits nesting to max_nested = 64
(src/libmime/mime_parser.c:38), but the limit is never reached for
message/rfc822 parts. When it descends into an embedded message, the
parser copies the nesting level into a new runtime (line 1552) and
increments only the parent’s counter, which the recursion does not use.
The depth check at lines 1171 and 1453 therefore never fires.

A mail consisting of a chain of bare "Content-Type: message/rfc822"
wrappers (about 34 bytes per level) makes the recursion depth limited
only by the message size. This exhausts the worker stack and crashes it.
Depths that do not crash still cost quadratic CPU time because of the
boundary pre-scan at each level. Any sender can trigger this by mail
(SMTP/milter) or over the HTTP scan interface. If the MTA lets mail
through when the scan fails, the mail is then delivered unscanned.

Upstream fixed it in 4.1.2, with a regression test that feeds a
500-level chain:

   commit 562c7bee0f3d57cdb8d9081911a4c8e85ae36938
   [CritFix] mime_parser: bound message/rfc822 recursion depth

https://github.com/rspamd/rspamd/commit/562c7bee0f3d57cdb8d9081911a4c8e85ae36938

The patch applies cleanly to 3.12.1. unstable and testing (4.1.5-1)
contain the fix; trixie does not. I found no CVE ID for this issue.

Could you please apply the fix to trixie through a stable update, or
coordinate a DSA with the security team?

I did not try to reproduce the crash on a running system. The analysis
is based on the upstream commit and the Debian source of 3.12.1-1 (whose
three patches do not touch the MIME parser).


Kind regards,

Paul