netdev - Re: [PATCH V2] netfilter: nf_conntrack: table full detailed log

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aILH9Z_C3V7BH6of@strlen.de>
Date: Fri, 25 Jul 2025 01:55:33 +0200
From: Florian Westphal <fw@...len.de>
To: Pablo Neira Ayuso <pablo@...filter.org>
Cc: lvxiafei <xiafei_xupt@....com>, coreteam@...filter.org,
	davem@...emloft.net, edumazet@...gle.com, horms@...nel.org,
	kadlec@...filter.org, kuba@...nel.org, linux-kernel@...r.kernel.org,
	lvxiafei@...setime.com, netdev@...r.kernel.org,
	netfilter-devel@...r.kernel.org, pabeni@...hat.com
Subject: Re: [PATCH V2] netfilter: nf_conntrack: table full detailed log

Pablo Neira Ayuso <pablo@...filter.org> wrote:
> I was thinking, does the packet logging exposes already the
> net->ns.inum? IIUC the goal is to find what netns is dropping what
> packet and the reason for the packet drop, not only in this case but
> in every case, to ease finding the needle in the stack. If so, then it
> probably makes sense to consolidate this around nf_log()
> infrastructure.

No, it doesn't.  It also depends on the backend:
for syslog, nothing will be logged unless nf_log_all_netns sysctl is
enabled.

For nflog, it is logged, to the relevant namespaces ulogd, or not in
case that netns doesn't have ulogd running.

For syslog one could extend nf_log_dump_packet_common() but I'm not sure
how forgiving existing log parsers are when this gets additional
field.

Also, would (in case we use this for the "table full" condition), should
this log unconditionally or does it need a new sysctl?

Does it need auto-ratelimit (probably yes, its called during packet
flood so we dont want to flood syslog/ulog)?

> Anyway, maybe I'm overdoing, I'll be fine with this approach if you
> consider it good enough to improve the situation.

I think its better than current state of affairs since it at least
allows to figure out which netns is experiencing this.