Bug 2388224

Summary: LibreOffice crash (segmentation fault) when opening document from UNO pipe
Product: [Fedora] Fedora Reporter: Mikkel Lauritsen <renard>
Component: libreofficeAssignee: libreoffice-sig
Status: NEW --- QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 42CC: dtardon, erack, gwync, libreoffice-sig, mattia.verga, maxwell, sberg.fun
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Stacktrace
none
Stacktrace from coredump
none
Java code demonstrating the problem
none
Test document none

Description Mikkel Lauritsen 2025-08-13 13:12:53 UTC 
I have a Java program (attached) that starts a headless LO process, connects to it using a named pipe and uses loadComponentFromURL to open an ODT file. Doing this with LO 24.8 works perfectly, but LO 25.2 crashes while reading the file. It happens with several ODT files that I've tried, all of which can be opened without problems from the GUI - the one I am testing with has been created in LO 25.2 and is completely empty.

The stacktraces (attached) show that the crash happens in package/source/zipapi/ZipFile.cxx:1173 or package/source/zipapi/ByteGrabber.cxx:59 . The ODT file is 9312 bytes, so in ZipFile.cxx nLength = 9312, nSize = 534 and nEnd = 8778. This matches well with what I observe - just before the crash happens the seek method of the input stream is called with position = 8778, corresponding to ZipFile.cxx line 1169, and nBytesToRead is 534 in ByteGrabber.cxx line 59.

Reproducible: Always

Steps to Reproduce:
1. Run the attached Java class (with modifications to match file locations).
Actual Results:
LO 25.2 crashes with a SEGV

Expected Results:
LO loads the ODT file
Comment 1 Mikkel Lauritsen 2025-08-13 13:14:45 UTC 
Created attachment 2103502 [details]
Stacktrace

Stacktrace recorded by gdb from starting LO with --backtrace
Comment 2 Mikkel Lauritsen 2025-08-13 13:15:49 UTC 
Created attachment 2103503 [details]
Stacktrace from coredump
Comment 3 Mikkel Lauritsen 2025-08-13 13:20:36 UTC 
Created attachment 2103504 [details]
Java code demonstrating the problem

To compile java_uno.jar, libreoffice.jar and unoloader.jar must be present. Paths in the code must be modified to where the LO installation and test document are. When running the LO installation folder must be given in the -Djava.library.path system property (-Djava.library.path=/usr/lib64/libreoffice/program e.g.)
Comment 4 Mikkel Lauritsen 2025-08-13 13:25:12 UTC 
Created attachment 2103505 [details]
Test document
Comment 5 Mikkel Lauritsen 2025-08-13 13:31:25 UTC 
I have noticed that the memory handling at the crash site in ZipFile::findCentralDirectory() has been refactored from LO 24.8 to 25.2 to use a sal_Int8[] wrapped in a unique_ptr instead of a Sequence.
Comment 6 Mattia Verga 2025-08-15 09:46:48 UTC 
I don't know much about Java programming, anyway from a packaging POV starting with 25.2.0.1 Fedora LibreOffice has been built with unbundled JavaWebsocket. I've fired a test build in COPR re-enabling the bundled JavaWebsocket, maybe you can try to enable that COPR repo and reinstall LO from there (provided the build will finish ok).

If using the bundled JavaWebsocket shows the same crash, I think it is better to report the bug upstream. Otherwise... I don't know what to do, the bundled and unbundled versions should be the same, so I would expect the same output from both.
Comment 7 Mattia Verga 2025-08-15 09:47:14 UTC 
I forgot to add the link to the test build:
https://copr.fedorainfracloud.org/coprs/mattia/libreoffice-testing/build/9418951/
Comment 8 Mikkel Lauritsen 2025-08-15 10:23:25 UTC 
(In reply to Mattia Verga from comment #6)
> I don't know much about Java programming, anyway from a packaging POV
> starting with 25.2.0.1 Fedora LibreOffice has been built with unbundled
> JavaWebsocket. I've fired a test build in COPR re-enabling the bundled
> JavaWebsocket, maybe you can try to enable that COPR repo and reinstall LO
> from there (provided the build will finish ok).
> 
> If using the bundled JavaWebsocket shows the same crash, I think it is
> better to report the bug upstream. Otherwise... I don't know what to do, the
> bundled and unbundled versions should be the same, so I would expect the
> same output from both.

Thanks - I have in fact already reported the bug upstream ( https://bugs.documentfoundation.org/show_bug.cgi?id=167936 ). FWIW the root cause seems to be that the code that reads the ODT file assumes that the input stream will never be from a remote client, so it's independent of the (in my case Java based) client talking to LO.