kern/41364: Panic in ipf(8)

[Jukka Ruohonen <jruohonen%iki.fi@localhost>]

>Number:         41364
>Category:       kern
>Synopsis:       Panic in ipf(89)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed May 06 05:25:00 +0000 2009
>Originator:     Jukka Ruohonen
>Release:        NetBSD 5.99.11
>Organization:
-
>Environment:
System: NetBSD camus.bitnet 5.99.11 NetBSD 5.99.11 (GENERIC_LOCAL) #0: Thu
Apr 23 17:08:34 UTC 2009
toor%camus.bitnet@localhost:/var/tmp/obj/sys/arch/amd64/compile/GENERIC_LOCAL 
amd64
Architecture: x86_64
Machine: amd64

>Description:

        Trying to disable ipf(8) that has not been enabled beforehand causes
        a complete lockdown. Today I managed to get a trace (this is quickly
        copied by hand and occured in a single user mode):

        Enter pathname of shell or RETURN for /bin/sh:
        # ipf -D
        panic: kernel diagnostic assertion "c->c_magic == CALLOUT_MAGIC"
        failed: file "/usr/src/sys/kern/kern_timeout.c", line 426
        fatal breakpoint trap in supervisor mode
        trap type 1 code 0 rip ffffffffff80242b75 cs 8 rflags 246 cr2
        717ffd9caff0 cpl0 rsp ffff8000495874b0
        Stopped in pid 5.1 (ipf) at     netbsd:breakpoint+0xf: leave
        db{0}> bt
        breakpoint() at netbsd:breakpoint+0xf
        panic() at netbsd:panic+0x289
        __kernassert() at netbsd:__kernassert+0x2d
        callout_stop() at netbsd:callout_stop+0xc2
        ipfdetach() at netbsd:ipfdetach+0x4c
        fr_ipf_ioctl() at netbsd:fr_ipf_ioctl+0x4bb
        cdev_ioctl() at netbsd:cdev_ioctl+0x91
        VOP_IOCTL() at netbsd:COP_IOCTL+0x6e
        vn_ioctl() at netbsd:vn_ioctl0x6d
        sys_ioctl() at netbsd:sys_ioctl+0x134
        syscall() at netbsd:syscall+0xc2
        db{0}>

>How-To-Repeat:

        Boot a kernel with working "ipf.conf" but "ipfilter=NO" and issue
        either "/etc/rc.d/ipfilter stop" or "ipf -D".

        This can be reproduced on stable i386 and AMD64 5.0 as well.

>Fix:

        By looking at "../sys/dist/ipf/netinet/ip_fil_netbsd.c", which is
        extremely hard to follow due #ifdefs, my initial thought is that
        ipfdetach() simply calls callout_stop() without assuring that
        callout_init() has called.