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.

Dear Debian folks,


rspamd 3.12.1 checks the length of the DKIM body hash (bh=) only for RSA
and ECDSA signatures, not for ed25519-sha256. In src/libserver/dkim.c,
rspamd_create_dkim_context() (lines 1195-1225 in 3.12.1) has no case for
DKIM_SIGN_EDDSASHA256, so ctx->bhlen is whatever the base64 value of bh=
decodes to. rspamd_dkim_check() then passes this length to memcmp()
against fixed-size digest buffers (lines 2746, 2766, 2785, 2795 and
2801), before the key type is checked at all.

An attacker who controls any domain and a DKIM key record for it can
send a mail with an ed25519 DKIM signature and an over-long bh=. rspamd
then reads past the stack and heap buffers. The upstream commit says
that the over-read scales with the header size and can walk off the
stack, i.e. crash the worker. Any rspamd verifying DKIM on inbound mail
(the default) is affected; the mail sender needs no account on the host.

Upstream fixed it in 4.1.3:

   commit e27c9fb6666f40116accca3e34c27c7fe04d4507
   [CritFix] dkim: bound bh= length before body hash comparison

https://github.com/rspamd/rspamd/commit/e27c9fb6666f40116accca3e34c27c7fe04d4507

The patch applies to 3.12.1 with reduced context (git apply -C1; one
file, 18 insertions). 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 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 dkim.c).


Kind regards,

Paul