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

Extremely long SPDX comment results in a segfault #12208

Open
agroce opened this issue Oct 27, 2021 · 7 comments
Open

Extremely long SPDX comment results in a segfault #12208

agroce opened this issue Oct 27, 2021 · 7 comments
Labels
bug 🐛 good first issue candidate Could be a "good first issue" but something is blocking it or it has open questions. low impact Changes are not very noticeable or potential benefits are limited. medium difficulty medium effort Default level of effort should compile without error Error is reported even though it shouldn't. Source is fine. should have We like the idea but it’s not important enough to be a part of the roadmap.

Comments

@agroce
Copy link

agroce commented Oct 27, 2021

Description

segfault.zip

The attached contract produces:

../build/solc/solc segfault.sol
Segmentation fault

when compiled with solc

On master, using AFL fuzzing. Another discovery using https://github.com/agroce/afl-compiler-fuzzer

Environment

  • Compiler version: 0.8.10-develop.2021.10.27+commit.7ebf71f3.Linux.clang
  • Target EVM version (as per compiler settings): N/A
  • Framework/IDE (e.g. Truffle or Remix): N/A
  • EVM execution environment / backend / blockchain client: N/A
  • Operating system: Ubuntu 20.04 in docker

Steps to Reproduce

Above shows pretty clearly, I think.

@cameel
Copy link
Member

cameel commented Oct 27, 2021

Thanks for the report!

Simpler repro:

{
    printf '// SPDX-License-Identifier: '
    for i in {1..29069}; do
        printf x
    done
} | solc -

This started happening on 0.8.8. The original repro has some special chars in it and a contract but the bug seems to be specifically in the SPDX comment parsing and a very long comment is enough to trigger it. In GDB I get an enormous stack trace that just keeps printing. It's somewhere in the C++ regex library. I think it recurses too deeply. Probably the pattern we use is not very efficient and backtracks too much.

For me it starts crashing at exactly 29069 x chars in the comment. I suspect that on different machines the exact limit might be different.

@cameel cameel changed the title Segfault when running solc Extremely long SPDX comment results in a segfault Oct 27, 2021
@cameel cameel added bug 🐛 should compile without error Error is reported even though it shouldn't. Source is fine. labels Oct 27, 2021
@hrkrshnn
Copy link
Member

hrkrshnn commented Nov 1, 2021

Nice bug ;)

@ekpyron
Copy link
Member

ekpyron commented Nov 1, 2021

If it's really the regex implementation, we can consider actually pulling in and moving to https://compile-time-regular-expressions.readthedocs.io/ :-). That way we could also speed up the regex patterns in the yul optimizer (during name cleanup)...

@cameel
Copy link
Member

cameel commented Nov 1, 2021

I rather suspect catastrophic backtracking. If that's the case then it's the regex itself that's the problem and using a more efficient implementation will only make it require larger input to crash :)

We might switch to a non-backtracking engine (if there's on available) but these typically support a more limited syntax.

@Marenz
Copy link
Contributor

Marenz commented Sep 13, 2022

Possibly related or even duplicate: #13496

@cameel cameel added medium effort Default level of effort low impact Changes are not very noticeable or potential benefits are limited. nice to have We don’t see a good reason not to have it but won’t go out of our way to implement it. should have We like the idea but it’s not important enough to be a part of the roadmap. and removed nice to have We don’t see a good reason not to have it but won’t go out of our way to implement it. labels Sep 27, 2022
@NunoFilipeSantos NunoFilipeSantos added the good first issue candidate Could be a "good first issue" but something is blocking it or it has open questions. label Dec 5, 2022
@claudioantonio
Copy link

This issue was used to create a Solidity compiler bug bounty that looks for new segfault errors on v0.8.27.

@Marenz
Copy link
Contributor

Marenz commented Sep 11, 2024

Possibly already fixed by #15209

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 good first issue candidate Could be a "good first issue" but something is blocking it or it has open questions. low impact Changes are not very noticeable or potential benefits are limited. medium difficulty medium effort Default level of effort should compile without error Error is reported even though it shouldn't. Source is fine. should have We like the idea but it’s not important enough to be a part of the roadmap.
Projects
None yet
Development

No branches or pull requests

7 participants