HomePhorge

Guard against crash during getmetadata on shared folder

Description

Guard against crash during getmetadata on shared folder

This is what the crash looks like. It's reproducible on that folder
only, via cyradm (as cyrus-admin or a user), by doing a

'getmd "shared/Folder Example/TODOs Fabian@example.com"'

[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/glibc-hwcaps/power9/libthread_db-1.0.so".
Core was generated by `imapd '.
Program terminated with signal SIGSEGV, Segmentation fault.
1979 if (!userid[0] || !strcmp(userid, state->userid)) {
Missing separate debuginfos, use: yum debuginfo-install cyrus-sasl-lib-2.1.27-6.el8_5.ppc64le cyrus-sasl-plain-2.1.27-6.el8_5.ppc64le glibc-2.28-211.el8.ppc64le jansson-2.14-1.el8.ppc64le keyutils-libs-1.5.10-9.el8.ppc64le krb5-libs-1.18.2-22.el8_7.ppc64le libcom_err-1.45.6-5.el8.ppc64le libdb-5.3.28-42.el8_4.ppc64le libgcc-8.5.0-16.el8_7.ppc64le libical-3.0.3-3.el8.ppc64le libicu-60.3-2.el8_1.ppc64le libpq-13.5-1.el8.ppc64le libselinux-2.9-6.el8.ppc64le libstdc++-8.5.0-16.el8_7.ppc64le libuuid-2.32.1-39.el8_7.ppc64le libxcrypt-4.1.1-6.el8.ppc64le libxml2-2.9.7-15.el8_7.1.ppc64le libzstd-1.4.4-1.el8.ppc64le mariadb-connector-c-3.1.11-2.el8_3.ppc64le openldap-2.4.46-18.el8.ppc64le openssl-libs-1.1.1k-7.el8_6.ppc64le pcre-8.42-6.el8.ppc64le pcre2-10.32-3.el8_6.ppc64le sqlite-libs-3.26.0-17.el8_7.ppc64le xapian-core-libs-1.4.18-3.el8.ppc64le xz-libs-5.2.4-4.el8_6.ppc64le zlib-1.2.11-21.el8_7.ppc64le
(gdb) bt
0 rw_cb (mailbox=0x1305cbba0 "example.com!shared.Folder Example.TODOs Fabian", uid=0, entry=0x1305c4c05 "/vendor/kolab/folder-type", userid=0x0, value=0x7fffcd104ca0, mdata=0x7fffcd104c90, rock=0x1305d0e50) at imap/annotate.c:1979
1 0x00007fff83308528 in find_cb (rock=0x7fffcd106ed0, key=<optimized out>, keylen=<optimized out>, data=0x7fff7f15aa69 "", datalen=49) at imap/annotate.c:1137
2 0x00007fff82e1f4b4 in myforeach (db=0x13057b0b0, prefix=0x7fffcd105e10 "418d184e-f18f-41c5-8ba6-05e221ea7c60", prefixlen=62, goodp=0x7fff83306e10 <find_p>, cb=0x7fff83308220 <find_cb>, rock=0x7fffcd106ed0, tidptr=<optimized out>)

at lib/cyrusdb_twoskip.c:1651

3 0x00007fff82e0de98 in cyrusdb_foreach (db=<optimized out>, prefix=<optimized out>, prefixlen=<optimized out>, p=<optimized out>, cb=<optimized out>, rock=<optimized out>, tid=<optimized out>) at lib/cyrusdb.c:281
4 0x00007fff83308754 in _findall (data=data@entry=0x7fffcd106ea8, rock=rock@entry=0x7fffcd106ed0) at imap/annotate.c:1171
5 0x00007fff8330c920 in _findall (rock=0x7fffcd106ed0, data=0x7fffcd106ea8) at imap/annotate.c:1228
6 annotatemore_findall_full (pattern=pattern@entry=0x7fff83422e98 "", mailbox=0x130612fd0, mboxname=<optimized out>, mboxname@entry=0x0, uid=<optimized out>, entry=<optimized out>, since_modseq=since_modseq@entry=0,

proc=proc@entry=0x7fff83309290 <rw_cb>, rock=rock@entry=0x1305d0e50, flags=<optimized out>, flags@entry=0) at imap/annotate.c:1228

7 0x00007fff8330cc98 in annotation_get_fromdb (state=0x1305d0e50, entry=0x1305c5360) at imap/annotate.c:1993
8 0x00007fff83307b0c in _annotate_fetch_entries (state=state@entry=0x1305d0e50, proxy_check=proxy_check@entry=1) at imap/annotate.c:2648
9 0x00007fff8330e278 in annotate_state_fetch (state=0x1305d0e50, entries=0x7fffcd107220, attribs=0x7fffcd107230, callback=<optimized out>, rock=<optimized out>) at imap/annotate.c:2788
10 0x000000010e9baa48 in annot_fetch_cb (astate=<optimized out>, astate@entry=0x1305d0e50, rock=rock@entry=0x7fffcd107260) at imap/imapd.c:10092
11 0x000000010e9d76f8 in apply_mailbox_array (proc=0x10e9baa20 <annot_fetch_cb>, rock=0x7fffcd107260, mboxes=0x7fffcd1072c8, state=<optimized out>) at imap/imapd.c:10199
12 cmd_getmetadata (tag=tag@entry=0x130581fe0 "PROXY18") at imap/imapd.c:10571
13 0x000000010e9e96ec in cmdloop () at imap/imapd.c:1591
14 0x000000010e9eff0c in service_main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at imap/imapd.c:1005
15 0x000000010e9b1bc8 in main (argc=<optimized out>, argv=<optimized out>, envp=0x7fffcd10b748) at master/service.c:647

The crash is triggered by no userid being found for the folder (which is
subsequently dereferenced. I assume there is some data corruption
somewhere, this patch doesn't fix any of it, it simply prevents the
crash logging an error instead.

Details

Provenance
mollekopfAuthored on Jan 30 2024, 2:09 PM
mollekopfPushed on Jan 30 2024, 2:36 PM
Parents
R111:a30129c8c8eb: Avoid creating a "shared" toplevel folder
Branches
Unknown
Tags
Unknown

Event Timeline