kern/64345: 4.x IPFW2 kernel memory leak (IPFW2+roteflaps+verrevpath) (fwd)

Dmitry Morozovsky marck at
Wed Mar 17 10:40:14 PST 2004

The following reply was made to PR kern/64345; it has been noted by GNATS.

From: Dmitry Morozovsky <marck at>
To: bug-followup at
Subject: Re: kern/64345: 4.x IPFW2 kernel memory leak (IPFW2+rote flaps+verrevpath)
Date: Wed, 17 Mar 2004 21:32:18 +0300 (MSK)

 Forwarding misfiled message to audit-trail:
 D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
 *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at ***
 ---------- Forwarded message ----------
 Date: Wed, 17 Mar 2004 17:16:13 +0300 (MSK)
 From: Oleg Bulyzhin <oleg at>
 To: Dmitry Morozovsky <marck at>
 Cc: FreeBSD-gnats-submit at
 Subject: Re: 4.x IPFW2 kernel memory leak (IPFW2+rote flaps+verrevpath)
 In order to reproduce problem do the following:
 ifconfig fxp0
 ipfw add 1 count verrevpath in
 while (true); do ping -c 2 -i 0.01 -S localhost>/dev/null; ping -c 2 -i
  0.01 -S localhost>/dev/null; route delete>/dev/null;netstat
  -rs|tail -1;vmstat -m|grep routetbl|tail -1;  done
 and look at numbers. If you run this script long enough (depends on your kernel
 memory size) you will get panic like this:
 panic: kmem_malloc(4096): kmem_map too small: 33554432 total allocated
 This happens due to verify_rev_path() calls rtalloc_ign() (for not cached
 routes) which increments rt_refcnt for corresponding rtentry structure.
 This lead to always 'held' routes which cannot be released by rtfree()
 (due to their rt_refcnt will never hit zero)
 P.S. this bug is remotely exploitable (at least if attacker is in your LAN).
 === Oleg Bulyzhin -- OBUL-RIPN -- OBUL-RIPE -- oleg at ===

More information about the freebsd-bugs mailing list