ctl_backups lock: segmentation fault if failed to obtain lock

[futzle]

When ctl_backups lock attempts to obtain a lock on a backup file that is already locked, the lock attempt correctly fails but the program crashes with a segmentation fault on cleanup.

Version: 3.0.11, Debian x86_64

Steps to reproduce:

1. Run a compaction in the background: /usr/lib/cyrus/bin/ctl_backups -F compact -A &
2. Take a note of which file is currently being compacted.
3. Try to lock this file with -x option: /usr/lib/cyrus/bin/ctl_backups lock -x 'echo foo' -f FILE_BEING_COMPACTED
4. Result: segmentation fault occurs

Backtrace:

# coredumpctl debug
           PID: 202215 (ctl_backups)
           UID: 103 (cyrus)
           GID: 8 (mail)
        Signal: 11 (SEGV)
     Timestamp: Sun 2019-11-17 08:48:04 AEDT (6min ago)
  Command Line: /usr/lib/cyrus/bin/ctl_backups lock -x echo foo -f /home/mail-3175-1/cyrus-backup/partitions/default/q/%SHARED_vh91AO
    Executable: /usr/lib/cyrus/bin/ctl_backups
 Control Group: /user.slice/user-1000.slice/session-1448.scope
          Unit: session-1448.scope
         Slice: user-1000.slice
       Session: 1448
     Owner UID: 1000 (localadmin)
       Boot ID: c887b7eb1d734962b8bddb745df21e8f
    Machine ID: facebc4e2dcd47a68a097acc9077814e
      Hostname: rsync
       Storage: /var/lib/systemd/coredump/core.ctl_backups.103.c887b7eb1d734962b8bddb745df21e8f.202215.1573940884000000.lz4
       Message: Process 202215 (ctl_backups) of user 103 dumped core.
                
                Stack trace of thread 202215:
                #0  0x0000560aa9421854 backup_close (ctl_backups)
                #1  0x0000560aa94206ea lock_run_exec (ctl_backups)
                #2  0x0000560aa9412718 main (ctl_backups)
                #3  0x00007fda03bdf09b __libc_start_main (libc.so.6)
                #4  0x0000560aa9412b7a _start (ctl_backups)

Probable cause: backupp contains a pointer to NULL:

(gdb) bt
#0  backup_close (backupp=0x7ffe776aa1a0) at backup/lcb.c:462
#1  0x0000560aa94206ea in lock_run_exec (create=<optimized out>, nonblock=<optimized out>, cmd=<optimized out>, 
    fname=<optimized out>, userid=<optimized out>) at backup/ctl_backups.c:1001
#2  cmd_lock_one (rock=<optimized out>, key=<optimized out>, key_len=<optimized out>, data=<optimized out>, 
    data_len=<optimized out>) at backup/ctl_backups.c:689
#3  0x0000560aa9412718 in main (argc=6, argv=0x7ffe776aa3d8) at backup/ctl_backups.c:542
(gdb) p backupp=0x7ffe776aa1a0
$1 = (struct backup **) 0x7ffe776aa1a0
(gdb) p backup
$2 = (struct backup *) 0x0

[elliefm]

I think this should fix it, but I don't have anything big enough lying around to test it in the wild. Can you try it out? Will try to set up a Cassandane test for it in the meantime.

diff --git a/backup/lcb.c b/backup/lcb.c
index 5800b7c77..2ea77d959 100644
--- a/backup/lcb.c
+++ b/backup/lcb.c
@@ -459,6 +459,8 @@ EXPORTED int backup_close(struct backup **backupp)
     gzFile gzfile = NULL;
     int r1 = 0, r2 = 0;
 
+    if (!backup) return 0;
+
     if (backup->append_state) {
         if (backup->append_state->mode != BACKUP_APPEND_INACTIVE)
             r1 = backup_append_end(backup, NULL);

[elliefm]

I've reproduced it in Cassandane and can confirm that patch does fix it. It's in git as 76b96d9 for 3.0, and 5719f10 for master