CVE-2026-43233

In the Linux kernel, the following vulnerability has been resolved:

netfilter: nfconntrackh323: fix OOB read in decode_choice()

In decodechoice(), the boundary check before getlen() uses the variable len, which is still 0 from its initialization at the top of the function:

unsigned int type, ext, len = 0;
...
if (ext || (son->attr & OPEN)) {
    BYTE_ALIGN(bs);
    if (nf_h323_error_boundary(bs, len, 0))  /* len is 0 here */
        return H323_ERROR_BOUND;
    len = get_len(bs);                        /* OOB read */

When the bitstream is exactly consumed (bs->cur == bs->end), the check nfh323errorboundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end), which is false. The subsequent getlen() call then dereferences *bs->cur++, reading 1 byte past the end of the buffer. If that byte has bit 7 set, get_len() reads a second byte as well.

This can be triggered remotely by sending a crafted Q.931 SETUP message with a User-User Information Element containing exactly 2 bytes of PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with the nfconntrackh323 helper active. The decoder fully consumes the PER buffer before reaching this code path, resulting in a 1-2 byte heap-buffer-overflow read confirmed by AddressSanitizer.

Fix this by checking for 2 bytes (the maximum that getlen() may read) instead of the uninitialized len. This matches the pattern used at every other getlen() call site in the same file, where the caller checks for 2 bytes of available data before calling get_len().