CVE-2026-43233

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_conntrack_h323: fix OOB read in decode_choice()<br /> <br /> In decode_choice(), the boundary check before get_len() uses the<br /> variable `len`, which is still 0 from its initialization at the top of<br /> the function:<br /> <br /> unsigned int type, ext, len = 0;<br /> ...<br /> if (ext || (son-&gt;attr &amp; OPEN)) {<br /> BYTE_ALIGN(bs);<br /> if (nf_h323_error_boundary(bs, len, 0)) /* len is 0 here */<br /> return H323_ERROR_BOUND;<br /> len = get_len(bs); /* OOB read */<br /> <br /> When the bitstream is exactly consumed (bs-&gt;cur == bs-&gt;end), the check<br /> nf_h323_error_boundary(bs, 0, 0) evaluates to (bs-&gt;cur + 0 &gt; bs-&gt;end),<br /> which is false. The subsequent get_len() call then dereferences<br /> *bs-&gt;cur++, reading 1 byte past the end of the buffer. If that byte<br /> has bit 7 set, get_len() reads a second byte as well.<br /> <br /> This can be triggered remotely by sending a crafted Q.931 SETUP message<br /> with a User-User Information Element containing exactly 2 bytes of<br /> PER-encoded data ({0x08, 0x00}) to port 1720 through a firewall with<br /> the nf_conntrack_h323 helper active. The decoder fully consumes the<br /> PER buffer before reaching this code path, resulting in a 1-2 byte<br /> heap-buffer-overflow read confirmed by AddressSanitizer.<br /> <br /> Fix this by checking for 2 bytes (the maximum that get_len() may read)<br /> instead of the uninitialized `len`. This matches the pattern used at<br /> every other get_len() call site in the same file, where the caller<br /> checks for 2 bytes of available data before calling get_len().