Fix infinite loop and memory exhaustion when folding RFC 2047 params

[sebastka]

Hello,

I noticed a lot of these errors on our production Roundcube 1.7.2 instances...

PHP Warning: Undefined variable $_quote in vendor/pear/mail_mime/Mail/mimePart.php on line 808

... and eventually:

PHP Fatal error: Allowed memory size of 67108864 bytes exhausted (tried to allocate 31457296 bytes) in vendor/pear/mail_mime/Mail/mimePart.php on line 808

AI use disclosure: Anthropic Claude Opus 4.8 helped me review and improve my fix for the quoted-printable branch and extended it to cover the base64 branch as well. It also generated the detailed comment below.

---

buildRFC2047Param() could loop forever and exhaust memory when an encoded parameter (e.g. a long or non-ASCII attachment filename) can't be folded within the wrap width, i.e. when the parameter name makes $add_len exceed $maxLength and the available $length goes negative.

• Base64 branch: $real_len becomes <= 0, so $_quote is an empty string and $value is likewise never advanced.
• Quoted-printable branch: the "{0,-N}" quantifier makes preg_match() fail, so $_quote is never set ("Undefined variable $_quote" warning on PHP 8) and substr($value, strlen($_quote)) never advances.

In both cases the while() condition stays true and $quoted grows until the PHP memory_limit is hit (fatal error): a single crafted header is enough to DoS the process.

Break out of both loops when nothing more can be folded; the trailing "$quoted .= $prefix . $value . $suffix" then emits the remainder as a single (over-long but valid) encoded word.

---

[till]

Can you add a test case?

[alecpl]

I confirm the issue and the fix. However, with this change the attachment headers (from the test) look like this:

Content-Transfer-Encoding: base64
Content-Type: application/pdf;
 charset=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX;
 name="=?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX?Q?=C3=A9=C3=A9=C3=A9=C3=A9=C3=A9=2Epdf?="
Content-Disposition: attachment;
 filename="=?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX?Q?=C3=A9=C3=A9=C3=A9=C3=A9=C3=A9=2Epdf?=";
 size=4

RFC2047 says: " An 'encoded-word' may not be more than 75 characters long, including 'charset', 'encoding', 'encoded-text', and delimiters. If it is desirable to encode more text than will fit in an 'encoded-word' of 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may be used."

So, we're not RFC compliant when the charset is that long. I would consider truncating the charset to a sane length (something like 48 or 64 characters).

[sebastka]

@alecpl Encoded words are now capped to 75 characters.