security bug - LibreOffice shouldn't require writable and executable memory pages at the same time

Hess THR hessnovTHR44 at
Tue Feb 6 11:07:10 UTC 2018


can someone please take a look at the:


OpenBSD has great features for Memory protection, ex.: W^X.^X

We can disable this function with the "wxallowed" mount point if a program needs it, and sadly, LibreOffice needs the wxallowed on /usr/local/. 

See example here:

Steps to Reproduce:
1. Use a secure OS that can help security audits, ex.: OpenBSD
2. Remove the wxallowed flag from /usr/local to enable the W^X enforcing, reboot
3. LibreOffice cannot start anymore, because it requires writable and executable memory pages in the same time, see Wiki link, why is this dangerous:

Actual Results:  
LibreOffice is prone to memory bugs if it needs writable/executable memory pages

Expected Results:
LibreOffice should run even with the remove wxallowed mount option. 

Reproducible: Always

User Profile Reset: No

Additional Info:
This is a security issue, please fix it with higher prio. 

Additional help from the forums: 

I'm not really sure but my guess is that LibreOffice is doing some dynamic runtime linking of a shared object and it's mapping the whole address space using one syscall with PROT_READ|PROT_WRITE|PROT_EXEC or alternatively PROT_ALL which i have already seen somewhere on github. – Karim Manaouil

@KarimManaouil Probably here:

It creates anonymous mapping with RWX access. – Ivan

More information about the LibreOffice mailing list