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
Question concerning CVE-2019-17543 #801
Comments
|
This is a relatively hard to trigger bug. Yes, it has been in the lurking for a long time, but the conditions required to trigger it are not trivial. Actually, in most systems, including the Note that the CLI is immune to this bug, as it does not present the required constraints to be exposed, hence the suggested reproduction command We invite all users of LZ4 to upgrade to v1.9.2, to reduce exposure to risks, but the risk is low : specifically, the |
|
Thanks for the answer, that clarifies why the reproduce does not work in my test case! |
Hi,
I am looking into CVE-2019-17543 [0][1], specifically I am trying to verify if the issue is present since 2014 as stated in the comment [2].
I am testing lz4 version 1.8 and tried to reproduce the issue using an asan build. The command used to reproduce was 'lz4 -1 -l reproducer outfile'.
Verified that libasan.so was used by lz4 and liblz4.so.1.8.0, verified that the correct liblz4 library is used and that the reproduce is the correct. But still do not see a problem with the old version(v1.8.0).
It would be great if someone could provide some feedback/background concerning the statement, that the problem is present since 2014.
Please note that I used a patch for lz4 which forces the lz4 binary to use the shared library instead of inlining all the LZ4_* functions. But I think that should not cause any problems.
[0] #756
[1] http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2019-17543
[2] https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=15941#c1
The text was updated successfully, but these errors were encountered: