The openddl-parser from kimkulling

Issue 24463 in oss-fuzz: assimp:assimp_fuzzer: Heap-buffer-overflow in ODDLParser::OpenDDLParser::parseIdentifier

ClusterFuzz-External via monorail [email protected]	ClusterFuzz-External via monorail [email protected]	Sat, Aug 1, 2:36 PM
ClusterFuzz-External via monorail [email protected]
to me	to me
to me

Add regression test suite for https://github.com/kimkulling/openddl-parser/pull/39

uint64 has different sizes on Windows, Linux

On Windows size is 4, on linux with gcc size is 8, with clanc 4.

DataArray parses also lists of array

When giving a list of arrays separated by a comma the statis method OpenDDLParser::parseDataList will parse the whole list.
So the Value list will not be correct and data can be get missed.

See unittest parseDataArrayListTest to reproduce this issue.

Not all nodes of the OpenGEX example are available after parsing.

When parsing the simple OpenGEX-example in the test/example folder not all nodes are available.

8 nodes should be there, after parsing only 6 are available. The name and type of the last node which is available is empty.

master not building on clang 10.0.1

Hi!

I'm attempting to build this with Clang 10.0.1, getting following error:

[  3%] Building CXX object CMakeFiles/openddl_parser.dir/code/OpenDDLExport.cpp.o
In file included from /Users/lerppana/Github/openddl-parser/code/OpenDDLExport.cpp:25:
In file included from /Users/lerppana/Github/openddl-parser/include/openddlparser/OpenDDLParser.h:27:
/Users/lerppana/Github/openddl-parser/include/openddlparser/OpenDDLParserUtils.h:323:21: error: unknown type name 'size_T'; did you mean 'size_t'?
    if (static_cast<size_T>(in) >= CharTableSize) {
                    ^~~~~~
                    size_t
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.0.0/include/stddef.h:46:23: note: 'size_t' declared here
typedef __SIZE_TYPE__ size_t;
                      ^

Is there possibly a typo in OpenDDLParserUtils.h:323?

strings with the comment syntax in them breaks the parser

this is a part of a file that i exported from blender.
blender apparently uses //f/ for f:\ so the parser thinks its a comment with the closing "}
making it unable to parse the file.
kitty.txt

Text Buffers of ids are not null-terminated

We need to have them null-terminated.

Fix coverity pending state.

OpenDDLParser::parseStructureBody cut first character of token

So when parsing Materialref it looks for aterialRef instead. This is cause by a false increment of the current character in the buffer.

Issue 24803 in oss-fuzz: assimp:assimp_fuzzer: Null-dereference READ in std::__1::char_traits<char>::length

New issue 24803 by ClusterFuzz-External: assimp:assimp_fuzzer: Null-dereference READ in std::__1::char_traits::length
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24803

Detailed Report: https://oss-fuzz.com/testcase?key=5095112535965696

Project: assimp
Fuzzing Engine: libFuzzer
Fuzz Target: assimp_fuzzer
Job Type: libfuzzer_ubsan_assimp
Platform Id: linux

Crash Type: Null-dereference READ
Crash Address: 0x000000000000
Crash State:
std::__1::char_traits::length
std::__1::basic_string<char, std::__1::char_traits, std::__1::allocator<ch
ODDLParser::OpenDDLParser::parseHeader

Sanitizer: undefined (UBSAN)

Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_ubsan_assimp&revision=202008080609

Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5095112535965696

Issue filed automatically.

See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally.
When you fix this bug, please

mention the fix revision(s).
state whether the bug was a short-lived regression or an old bug in any stable releases.
add any other useful information.
This information can help downstream consumers.

If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without an upstream patch, then the bug report will automatically
become visible to the public.

Version not updated

The evrsion string is still 0.1.0.

HexValue 0x3F800000 will be returned as infinite instead of 1.0f

When parsing the following value 0x3F800000 a float value of 1.0f is expected. Instead of this an infinite value will be returned. This is wrong!

Class OpenDDLParser is a mixup of public API and helper methods

We need to separate these.

OpenDDL Parser need an option to build static library

OpenDDL Parser has only the option to build shard library.

Since MIT permits static library linking.

Travis shall execute unit tests automatically

At the moment no unittest execution is supported by travis job. We need to execute the unittests for each new build.

add doxygen documentation

We need to have the doxygen documentation available.

DataArrayLists containing multiple arrays will be returned as one big list

Given a list of floats with 3 items in an array:
"float[ 3 ]\n"
"{\n"
" {0x3F800000, 0x00000000, 0x00000000},\n"
" 0x00000000, 0x3F800000, 0x00000000},\n"
" 0x00000000, 0x00000000, 0x3F800000},\n"
" 0xBEF33B00, 0x411804DE, 0x00000000} \n"
"}\n";

These will be returned as one big linked list instead of 4 bundled of data array lists with 3 items for each list.

References in data lists will not be handled correctly

The references in the integration test parseEmbeddedStructureWithRefTest are not stored in the child nodes. When parsing the structures the child nodes ObjectRef and MaterialRef shall contain reference data, but they are empty.

Test OpenDDLIntegrationTest.parseEmbeddedStructureWithRefTest failes

Output:
bjectRef
aterialRef
D:\projects\openddl-parser\test\OpenDDLIntegrationTest.cpp(114): error: Value of: childs.size()
Actual: 1
Expected: 3
[ FAILED ] OpenDDLIntegrationTest.parseEmbeddedStructureWithRefTest (1 ms)

Node hierarchy is plain

At the moment the node hierarhcy created by the parser has only a level depth of 1. This is wrong!

Issue 31795 in oss-fuzz: assimp:assimp_fuzzer: Heap-buffer-overflow in ODDLParser::OpenDDLParser::normalizeBuffer

Status: New
Owner: ----
CC: [email protected]
Labels: Restrict-View-Commit ClusterFuzz Stability-Memory-AddressSanitizer Reproducible OS-Linux Engine-afl Security_Severity-Medium Proj-assimp Reported-2021-03-07
Type: Bug-Security

New issue 31795 by ClusterFuzz-External: assimp:assimp_fuzzer: Heap-buffer-overflow in ODDLParser::OpenDDLParser::normalizeBuffer
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=31795

Detailed Report: https://oss-fuzz.com/testcase?key=5753118978605056

Project: assimp
Fuzzing Engine: afl
Fuzz Target: assimp_fuzzer
Job Type: afl_asan_assimp
Platform Id: linux

Crash Type: Heap-buffer-overflow READ 1
Crash Address: 0x61e000002e60
Crash State:
ODDLParser::OpenDDLParser::normalizeBuffer
ODDLParser::OpenDDLParser::parse
Assimp::OpenGEX::OpenGEXImporter::InternReadFile

Sanitizer: address (ASAN)

Recommended Security Severity: Medium

Crash Revision: https://oss-fuzz.com/revisions?job=afl_asan_assimp&revision=202008080609

Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5753118978605056

Issue filed automatically.

See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally.
When you fix this bug, please

mention the fix revision(s).
state whether the bug was a short-lived regression or an old bug in any stable releases.
add any other useful information.
This information can help downstream consumers.

If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without an upstream patch, then the bug report will automatically
become visible to the public.

Issue 40565 in oss-fuzz: assimp:assimp_fuzzer: Undefined-shift in ODDLParser::OpenDDLParser::parseHexaLiteral

_Status: New
Owner: ----
CC: [email protected]
Labels: Restrict-View-Commit ClusterFuzz Reproducible Stability-UndefinedBehaviorSanitizer Engine-libfuzzer OS-Linux Proj-assimp Reported-2021-11-01
Type: Bug

New issue 40565 by ClusterFuzz-External: assimp:assimp_fuzzer: Undefined-shift in ODDLParser::OpenDDLParser::parseHexaLiteral
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=40565

Detailed Report: https://oss-fuzz.com/testcase?key=4594942421368832

Project: assimp
Fuzzing Engine: libFuzzer
Fuzz Target: assimp_fuzzer
Job Type: libfuzzer_ubsan_assimp
Platform Id: linux

Crash Type: Undefined-shift
Crash Address:
Crash State:
ODDLParser::OpenDDLParser::parseHexaLiteral
ODDLParser::OpenDDLParser::parseFloatingLiteral
ODDLParser::OpenDDLParser::parseDataList

Sanitizer: undefined (UBSAN)

Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_ubsan_assimp&range=202110290607:202110300606

Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4594942421368832

Issue filed automatically.

See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally.
When you fix this bug, please

mention the fix revision(s).
state whether the bug was a short-lived regression or an old bug in any stable releases.
add any other useful information.
This information can help downstream consumers.

If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without an upstream patch, then the bug report will automatically
become visible to the public.

Use cpp-coverall

see https://coveralls.zendesk.com/hc/en-us/articles/201342799-C-C-

normalizeparser does not shrink the buffer after normalize process.

It has still the old size.

Issue 61893 in oss-fuzz: assimp:assimp_fuzzer: Container-overflow in ODDLParser::OpenDDLParser::parseIntegerLiteral

Status: New
Owner: ----
CC: kim.k...@googlemail.com
Labels: Restrict-View-Commit ClusterFuzz Stability-Memory-AddressSanitizer Reproducible Engine-libfuzzer OS-Linux Security_Severity-Medium Proj-assimp Reported-2023-08-30
Type: Bug-Security

New issue 61893 by ClusterFuzz-External: assimp:assimp_fuzzer: Container-overflow in ODDLParser::OpenDDLParser::parseIntegerLiteral
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=61893

Detailed Report: https://oss-fuzz.com/testcase?key=4980126616780800

Project: assimp
Fuzzing Engine: libFuzzer
Fuzz Target: assimp_fuzzer
Job Type: libfuzzer_asan_assimp
Platform Id: linux

Crash Type: Container-overflow READ 1
Crash Address: 0x619000002c24
Crash State:
ODDLParser::OpenDDLParser::parseIntegerLiteral
ODDLParser::OpenDDLParser::parseDataList
ODDLParser::OpenDDLParser::parseStructureBody

Sanitizer: address (ASAN)

Recommended Security Severity: Medium

Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_assimp&revision=202308300601

Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=4980126616780800

Issue filed automatically.

OpenDDLIntegrationTest.parseOpenGEXTest has errors during parsing

Please check:

Error:Invalid token
, { expected.

Error:Invalid token x, { expected.
x3F800000
Error:Invalid token , { expected.
//
Error:Invalid token 0, { expected.
Error:Invalid token ., { expected.
.47506
Error:Invalid token ., { expected.
.50119
Error:Invalid token ,, { expected.
Error:Invalid token }, { expected.

Error:Invalid token
, { expected.

Value in DataArrayList are containing only the first array

When parsing the following DataArrayList:
"float[ 3 ]\n"
"{\n"
" {0x3F800000, 0x00000000, 0x00000000},\n"
" {0x00000000, 0x3F800000, 0x00000000},\n"
" {0x00000000, 0x00000000, 0x3F800000},\n"
" {0xBEF33B00, 0x411804DE, 0x00000000} \n"
"}\n";

only the first array will be returned for all arrays stored in the DataArrayList. ( so only 0x3F800000, 0x00000000, 0x00000000} will be returned for all 4 DataArrays ).

New source release for AssetImporterLib3.2

Data array will be parsed wrong

the following array will be interpreted as 4 x 4 integers instead of 16 floats:
float[16]
{
{0x3F800000, 0x00000000, 0x00000000, 0x00000000, // {1, 0, 0, 0
0x00000000, 0x3F800000, 0x00000000, 0x00000000, // 0, 1, 0, 0
0x00000000, 0x00000000, 0x3F800000, 0x00000000, // 0, 0, 1, 0
0x43041438, 0x411804DE, 0x00000000, 0x3F800000} // 132.079, 9.50119, 0, 1}
}

Issue 24587 in oss-fuzz: assimp:assimp_fuzzer: Stack-overflow in ODDLParser::OpenDDLParser::parseStructureBody

New issue 24587 by ClusterFuzz-External: assimp:assimp_fuzzer: Stack-overflow in ODDLParser::OpenDDLParser::parseStructureBody
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24587

Detailed Report: https://oss-fuzz.com/testcase?key=5699047558742016

Project: assimp
Fuzzing Engine: libFuzzer
Fuzz Target: assimp_fuzzer
Job Type: libfuzzer_asan_assimp
Platform Id: linux

Crash Type: Stack-overflow
Crash Address: 0x7ffd103fcce8
Crash State:
ODDLParser::OpenDDLParser::parseStructureBody
ODDLParser::OpenDDLParser::parseStructure
ODDLParser::OpenDDLParser::parseNextNode

Sanitizer: address (ASAN)

Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_assimp&revision=202007310618

Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5699047558742016

Issue filed automatically.

See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally.
When you fix this bug, please

mention the fix revision(s).
state whether the bug was a short-lived regression or an old bug in any stable releases.
add any other useful information.
This information can help downstream consumers.

If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without an upstream patch, then the bug report will automatically
become visible to the public.

End of buffer will be not detected correctly during parsing

When parsing a buffer the end of characters will not detected correctly.

OpenGEX: Cannot load unsigned_int16 indices

Issue related to assimp/assimp#1341

WIndows build is broken

Just fix it!

Global s_allocatedNodes accessed without synchronization

Global s_allocatedNodes is defined here:

openddl-parser/code/DDLNode.cpp

Line 31 in 3fbbe5e

DDLNode::DllNodeList DDLNode::s_allocatedNodes;

and accessed in multiple places without synchronization. This can break badly when the library is used in multithreaded program, for example with several instances of assimp Importer.

A workaround would be adding synchronization to all accesses. An actual solution would be removing this and making it local to each instance somehow.

Typenames of nodes contain line end characers

For instance:
Transform
{
float[16]
{
{0x3F800000, 0x00000000, 0x00000000, 0x00000000, // {1, 0, 0, 0
0x00000000, 0x3F800000, 0x00000000, 0x00000000, // 0, 1, 0, 0
0x00000000, 0x00000000, 0x3F800000, 0x00000000, // 0, 0, 1, 0
0x43041438, 0x411804DE, 0x00000000, 0x3F800000} // 132.079, 9.50119, 0, 1}
}
}

type name contains Transform\r\n

Color node will be parsed wrong

The following color node declaration will be interpreted as a data list with 2 items instead of 3.
Color (attrib = "diffuse") {float[3] {{0.588235, 0.588235, 0.588235}}}

New issue 24488 by ClusterFuzz-External: assimp:assimp_fuzzer: Direct-leak in ODDLParser::OpenDDLParser::parseIdentifier https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24488

New issue 24488 by ClusterFuzz-External: assimp:assimp_fuzzer: Direct-leak in ODDLParser::OpenDDLParser::parseIdentifier
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=24488

Detailed Report: https://oss-fuzz.com/testcase?key=5090349744390144

Project: assimp
Fuzzing Engine: libFuzzer
Fuzz Target: assimp_fuzzer
Job Type: libfuzzer_asan_assimp
Platform Id: linux

Crash Type: Direct-leak
Crash Address:
Crash State:
ODDLParser::OpenDDLParser::parseIdentifier
ODDLParser::OpenDDLParser::parseProperty
ODDLParser::OpenDDLParser::parseHeader

Sanitizer: address (ASAN)

Crash Revision: https://oss-fuzz.com/revisions?job=libfuzzer_asan_assimp&revision=202007290504

Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=5090349744390144

Issue filed automatically.

See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally.
When you fix this bug, please

mention the fix revision(s).
state whether the bug was a short-lived regression or an old bug in any stable releases.
add any other useful information.
This information can help downstream consumers.

If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without an upstream patch, then the bug report will automatically
become visible to the public.

OpenDDLParser's construtor and setBuffer(char* buffer, size_t len) 's buffer param type should be const char*

OpenDDLParser's construtor and setBuffer(char* buffer, int len) 's buffer param type should be const char*

OpenDDLParser( const char *buffer, size_t len ); void setBuffer( const char *buffer, size_t len );
#36

Memory leak in DDLNode: references will not be released

Must be released in destructor.

Fix compiler warnings

/home/travis/build/assimp/assimp/contrib/openddlparser/code/OpenDDLParser.cpp: In member function ‘char* ODDLParser::OpenDDLParser::parseHeader(char_, char_)’:
/home/travis/build/assimp/assimp/contrib/openddlparser/code/OpenDDLParser.cpp:243:66: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
/home/travis/build/assimp/assimp/contrib/openddlparser/code/OpenDDLParser.cpp: In member function ‘char_ ODDLParser::OpenDDLParser::parseStructure(char_, char_)’:
/home/travis/build/assimp/assimp/contrib/openddlparser/code/OpenDDLParser.cpp:300:54: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
/home/travis/build/assimp/assimp/contrib/openddlparser/code/OpenDDLParser.cpp: In member function ‘char_ ODDLParser::OpenDDLParser::parseStructureBody(char_, char_, bool&)’:
/home/travis/build/assimp/assimp/contrib/openddlparser/code/OpenDDLParser.cpp:368:58: warning: deprecated conversion from string constant to ‘char_’ [-Wwrite-strings]
In file included from /home/travis/build/assimp/assimp/contrib/openddlparser/include/openddlparser/OpenDDLParser.h:29:0,
from /home/travis/build/assimp/assimp/contrib/openddlparser/code/OpenDDLParser.cpp:23:
/home/travis/build/assimp/assimp/contrib/openddlparser/include/openddlparser/OpenDDLParserUtils.h: In function ‘bool ODDLParser::isCharacter(T) [with T = char]’:
/home/travis/build/assimp/assimp/contrib/openddlparser/code/OpenDDLParser.cpp:339:48: instantiated from here
/home/travis/build/assimp/assimp/contrib/openddlparser/include/openddlparser/OpenDDLParserUtils.h:176:63: warning: suggest parentheses around ‘&&’ within ‘||’ [-Wparentheses]
/home/travis/build/assimp/assimp/contrib/openddlparser/code/OpenDDLParser.cpp: At global scope:
/home/travis/build/assimp/assimp/contrib/openddlparser/code/OpenDDLParser.cpp:41:24: warning: ‘ODDLParser::Grammar::OpenBracketToken’ defined but not used [-Wunused-variable]
/home/travis/build/assimp/assimp/contrib/openddlparser/code/OpenDDLParser.cpp:42:24: warning: ‘ODDLParser::Grammar::CloseBracketToken’ defined but not used [-Wunused-variable]
/home/travis/build/assimp/assimp/contrib/openddlparser/code/OpenDDLParser.cpp:43:24: warning: ‘ODDLParser::Grammar::OpenPropertyToken’ defined but not used [-Wunused-variable]
/home/travis/build/assimp/assimp/contrib/openddlparser/code/OpenDDLParser.cpp:44:24: warning: ‘ODDLParser::Grammar::ClosePropertyToken’ defined but not used [-Wunused-variable]
/home/travis/build/assimp/assimp/contrib/openddlparser/code/OpenDDLParser.cpp:47:24: warning: ‘ODDLParser::Grammar::RefToken’ defined but not used [-Wunused-variable]
[ 1%] Building CXX object contrib/openddlparser/CMakeFiles/openddl_parser.dir/code/DDLNode.cpp.o
/home/travis/build/assimp/assimp/contrib/openddlparser/include/openddlparser/DDLNode.h: In constructor ‘ODDLParser::DDLNode::DDLNode(const string&, const string&, size_t, ODDLParser::DDLNode_)’:
/home/travis/build/assimp/assimp/contrib/openddlparser/include/openddlparser/DDLNode.h:84:12: warning: ‘ODDLParser::DDLNode::m_idx’ will be initialized after [-Wreorder]
/home/travis/build/assimp/assimp/contrib/openddlparser/include/openddlparser/DDLNode.h:82:20: warning: ‘ODDLParser::DataArrayList* ODDLParser::DDLNode::m_dtArrayList’ [-Wreorder]
/home/travis/build/assimp/assimp/contrib/openddlparser/code/DDLNode.cpp:47:1: warning: when initialized here [-Wreorder]

Unused parameter in Value

Just fix it!

Remove unnecessary null pointer checks

An extra null pointer check is not needed in functions like the following.

Failed to parse LightObject

LightObject $light1 (type = "point") // Lamp
{
Color (attrib = "light") {float[3] {{1.0, 1.0, 1.0}}}

Atten (curve = "inverse_square")
{
Param (attrib = "scale") {float {5.47722400800463}}
}
}
#39

Measure test coverage

We need to measure the test coverage for the unit tests.

When loading OpenGEX examle references are broken

The reference-name from the
ObjectRef {ref {$geometry1}}

is broken

Finalize export!

We need to deploy the doxygen doc to the website

See title.

Issue 37494 in oss-fuzz: assimp:assimp_fuzzer: Index-out-of-bounds in bool ODDLParser::isNumeric<char const>

Status: New
Owner: ----
CC: [email protected]
Labels: Restrict-View-Commit ClusterFuzz Reproducible Stability-UndefinedBehaviorSanitizer Engine-libfuzzer OS-Linux Security_Severity-Medium Proj-assimp Reported-2021-08-23
Type: Bug-Security

New issue 37494 by ClusterFuzz-External: assimp:assimp_fuzzer: Index-out-of-bounds in bool ODDLParser::isNumeric
https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=37494

Detailed Report: https://oss-fuzz.com/testcase?key=6294242528460800

Project: assimp
Fuzzing Engine: libFuzzer
Fuzz Target: assimp_fuzzer
Job Type: libfuzzer_ubsan_assimp
Platform Id: linux

Crash Type: Index-out-of-bounds
Crash Address:
Crash State:
bool ODDLParser::isNumeric
ODDLParser::OpenDDLParser::parseIdentifier
ODDLParser::OpenDDLParser::parseName

Sanitizer: undefined (UBSAN)

Recommended Security Severity: Medium

Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_ubsan_assimp&range=202008080609:202104020622

Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6294242528460800

Issue filed automatically.

See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally.
When you fix this bug, please

mention the fix revision(s).
state whether the bug was a short-lived regression or an old bug in any stable releases.
add any other useful information.
This information can help downstream consumers.

If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored.

This bug is subject to a 90 day disclosure deadline. If 90 days elapse
without an upstream patch, then the bug report will automatically
become visible to the public.

DataArrayList::size() returns wrong size

If the linked list has 1 element, m_next is null, and return 0 instead of 1.
Also time complexity should be reduced to O(1) by keeping a size attribute for each list...

kimkulling / openddl-parser Goto Github PK

openddl-parser's Introduction

openddl-parser's People

Contributors

Stargazers

Watchers

Forkers

openddl-parser's Issues

Recommend Projects

Recommend Topics

Recommend Org