A recent run of Klocwork static analysis found the following issue: 'table' array elements are used uninitialized in this function with index range: [77, 103] [105, 107] [109, 111] [113, 115] [117, 119] [121, 123] EQ(154) EQ(167). Also there is one similar error on line 1685. There's at least one bug here, but I think there may be more. It may also legitimately be a security issue. Not all entries in the table are initialized, but a check at the end of the function (added in 1a814217 by Jordan) checks that the function pointer is not NULL before returning. At the very least, the table should be memset to 0. However, some of the slots that are missing map to formats that I think should have decode functions. For example, the table has an entry for MESA_FORMAT_RGBA_UINT32, but not for MESA_FORMAT_R_UINT32 (121), MESA_FORMAT_RG_UINT32 (122), or MESA_FORMAT_RGB_UINT32 (123). MESA_FORMAT_ETC2_SRGB8_PUNCHTHROUGH_ALPHA1 (154) is also missing, but the other ETC2 formats are present. It seems to me that the only NULL entry in the table should be MESA_FORMAT_NONE. If that is in fact the case, we should add a unit test.
It's truly impressive how awesome this "secure bug tracker" feature is.
This should be fixed by the following four patches: http://lists.freedesktop.org/archives/mesa-dev/2013-April/038304.html http://lists.freedesktop.org/archives/mesa-dev/2013-April/038305.html http://lists.freedesktop.org/archives/mesa-dev/2013-April/038306.html http://lists.freedesktop.org/archives/mesa-dev/2013-April/038307.html
Fixed on Mesa master by those commits. They've been marked as candidates for stable. We should also memset the table and create a unit test that verifies that each entry from 0 .. MESA_FORMAT_COUNT is non-NULL. That can be done as a follow-up project.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.