SEGV in httpd when listing another users calendar

[narc-Ontakac2]

(gdb) bt
#0  0x00007fd85f775262 in __GI___libc_free (mem=0x840) at ./malloc/malloc.c:3453
#1  0x00007fd86074ca86 in _dlist_clean (dl=0x562e49a7bbf0) at imap/dlist.c:378
#2  0x00007fd86074ca05 in _dlist_clean (dl=<optimized out>) at imap/dlist.c:372
#3  dlist_free (dlp=dlp@entry=0x7ffc98ec8718) at imap/dlist.c:755
#4  0x0000562e2d13bca0 in caldav_get_validators (mailbox=0x562e499020c0, data=<optimized out>, userid=0x562xxxxxxxxx "someone", record=0x7ffc98ec8960, 
    etag=0x7ffc98ec87d0, lastmod=0x0) at imap/caldav_util.c:202
#5  0x0000562e2d1659ab in propfind_getetag (name=0x562e498a6500 "getetag", ns=0x562e498a64c0, fctx=0x7ffc98ec8ed0, prop=<optimized out>, 
    resp=<optimized out>, propstat=0x7ffc98ec8850, rock=0x0) at imap/http_dav.c:1973
#6  0x0000562e2d164943 in xml_add_response (fctx=fctx@entry=0x7ffc98ec8ed0, code=code@entry=0, precond=precond@entry=0, desc=desc@entry=0x0, 
    location=location@entry=0x0) at imap/http_dav.c:1594
#7  0x0000562e2d165229 in propfind_by_resource (rock=0x7ffc98ec8ed0, data=0x7ffc98ec8be0) at imap/http_dav.c:5942
#8  0x00007fd8606061ff in sqldb_exec (open=0x562e498a68f0, 
    cmd=cmd@entry=0x7fd860812a80 "SELECT  ical_objs.rowid, ical_objs.creationdate, ical_objs.mailbox, ical_objs.resource, ical_objs.imap_uid, ical_objs.lock_token, ical_objs.lock_owner, ical_objs.lock_ownerid, ical_objs.lock_expire, i"..., bvals=bvals@entry=0x7ffc98ec8c80, 
    cb=cb@entry=0x7fd8607ce0f0 <read_cb>, rock=rock@entry=0x7ffc98ec8bb0) at lib/sqldb.c:432
#9  0x00007fd8607ceaf0 in caldav_foreach (caldavdb=<optimized out>, mbentry=<optimized out>, cb=<optimized out>, rock=<optimized out>)
    at imap/caldav_db.c:495
#10 0x0000562e2d165303 in propfind_by_resources (fctx=fctx@entry=0x7ffc98ec8ed0) at imap/http_dav.c:5988
#11 0x0000562e2d16c85b in propfind_by_collection (mbentry=<optimized out>, rock=rock@entry=0x7ffc98ec8ed0) at imap/http_dav.c:6150
#12 0x0000562e2d143768 in calquery_by_collection (mbentry=<optimized out>, rock=rock@entry=0x7ffc98ec8ed0) at imap/http_caldav.c:6926
#13 0x0000562e2d149fb8 in report_cal_query (txn=0x562e498b5540, rparams=<optimized out>, inroot=<optimized out>, fctx=0x7ffc98ec8ed0)
    at imap/http_caldav.c:7022
#14 0x0000562e2d16dc2f in meth_report (txn=0x562e498b5540, params=0x562e2d29b880 <caldav_params>) at imap/http_dav.c:8373
#15 0x0000562e2d18b37b in process_request (txn=0x562e498b5540) at imap/httpd.c:1972
#16 0x0000562e2d176f1e in frame_recv_cb (session=<optimized out>, frame=0x562e498db9d8, user_data=<optimized out>) at imap/http_h2.c:318
#17 0x00007fd860ae5e35 in ?? () from /lib/x86_64-linux-gnu/libnghttp2.so.14
#18 0x00007fd860aeba8f in nghttp2_session_mem_recv2 () from /lib/x86_64-linux-gnu/libnghttp2.so.14
#19 0x0000562e2d178496 in http2_input (conn=conn@entry=0x562e2d2a7220 <http_conn>) at imap/http_h2.c:956
#20 0x0000562e2d191f6b in cmdloop (conn=<optimized out>) at imap/httpd.c:2201
#21 0x0000562e2d192b32 in service_main (argc=<optimized out>, argv=<optimized out>, envp=envp@entry=0x7ffc98ecf540) at imap/httpd.c:1075
#22 0x0000562e2d139eec in main (argc=<optimized out>, argv=<optimized out>, envp=0x7ffc98ecf540) at master/service.c:647
(gdb) up
#1  0x00007fd86074ca86 in _dlist_clean (dl=0x562e49a7bbf0) at imap/dlist.c:378
warning: 378	imap/dlist.c: Datei oder Verzeichnis nicht gefunden
(gdb) display *dl
4: *dl = {name = 0x562e49a7b <error: Cannot access memory at address 0x562e49a7b>, head = 0x0, tail = 0x0, next = 0x31, type = 1602984736, 
  sval = 0x7fd85f8b9b20 <main_arena+96> "", nval = 0, gval = 0x0, part = 0x840 <error: Cannot access memory at address 0x840>}

