netdev - Re: Warning when unloading the nf_conntack module (regression?)

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]

Date:	Tue, 5 Aug 2008 03:08:17 +0200 (CEST)
From:	Krzysztof Oledzki <ole@....pl>
To:	Al Viro <viro@...IV.linux.org.uk>
cc:	Arjan van de Ven <arjan@...radead.org>, netdev@...r.kernel.org,
	kaber@...sh.net
Subject: Re: Warning when unloading the nf_conntack module (regression?)



On Tue, 5 Aug 2008, Krzysztof Oledzki wrote:

>
>
> On Mon, 4 Aug 2008, Al Viro wrote:
>
>> On Mon, Aug 04, 2008 at 11:16:07PM +0200, Krzysztof Oledzki wrote:
>> 
>>> Solves partially: no more WARNING, however entries are still missing &
>>> duplicated:
>>> 
>>> # sysctl -a 2>/dev/null|grep net.netfilter
>>> net.netfilter.nf_conntrack_generic_timeout = 600
>>> net.netfilter.nf_conntrack_acct = 1
>>> net.netfilter.nf_conntrack_generic_timeout = 600
>>> net.netfilter.nf_conntrack_acct = 1
>> 
>> Very interesting.  Could you see at which point duplicates appear?  I.e.
>> in which sequence do you get registrations, at least on the level of "this
>> module is loaded first, no duplicates, this one comes after, etc."
>
> All I need to do is to load a single "nf_conntrack" module.
>
>> 	... ah, hell.  I see what's going on.  The trouble is in
>> nf_conntrack_standalone; you get a table that has _both_ net.netfilter.* 
>> and
>> net.nf_conntrack_max, which means that it's attached to unified tree at
>> net; if we already have something with net.netfilter, you've got trouble -
>> which entry net.netfilter will come from?
>
> Indeed.
>
>> _All_ this crap comes from lousy historical API; it's too much for this
>> cycle, but for .28 I'm going to clean that mess up.  For now, split that
>> table in two and register them separately.  I.e. register 
>> nf_ct_sysctl_table[]
>> at nf_net_netfilter_sysctl_path *and* remove the "netfilter" entry from
>> nf_ct_netfilter_table[].
>
> Will do. Thanks.
>
>> I'm really going down right now; will follow up after I get some sleep...
>
> Right. I'll try to prepare and test your ideas at that time. Thank you again.

Both good and bad news. The good one is with two above fixes the netfilter 
issue seems to be now solved. However, starting from the
9043476f726802f4b00c96d0c4f418dde48d1304, even with NETFILNER=n, there are 
other duplicated entries:

# find /proc/sys -type d |sort|uniq -d

/proc/sys/net/core
/proc/sys/net/ipv4/route
/proc/sys/net/ipv6
/proc/sys/net/ipv6/conf
/proc/sys/net/ipv6/conf/all
/proc/sys/net/ipv6/conf/bond0
/proc/sys/net/ipv6/conf/default
/proc/sys/net/ipv6/conf/dummy0
/proc/sys/net/ipv6/conf/eth0
/proc/sys/net/ipv6/conf/eth1
/proc/sys/net/ipv6/conf/eth2
/proc/sys/net/ipv6/conf/gre0
/proc/sys/net/ipv6/conf/ip6tnl0
/proc/sys/net/ipv6/conf/lo
/proc/sys/net/ipv6/conf/sit0
/proc/sys/net/ipv6/conf/tunl0
/proc/sys/net/ipv6/conf/vlan1
/proc/sys/net/ipv6/conf/vlan33
/proc/sys/net/ipv6/icmp
/proc/sys/net/ipv6/neigh
/proc/sys/net/ipv6/neigh/bond0
/proc/sys/net/ipv6/neigh/default
/proc/sys/net/ipv6/neigh/dummy0
/proc/sys/net/ipv6/neigh/eth0
/proc/sys/net/ipv6/neigh/eth1
/proc/sys/net/ipv6/neigh/eth2
/proc/sys/net/ipv6/neigh/gre0
/proc/sys/net/ipv6/neigh/ip6tnl0
/proc/sys/net/ipv6/neigh/lo
/proc/sys/net/ipv6/neigh/sit0
/proc/sys/net/ipv6/neigh/tunl0
/proc/sys/net/ipv6/neigh/vlan1
/proc/sys/net/ipv6/neigh/vlan33
/proc/sys/net/ipv6/route

Best regards,

 			Krzysztof Olędzki