Fix null byte handling in string literals

[richardwooding]

Description

Fuzzing discovered that CEL string literals containing null bytes (\x00) generate PostgreSQL SQL with unescaped null bytes. This is a security and correctness issue as null bytes can terminate strings unexpectedly in C-based PostgreSQL internals.

Example

Input CEL expression:

name == "\x00"

Current SQL output:

name = '�'  -- Contains literal null byte

Expected behavior:
Either:

1. Escape the null byte: name = E'\\x00' (using PostgreSQL hex escaping)
2. Reject with error: Return an error message like "string literals cannot contain null bytes"

Reproduction

The crash case is preserved in the fuzz corpus:

testdata/fuzz/FuzzConvert/299bc76ba66bca6b

Run the fuzz regression test:

go test -v -run=FuzzConvert/299bc76ba66bca6b

Impact

• Security: Potential for unexpected SQL behavior
• Correctness: Generated SQL may not execute as intended
• Data integrity: Null bytes can corrupt string comparisons

Suggested Fix

Add null byte detection in cel2sql.go when processing string constants:

func (con *converter) visitConst(expr *exprpb.Expr) error {
    // ... existing code ...
    case *exprpb.Constant_StringValue:
        strVal := constant.GetStringValue()
        if strings.Contains(strVal, "\x00") {
            return errors.New("string literals cannot contain null bytes")
        }
        // ... rest of escaping logic ...
    }
}

Or implement proper escaping using PostgreSQL's E'...' syntax with hex encoding.

Context

This bug was discovered during the implementation of comprehensive fuzzing. The fuzzer found this issue within 2 seconds of execution, demonstrating the value of fuzz testing for security-critical string processing code.

Related

• Test case: testdata/fuzz/FuzzConvert/299bc76ba66bca6b
• Discovered via: FuzzConvert test