richox / libzling

fast and niubility compression library.
88 stars 20 forks source link

encoding crash #11

Open inikep opened 8 years ago

inikep commented 8 years ago

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

jibsen commented 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;
 }
inikep commented 8 years ago

Your patch works but I wonder now if zling has more problems.

nemequ commented 8 years ago

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).

richox commented 8 years ago

@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:)

nemequ commented 8 years ago

I'll let it run for a while

55+ million execs later, no crashes. Encoder is probably pretty safe (at least on x86_64).

inikep commented 8 years ago

Good to know, thanks Evan.