Re: [PATCH nf] netfilter: nf_nat: do not reuse an unexpected expectation on RTCP clash

Greg KH <[email protected]>
Newsgroups gmane.comp.security.firewalls.netfilter.devel
Message-ID <2026071210-grid-runaround-4318@gregkh>
On Sun, Jul 12, 2026 at 10:08:16AM +0200, Florian Westphal wrote:
> Greg KH <[email protected]> wrote:
> > > This is no different than the WARNs on list corruption or refcount
> > > under/overflows.
> > 
> > True, but adding new ones is not a good idea, and removing the existing
> > ones is a good idea.
> 
> We're fucked, then.  Can we at least use DEBUG_NET_WARN or something
> like that so at least fizzers can give us hints about bugs?!

That's up to you.  If panic_on_warn wasn't an option, about half of the
kernel CVEs would disappear tomorrow.

> > > Would you propose to remove those?  I hope not, they help catch bugs.
> > 
> > Bugs that userspace can trigger?  If so, then properly catch them by
> > testing and handling the issue.
> 
> Aka "Don't write buggy code".  Should have thought of that.

No, I'm not saying that, I'm saying that if this is something that could
possibly happen, then let's catch that with a real check.

> > If userspace can never trigger it, then
> > it's not really needed as the code is never going to trigger.
> 
> It causes memory corruption and evidently triggers.
> 
> With "silently catch error" and no WARN there will be rare,
> intermittent connectivity issues.
> 
> We are NOT in a syscall, there is no process to return
> a meaningful error code to.

It's up to you, if you really want WARN_ON(), that's fine, but realize
that if it can be triggered, it will require a round of fixing as it can
take down systems.

thanks,

greg k-h
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.