Source: dpkg Source-Version: 1.22.7 Severity: important Tags: security Hi!
I got this report privately some time ago, analyzed it to be a potential low impact DoS security bug, where I looped the security team in, and they agreed, and considered it not worth a CVE nor a security upload, instead considered it should be queued as a normal stable upload fix. I'll forward as well my reply with my analysis. Filing this now as I'm about to upload dpkg 1.23.8, so that there is a public record of this from the reporter, and so that it can be tracked and referenced from the changelog. Elias, sorry I didn't coordinate on the release of this, but just recalled I had the fix in a branch and I needed to file this. Hope publishing this now w/o coordination is not too inconvenient! ----- Forwarded message from zer0d4y5 <[email protected]> ----- Date: Sun, 26 Jul 2026 20:42:27 -0400 From: zer0d4y5 <[email protected]> To: [email protected] Subject: NULL pointer dereference in dpkg control/Packages parser (empty first field) Message-ID: <cajhzqk6_6cnrho7tgvd6txlbuyaugj58bmsmzz+b5aux6qk...@mail.gmail.com> Hello, I found a small but reproducible crash in dpkg's control-stanza parser and wanted to report it privately first so it can be fixed before any public writeup. Parsing a control or Packages stanza whose first field has an empty value, when that field is handled by a value-dereferencing parser (Version is the clean case), crashes dpkg with a NULL pointer dereference. It is a denial of service, not memory corruption or code execution, but it does take down dpkg on malformed input where a clean error would be expected. Root cause: in lib/dpkg/parse.c, pkg_parse_field() passes fs->value.buf to the field handler. For an empty value, varbuf_set_buf() calls varbuf_add_buf(..., 0), which returns early without allocating, so when this is the first field parsed in a stanza the varbuf has never grown and fs->value.buf is still NULL (fs is memset to 0 at the top of parsedb_parse). f_version() then reaches parse_db_version() and parseversion(), which dereferences it at parsehelp.c:250 (while (*string ...)) with no NULL guard. Trigger (10 bytes): printf 'Version:\nz\n' > crash.pkgs Reproduced on the shipped Ubuntu 26.04 dpkg 1.23.7 and on current git HEAD (1.23.7-203-g7004a048f), both segfault (exit 139, core dumped): dpkg --merge-avail crash.pkgs # also --update-avail dpkg --install <a .deb whose control's first field is an empty Version:> apt is not affected (it has its own parser), and dpkg-deb --info/--field only dump the control text without semantic parsing, so they do not crash. The reachable consumers are libdpkg's parsedb callers. Suggested fix (one line, verified): pass a guaranteed C string to the field handlers, for example varbuf_str(&fs->value) instead of fs->value.buf in pkg_parse_field(). varbuf_str() returns "" for a NULL buffer, so parseversion cleanly reports "version string is empty". I rebuilt current git HEAD with this change and the same input now returns dpkg: error: parsing file 'crash.pkgs' near line 1: 'Version' field value '': version string is empty with exit 2, instead of crashing. This one change covers every field handler, not just Version. I am happy to share the exact .deb reproducer and a patch in whatever form is easiest. No rush on my end, and I will hold off on any public description until you have had a chance to look and a fix is available. Please let me know a good way to coordinate. Thanks for dpkg, and for maintaining it so carefully. Best regards, Elias ----- End forwarded message ----- Thanks, Guillem
