Any SAX-to-SAX transformation, like in this case should
use SvXMLLegacyToFastDocHandler on the left end, as right
end of the pipe is moved to fast Contexts.
Used delegating constructor here, since m_xDocumentHandler
is constant in SVGReader class.
Change-Id: I1fc841c96aaa618f0b566fdb0301ad48fd869f1c
Reviewed-on: https://gerrit.libreoffice.org/51815
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
...that is created as argument to
EnhancedCustomShape::FunctionParser::parseFunction (and referenced from data
reachable from aExpressNode), but still referenced during following
aExpressNode->fillNode call. Reintroduce the aCustoShape2d variable that had
been removed with 86c4672f46 "OperationSmiley:
Secured quite some places using CustomShape", causing the regression that in
UBSan builds e.g. CppunitTest_sc_subsequent_export_test would fail with
> /svx/source/customshapes/EnhancedCustomShapeFunctionParser.cxx:261:57: runtime error: member call on address 0x2b1295491180 which does not point to an object of type 'EnhancedCustomShape2d'
> 0x2b1295491180: note: object is of type 'SfxItemSet'
> 1a 04 00 01 10 99 42 cb 12 2b 00 00 10 2d 8f 00 40 60 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ^~~~~~~~~~~~~~~~~~~~~~~
> vptr for 'SfxItemSet'
> #0 0x2b131efeb12d in (anonymous namespace)::EnumValueExpression::fillNode(std::__debug::vector<EnhancedCustomShapeEquation, std::allocator<EnhancedCustomShapeEquation> >&, EnhancedCustomShape::ExpressionNode*, unsigned int) /svx/source/customshapes/EnhancedCustomShapeFunctionParser.cxx:261:57
> #1 0x2b131f01f061 in (anonymous namespace)::BinaryFunctionExpression::fillNode(std::__debug::vector<EnhancedCustomShapeEquation, std::allocator<EnhancedCustomShapeEquation> >&, EnhancedCustomShape::ExpressionNode*, unsigned int) /svx/source/customshapes/EnhancedCustomShapeFunctionParser.cxx:632:40
> #2 0x2b12e0915a5c in ConvertEnhancedCustomShapeEquation(SdrObjCustomShape const&, std::__debug::vector<EnhancedCustomShapeEquation, std::allocator<EnhancedCustomShapeEquation> >&, std::__debug::vector<int, std::allocator<int> >&) /filter/source/msfilter/escherex.cxx:2426:62
[...]
when accessing the already-dead EnhancedCustomShape2d object.
Change-Id: I8f3e598f81e8e01e2505483437025ddd4cee2ec9
...as started to happen when reading (invalid)
filter/qa/cppunit/data/tiff/fail/RC4-crash-7.tiff in
CppunitTest_filter_tiff_test after c81765629b
"coverity#1266496 Untrusted loop bound":
> /filter/source/graphicfilter/itiff/itiff.cxx:270:47: runtime error: value -nan is outside the range of representable values of type 'int'
> #0 0x2b5bae7ad928 in TIFFReader::ReadIntData() /filter/source/graphicfilter/itiff/itiff.cxx:270:47
> #1 0x2b5bae7b0017 in TIFFReader::ReadTagData(unsigned short, unsigned int) /filter/source/graphicfilter/itiff/itiff.cxx:320:27
> #2 0x2b5bae7e80f3 in TIFFReader::ReadTIFF(SvStream&, Graphic&) /filter/source/graphicfilter/itiff/itiff.cxx:1377:21
[...]
With an error-reporting concept apparently missing here, just convert such out-
of-bounds values to zero. (And make ReadDoubleData not go though the value-
limiting ReadIntData for floating types.)
Change-Id: I6e53e468e6b98fb7a7d5fd7f3336ee2168f76e30
Reviewed-on: https://gerrit.libreoffice.org/51700
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Changed quite some places of SdrObjCustomShape usage to use
references instead of pointers, thus forcing to more secure
handling. Changed some test and change methods, even found a
memory leak by doing so.
Change-Id: Iba76037a3c54af50bb05e6bd63d7ad04624665a7
In docx a colour value is represented as a 6-digit hex RGB value, or
alternatively the word "auto" to represent automatic colour.
- Add support for reading the value "auto" as COL_AUTO. Previously
this would be read as if it were a hex value, stopping at the
letter 'u' which is not a valid hex digit, resulting in the colour
0x00000A - a very dark blue, which looks close enough to black that
it went unnoticed for a long time :-)
- Remove code which tried to handle this wrong 0x00000A value,
including the constant OOXML_COLOR_AUTO, as it is no longer needed
and will cause surprises for anyone who really wanted this exact
shade of dark blue
- Fix unit tests that were checking for 0x00000A
Change-Id: I6000070341931147ff9341ad6281cd3b53c02b46
Reviewed-on: https://gerrit.libreoffice.org/50995
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
This is preparing to change how GraphicManager works where it
won't base itself around GraphicObject anymore but Graphic. No
functional or cosmetic change was made to the classes, only
changes that were needed because of the move and rename.
The only thing that wasn't moved is the GraphicRenderer as it
is not needed in vcl for now (but makes sense to move it in the
future to keep graphic stuff together).
grfmgr was renamed to GraphicObject as the GraphicManager will be
changed a lot and most likely moved out, so the name grfmgr won't
make any sense anymore.
All the UNO implementations were renamed with a prefix Uno and
used the same name as the class name. This is made to be more
specific which are the Uno objects (for example graphic.cxx
contained the implementation of XGraphic, which is similar to
graph.cxx contains Graphic).
Change-Id: I54a2fa6c7e997469aaa7770db05244adb9f64137
Reviewed-on: https://gerrit.libreoffice.org/51068
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
It makes sense to disable a filter, as a temporary security measure,
when there is a 0-day vulnerability in it.
E.g., when 0-day found in AbiWord filter, this config snippet disables it:
<item oor:path="/org.openoffice.TypeDetection.Filter">
<node oor:name="Filters">
<node oor:name="AbiWord">
<prop oor:name="Enabled" oor:finalized="true">
<value>false</value>
</prop>
</node>
</node>
</item>
Change-Id: I8b84250c7e4aac3555877d23f58ed13a2210ebfc
Reviewed-on: https://gerrit.libreoffice.org/50961
Reviewed-by: Andras Timar <andras.timar@collabora.com>
Tested-by: Andras Timar <andras.timar@collabora.com>
and use the underlying comphelper methods rather. This is so that I can
break the dependency that tools has on sax, and can add methods that
make sax depend on tools.
Change-Id: I8a2d6ce2ffc3529a0020710ade6a1748ee5af7d5
Reviewed-on: https://gerrit.libreoffice.org/50767
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
Johnny_M