https://bugs.documentfoundation.org/show_bug.cgi?id=173994
Bug ID: 173994
Summary: FILEOPEN DOCX: U+200E/U+200F in a REF/PAGEREF field
result makes Writer allocate memory without bound
during layout
Product: LibreOffice
Version: 26.8.0.3 release
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Writer
Assignee: [email protected]
Reporter: [email protected]
Description:
if I open a OOXML document with a cross-reference containing a left-to-right
mark (LRM, U+200E), memory consumption increases sharply in a matter of seconds
and LibreOffice ends up not responding / crashing
Steps to Reproduce:
1. Open the attached lrm-in-ref-field-minimal.docx in Writer
(or run: soffice --headless --convert-to pdf lrm-in-ref-field-minimal.docx)
2. Watch the memory use of soffice.bin
Actual Results:
Writer never finishes loading. soffice.bin memory grows by about 1 GB per
second.
In a Docker container limited to 8 GB RAM without swap, the process reaches 8
GB
in about 10 seconds and is killed by the OOM killer. Without a memory limit it
grows until the system runs out of memory.
Expected Results:
The document opens and shows the field result (an empty-looking reference),
as it does in 26.2.6.3 (about 90 MB peak memory, under 1 second).
Reproducible: Always
User Profile Reset: Yes
Additional Info:
The attached file is a 995-byte DOCX with one paragraph containing one field.
Its whole word/document.xml is:
```
<w:document
xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main";><w:body>
<w:p>
<w:r><w:fldChar w:fldCharType="begin"/></w:r>
<w:r><w:instrText xml:space="preserve"> REF _Ref1 \h </w:instrText></w:r>
<w:r><w:fldChar w:fldCharType="separate"/></w:r>
<w:r><w:t>‎</w:t></w:r>
<w:r><w:fldChar w:fldCharType="end"/></w:r>
</w:p>
</w:body></w:document>
```
Word writes U+200E (LEFT-TO-RIGHT MARK) in front of paragraph-number cross-
references (REF ... \r \h), so real-world contracts with numbered clause
references commonly contain this. We found six such documents; all of them
trigger the problem. Removing only the U+200E characters inside REF field
results makes them open normally (about 150 MB, 2 seconds).
Variants tested on 26.8.0.3 (8 GB limit, 60 s timeout, headless PDF export):
REF field, result U+200E, no bookmark in the document -> runaway memory
REF field, result U+200E, bookmark _Ref1 present -> runaway memory
REF \r \h to a numbered paragraph, result U+200E + "1" -> runaway memory
REF field, result U+200F (RLM) -> runaway memory
PAGEREF field, result U+200E -> runaway memory
REF field, result U+200B (zero width space) -> OK
REF field, result "x" -> OK
PAGE field, result U+200E -> OK
U+200E in plain text, not in a field -> OK
Versions tested with the minimal file (official TDF aarch64 .deb builds,
Debian trixie, Docker):
26.2.6.3 (8221e31b3ac356a1623c672912a3d2b492f7e3d1) -> OK
26.8.0.3 (bce0998afefdbc355585ca324285661a2170ba77) -> runaway memory
26.8.1.1 (bf6ef2662401c7d6dce671ab4deb26ee0af3a7c1) -> runaway memory
...
Version: 26.8.0.3 (AARCH64)
Build ID: bce0998afefdbc355585ca324285661a2170ba77
OS: Linux (Debian trixie, Docker on macOS)
--
You are receiving this mail because:
You are the assignee for the bug.
