From nobody@FreeBSD.org  Tue Feb 27 12:26:50 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id B5AB837B718
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 27 Feb 2001 12:26:50 -0800 (PST)
	(envelope-from nobody@FreeBSD.org)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f1RKQoS35094;
	Tue, 27 Feb 2001 12:26:50 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200102272026.f1RKQoS35094@freefall.freebsd.org>
Date: Tue, 27 Feb 2001 12:26:50 -0800 (PST)
From: msmith@netapp.com
To: freebsd-gnats-submit@FreeBSD.org
Subject: route structures are being leaked.
X-Send-Pr-Version: www-1.0

>Number:         25421
>Category:       kern
>Synopsis:       route structures are being leaked.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    ru
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb 27 12:30:01 PST 2001
>Closed-Date:    Wed Aug 8 01:16:00 PDT 2001
>Last-Modified:  Wed Aug 08 01:17:01 PDT 2001
>Originator:     Mark Smith
>Release:        4.2
>Organization:
Network Appliance
>Environment:
>Description:
This was found in a kernel with networking code derived from FreeBSD
not from FreeBSD itself.  However, from a code review of the FreeBSD-4.2 source, it appears FreeBSD has the same problem.

In in_losing() we have this:

        if ((rt = inp->inp_route.ro_rt)) {
                inp->inp_route.ro_rt = 0;
                bzero((caddr_t)&info, sizeof(info));
                info.rti_info[RTAX_DST] =
                        (struct sockaddr *)&inp->inp_route.ro_dst;
                info.rti_info[RTAX_GATEWAY] = rt->rt_gateway;
                info.rti_info[RTAX_NETMASK] = rt_mask(rt);
                rt_missmsg(RTM_LOSING, &info, rt->rt_flags, 0);
                if (rt->rt_flags & RTF_DYNAMIC)
                        (void) rtrequest(RTM_DELETE, rt_key(rt),
                                rt->rt_gateway, rt_mask(rt), rt->rt_flags,
                                (struct rtentry **)0);
                else
                /*
                 * A new route can be allocated
                 * the next time output is attempted.
                 */
                        rtfree(rt);
        }

Since rt was the cached route of the pcb, the ref count is >= 1 since
the pcb will have a ref count on it.  In the case of a dynamic route,
in_losing calls rtrequest to delete the route but not rtfree.
rtrequest() only deletes the route from the routing table.  It does
not free the route structure unless rt_refcnt is 0.  We know
it won't be zero because the pcb has a ref count.  As a result it
appears that we leak a route structure since it will never be freed.



>How-To-Repeat:
The problem is easiest to recreate on a lossy network where we
receive a lot of route redirects.
>Fix:
In in_losing() the fix appears to be to simply delete the else just
before the rtfree() call so that rtfree is always called.
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->jesper 
Responsible-Changed-By: jesper 
Responsible-Changed-When: Mon May 28 13:59:53 PDT 2001 
Responsible-Changed-Why:  
Will work on this one 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25421 
State-Changed-From-To: open->feedback 
State-Changed-By: ru 
State-Changed-When: Fri Jun 29 05:09:02 PDT 2001 
State-Changed-Why:  
Fixed in 5.0-CURRENT, in_pcb.c,v 1.85. 


Responsible-Changed-From-To: jesper->ru 
Responsible-Changed-By: ru 
Responsible-Changed-When: Fri Jun 29 05:09:02 PDT 2001 
Responsible-Changed-Why:  
MFC reminder. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25421 
State-Changed-From-To: feedback->closed 
State-Changed-By: ru 
State-Changed-When: Wed Aug 8 01:16:00 PDT 2001 
State-Changed-Why:  
Fixed in 4.4-PRERELEASE, in_pcb.c,v 1.59.2.16. 

http://www.FreeBSD.org/cgi/query-pr.cgi?pr=25421 
>Unformatted:
