Debian Patches
Status for libdate-manip-perl/6.99-2
| Patch | Description | Author | Forwarded | Bugs | Origin | Last update |
|---|---|---|---|---|---|---|
| CVE-2026-60074-r1.patch.patch | Date::Manip: restrict numeric date fields to ASCII digits CVE-2026-60074. The parse regexes capture year, month and day with the \d shorthand, which on a character string matches the whole Unicode decimal digit property \p{Nd} and not just [0-9]. Date::Manip::Base::check validates the captured fields with numeric comparisons alone, and _parse_check stores the numified fields, so a field whose leading characters are ASCII digits numifies to an in-range prefix and satisfies every test. With U+0664 ARABIC-INDIC DIGIT FOUR as the final character of the year, ParseDate("202\x{664}-03-08") returns 0202030800:00:00; a non-ASCII digit in the month or day field shifts those fields the same way ("2026-1\x{662}-08" returns January, "2026-03-1\x{665}" returns the 1st), and one in a fractional minute field drops the fraction. [0-9] rather than \d, so a field holding a non-ASCII digit fails to match and the string does not parse. Both validators are hardened as well, since Date::Manip::Date's set() passes caller supplied values straight to them: check() requires the year, month and day to be ASCII digit strings before range testing them, and check_time() uses [0-9] in its format test. Every date string in a 42 entry corpus of legitimate formats (ISO 8601 basic and extended, ordinal and week dates, m/d/y, RFC 2822 with a numeric offset, ctime, named months and zones, "1st Sunday in March 2026", "in 3 days", "noon", 24:00 times, fractional hours and minutes) parses to the same value before and after. diff --git a/lib/Date/Manip/Base.pm b/lib/Date/Manip/Base.pm index 4195056..5de1637 100644 |
CPANSec Security Scanner Bot <cpan-security@security.metacpan.org> | no | debian | https://security.metacpan.org/patches/D/Date-Manip/6.99/CVE-2026-60074-r1.patch | |
| CVE-2026-60075-r1.patch.patch | Date::Manip: cap the length of a string handed to the parsers CVE-2026-60075. _parse_time removes a time from anywhere in the string with the unanchored substitution s/$timerx/ /, where $timerx is an auto-generated alternation of time patterns reached through a leading (?:$atrx|^|\s+). The engine retries the match at every position of an interior whitespace run: at each start position the leading \s+ consumes the rest of the run greedily, the time alternation fails because the run holds no digits, and the engine backtracks a space at a time across the run before advancing the start position. The cost is quadratic in the length of the run, and no time need be present in the string. On the machine this patch was tested on, parsing "x" . (" " x 2000) . "x" took 1.7 seconds of CPU and "x" . (" " x 16000) . "x" took 107 seconds, rising about fourfold for each doubling of the run. parse_time entries, before any regex runs, which is the shape of the fix libwww-perl shipped in HTTP::Date 6.08 for the same weakness class. Legitimate date strings are well under 100 characters, and a 42 entry corpus of legitimate formats parses to the same value before and after. diff --git a/lib/Date/Manip/Date.pm b/lib/Date/Manip/Date.pm index 7699921..859cef5 100644 |
CPANSec Security Scanner Bot <cpan-security@security.metacpan.org> | no | debian | https://security.metacpan.org/patches/D/Date-Manip/6.99/CVE-2026-60075-r1.patch |