Open inikep opened 8 years ago
From a quick look at the code, I am guessing:
diff --git a/libzling/libzling_lz.cpp b/libzling/libzling_lz.cpp
index 336adf6..3cc7f93 100644
--- a/libzling/libzling_lz.cpp
+++ b/libzling/libzling_lz.cpp
@@ -294,6 +294,9 @@ int inline ZlingRolzEncoder::MatchLazy(unsigned char* buf, int pos, int maxlen,
return 1;
}
node = bucket->suffix[node];
+ if (node == 65535) {
+ break;
+ }
}
return 0;
}
Your patch works but I wonder now if zling has more problems.
Your patch works but I wonder now if zling has more problems.
I'm fuzzing the encoder now, with @jibsen's patch applied. It's absurdly slow, but I'll let it run for a while.
For the decoder, I ran AFL for several days; enough to complete several cycles. Obviously I can't say for certain that it's safe, but I'm pretty comfortable with it, at least with current compilers (there are lots of unaligned stores/loads which may well break with future compilers and/or other architectures).
@jibsen thanks for the patch, i will apply it as soon as possible @inikep using libzling in a production environment is not a good idea:)
I'll let it run for a while
55+ million execs later, no crashes. Encoder is probably pretty safe (at least on x86_64).
Good to know, thanks Evan.
I've included the newest commit of libzling (ee058fad67d83550f268bfc50ee7824edc74fda2) to lzbench and now I have crash during encoding at level 2 with my "win81" file (https://docs.google.com/uc?id=0BwX7d...xport=download).
If you are not able to generate the bug you can use "lzbench.exe -v9 -ezling win81" compiled from: https://github.com/inikep/lzbench/commits/dev