[From nobody Fri Oct 23 01:23:05 2026 Received: (at submit) by bugs.debian.org; 22 Oct 2026 19:13:46 +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.4 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, 23; hammy, 149; neutral, 113; spammy, 1. spammytokens:0.985-+--inner 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]:45752) 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 1xJyEU-00BNXt-2e for submit@bugs.debian.org; Thu, 22 Oct 2026 19:13:46 +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=ckMRPRdjeh2n9Tz0QxXp5jWTwfrndwNhlyA9Up7cXj0=; b=qvpaU1x6BDCD54hc/OQdDeqRkQ bCBOZfBwUlcVcRqnCQH3mBOoj1H2xEMPlc39r3NSTzngqiob3XelVnqdzOuqb4dfPdDdD+5vRk3XD GeXc3b11NNdPlbGvP4xwUN2fqIe6Ier17nUxDIS0Yt5D4FQxQIzCPfEVEQlLOVLrqdbKwbcCKQCPJ Rz5Vv85JzhaAlFJR2CTIoYJnap3LX283gYqXxBe/4yrh+RFAsnJIcVIn0dWyNl4wvXv4tDkv8YtN3 m3e5n2glnBzjtfzK2V9nWumbcuFC5WpoAOvZdQVXldy6lgyxlw9stSg5qfHI3aOLjuzvp74wGKBEY on35sk3Q==; 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 1xJyER-002clw-1O for submit@bugs.debian.org; Thu, 22 Oct 2026 19:13:44 +0000 Received: by eldamar.lan (Postfix, from userid 1000) id CD424DC056E; Thu, 22 Oct 2026 21:13:42 +0200 (CEST) Date: Thu, 22 Oct 2026 21:13:42 +0200 From: Salvatore Bonaccorso <carnil@debian.org> To: submit@bugs.debian.org Subject: libdbi-perl: CVE-2026-108518 CVE-2026-111879 Message-ID: <atpgZpaiKCUIwNNs@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: libdbi-perl Version: 1.655-1 X-Debbugs-CC: team@security.debian.org Severity: important Tags: security upstream Hi, The following vulnerabilities were published for libdbi-perl. CVE-2026-108518[0]: | DBI versions before 1.656 for Perl crash via type confusion in | dbi_profile when a database handle is destroyed under a Profile Path | with an {attr} element. An {attr} element names a database handle | attribute, which dbi_profile reads from the handle's inner hash. It | expects the inner handle as a reference and dereferences it, but a | handle that is being destroyed hands back the inner hash itself, so | the dereference yields the hash's bucket array. A type check on that | pointer usually fails and the call goes unprofiled. When the memory | it addresses passes the check, the attribute lookup dereferences a | NULL or invalid pointer and the process dies on SIGSEGV. The Path | is set by the application, by the Profile handle attribute, or by | the DBI_PROFILE environment variable, so | `DBI_PROFILE={ImplementorClass}` can crash an unmodified program. CVE-2026-111879[1]: | DBI versions before 1.656 for Perl hang on a later open of a | DBD::DBM table because a failed open_data does not release the | table's lock. open_data creates the table's lock file and takes an | exclusive flock on it for a CREATE, before the checks that can | croak: a dbm_mldbm value that is not a module name, a failing tie, | or a missing data file. The croak unwinds before the table object is | blessed, so nothing releases the lock, and the meta data holding the | open descriptor stays cached on the database handle. The dbm_mldbm | and dbm_type values come from the DSN or the connect attributes, so | a caller that chooses the serializer or the storage backend can | trigger the failure. The flock has no timeout, so a later open of | that table (even through a separate database handle) blocks for as | long as the handle holding the stale lock lives, in the same process | or any other. 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-108518 https://www.cve.org/CVERecord?id=CVE-2026-108518 https://lists.security.metacpan.org/cve-announce/msg/44513047/ [1] https://security-tracker.debian.org/tracker/CVE-2026-111879 https://www.cve.org/CVERecord?id=CVE-2026-111879 https://lists.security.metacpan.org/cve-announce/msg/44513053/ Regards, Salvatore ]