Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 13 Apr 2017 21:06:19 -0700
From:      Cy Schubert <Cy.Schubert@komquats.com>
To:        Cy Schubert <cy@FreeBSD.org>
Cc:        src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org
Subject:   Re: svn commit: r316809 - head/sys/contrib/ipfilter/netinet
Message-ID:  <201704140406.v3E46JOb017269@slippy.cwsent.com>
In-Reply-To: Message from Cy Schubert <cy@FreeBSD.org> of "Fri, 14 Apr 2017 03:54:36 -0000." <201704140354.v3E3sawZ005932@repo.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In message <201704140354.v3E3sawZ005932@repo.freebsd.org>, Cy Schubert 
writes:
> Author: cy
> Date: Fri Apr 14 03:54:36 2017
> New Revision: 316809
> URL: https://svnweb.freebsd.org/changeset/base/316809
> 
> Log:
>   Fix a use after free panic in ipfilter's fragment processing.
>   Memory is malloc'd, then a search for a match in the fragment table
>   is made and if the fragment matches, the wrong fragment table is
>   freed, causing a use after free panic. This commit fixes this.
>   
>   A symptom of the problem is a kernel page fault in bcopy() called by
>   ipf_frag_lookup() at line 715 in ip_frag.c. Another symptom is a
>   kernel page fault in ipf_frag_delete() when called by ipf_frag_expire()
>   via ipf_slowtimer().
>   
>   MFC after:	1 week
> 
> Modified:
>   head/sys/contrib/ipfilter/netinet/ip_frag.c
> 
> Modified: head/sys/contrib/ipfilter/netinet/ip_frag.c
> =============================================================================
> =
> --- head/sys/contrib/ipfilter/netinet/ip_frag.c	Fri Apr 14 03:23:03 201
> 7	(r316808)
> +++ head/sys/contrib/ipfilter/netinet/ip_frag.c	Fri Apr 14 03:54:36 201
> 7	(r316809)
> @@ -474,7 +474,7 @@ ipfr_frag_new(softc, softf, fin, pass, t
>  			  IPFR_CMPSZ)) {
>  			RWLOCK_EXIT(lock);
>  			FBUMPD(ifs_exists);
> -			KFREE(fra);
> +			KFREE(fran);
>  			return NULL;
>  		}
>  
> 

It's surprising how few people/sites have encountered this panic. I only 
encounter this problem on the ShawOpen network anywhere in Edmonton, AB, 
Canada. However all other networks, including ShawOpen networks in other 
cities in Canada don't pass fragments that cause this panic, which by 
looking at the code should happen frequently. There is a similar panic, 
with a sometimes similar backtrace to the panics I experiences in FreeBSD, 
documented in NetBSD-7.


-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  http://www.FreeBSD.org

	The need of the many outweighs the greed of the few.





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201704140406.v3E46JOb017269>