cyrusimap / cyrus-imapd

Cyrus IMAP is an email, contacts and calendar server
http://cyrusimap.org
Other
517 stars 142 forks source link

httpd crashing on caldav #4903

Closed netfenceventu closed 1 month ago

netfenceventu commented 1 month ago

I've got an install of 3.4.7 on FreeBSD 13.3/amd64 which has been working properly for years. Recently (possibly due to some upgrades?) it started crashing when a specific user accesses a specific shared calendar.

All the users use the same client (ThunderBird 115.10) and all the allowed users are able to use that shared calendar except that specific one. When this user's client connects to the calendar, it does not work and I see in the logs something like:

http[24069]: login: [127.0.2.1] user1 Basic User logged in SESSIONID=<mail-1713859646-24069-1-2696860745399299929>
http[24069]: [127.0.2.1] as "user1" with "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:115.0) Gecko/20100101 Thunderbird/115.10.1" via SESSIONID=<mail-1713859646-24069-1-2696860745399299929>; "REPORT /dav/calendars/user/user1/sharedcalendar.Default/ HTTP/1.1" (origin=https://mail.xxxxxxxxxxxx.it/; auth=Basic; type=calendar-multiget; depth=1) => "HTTP/1.1 207 Multi-Status" (tx-encoding=chunked; cnt-encoding=br) [timing: cmd=0.043418 net=0.000008 total=0.043426]
master[20824]: process type:SERVICE name:http path:/usr/local/cyrus/libexec/httpd age:0.183s pid:24069 signaled to death by signal 11 (Segmentation fault, core dumped)
kernel: pid 24069 (httpd), jid 5, uid 60: exited on signal 11 (core dumped)

I tried removing and re-adding permissions for this calendar to this specific user: nothing changed.

So I compiled Cyrus and libical with debug info and here's the stack trace:

#0  0x00000008349c492b in icalparser_string_line_generator (out=0x84080bdb0 "", buf_size=80, d=0x820ff1178) at /wrkdirs/usr/ports/devel/libical/work/libical-3.0.16/src/libical/icalparser.c:1298
#1  0x00000008349c24e1 in icalparser_get_line (parser=0x84080bda0, line_gen_func=0x8349c4890 <icalparser_string_line_generator>) at /wrkdirs/usr/ports/devel/libical/work/libical-3.0.16/src/libical/icalparser.c:536
#2  0x00000008349c273b in icalparser_parse (parser=0x84080bda0, line_gen_func=0x8349c4890 <icalparser_string_line_generator>) at /wrkdirs/usr/ports/devel/libical/work/libical-3.0.16/src/libical/icalparser.c:639
#3  0x00000008349c4acc in icalparser_parse_string (
    str=0x854ded1fc "BEGIN:VCALENDAR\r\nPRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN\r\nVERSION:2.0\r\nBEGIN:VTIMEZONE\r\nTZID:Europe/Rome\r\nX-TZINFO:Europe/Rome[2024a]\r\nBEGIN:STANDARD\r\nTZOFFSETTO:+0100\r\nTZOFFSETFROM:+\
0"...) at /wrkdirs/usr/ports/devel/libical/work/libical-3.0.16/src/libical/icalparser.c:1351
#4  0x000000000024998e in propfind_caldata (name=0x8407fe780 "calendar-data", ns=0x8407caae0, fctx=0x820ff28d8, prop=0x840815c00, resp=0x84093a800, propstat=0x820ff1470, rock=0x14) at imap/http_caldav.c:5867
#5  0x00000000002649c9 in xml_add_response (fctx=0x820ff28d8, code=0, precond=0, desc=0x0, location=0x0) at imap/http_dav.c:1581
#6  0x0000000000270802 in propfind_by_resource (rock=0x820ff28d8, data=0x82434e8b0 <caldav_lookup_resource[cdata]>) at imap/http_dav.c:5867
#7  0x00000000002741c7 in report_multiget (txn=0x820ff2b98, rparams=0x2d2000 <caldav_params>, inroot=0x840815a80, fctx=0x820ff28d8) at imap/http_dav.c:7408
#8  0x00000000002616f1 in meth_report (txn=0x820ff2b98, params=0x2d2000 <caldav_params>) at imap/http_dav.c:8266
#9  0x000000000029c801 in process_request (txn=0x820ff2b98) at imap/httpd.c:1827
#10 0x00000000002a49da in http1_input (txn=0x820ff2b98) at imap/httpd.c:1893
#11 0x000000000029a32d in cmdloop (conn=0x820ff5dd8) at imap/httpd.c:2046
#12 0x0000000000299d55 in service_main (argc=1, argv=0x840779000, envp=0x820ff70d8) at imap/httpd.c:963
#13 0x00000000002c73b6 in main (argc=1, argv=0x820ff70c8, envp=0x820ff70d8) at master/service.c:647 

At frame #3 (icalparser_parse_string), it seems str is 7684 chars long, but not null-terminated.

Going up the stack, at frame #4 (propfind_caldata): fctx->msg_buf.len=8192 fctx->s is full, again without a null terminator.

Altough myself a developer, I'm not familiar with CyrusIMAP's code, so I don't know what to check. Any suggestion is welcome.

netfenceventu commented 1 month ago

Just an update: a second user started having the same problem on the same calendar (and now she can't see it at all in ThunderBird).

elliefm commented 1 month ago

That backtrace is really helpful, thanks. Looks like this was already fixed on master by https://github.com/cyrusimap/cyrus-imapd/pull/3809

Are you able to apply the patches from that PR and see if that helps? You can get them in raw patch format by adding ".patch" to the end of the url, like this: https://github.com/cyrusimap/cyrus-imapd/pull/3809.patch

netfenceventu commented 1 month ago

Hello and thank you very much! I had to work the patches a little, as they don't apply cleanly to 3.4, but they indeed fixed the problem.