Integer Truncation in h_token Allows Parser Bypass (/src/parsers/token.c)

[zwrh]

An integer truncation vulnerability exists in the Hammer parser library's h_token implementation located in:
/src/parsers/token.c

The function accepts a size_t length parameter but stores it in a uint8_t field inside the HToken structure. This truncates values larger than 255 bytes, creating a mismatch between the copied buffer size and the stored token length. This can allow an attacker to bypass parser token validation.

The vulnerable structures and functions:

typedef struct {
    uint8_t *str;
    uint8_t len;
} HToken;
...
HParser *h_token(const uint8_t *str, const size_t len) {
    return h_token__m(&system_allocator, str, len);
}

HParser *h_token__m(HAllocator *mm__, const uint8_t *str, const size_t len) {
    HToken *t = h_new(HToken, 1);
    uint8_t *str_cpy = h_new(uint8_t, len);
    memcpy(str_cpy, str, len);
    t->str = str_cpy, t->len = len; // truncated when assigned to uint8_t
    return h_new_parser(mm__, &token_vt, t);
}

The function accepts a size_t len parameter but stores it in a uint8_t:

• size_t len → uint8_t len
• If len > 255, the value is truncated: t->len = len % 256

However, the memcpy copies the full len bytes, creating inconsistent behavior between the stored token length and the actual allocated token buffer.

This mismatch can allow Token validation bypass, unexpected parser matches, incorrect parsing logic, and malformed inputs being accepted as valid tokens. If Hammer is used for protocol validation, input filtering, or security-sensitive parsing, this could allow invalid data to bypass parser rules.

Proof of Concept

#include <hammer/hammer.h>
#include <stdio.h>
#include <string.h>

int main(void) {
    uint8_t expected[256];

    memset(expected, 0x41, 256);

    HParser *parser = h_token(expected, 256);

    // Input clearly does not match expected token
    HParseResult *result = h_parse(parser, (uint8_t*)"Hello!", 0);

    if (result) {
        printf("bypassed!\n");
        h_parse_result_free(result);
    }

    return 0;
}

Expected Behavior:
The parser should reject "Hello!".

Actual Behavior:
The parser accepts the input due to the truncated token length.

Suggested Fix:
Use a larger integer type for the token length:

typedef struct {
    uint8_t *str;
    size_t len;
} HToken;

Researchers credited with discovering this issue:
Tyler Waddell
Ardian Peach
Muhammad Ali
Anthony Marrongelli

[melbasiouny-riverside]

Fixed this issue in PR#5 and released in v1.1.2.

[prashantbarca]

Hey folks, I just encountered the same bug and want to push back on the fix. The fix is essentially adding an assert, an abort, and a typecast. On servers, this is like a denial-of-service attack if the string is somehow attacker-controlled.

I think a much better fix would be to change the type of this field from uint8_t to size_t. That way, you would not need to restrict token fields to 255 bytes.

The larger issue is that the same pattern applies to the h_bits function as well.

    uint8_t input[64];
    memset(input, 0xFF, 64);

    /* h_bits(264, false) wraps to h_bits(8, false) */
    HParser *p264 = h_bits(264, false);
    HParseResult *r264 = h_parse(p264, input, 64);

    printf("h_bits(264, false): uint = %lu  (BUG -264 mod 256 = 8, reads 1 byte)\n",
           r264 ? (unsigned long)r264->ast->uint : 0);
    if (r264) h_parse_result_free(r264);

    /* h_bits(256, false) wraps to h_bits(0, false) */
    HParser *p256 = h_bits(256, false);
    HParseResult *r256 = h_parse(p256, input, 64);

    printf("h_bits(256, false): uint = %lu  (BUG - 256 mod 256 = 0, reads 0 bits)\n",
           r256 ? (unsigned long)r256->ast->uint : 0);
    if (r256) h_parse_result_free(r256);

Output:

h_bits(264, false): uint = 255  (BUG — 264 mod 256 = 8, reads 1 byte)
h_bits(256, false): uint = 0  (BUG — 256 mod 256 = 0, reads 0 bits)

[melbasiouny-riverside]

Thanks for the feedback. After further review, we want to share our findings and explain the direction we're taking.

The DoS concern, while worth raising, we believe does not apply here. The h_token function is called at grammar construction time with programmer-supplied literals, not at parse time with user-controlled data. Passing a token longer than 255 bytes represents a programming error at the call site, and asserting on programming errors is standard and appropriate practice. The attacker-controlled data path runs through h_parse, not h_token.

That said, we agree that increasing the len field is the right long-term fix, and we're moving forward with that approach. Our initial hesitation was twofold: we saw no practical use case for tokens exceeding 255 bytes, and we had concerns about memory overhead given how quickly state scales in the Packrat backend. On revisiting the struct layout, however, we recognize that due to alignment padding on most targets, increasing len to size_t does not increase the size of HToken in practice; the trailing struct padding already accounts for the difference.

We will be applying the same analysis to the other affected parsers before finalizing the fix.