After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 523891 - PATCH: stop pwlib from causing crash when rescaling bayer v4l data to yuv420
PATCH: stop pwlib from causing crash when rescaling bayer v4l data to yuv420
Status: RESOLVED FIXED
Product: ekiga
Classification: Applications
Component: PTLIB
2.0.x
Other Linux
: Normal normal
: ---
Assigned To: Ekiga maintainers
Ekiga maintainers
Depends on:
Blocks:
 
 
Reported: 2008-03-22 18:46 UTC by Hans de Goede
Modified: 2008-04-03 08:56 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22

Attachments
PATCH: stop pwlib from causing crash when rescaling bayer v4l data to yuv420 (1.36 KB, patch)
2008-03-22 18:50 UTC, Hans de Goede 		none Details | Review

Description Hans de Goede 2008-03-22 18:46:53 UTC 
Hi,

I encountered this crash in ekiga while writing a v4l2 device driver for a pac207 usb webcam (*). I was testing my driver with ekiga and at first I blamed my driver, but a few hours later I know better.

ekiga uses pwlib to access webcam's, and pwlib's vconvert.cxx, and converters from that class should be able to handle both pixelformat changes as scaling. 

However the SBGGR8toYUV420P converter always assumes that the input image and the output image are the same, without checking this, causing memory corruption (a buffer overflow) when they differ in size.

This patch fixes this by using the currently #ifdef-ed out slower path when the sizes differ. It also fixes the (wrongly) swapping of red and blue in this (before this patch unused) path.
Comment 1 Hans de Goede 2008-03-22 18:50:23 UTC 
Created attachment 107827 [details] [review]
PATCH: stop pwlib from causing crash when rescaling bayer v4l data to yuv420

The promised patch.
Comment 2 Hans de Goede 2008-03-22 18:53:21 UTC 
Oops forgot to explain the (*):

(*) I know this cam is supported by gspca, thats where I'm getting the info needed to write the driver for. I'm writing a new standalone v4l2 (no in kernel bayer -> rgb conversion) driver, which should adhere to all kernel coding standards, making it suitable for upstream/mainline inclusion.
Comment 3 Snark 2008-03-23 08:28:14 UTC 
I'll try to ping Luc about it, thanks!
Comment 4 Damien Sandras 2008-03-27 09:09:43 UTC 
It has been fixed in PWLIB trunk. Thanks for the fix!
Comment 5 Damien Sandras 2008-03-27 17:37:27 UTC 
I even backported it to Phobos.