[narc-Ontakac2]

The above is from a Debian cyrus-imapd 3.10.2-1.

[narc-Ontakac2]

It is reproducible here. The call (by someone) that causes this is

0536685-39906-5-15879562078013892709>; "REPORT /dav/calendars/user/someone/someoneelse.Default/ HTTP/2" (auth=Basic; type=calendar-query; depth=1) => "HTTP/2 207 Multi-Status" (stream-id=1; tx-encoding=chunked; cnt-encoding=br) [timing: cmd=0.003155 net=0.000080 total=0.003235]

The call (by somoneelse) REPORT /dav/calendars/user/someoneelse/Default/ HTTP/1.1 does not cause the issue.

[ksmurchison]

Can you provide the entire request, perhaps by enabling telemetry?

[narc-Ontakac2]

Logged from the Evolution calendar backend

REPORT /dav/calendars/user/someone/someoneelse.Default/ HTTP/2
Soup-Debug-Timestamp: 1761193037
Soup-Debug: EWebDAVSession 1 (0x7f3db0003a20), SoupMessage 7 (0x7f3dcc2c6940), GSocket 5 (0x55f3e10718d0), restarted
Soup-Host: mail.heute-morgen.de
User-Agent: Evolution/3.56.1
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/xml; charset="utf-8"
Accept-Encoding: gzip, deflate, br
Accept-Language: de-de, de;q=0.9
Content-Length: 244
Authorization: Basic [someone:********]
Depth: 1

<?xml version="1.0" encoding="UTF-8"?>
<calendar-query xmlns="urn:ietf:params:xml:ns:caldav" xmlns:D="DAV:"><D:prop><D:getetag/></D:prop><filter><comp-filter name="VCALENDAR"><comp-filter name="VEVENT"/></comp-filter></filter></calendar-query>

[ksmurchison]

I can't reproduce on current Cyrus as shown by the request/response below (from the Cassandane test in #5709).
You might want to upgrade to v3.12.1

REPORT /dav/calendars/user/cassandane/test.Default/ HTTP/1.1
Host: 127.0.0.1:29100
Authorization: Basic Y2Fzc2FuZGFuZTpwYXNz
Depth: 1
Content-Length: 279
Content-Type: application/xml
User-Agent: Net-DAVTalk/0.22

<?xml version="1.0" encoding="UTF-8"?>
<calendar-query xmlns="urn:ietf:params:xml:ns:caldav" xmlns:D="DAV:">
  <D:prop>
    <D:getetag/>
  </D:prop>
  <filter>
    <comp-filter name="VCALENDAR">
      <comp-filter name="VEVENT"/>
    </comp-filter>
  </filter>
</calendar-query>


HTTP/1.1 207 Multi-Status
Date: Wed, 26 Nov 2025 17:28:29 GMT
Connection: Upgrade
Upgrade: h2c
Alt-Svc: h2c=":29100"
Vary: Accept-Encoding, Brief, Prefer
Content-Type: application/xml; charset=utf-8
Transfer-Encoding: chunked

6c
<?xml version="1.0" encoding="utf-8"?>
<D:multistatus xmlns="urn:ietf:params:xml:ns:caldav" xmlns:D="DAV:">

291
  <D:response>
    <D:href>/dav/calendars/user/cassandane/test.Default/52E643A6-CAED-11F0-8A7F-883F240A8DF7.ics</D:href>
    <D:propstat>
      <D:prop>
        <D:getetag>"7de7e5a43046b3e7cc652d6bb14d23679beae961"</D:getetag>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
  <D:response>
    <D:href>/dav/calendars/user/cassandane/test.Default/52EE811A-CAED-11F0-8A7F-883F240A8DF7.ics</D:href>
    <D:propstat>
      <D:prop>
        <D:getetag>"faa6012358d8747e9823d83b7b93d6483c313b45"</D:getetag>
      </D:prop>
      <D:status>HTTP/1.1 200 OK</D:status>
    </D:propstat>
  </D:response>
</D:multistatus>

0

[ksmurchison]

Actually, you might have corrupt user-specific data. This patch might prevent the crasher:

c1755c5