CVE-2026-43233

What it actually does

This flaw is an out-of-bounds read in the Linux kernel H.323 connection-tracking helper, nf_conntrack_h323. A remote unauthenticated sender can trigger the bug by sending a crafted H.323/Q.931 SETUP message to TCP port 1720 through a Linux firewall or gateway where the H.323 conntrack helper is active. The parser incorrectly checks for zero remaining bytes before reading a length field, allowing a 1–2 byte read past the end of a heap buffer. The most likely technical outcome is kernel memory-safety fault, warning, oops, panic, or denial of service; the CVSS vector also reflects limited confidentiality exposure from a small out-of-bounds read. There is no indication from the provided data that reliable remote code execution is available.

Why it matters to the business

Systems using Linux-based firewalls, routers, gateways, or hosts that inspect H.323 traffic may be remotely disrupted by a single malformed network message, potentially interrupting voice/video services or causing firewall instability. Exposure is configuration-dependent: Linux is widely deployed, but this issue requires the nf_conntrack_h323 helper to be active or invoked for H.323 traffic. The vulnerability is not listed in CISA KEV, is not identified as ransomware-used, has low EPSS likelihood, and has no reported exploit maturity in the provided data, so prioritization should focus on internet-facing or untrusted-network devices that allow or inspect TCP/1720 traffic.

How an attack unfolds

An attacker identifies a Linux firewall, gateway, or host that allows H.323 signaling on TCP port 1720 and has the nf_conntrack_h323 helper enabled. The attacker opens or sends traffic toward TCP/1720 and includes a malformed Q.931 SETUP message with a User-User Information Element containing a minimal PER-encoded payload that causes the H.323 decoder to consume the bitstream exactly. When the vulnerable decoder reaches decode_choice(), it performs an ineffective boundary check using a zero length, then calls get_len(), which reads one or two bytes beyond the end of the allocated buffer. Depending on kernel build, memory layout, and hardening, this can produce no visible symptom, a kernel warning, a KASAN/KFENCE report, an oops, or a crash/panic. Repeated attempts can be used to degrade availability of affected network security or routing infrastructure.

How to fix it

Upgrade the Linux kernel to a vendor-supported release that includes the nf_conntrack_h323 decode_choice() boundary-check fix. Because no exact fixed versions were provided, use the distribution or appliance vendor advisory for the specific kernel stream in use. Where immediate patching is not possible, reduce exposure by disabling the H.323 conntrack/NAT helpers if they are not required, for example by unloading or blacklisting nf_conntrack_h323 and nf_nat_h323 where operationally safe. Disable automatic conntrack helper assignment where applicable, such as net.netfilter.nf_conntrack_helper=0, and remove explicit iptables/nftables CT helper rules for H.323 if not needed. Restrict TCP/1720 to trusted sources only, block unsolicited H.323 signaling from untrusted networks, and place compensating controls upstream of Linux systems that must continue handling H.323 traffic. Validate operational impact before disabling the helper, because some legacy H.323 voice/video and NAT traversal workflows may depend on it.

How to confirm the fix worked

Confirm exposure by checking whether the running kernel is from a vendor release that contains the fix and whether nf_conntrack_h323 or nf_nat_h323 is loaded or configured. Review lsmod, modprobe configuration, sysctl net.netfilter.nf_conntrack_helper, and firewall rules for explicit CT helper use with H.323. Confirm that untrusted networks cannot reach TCP/1720 unless required. After patching or mitigation, verify the running kernel has been rebooted into the fixed version, the vulnerable helper is no longer loaded if disabled, and firewall policy blocks or restricts H.323 as intended. In test environments only, a controlled H.323 malformed-packet regression test should no longer produce kernel warnings, KASAN reports, oopses, or crashes.

Typical attack path

1. Discover or assume a Linux-based firewall, router, gateway, or host is processing H.323 traffic on TCP port 1720.
2. Send a crafted Q.931 SETUP message containing a User-User Information Element with malformed or minimal PER-encoded data.
3. Cause the nf_conntrack_h323 helper to parse the message while tracking the connection.
4. Trigger the flawed decode_choice() boundary check and force get_len() to read past the end of the H.323 parsing buffer.
5. Observe whether the target drops traffic, logs a kernel memory error, resets, panics, or becomes temporarily unavailable.
6. Repeat the traffic to cause sustained denial of service if the system is vulnerable and reachable.

How to detect it

To assess possible prior exploitation, correlate network telemetry for inbound or transit TCP/1720 H.323/Q.931 SETUP traffic with kernel instability events. Useful sources include firewall accept/drop logs, NetFlow/IPFIX, IDS packet metadata, packet captures, systemd journal, /var/log/kern.log, /var/log/messages, /var/log/syslog, crash dumps, kdump/vmcore records, and kernel panic/oops reports. Look for short or malformed H.323 User-User Information Elements, repeated SETUP messages, connection attempts from unusual external sources, and any kernel memory-safety reports around the same timestamp. On hardened or debug kernels, search for KASAN, KFENCE, BUG, WARNING, slab, or heap-buffer-overflow messages referencing nf_conntrack_h323, decode_choice(), or get_len(). On production kernels without memory sanitizers, evidence may be limited to unexplained reboots, watchdog resets, soft lockups, kernel oopses, or firewall failover events shortly after TCP/1720 traffic. Absence of logs does not prove absence of exploitation, because the trigger may cause an immediate crash before full logging is flushed.

• TCP/1720
• port 1720
• H.323
• Q.931 SETUP
• User-User Information Element
• nf_conntrack_h323
• nf_nat_h323
• decode_choice
• get_len
• heap-buffer-overflow
• KASAN
• KFENCE
• BUG: KASAN
• kernel BUG
• Oops
• Kernel panic
• general protection fault
• slab-out-of-bounds
• nf_conntrack_helper
• net.netfilter.nf_conntrack_helper
• nf_conntrack_h323.ko
• nf_nat_h323.ko

What your security team should do

• Prioritize internet-facing Linux firewalls, routers, SBC-adjacent gateways, and hosts that allow or inspect TCP/1720 H.323 traffic.
• Patch affected Linux kernels using the appropriate distribution or appliance vendor update, then reboot into the fixed kernel.
• If H.323 is not required, disable nf_conntrack_h323 and nf_nat_h323 and block TCP/1720 at network boundaries.
• If H.323 is required, restrict TCP/1720 to trusted peers and monitor closely until patching is complete.
• Audit firewall rules for explicit H.323 CT helper assignments and remove unnecessary helper use.
• Search recent kernel logs and network telemetry for crashes or malformed H.323 traffic targeting TCP/1720.
• Add SIEM detections for kernel oops/panic/KASAN messages referencing nf_conntrack_h323, decode_choice, or get_len near TCP/1720 activity.
• Track vendor advisories because exact fixed package versions vary by distribution and kernel branch.