Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

panicked at 'attempt to add with overflow', src/scanners.rs:586:49 #352

Closed
dimbleby opened this issue Jun 8, 2019 · 3 comments · Fixed by #353
Closed

panicked at 'attempt to add with overflow', src/scanners.rs:586:49 #352

dimbleby opened this issue Jun 8, 2019 · 3 comments · Fixed by #353

Comments

@dimbleby
Copy link
Contributor

dimbleby commented Jun 8, 2019

A real edge case this, impressive work by the fuzzer...

I imagine that the testcase can be shrunk, but I haven't tried:

[]([]([]([](\x1b]([](|AN\x0b|||[](&&&#0000000000000000000000\x01\x00\x00\x00[]([]([]([](|||||||[](&&&#0000000000000000000\x1000000000[]([]([](|||||||[](&&&#0018446744073709551([](|||||||[](&&&#001844674407370955161615\x01\x00\x00\x00[]([]\x112\x00372\x008\x005156194&#&#&#&
  10: core::panicking::panic
             at src/libcore/panicking.rs:49
  11: pulldown_cmark::scanners::parse_decimal::{{closure}}
             at src/scanners.rs:586
  12: <core::iter::adapters::TakeWhile<I,P> as core::iter::traits::iterator::Iterator>::try_fold::{{closure}}
             at /rustc/627486af15d222bcba336b12ea92a05237cc9ab1/src/libcore/iter/adapters/mod.rs:1375
  13: <core::slice::Iter<T> as core::iter::traits::iterator::Iterator>::try_fold
             at /rustc/627486af15d222bcba336b12ea92a05237cc9ab1/src/libcore/slice/mod.rs:3140
  14: <core::iter::adapters::TakeWhile<I,P> as core::iter::traits::iterator::Iterator>::try_fold
             at /rustc/627486af15d222bcba336b12ea92a05237cc9ab1/src/libcore/iter/adapters/mod.rs:1373
  15: pulldown_cmark::scanners::parse_decimal
             at src/scanners.rs:582
  16: pulldown_cmark::scanners::scan_entity
             at src/scanners.rs:640
  17: pulldown_cmark::parse::FirstPass::parse_line::{{closure}}
             at src/parse.rs:742
  18: pulldown_cmark::parse::scalar_iterate_special_bytes
             at src/parse.rs:2273
  19: pulldown_cmark::parse::iterate_special_bytes
             at src/parse.rs:2266
  20: pulldown_cmark::parse::FirstPass::parse_line
             at src/parse.rs:580
  21: pulldown_cmark::parse::FirstPass::parse_paragraph
             at src/parse.rs:523
  22: pulldown_cmark::parse::FirstPass::parse_block
             at src/parse.rs:399
  23: pulldown_cmark::parse::FirstPass::run
             at src/parse.rs:252
  24: pulldown_cmark::parse::Parser::new_with_broken_link_callback
             at src/parse.rs:1798
  25: pulldown_cmark::parse::Parser::new_ext
             at src/parse.rs:1784
  26: pulldown_cmark::parse::Parser::new
             at src/parse.rs:1780
@mity
Copy link

mity commented Jun 8, 2019

Do I read this story correctly that p-c tries to parse integers of arbitrary lengths? As far as I can remember the CommonMark specification imposes limits in all the cases where that has to be done. That includes (ordered) list item marks as well as numeric character references. (And when honoring the limits, the unchecked operations might be quite possibly good enough.)

@raphlinus
Copy link
Collaborator

I'll wait for @marcusklaas to review before merging. I think what @mity wrote was the original intent, but something may have changed.

@marcusklaas
Copy link
Collaborator

I have created a PR to add this to the fuzzing trophy case here

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants