Crashes when the number of properties is less than what the header defines
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 55/100
Research direction
Start at the element-property loop that calls parseNext and inspect tokenSplit and parseNext together. Reproduce the supplied PLY example with fewer values than declared, then verify that the chosen bounds-checking behavior prevents an out-of-bounds access and handles the malformed row safely.
Written by the indexing model from the issue text.
Description
Properties are parsed with a loop that is repeated elem.properties.size() times, which is the number of properties the header says this element should have.
vector<string> tokens = tokenSplit(line);
size_t iTok = 0;
for (size_t iP = 0; iP < elem.properties.size(); iP++) {
elem.properties[iP]->parseNext(tokens, iTok);
}
However if this element has less properties than the header defines, tokenSplit(line) returns a number of tokens less than elem.properties.size().
Then when we call parseNext, tokens[curEntry] is an out-of-bounds access and we crash when trying to create an istringstream from whatever garbage we read.
virtual void parseNext(const std::vector<std::string>& tokens, size_t& currEntry) override {
data.emplace_back();
std::istringstream iss(tokens[currEntry]);
typename SerializeType<T>::type tmp; // usually the same type as T
iss >> tmp;
data.back() = tmp;
currEntry++;
};
Here is an example file that will cause a crash:
ply
format ascii 1.0
element vertex 1
property float x
property float y
property char z
comment There are 3 properties but we provide only 2!
end_header
3 4
Possible fixes:
- Verify that the number of tokens matches the expected number of properties
- In
parseNext, ensure thatcurrEntryis withintokens.size() - In
parseNext, usetokens.at(currEntry)
- Dominant language
- C++
- Stars
- 406
- Forks
- 74
- PR merge metrics
- No merged PRs in 30d
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from nmwsharp/happly
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
-
Difficulty 3/5 1-2 days Newbie friendliness 56/100
-
Difficulty 3/5 1-2 days Newbie friendliness 48/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 45/100
-
Difficulty 5/5 Over a week Newbie friendliness 20/100
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
google/libultrahdr#485 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
godotengine/godot#123776 ·
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 60/100
-
good first issue
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
ros2/common_interfaces#344 ·