Hey Jason, On Fri, 2015-08-21 at 15:45 -0600, Jason Gerard DeRose wrote: > As part of helping me understand the libfprint code, I ran scan-build > and fixed one NULL pointer dereference it reported, which after > tracing > that back led to another small fix. > > 0001_fix_NULL_pointer_dereference_in_vfs5001_submit_image.patch > =============================================================== > submit_image() in drivers/vfs5001.c checks whether `img` is NULL, but > was missing a return at the end of the conditional block, so it would > still go on to dereference the NULL pointer when setting `img > ->flags`, > `img->width`, and `img->height`. > > This was caught by scan-build and I confirmed that scan-build no > longer > reported an error here after the fix.
This should go in the commit message, not in the email. > 0002-fpi_img_new_assumes_g_malloc0_succeeds.patch > ================================================= > fpi_img_new() in img.c assumes that g_malloc0() always succeeds, for > which there is no guarantee. There is. GLib's memory allocation code either succeeds, or aborts: https://developer.gnome.org/glib/stable/glib-Memory-Allocation.html#glib-Memory-Allocation.description > So if g_malloc0() fails (returns NULL), fpi_img_new() should abort > and > return NULL, should not set `img->length`. > > Likewise, fpi_img_new_for_imgdev() should check whether fpi_img_new() > returns NULL, and if it does, fpi_img_new_for_imgdev() should abort > and > return NULL, should not set `img->width`, `img->height`. > > The next step, of course, is making sure all fpi_img_new(), > fpi_img_new_for_imgdev() consumers check for a NULL return value and > do > the right thing. A task I haven't tackled yet. So you can drop this patch, and assume that any calls to g_malloc and variants will succeed. > Please guide me on preferred patch workflow style! > ================================================== > > If I haven't submitted these patches in an acceptable form, or if you > would like me to do it differently next time, please let me know! > > I'm still trying to find my way around here, don't really know the > best > approach yet :D The best would be to attach the patches to bugs filed at https://bugs.freedesktop.org You can use git-bz: http://blog.fishsoup.net/2008/11/16/git-bz-bugzilla-subcommand-for-git/ to attach patches to bugzilla, which will make iterating through patches easier to track. Cheers _______________________________________________ fprint mailing list fprint@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/fprint
