[PATCH] IPSec fixes

Bjoern A. Zeeb bzeeb-lists at lists.zabbadoz.net
Mon Jan 19 14:07:35 PST 2004

On Fri, 16 Jan 2004 itojun at iijlab.net wrote:

> 	this does not help me repeat the symptom.  could you cook up a shell
> 	script which panics your box? (if possible, only with setkey)

reproducing with setkey only should not be possible from my current
understanding. one needs at least some other SP "consumers".

I have identified to always have a delta of 54 SPs allocated (when no
change is in progress) in my setup; these are:
- 2 persistent from key.c (ip4_def, ip6_def)
- 2 persistent from ipsec.c (PCB in, out)
- 18 in my SPD (from setkey spdadd)
- 2 grabed by inetd on startup and released on kill
- 30 grabed by racoon on startup and released on kill

w/o any of the 3 patches from either you or me all SPs not in sptree
and not persitient will be free(9)ed too early and marked dead with
the first spdflush.

While your patch prevents them from being free(9)ed too early it will
still mark them dead. This is addressed in my last last patch at the
end of my last (somewhat gushing) mail. As said I could not find a
reason for marking them dead but this is up for discussion.

I haven't tested the following script yet but I hope it will do the
trick for you on NetBSD (please change to s.th.
appropriate if needed).

--- cut ---

set -x


# either racoon(30) or inetd(2) aquire some SP (struct secpolicy) here
# that are only in sptailq and not in sptree
/usr/sbin/inetd -l -wW -C 60
/usr/local/sbin/racoon -f /path/to/racoon.conf

# let things settle
sleep 3

# just flush your SPD though there are no entries in;
# w/o whichever of the three patches this will decrement refcnt
# of those entries not in sptree but only in sptailq by one and mark
# them dead leading to a too early free(9) (last after killing the
# daemons if refcnt had been >1).
setkey -DPF

# let things settle
sleep 3

# this should lead to a memory modified after free situation
kill `cat /var/run/inetd.pid`
/usr/bin/killall racoon

ping -f $IP_NO_ON_THIS_BOX
--- cut ---

At least if testing on FreeBSD have INVARIANTS support in your kernel
for uma_dbg_alloc et al (don't know about NetBSD).


Bjoern A. Zeeb				bzeeb at Zabbadoz dot NeT
56 69 73 69 74				http://www.zabbadoz.net/

More information about the freebsd-current mailing list