CVE-2026-80603: netfilter: nf_conntrack_irc: fix parse_dcc() off-by-one OOB read
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nfconntrackirc: fix parsedcc() off-by-one OOB read
parsedcc() treats dataend as an inclusive end pointer, but its only caller passes datalimit = ibptr + datalen, which points one past the last valid byte.
The newline search loop iterates while tmp <= dataend, so when no newline is present, tmp is read at tmp == dataend, one byte beyond the region filled by skbheaderpointer().
ircbuffer is kmalloc'd as MAXSEARCHSIZE + 1 bytes and datalen is capped at MAXSEARCHSIZE, so the stray read does not fault. The byte is uninitialized or stale; if it contains an ASCII digit, simplestrtoul will consume it and produce a wrong DCC IP or port in the conntrack expectation. The extra allocation byte is also a fragile guard: if the cap or allocation size changes, this becomes a real out-of-bounds read.
Change the loop and its post-loop check to use strict less-than, consistent with the caller's exclusive-end convention. Update the function comment accordingly.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Configuration
Update the byte newline search loop and its post-loop check in nf_conntrack_irc::parse_dcc() to use strict less-than so that *tmp is never read when tmp == data_end (one byte past the skb_header_pointer() filled region). Also update the function comment accordingly to match the caller's exclusive-end convention.
Linux kernel netfilter (nf_conntrack_irc) / parse_dcc() Loop condition and post-loop check = Use strict less-than (tmp < data_end) instead of tmp <= data_end
Event History
Frequently Asked Questions
What traffic must be present for this issue to be reachable?
The affected code is the IRC conntrack helper's DCC parser, so reachability depends on IRC traffic being processed by nf_conntrack_irc and containing a DCC field whose searched data has no newline before the supplied data limit.
What is the practical effect of the out-of-bounds read in the described implementation?
The read is one byte past the region populated by skb_header_pointer(). Because the buffer has an extra allocated byte and input is capped at MAX_SEARCH_SIZE, it does not fault in the described configuration, but stale or uninitialized data that is an ASCII digit can be incorporated into the parsed DCC IP address or port and create an incorrect conntrack expectation.
Is this described as an immediately crashing out-of-bounds read?
No. The description states that the extra allocated byte prevents a fault under the current allocation and size cap, although it is a fragile guard and could become a real out-of-bounds read if those limits change.
What change resolves the issue?
The fix changes the newline-search loop and its post-loop check to use strict less-than comparisons, matching the caller's exclusive end-pointer convention.