netfilter buglog - Jun 2003 - [Bug 91] conntrack unload loops forever (reproducible)

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=91





------- Additional Comments From kaber@trash.net  2003-06-16 00:38 -------
problem seems to be a dropped reference in remove_expectations, can be
reproduced by
unloading ip_conntrack after unloading a helper which is helping a connection.
Attached patch fixes my problems.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=91





------- Additional Comments From kaber@trash.net  2003-06-16 00:40 -------
Created an attachment (id=27)
drop refcnt of master conntrack for confirmed expectations in
remove_expectations


------- Additional Comments From laforge@netfilter.org  2003-06-24 20:04 -------
fix is now in pending patches, will submit it with the next couple of patches to
davem.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=91





------- Additional Comments From francesco@unipg.it  2003-06-27 16:32 -------
Created an attachment (id=28)
infinite loop fix


------- Additional Comments From francesco@unipg.it  2003-06-27 16:44 -------
The infinite loop were caused by the 'exp->expectant = NULL'
assignment; first
i've tried the patch posted by Patrick but on my system it has caused a
kernel
hang-up. With the patch i've posted, the problem seems to be fixed. I wonder
who added that assignment, and why... (in the 2.4.20 wasn't present, the 
remove_expectations() worked fine, and the code was about the same)   



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=91





------- Additional Comments From kaber@trash.net  2003-06-27 16:58 -------
it crashed your kernel ? i'm wondering because we have this patch running on
a
couple hundred of boxes without problems so far. firewall restart with module
unload/load happens rather frequent. which kernel-version did you use and were
there other patches applied ?



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=91





------- Additional Comments From gandalf@wlug.westbo.se  2003-06-27 18:11
-------
I added that part of the code.
It's one part of the use-after-free fix which caused memory-corruption.

I must have forgotten to add the ip_conntrack_put(exp->expectant) which
Patrick added with his patch.




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=91





------- Additional Comments From francesco@unipg.it  2003-06-27 23:50 -------
My kernel version is 2.4.21. The patches applied are h323 conntrack/nat and 
bridge-nf. I don't know if the crash is related to Patrick patch, but when
i've
removed the line of code the kernel has worked again.
However, if in remove_expectations we must skip the assured expectations, i see 
no reason to set the expectant pointer to NULL. When remove_exp is called from 
the unhelp function, we must remove only the unassured expectations, while the 
assured ones must continue to exist and they must continue to refer to a valid 
master conntrack.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=91





------- Additional Comments From gandalf@wlug.westbo.se  2003-06-28 09:47
-------
Created an attachment (id=29)
Fix unhelp


------- Additional Comments From gandalf@wlug.westbo.se  2003-06-28 09:48
-------
By removing the exp->expectant = NULL line you've introduced a
memory-corruption
again.
The real fix should be something like the patch I've attached, it's
incremental
to Patricks first attachment to this bug. It's uncompiled/untested and I
just
woke up so handle with care.




------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=91





------- Additional Comments From francesco@unipg.it  2003-06-30 11:03 -------
I'm trying the last Martin patch and it seems to work correctly...  I had no
time for look at the  code so i've a question: when (and where) the
mem-corruption you mention happens?



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=91

laforge@netfilter.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|laforge@netfilter.org       |gandalf@netfilter.org
             Status|ASSIGNED                    |NEW



------- Additional Comments From laforge@netfilter.org  2003-06-30 16:58 -------
martin: can you please rename 'flag' into something more obvious like
'drop_refcount' and put the patch in patch-o-matic so I can include it
with my
next patchet I'll submit to davem?

thanks.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=91

gandalf@netfilter.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From gandalf@netfilter.org  2003-06-30 18:24 -------
Renamed and put into pending in p-o-m.

Not attached here again since it was just a simple rename of a variable.

Resolving bug, please feel free to reopen if problem still persists.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.