A heap use-after-free flaw was found in Gnumeric's workbook XML parser. A malformed SheetObjectComponent element can cause the parser to release a sheet-object component and later pass the freed object to sheetobjectcomponentsetcomponent(). When a user opens a crafted Gnumeric workbook, the stale object is dereferenced during XML parsing, causing Gnumeric to crash. The issue was reproduced in the 1.12.61 release and an AddressSanitizer-instrumented development build; it was also present in source reported as version 1.11.0 and later. The available proof of concept demonstrates a denial of service only. No code execution, information disclosure, or data-integrity impact has been demonstrated. A patch was available, but no fixed release had been identified at the time of reporting.

Untrusted search path vulnerability in the GObject wrapper around Python interpreter allows local users to execute arbitrary code via a Trojan horse Python file in the current working directory, related to an erroneous setting of sys.path by the PySysSetArgv function.

References (more details, test case): http://www.nabble.com/Bug-484305%3A-bicyclerepair%3A-bike.vim-imports-untrusted-python-files-from-cwd-td18848099.html

Relevant part of the code in gnumeric-N.V.R/plugins/python-loader/gnm-py-interpreter.c:

103 PySysSetArgv (GNELEMENTS (pluginargv) - 1, pluginargv); 104 pyinitgnumeric (interpreter);

Proposed patch: The Debian patch for similar dia's Python related issue, available at:

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=pythonpath.diff;att=1;bug=504251

should be sufficient to resolve this issue.