CVE-2026-43233

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

netfilter: nf_conntrack_h323: fix OOB read in decode_choice()

In decode_choice(), the boundary check before get_len() 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

nf_h323_error_boundary(bs, 0, 0) evaluates to (bs->cur + 0 > bs->end),

which is false. The subsequent get_len() 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 nf_conntrack_h323 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 get_len() may read)

instead of the uninitialized `len`. This matches the pattern used at

every other get_len() call site in the same file, where the caller

checks for 2 bytes of available data before calling get_len().