Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 15 Mar 2013 17:51:54 +0100
From: "Costin Enache" <>
To: <>
Subject: err in rules processor and dirty fix [rules.c]

Ugly thing in the rule processor, when the rules are using \xHH
representation and the rule line size exceeds 0x100; this is only my
particular case, it can generate errors in many other ways.


The (params.h) RULE_BUFFER_SIZE is used for the rule pre-processor output,
as defined in rpp.h:

/* Current rule after preprocessing */

        char output[RULE_BUFFER_SIZE];


The same RULE_BUFFER_SIZE is used in rules.c in rules_reject:

char *rules_reject(char *rule, int split, char *last, struct db_main *db)


        static char out_rule[RULE_BUFFER_SIZE];


The rules_reject function is called for unprocessed data, as it comes from
the config file, for example to remote duplicate rules


The unprocessed data can easily be over 0x100, such as in my unfortunate
case, when using \xHH for a long character list. In this case the remove
duplicates function will only compare the first 0x100 bytes of the rules -
dumping all the rules which begin with the same 0x100 bytes.


Quick and dumb fix, not sure that it is 100% ok and what else it breaks, but
it solves my hex encoding problem:


--- rules.c.orig        2013-03-15 17:34:14.000000000 +0100

+++ rules.c     2013-03-15 17:34:22.000000000 +0100

@@ -701,7 +701,7 @@

 char *rules_reject(char *rule, int split, char *last, struct db_main *db)


-       static char out_rule[RULE_BUFFER_SIZE];

+       static char out_rule[4*RULE_BUFFER_SIZE];

        while (RULE)

        switch (LAST) {






Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.