Red Hat Bugzilla – Bug 157849
CVE-2005-3274 IPVS panic at ip_vs_conn_flush() when unloading ip_vs module
Last modified: 2007-11-30 17:07:07 EST
Escalated to Bugzilla from IssueTracker
Reassigning to DaveM.
Dave M. and Peter S. requested that I finish up the work on this bug. I'll get the smoke tested patch posted here asap.
Created attachment 115883 [details] patch to prevent unlocking in the middle of list traversal I know previously I thought that the second egenera patch was the right thing to do, but now after looking more closely at it, I think the first idea is probably the better way to go. The problem comes down to the fact that you release the spinlock that protects the list while you still have outstanding work to do regarding the reading of its prev and next pointers (via the for loop). As such, when we re-aquire the lock, we need to reset our loop counter so that it starts at the beginning of the list again (to ensure that our prev and next pointers aren't corrupt). The second suggested fix that I initially thought was good now worries me a bit, because it tries to accomplish the same thing in a less reliable manner. By increasing the ref count on the next pointer we can prevent the current elements next pointer from becomming corrupt, but its still possible (although far less likely) that the next->next entry might get freed, and race with the ip_vs_conn_flush loop. My point is I don't think the second solution is really a complete fix. We need to provide mutual exclusion to _all_ list modifications and accesses. That means either resetting the entry pointer to the start of the loop, or to just not unlock the loop. Since we're waiting on the list to be flushed here, this boils down to waiting for each element to flush individually (by re-expiring the same cp entry using the list reset method ) waiting for each to finish, or by holding the lock, until each expiration is requested, and then rescanning the list looking for stragglers to re-expire (the mutex holding method). The Latter seems less prone to errors to me. It looks like this needs to go upstream as well, so I'll post this there first, and if there isn't any push-back on it, I'll push it here for RHEL3/4.
Created attachment 115935 [details] new patch to prevent ipvs race I've gotten some upstream feedback, and this is the variant of the patch that is getting some traction currently.
Created attachment 116070 [details] upstream backport of ipvs fix Upstream backport to RHEL3 of ipvs patch
Created attachment 116081 [details] correct upstream backport patch Sorry, posted the wrong patch previously. This is the correct one.
A fix for this problem has just been committed to the RHEL3 U6 patch pool this evening (in kernel version 2.4.21-32.10.EL).
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-663.html