Christos Zoulas <chris...@netbsd.org> 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