The get_app_path function in desktop/unx/source/start.c in LibreOffice through 6.0.5 mishandles the realpath function in certain environments such as FreeBSD libc, which might allow attackers to cause a denial of service (buffer overflow and application crash) or possibly have unspecified other impact if LibreOffice is automatically launched during web browsing with pathnames controlled by a remote web site.
Related to CVE-2018-11236
For one, that get_app_path is only called with argv of LO's oosplash helper executable (installed at /usr/lib.../libreoffice/program/oosplash, called during the LO start-up sequence). So an attack would need launch that executable with a suitably long argv. I don't see how that could happen "if LibreOffice is automatically launched during web browsing with pathnames controlled by a remote web site." (<https://nvd.nist.gov/vuln/detail/CVE-2018-14939>)
For another, I don't see how that get_app_path uses realpath(3) wrongly. If there is an issue with the glibc implementation of realpath(3), as CVE-2018-11236 states, then it should be necessary and sufficient to fix the issue in glibc, and not in client code calling realpath(3), or am I missing something?
Neither do I see how can this cause buffer overflow on Linux. I also can't think of such attack scenario where a path name to oosplash can be controlled by remote web site.
For CVE-2018-11236, you're right, that's indeed a separate issue in realpath implementation that might get potentially triggered using this code, but that's out of scope of LO and this issue.
This issue did not affect the versions of libreoffice as shipped with Red Hat Enterprise Linux 5, 6 and 7.