Bug#1151666: libdbi-perl: CVE-2026-108518 CVE-2026-111879

[Salvatore Bonaccorso]

Source: libdbi-perl
Version: 1.655-1
X-Debbugs-CC: team at 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