Re: netfilter: nf_conntrack_irc: port truncation via simple_strtoul to u16 enables NAT pinhole

[Willy Tarreau <w@1wt.eu>]

On Thu, Apr 30, 2026 at 05:25:42PM +0200, Pablo Neira Ayuso wrote:
> On Thu, Apr 30, 2026 at 05:23:11PM +0200, Pablo Neira Ayuso wrote:
> > Cc'ing netfilter-devel@
> > 
> > On Thu, Apr 30, 2026 at 03:00:20PM +0000, rc wrote:
> > > hey,
> > >  
> > > I would like to report the above security issue:
> > >  
> > >  
> > >  Affected versions: all kernels with net/netfilter/nf_conntrack_irc.c 
> > > (verified present in 7.1.0-rc1 mainline, code unchanged since initial
> > > implementation)
> > >  
> > >  
> > > Description
> > > -----------
> > >  
> > >  
> > > parse_dcc() in nf_conntrack_irc.c stores the return value of
> > > simple_strtoul() directly into a u_int16_t pointer (line 96):
> > >  
> > >  
> > >  *port = simple_strtoul(data, &data, 10);
> > >  
> > >  
> > > simple_strtoul() returns unsigned long. When the attacker-controlled
> > > port string in a DCC command exceeds 65535, the value silently
> > > truncates to u16. For example:
> > >  
> > >  
> > >  65558 -> u16 = 22 (SSH)
> > >  131094 -> u16 = 22 (SSH)
> > >  65536 -> u16 = 0
> > >
> > > An attacker on an IRC channel can send a crafted DCC SEND message
> > > through a Linux NAT gateway running the nf_conntrack_irc helper. The
> > > helper parses the port, truncates it, and opens a NAT pinhole
> > > (via nf_nat_irc) for the truncated port on the internal host. This
> > > bypasses the firewall/NAT to expose arbitrary services (SSH, HTTP,
> > > database ports) on internal hosts.
> > 
> > You don't need truncation to open a port via conntrack helper with an
> > expectation.
> > 
> > Tighening the conntrack helper parser is fine, this is net-next
> > material:
> > 
> > 0) There is a document by Eric Leblond already explaining the
> >    situation with conntrack helpers, which is old.
> > 1) Helper are disabled by default, you have to enable them explicitly
> >    via ruleset, for some time already.
> > 
> > Thanks for your report.
> 
> Having said this, patches are welcome for consideration, this is a
> project run by volunteers, that is the best way you can contribute.

Rahul, could you please turn your proposed fix into a regular patch ready
to be applied as per Documentation/process/submitting-patches.rst ? This
will save some maintainers' time and is the best way for you to be credited
for finding and fixing this bug, if accepted.

Thanks,
Willy