Bug#1108192: dpkg: segfault in dpkg-trigger

On Sun, Jun 22, 2025 at 11:39:41PM +0200, Guillem Jover wrote:
> > This may be a usage error on my part, but it should probably not be
> > segfaulting either way.  While investigating a possible solution to
> > #1108166, I encountered the following segfault in dpkg-trigger:
> > 
> > root@satest-trixie:~# dpkg-trigger --by-package=sa-compile --no-await --no-act sa-compile-upgrade
> > [  721.686463] dpkg-trigger[5137]: segfault at c0 ip 00007f8b7d127d8a sp 00007fffe1a0dc90 error 4 in libc.so.6[64d8a,7f8b7d0e
> > b000+165000] likely on CPU 0 (core 0, socket 0)
> > [  721.688762] Code: 00 e8 ea 3d 02 00 48 89 f9 e9 a5 fa ff ff 66 90 41 57 41 56 41 55 41 54 49 89 d4 55 48 89 f5 53 48 89 fb
> >  48 81 ec f8 00 00 00 <8b> 87 c0 00 00 00 64 4c 8b 2c 25 28 00 00 00 4c 89 ac 24 e8 00 00
> > Segmentation fault
> 
> I tried that invocation on a minimal sid chroot, with the sa-compile
> package installed, and I could not reproduce the segfault. If you can
> still reproduce that, could you send at least the dpkg status file and
> the /var/lib/dpkg/triggers/ directory? If that contains sensitive data,
> feel free to send it privately to me.
> 
> Also if you could also send a backtrace that would be great.

It seems that the problem is only triggered if dpkg-trigger is run
*without* --no-act first. Then a subsequent invocation *with* --no-act
triggers the ѕegfault.

It does not seem specific to any of the packages or triggers that I was
working on, and can be reproduced with an arbitrary trigger.

See the attached script for a simple repro using docker containers.  Let
me know if you still have trouble reproducing it and I can get you a
core file.

Stack trace looks like:
(gdb) bt                                                                                                                     
#0  0x00007fbca6df0d8a in __vfprintf_internal (s=0x0, format=format@entry=0x55d0872763ac "%s", ap=ap@entry=0x7fff25f83660,
    mode_flags=mode_flags@entry=2) at ./stdio-common/vfprintf-internal.c:1525
#1  0x00007fbca6ea8fb6 in ___vfprintf_chk (fp=<optimized out>, flag=flag@entry=1, format=format@entry=0x55d0872763ac "%s",
    ap=ap@entry=0x7fff25f83660) at ./debug/vfprintf_chk.c:29
#2  0x000055d087270abc in vfprintf (__stream=<optimized out>, __fmt=<optimized out>, __ap=0x7fff25f83660)
    at /usr/include/x86_64-linux-gnu/bits/stdio2.h:166
#3  trigdef_update_printf (format=format@entry=0x55d0872763ac "%s") at ../../../lib/dpkg/trigdeferred.c:157
#4  0x000055d08726acfe in tdm_add_trig_begin (trig=0x7fff25f83750 "sa-compile-upgrade") at ../../src/trigger/main.c:146
#5  0x000055d087270bb5 in trigdef_parse () at ../../../lib/dpkg/trigdeferred.c:211
#6  0x000055d08726a995 in do_trigger (argv=<optimized out>) at ../../src/trigger/main.c:201
#7  0x000055d08726a6c8 in main (argc=<optimized out>, argv=<optimized out>) at ../../src/trigger/main.c:265

#!/usr/bin/bash

image=debian:trixie
# The trigger name does not matter; it can be a real trigger that
# exists, e.g. perl-major-upgrade, or an arbitrarily made up name
trigger_name=foo

# This does not trigger a crash. Note that there's only a single invocation of dpkg-trigger
# docker run -it "$image" bash -c "apt-get update && \
#    dpkg-trigger --by-package=sa-compile --no-await --no-act $trigger_name ; \
#    echo trigger exited status \$?"

docker run -it "$image" bash -c "apt-get update && \
   dpkg-trigger --by-package=sa-compile --no-await $trigger_name ; \
   echo trigger exited status \$? ; \
   dpkg-trigger --by-package=sa-compile --no-await --no-act $trigger_name ; \
   echo trigger exited status \$?"