Subject: NetBSD Security Advisory 2005-012: SO_LINGER argument checking DIAGNOSTIC panic
To: None <>
From: NetBSD Security-Officer <>
List: netbsd-announce
Date: 11/08/2005 10:00:45
Hash: SHA1

		 NetBSD Security Advisory 2005-012

Topic:		SO_LINGER argument checking DIAGNOSTIC panic

Version:	NetBSD-current:	source prior to October 21, 2005
		NetBSD 2.1:	affected
		NetBSD 2.0.3:	affected
		NetBSD 2.0:	affected
		NetBSD 1.6:	not affected

Severity:	local denial-of-service crash by unprivileged user

Fixed:		NetBSD-current:		October 21, 2005
		NetBSD-3 branch:	October 21, 2005
		NetBSD-2.1 branch:	October 31, 2005
					   (2.1.1 will include the fix)
		NetBSD-2.0 branch:	October 31, 2005
					   (2.0.4 will include the fix)
		NetBSD-2 branch:	October 21, 2005


The SO_LINGER socket option can be passed negative a linger time,
which can be used by an unprivileged user to trigger a kernel
assertion panic if the kernel is compiled with "options DIAGNOSTIC".

Technical Details

The socket option SO_LINGER, accessed through setsockopt(3), takes a
structure containing the linger time, in seconds. This linger time
argument was not being bounds checked carefully enough.  If you pass a
negative linger time and enable the socket option, soclose() calls
tsleep() with a timeout of that negative time * hz.  The same problem
occurs if the number of seconds times hz overflows INT_MAX.

In a DIAGNOSTIC kernel, KASSERT() in callout_reset() fires when it
receives the negative value, triggering a panic. With DIAGNOSTIC off,
this appears to be harmless.

The SO_LINGER time argument has never been properly bounds checked,
however the potential crash was introduced together with a new callout
implementation introduced in NetBSD-current at 1.6N, after the 1.6
release was branched.  In that implementation, a KASSERT() was called
on all timeout values to catch cases such as this, instead of silently
bumping any negative value up to 1.  Therefore, releases 1.6 and
prior, and non-DIAGNOSTIC kernels, cannot be used to trigger a crash
in this manner.

The additional consistency checks enabled by this option are somewhat
expensive, and can trigger crash dumps for analysis should they fire,
as in this case. Therefore, DIAGNOSTIC is not recommended for use on
production systems, though it may well be desirable on development or
test systems.

A number of NetBSD ports ship GENERIC or other kernel configurations
with DIAGNOSTIC enabled.

Solutions and Workarounds

Users running kernels without "options DIAGNOSTIC" are not affected,
and need take no action.  

For affected systems, the kernel must be rebuilt to remove the
vulnerability - either by removing the DIAGNOSTIC option from your
kernel config, or by updating the kernel sources to include the fix
for additional bounds checking (or both).

For all affected NetBSD versions, you need to obtain fixed kernel
sources, rebuild and install the new kernel, and reboot the system.
The fixed source may be obtained from the NetBSD CVS repository.

The following instructions briefly summarise how to upgrade your
kernel.  In these instructions, replace:

  ARCH     with your architecture (from uname -m), and 
  KERNCONF with the name of your kernel configuration file.

To update from CVS, re-build, and re-install the kernel:

        # cd src
        # cvs update -d -P sys/kern/uipc_socket.c
	# ./ kernel=KERNCONF
	# mv /netbsd /netbsd.old
	# cp sys/arch/ARCH/compile/obj/KERNCONF/netbsd /netbsd
	# shutdown -r now

For more information on how to do this, see:

Thanks To

Nathan J. Williams for finding and fixing the issue.

Revision History

	2005-11-01	Initial release

More Information

Advisories may be updated as new information becomes available.
The most recent version of this advisory (PGP signed) can be found at

Information about NetBSD and NetBSD security can be found at and

Copyright 2005, The NetBSD Foundation, Inc.  All Rights Reserved.
Redistribution permitted only in full, unmodified form.

$NetBSD: NetBSD-SA2005-012.txt,v 1.4 2005/11/02 04:34:23 dan Exp $

Version: GnuPG v1.4.2 (NetBSD)