Re: CVS commit: src/sys/kern

[Tom Ivar Helbekkmo <tih%hamartun.priv.no@localhost>]

Christos Zoulas <christos%netbsd.org@localhost> writes:

> Log Message:
> pass valsize for getsockopt like we do for setsockopt

Looks like that uncovered something:

Crash version 8.99.9, image version 8.99.9.
System panicked: kernel diagnostic assertion "sopt->sopt_size == len" failed: file "/usr/src/sys/kern/uipc_socket.c", line 2112
Backtrace from time of crash is available.
crash> bt
_KERNEL_OPT_NARCNET() at 0
?() at ffffe401180808c0
vpanic() at vpanic+0x149
ch_voltag_convert_in() at ch_voltag_convert_in
sockopt_set() at sockopt_set+0x80
sogetopt() at sogetopt+0x18c
sys_getsockopt() at sys_getsockopt+0xb0
syscall() at syscall+0x1d8
--- syscall (number 118) ---

Looking at that KASSERT(), it seems to me that it makes it possible for
a user to crash the system merely by calling getsockopt() with a buffer
that is of the wrong size for the requested data.  That can't be good.

Wouldn't it be better to check that sopt->sopt_size >= len, and return
an error if not?  I think you should be allowed to getsockopt() into a
buffer that's larger than the data you're fetching, but get an error if
you allocate insufficient space.  The manual page says:

   For getsockopt(), optlen is a value-result parameter, initially
   containing the size of the buffer pointed to by optval, and modified
   on return to indicate the actual size of the value returned.

-tih
-- 
Most people who graduate with CS degrees don't understand the significance
of Lisp.  Lisp is the most important idea in computer science.  --Alan Kay