[From nobody Sat Oct 17 16:39:08 2026 Received: (at submit) by bugs.debian.org; 17 Oct 2026 06:08:06 +0000 X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02 (2024-03-25) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-107.3 required=4.0 tests=ALL_TRUSTED,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, FOURLA,FROMDEVELOPER,SPF_HELO_NONE,SPF_PASS,USER_IN_DKIM_WELCOMELIST autolearn=ham autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 56; hammy, 150; neutral, 264; spammy, 0. spammytokens: hammytokens:0.000-+--Hx-spam-relays-external:sk:stravin, 0.000-+--H*RT:sk:stravin, 0.000-+--Hx-spam-relays-external:311, 0.000-+--H*RT:311, 0.000-+--H*RT:108 Return-path: <carnil@debian.org> Received: from stravinsky.debian.org ([2001:41b8:202:deb::311:108]:41318) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <carnil@debian.org>) id 1xHxaP-00Gf3L-2F for submit@bugs.debian.org; Sat, 17 Oct 2026 06:08:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org; s=smtpauto.stravinsky; h=X-Debian-User:Content-Type:MIME-Version:Message-ID: Subject:To:From:Date:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=vaL+c9YyS3c5GuiJTPY3rBhTGNkrJ6ZtlOn4sYryC+s=; b=jF6DD2k9xsDcLbnnsb3MWnBhxf 8BtL7G4nyi5XwBjHIizmbVmkDPHBcKYgsnPReIMt1Se+kKoOJG9KQRLI8GSPAdGr4JgVpiLmXkkZb hYs1G9kom2kFThMTVK55grXbJqdwTtDt+z80t2Sd7UeD9udCmNsCx+yDan12NabS7Mu0xNvdjQDMl QlJO0Lu+tQcz5tZLwrEoBMmPWiDiqrDrUY+JUjcKsNM03uZYvDQClI2BxAsYdXvr0QQ7KRkzVr2kF Ncx4N6NkwiNRUhZUWynsKtLyvt7X6gFWSgYYnojlxGDPMVsoYpvbo0Q9yWZr272eLLchYrh7qGYMD h5nMMTPw==; Received: from authenticated-user by stravinsky.debian.org with esmtpsa (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256) (Exim 4.96) (envelope-from <carnil@debian.org>) id 1xHxaO-006Xdk-0J for submit@bugs.debian.org; Sat, 17 Oct 2026 06:08:04 +0000 Received: by eldamar.lan (Postfix, from userid 1000) id 8DAE2DC0587; Sat, 17 Oct 2026 08:08:03 +0200 (CEST) Date: Sat, 17 Oct 2026 08:08:03 +0200 From: Salvatore Bonaccorso <carnil@debian.org> To: submit@bugs.debian.org Subject: libtext-csv-xs-perl: CVE-2026-110753 CVE-2026-110752 CVE-2026-110754 CVE-2026-110755 CVE-2026-110756 CVE-2026-110757 CVE-2026-110758 CVE-2026-110759 Message-ID: <atMQwyksp2hnBLeY@eldamar.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Debian-User: carnil Delivered-To: submit@bugs.debian.org Source: libtext-csv-xs-perl Version: 1.64-1 X-Debbugs-CC: team@security.debian.org Severity: important Tags: security upstream Hi, The following vulnerabilities were published for libtext-csv-xs-perl. CVE-2026-110753[0]: | Text::CSV_XS versions from 1.46 before 1.65 for Perl have a use- | after-free of bind_columns variables when skip_empty_rows skips an | empty line in getline. With bind_columns, the parser writes each | field into the caller's own scalar without taking a reference to it. | When skip_empty_rows skips an empty last line, the parser frees the | current field scalar without checking whether it is bound, dropping | one reference from the application's variable. The "eof" mode does | the same on any empty line. The variable is then freed while the | application still references it, so later code uses freed memory and | can crash the process. CVE-2026-110752[1]: | Text::CSV_XS versions before 1.65 for Perl allow memory exhaustion | by allocating one entry per index of an RFC 7111 selector in | fragment. fragment expands a row= or col= selector into an array | with one element per selected index before it reads any data, and it | does not clamp an explicit end column in a cell= selector to the | row. Only the syntax and order of the ranges are checked, so | row=1-400000000 on a two-line file allocates 400 million elements. | An application that passes a request-supplied fragment to fragment | or csv can be made to exhaust memory, which ends the process with an | Out of memory error that eval cannot catch. CVE-2026-110754[2]: | Text::CSV_XS versions before 1.65 for Perl leak the parsed fields of | a record that fails to parse in getline. getline collects the | fields of a record into a new array and returns a reference to it | only when the parse succeeds. When the record has a syntax error, | getline returns undef and never frees the array or the fields parsed | before the error. A long-running process parsing untrusted CSV | retains every malformed record it is sent, so repeated malformed | input exhausts its memory. CVE-2026-110755[3]: | Text::CSV_XS versions before 1.65 for Perl allow quadratic CPU use | by copying the unparsed remainder per record of CR-only input in | getline. With eol unset, the default, getline reads with Perl's | default line separator, so input with CR-only line endings arrives | as one chunk. After each record the parser copies the whole unparsed | remainder into a new buffer, which the next call parses and copies | again, so the work grows with the square of the input size. A | reader with default options that is sent CSV with classic Mac line | endings spends seconds of CPU time on a megabyte of input. CVE-2026-110756[4]: | Text::CSV_XS versions before 1.65 for Perl drop the end of a record | and its line ending when a UTF-8 flagged field precedes invalid | UTF-8 bytes in print. When a record contains a UTF-8 flagged field, | print holds back trailing bytes that are not valid UTF-8 at each | buffer flush, so that a character split across two flushes can be | completed. Nothing writes the held-back bytes after the record's | final flush. A record whose last field ends in such a byte loses it, | any closing quote and the line ending, while print still returns | true. combine is not affected. The next record is written onto the | same line, or, when the last field was quoted, the missing closing | quote makes a reader take every following record as part of that | field. CVE-2026-110757[5]: | Text::CSV_XS versions before 1.65 for Perl allow record splitting by | writing strings used as numbers without quotes in combine. combine | and print do not check whether a field needs quotes when its value | has Perl's integer or numeric flag set. Perl sets these flags on a | string used in a numeric operation when it parses as a number, which | allows leading and trailing whitespace. With binary set, as csv does | by default, "12\n" passes a check such as $qty > 0 and is then | written unquoted with its newline. A value validated as a number | can end the record early and turn the fields after it into a | separate row. CVE-2026-110758[6]: | Text::CSV_XS versions before 1.65 for Perl read before the start of | an all-blank field under allow_whitespace in strip_trail_whitespace. | Under allow_whitespace, strip_trail_whitespace removes trailing | spaces and tabs from each unquoted field without stopping at the | start of the field. For a field of only blanks it reads the byte | before the field's heap buffer. If that byte is also a space or tab, | it may be zeroed and the walk continue backwards, depending on what | the allocator placed there. Leading blanks are normally skipped | before a field is stored, but an all-blank field still arrives after | a leading escape_char that differs from quote_char, or as a quoted | field in getline when its line ends in two CRs. CVE-2026-110759[7]: | Text::CSV_XS versions before 1.65 for Perl return a 0xFF byte that | is not in the input for an empty last field followed by a lone CR in | parse. When the input to parse ends in a separator and a lone CR, | the parser treats the end of the input as the next character and | stores the end-of-file marker in the field as the byte 0xFF. With | binary set, parse("a,\r") returns the fields "a" and "\xFF". On | UTF-8 flagged input the last field is a UTF-8 flagged string holding | that lone byte, which is malformed UTF-8. The same input with a non- | empty last field is rejected as an error. A CRLF file read line by | line and chomped ends this way when its last column is empty, so the | application receives a byte that is not in its input. All fixes are included in 1.65 upstream. In the security-tracker we link to the individual advisories and fixing commits for potential backporting. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-110753 https://www.cve.org/CVERecord?id=CVE-2026-110753 [1] https://security-tracker.debian.org/tracker/CVE-2026-110752 https://www.cve.org/CVERecord?id=CVE-2026-110752 [2] https://security-tracker.debian.org/tracker/CVE-2026-110754 https://www.cve.org/CVERecord?id=CVE-2026-110754 [3] https://security-tracker.debian.org/tracker/CVE-2026-110755 https://www.cve.org/CVERecord?id=CVE-2026-110755 [4] https://security-tracker.debian.org/tracker/CVE-2026-110756 https://www.cve.org/CVERecord?id=CVE-2026-110756 [5] https://security-tracker.debian.org/tracker/CVE-2026-110757 https://www.cve.org/CVERecord?id=CVE-2026-110757 [6] https://security-tracker.debian.org/tracker/CVE-2026-110758 https://www.cve.org/CVERecord?id=CVE-2026-110758 [7] https://security-tracker.debian.org/tracker/CVE-2026-110759 https://www.cve.org/CVERecord?id=CVE-2026-110759 Regards, Salvatore ]