Bug 128662 - LibreOffice crashed when receiving certain WebDAV error responses
Summary: LibreOffice crashed when receiving certain WebDAV error responses
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.3.3.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Julian Kalinowski
URL:
Whiteboard: target:7.0.0 target:6.4.3
Keywords:
Depends on:
Blocks: WebDAV
  Show dependency treegraph
 
Reported: 2019-11-08 07:40 UTC by robert.kollin
Modified: 2020-04-17 10:59 UTC (History)
6 users (show)

See Also:
Crash report or crash signature: ["com::sun::star::ucb::Lock::Lock(com::sun::star::ucb::Lock%20const%20&)"]


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description robert.kollin 2019-11-08 07:40:57 UTC
Description:
This Bug is quite similar to 126595. Now we face this problem again when trying to open a .doc/.docx file with LibreOffice.

When trying to open a document via a WebDAV-request initiated by an Active-X plugin LibreOffice crashes when the servers submits an xml-formatted error.

Steps to Reproduce:
Fiddler Shows following error:
HTTP/1.1 423 Locked
Set-Cookie: JSESSIONID-VIS55PS1=B289C6A550497313101E7F99DD9A098A; Path=/vis; HttpOnly
Engine: IT Hit WebDAV Server
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: PROPFIND, PROPPATCH, COPY, MOVE, DELETE, MKCOL, LOCK, UNLOCK, PUT, GETLIB, VERSION-CONTROL, CHECKIN, CHECKOUT, UNCHECKOUT, REPORT, UPDATE, CANCELUPLOAD, HEAD, OPTIONS, GET, POST
Access-Control-Allow-Headers: Overwrite, Destination, Content-Type, Depth, User-Agent, X-File-Size, X-Requested-With, If-Modified-Since, X-File-Name, Cache-Control
Access-Control-Max-Age: 2147483647
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked
Date: Fri, 08 Nov 2019 07:24:34 GMT
Server: Apache

7d
<?xml version="1.0" ?><d:error xmlns:d="DAV:"><d:responsedescription>The object is readonly</d:responsedescription></d:error>
0


Actual Results:
LibreOffice crash: crashreport.libreoffice.org/stats/crash_details/f7d58850-d50d-4a17-8432-bafc4dd2f9a1

Expected Results:
LibreOffice open the document


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Julien Nabet 2019-11-08 15:40:36 UTC
On Win10 with master sources updated today, I made this test.
There's a shared directory from Sharepoint with a docx.
If I open the file with LO, no crash.
If I open the file with Word (to have a lock) then with LO, it asks me if I should open in read-only, make a copy or cancel. I tried the 2 first ones, no crash.

Do you reproduce the crash with any file? (For example, if you create a brand new docx containing just "test")
Comment 2 Julien Nabet 2019-11-08 15:53:32 UTC
Also do you reproduce this with LO 64 bits?
Indeed, crashreport indicates x86
Comment 3 luporpi 2019-11-15 11:12:51 UTC
we may have identified the cause of the problem.

it is not the lock that causes the crash but probably an empty response for profind lockdiscovery



HTTP/1.1 207 Multi-Status
Set-Cookie: JSESSIONID-VIS55PS1=B89B49CDF0AA9A7B582F569B6EFD9DAC; Path=/vis; HttpOnly
Engine: IT Hit WebDAV Server
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: PROPFIND, PROPPATCH, COPY, MOVE, DELETE, MKCOL, LOCK, UNLOCK, PUT, GETLIB, VERSION-CONTROL, CHECKIN, CHECKOUT, UNCHECKOUT, REPORT, UPDATE, CANCELUPLOAD, HEAD, OPTIONS, GET, POST
Access-Control-Allow-Headers: Overwrite, Destination, Content-Type, Depth, User-Agent, X-File-Size, X-Requested-With, If-Modified-Since, X-File-Name, Cache-Control
Access-Control-Max-Age: 2147483647
Content-Type: text/xml;charset=UTF-8
Transfer-Encoding: chunked
Date: Thu, 14 Nov 2019 07:38:11 GMT
Server: Apache

177
<?xml version="1.0" ?><d:multistatus xmlns:d="DAV:"><d:response><d:href>http://server:8114/webdav/12450/file.doc</d:href><d:propstat><d:status>HTTP/1.1 200 OK</d:status><d:prop><d:lockdiscovery></d:lockdiscovery></d:prop></d:propstat></d:response></d:multistatus>
0



