It was found that the OPVPWrapper::loadDriver() function in the pdftoopvp filter did not restrict the directory drivers could be loaded from. As the driver name can be configured based on a PPD file, processing a PDF in an attacker-controlled directory containing a malicious driver could lead to arbitrary code execution with the privileges of the "lp" user.
This issue was discovered by Florian Weimer of the Red Hat Product Security Team.
This issue has been resolved in upstream cups-filters-1.0.47
Created cups-filters tracking bugs for this issue:
Affects: fedora-all [bug 1074840]