2081532 - Calendar invitation overlay eagerly materializes unbounded packed RDATE values

Status: RESOLVED FIXED

(Calendar :: E-mail based Scheduling (iTIP/iMIP), defect)

Description

[YuYoung Sung]

Attachment: Full report, packed-RDATE invitation PoC, runtime measurements, and duplicate analysis

Severity: Moderate (CVSS 3.1 4.3, AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L)
CWE-400

Confirmed in Thunderbird Daily 160.0a1 build 20261012100649 and official thunderbird/thunderbird-desktop main commit 981aabb3c318c0c185c753730a080640b1219f22 on 2026-10-14.

While rendering a calendar invitation, createInvitationOverlay() walks every positive recurrence date, creates an occurrence, inserts it into a sorted array, formats it, and joins the complete result into DOM text. There is no limit or truncation for an attacker-controlled packed RDATE list.

The exact Daily overlay path took 663 ms for 4,000 dates, 1.24 seconds for 8,000, 2.82 seconds for 16,000, and 5.67 seconds for 32,000 explicit dates in a 288 KB VEVENT, before the overlay DOM was returned. Opening a text/calendar invitation performs this synchronously on the main thread.

This differs from VTIMEZONE/RRULE expansion reports: the payload is a finite explicit RDATE list and the affected path is invitation-overlay materialization. Public searches for RDATE invitation performance/denial-service terms found no matching report.

The attached ZIP contains the full report, exact runtime PoC, measurements, and duplicate analysis. Suggested fix: cap or truncate rendered recurrence items, avoid eagerly building the complete display string, and add a packed-RDATE regression test.

Comment 1

[Magnus Melin [:mkmelin]]

Not really a sec issue. But a small bug.

Comment 2

[Magnus Melin [:mkmelin]]

Attachment: Bug 2081532 - Limit the number of canceled and modified occurrences listed in the invitation overlay. r=tobyp

The overlay created an occurrence for every RDATE and formatted every
RDATE/EXDATE, so invitations with a long packed RDATE list could block the
main thread for seconds. Sort the candidates by start time first and only
create and format the first MAX_LISTED_OCCURRENCES (100) of them, ending a
truncated list with an ellipsis.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/44a922a1c291
Limit the number of canceled and modified occurrences listed in the invitation overlay. r=tobyp