Since we are able to change the device image resolution on the fly in the
authormglocker <mglocker@openbsd.org>
Sat, 26 Jul 2008 11:42:43 +0000 (11:42 +0000)
committermglocker <mglocker@openbsd.org>
Sat, 26 Jul 2008 11:42:43 +0000 (11:42 +0000)
commit70fff4d68e570daee60a68100d5a5a53367fa96e
treec37c65307ce3bd1f709ffd1a5127d41dfcb3d6ca
parent958b4b42cbacbc81c998fe7fb843e5a319b86c35
Since we are able to change the device image resolution on the fly in the
meantime, the memory allocation for the read(2) method for video(4)
is not right anymore, and can cause a buffer overflow.

We fix this by queuering the maximum available image size for a device at
attach time.  If the image size should exceed our video(4) buffer after a
video format change (which shouldn't happen), uvideo(4) will gracefully
fail.

Also tested by kettenis@
sys/dev/usb/uvideo.c
sys/dev/usb/uvideo.h
sys/dev/video.c