CVE-2026-80603

The Linux kernel's netfilter nf_conntrack_irc module contains an off-by-one out-of-bounds read in parse_dcc(), which treats the buffer end pointer as inclusive while its caller passes an exclusive limit (ib_ptr + datalen), causing one byte beyond the packet data copied via skb_header_pointer() to be read. The bug is triggered when the IRC conntrack helper parses an IRC DCC command whose data contains no trailing newline, so the newline-search loop reads at the position one past the last valid byte; that byte is uninitialized or stale kernel memory. If the stray byte happens to be an ASCII digit, simple_strtoul consumes it and produces a wrong DCC IP address or port in the conntrack expectation, so an attacker sending IRC traffic through an affected host can corrupt NAT/conntrack handling of DCC transfers; the overread itself cannot fault because the buffer is allocated with one extra byte. Only Linux systems where the nf_conntrack_irc helper is loaded and processing IRC traffic are affected in practice, which typically means firewalls or NAT gateways with the IRC helper enabled. No public proof-of-concept is known, the flaw is not in CISA's KEV catalog, and EPSS estimates a 0.4% chance of exploitation in the next 30 days.

What to do: Apply your distribution's kernel update once it includes the nf_conntrack_irc fix (the upstream change switches the parse loop to strict less-than bounds). In the meantime, check whether the helper is in use (e.g., 'lsmod | grep nf_conntrack_irc' and inspect iptables/nftables rules for the IRC helper, plus the nf_conntrack_helper auto-assignment sysctl); if it is not needed, unload the module or disable IRC helper handling on unpatched kernels. No exploit code is required for remediation, and no workarounds beyond disabling the helper are documented.