we will investigate this further. maybe it is a problem in our webdav server.

but this should not lead to a crash regardless.
Comment 4 Julien Nabet 2019-11-18 16:57:46 UTC
On Win10 with master sources updated today, I still can't reproduce this with a Sharepoint share (which uses Webdav).

In SfxMedium::LockOrigFileOnDemand, I tried to add some logs and even to throw manually an exception in https://opengrok.libreoffice.org/xref/core/sfx2/source/doc/docfile.cxx?r=9aadd633#1185.
Indeed, even when opening the file with Word and trying to open it with LO, there's no complain.
When I added the throw, LO indicates file is readonly and proposed to open it in read-only, copy or cancel.

I also noticed LO went into the catch but didn't enter block:
"if (aContentToLock.getPropertyValue("DAV:lockdiscovery") >>= aLocks)"
which contains css::ucb::Lock treatment.

Thorsten: taking a look at dev forum, I noticed a comment from you, any idea here?
Also, do we still have both Webdav implementations (serf + neon)?
Comment 5 Julien Nabet 2019-11-18 17:09:25 UTC
Forgot to tell that, without adding manual exception, I noticed this in console:
warn:ucb.ucp.webdav:6156:16376:ucb/source/ucp/webdav-neon/webdavcontent.cxx:3128: resourceTypeForLocks() DAVException - URL: <XXXHIDEURLXXX>, DAV ExceptionCode: 0, HTTP error: 207
Comment 6 Julien Nabet 2019-11-20 16:02:09 UTC
A thread a bit old but indicating some diffs between "neon" (by default Webdav mechanism) and "serf"
https://lists.freedesktop.org/archives/libreoffice/2015-August/069739.html
Comment 7 Xisco Faulí 2019-12-26 15:35:05 UTC
Hello Robert,
Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ after bug 129519 got fixed?
You can install it alongside the standard version.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Comment 8 luporpi 2020-01-13 11:18:41 UTC
it was tested with 6.2.0.4. the error still exists.
Comment 9 Aron Budea 2020-01-13 11:46:13 UTC
Version 6.2.0.4 is from a year ago, it shold be retested with a fresh master daily build.
Comment 10 luporpi 2020-01-13 16:13:52 UTC
sorry. this was a typo. test was with 6.4.0.2
Comment 11 Julian Kalinowski 2020-03-18 08:37:10 UTC
I can reproduce the crash using LO 6.4.0.3 and the application in question, VIS.

The corresponding crash report can be found here:
https://crashreport.libreoffice.org/stats/crash_details/57f50a26-777e-45fb-8dee-3dfdc54cf2cf

As Robert said, the propfind result is empty, so this could be the cause.
As we can see from the crash lock, this line crashes:

css::ucb::Lock aLock = aLocks[0];

Could it be that this statement:
if (aContentToLock.getPropertyValue("DAV:lockdiscovery") >>= aLocks)
is true, even if there are no locks? I'm not sure about the Any >>= operator.

LO obviously expects locks to be there if a resource is locked - but it shouldn't crash if that's not the case, as an empty lockdiscovery result seems to be allowed in general.
Comment 13 Commit Notification 2020-03-31 13:29:42 UTC
Julian Kalinowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/37cb8ac6abfc9bfd44aed1a51f6374ad1e23583a

tdf#128662 Fix exception when accessing empty lock list

It will be available in 6.4.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 14 Commit Notification 2020-04-01 09:39:25 UTC
Julian Kalinowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-4-3":

https://git.libreoffice.org/core/commit/a9ed52fca453f14cd38d948eba749248892577e4

tdf#128662 Fix exception when accessing empty lock list

It will be available in 6.4.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 15 Julian Kalinowski 2020-04-17 05:40:39 UTC
@Robert @luporpi: Could you please test with 6.4.3 released yesterday? The crash is fixed for me.
Comment 16 robert.kollin 2020-04-17 09:50:30 UTC
Hi Julian,

it looks like everything is working well with LO 6.4.3.
Instead of a crash it show up a dialog where I can choose if I want to open the file protected or as local copy.

Bug is fixed in my mind.
Comment 17 Xisco Faulí 2020-04-17 10:59:37 UTC
Setting to verified based on comment 16.
@Julian, thanks for fixing this issue!!