Control: found -1 4.6.2-1 [Petter Reinholdtsen] > If I understand the issue correctly, a user with access to /dev/video > can cause the kernel to leak memory and eventually run out of memory by > doing repeated calls to mmap(). In other words, users with video group > membership can bring down the machine.
I've tried to track down a way to reproduce the problem without any luck so far. I asked on #v4l to see if anyone there could help and got some more information: <pere> hi. I'm trying to figure out if CVE-2010-5321 reported via <URL: https://bugzilla.redhat.com/show_bug.cgi?id=620629 > still exist in the linux kernel, and it links to <URL: https://linuxtv.org/irc/v4l/index.php?date=2010-07-29 > for more information. But that IRC log page is empty. Anyone here know how to reproduce the problem or find the log from that day? <pinchartl> pere: that's old <pinchartl> the bug seems to affect videobuf only, not videobuf2 <pere> yeah. at it seem to be unsolved, but I have not been able to verify it. <pinchartl> not all drivers have been converted to videobuf2 <pinchartl> but if the drivers you are interested in have been, then you should be safe from that point of view <pere> my focus is tracking CVEs in Debian, to know if the issue still exist or not. <pere> <URL: https://security-tracker.debian.org/tracker/CVE-2010-5321 > show the kernel still vulnerable... <pinchartl> I don't know I'm afraid <pinchartl> (one more reason to get rid of videobuf) <pere> how can I tell if a driver/device uses videobuf and not videobuf2? I assume some specific hardware is needed to reproduce the problem. <pinchartl> search for #include <media/videobuf-.*.h> in the sources <pinchartl> there's 9 of them left if I count properly <pinchartl> via-camera, fsl-viu, bttv, cx18, tm6000, zr364xx, cx231xx, pxa_camera and omap_vout <pinchartl> ah, and omap1_camera and timblogiw in staging <pinchartl> so that's 11 <pere> hm, wonder if I have a PCI card supported by bttv... <pinchartl> patches would be great :-) <pere> I am sure it would, but lack the capacity too look into that. :) <pere> pinchartl: is the description in that bug report enough for you to know how to reproduce it? I've tried writing a test program, but only got a v4l2 device and got EBUSY when calling mmap() several times there. <pere> but I suspect my test program is flawed, as I did not really quite understand the description. <pere> the redhat bug report was very short, and I suspect the details are in one of the referred bug reports, which are not available to the public. :( According to this report the issue still exist in the kernel for a small number of camera drivers, so I mark it as found in the unstable kernel too. I notice this bug is tagged upstream. Is there a bug report upstream too? I've been unable to find any. -- Happy hacking Petter Reinholdtsen
