>Number:         17404
>Category:       kern
>Synopsis:       ipfilter's in-kernel datatypes for /dev/ipl do not match the ones in /usr/sbin/ipmon
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jun 26 07:24:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Tomi Nylund
>Release:        NetBSD 1.6_BETA2
>Organization:
University of Oulu
>Environment:
sikw4:(root)/usr/src/usr.sbin/ipf/ipmon# uname -a
NetBSD sikw4 1.6_BETA2 NetBSD 1.6_BETA2 (SIK-TESTI-IPv6) #2: Wed Jun 26 15:58:25 EEST 2002     root@sikw4:/usr/src/sys/arch/sparc64/compile/SIK-TESTI-IPv6 sparc64
sikw4:(root)/usr/src/usr.sbin/ipf/ipmon# 

>Description:
There is a datatype mismatch inside kernel wrt. ipmon.c's version
of ioctl(FIONREAD) syscall, and the implementation in ip_log.c. In ip_log.c, we have size_t, which is 64 bits long in sparc64, and in ipmon.c, we have int, which is 32 bits.. This leads to a condition similar to the one described in kern/17403, where in big-endian architecture you get only zeroes, while in little-endian 64-bit machine, everything "just works", but copyout of 8 bytes into pointer to 4 bytes may be bad for your health anyway?
>How-To-Repeat:
Take NetBSD/sparc64 machine, and try to log something through /dev/ipl,
and ipmon. Nothing shows up. If you cat /dev/ipl, you can see data
showing up, but ipmon does not understand it.

>Fix:
Please see
http://www.ee.oulu.fi/~wizard/ip_log.c-patch.tar
which contains patches for src/sys/netinet/ip_log.c, and ip_fil.h to
change iplused's type from size_t to int, thus matching the datatypes with the ones in ipmon. This matches the int pointer implementation described in ipl(4).

>Release-Note:
>Audit-Trail:
>Unformatted: