Bug 41677 - Potential deallocation at null pointer while getting of extra extensions info
Summary: Potential deallocation at null pointer while getting of extra extensions info
Status: RESOLVED NOTABUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: 7.11
Hardware: All All
: medium minor
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-10-11 05:04 UTC by Alexander Tsvetkov
Modified: 2011-10-11 09:32 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Alexander Tsvetkov 2011-10-11 05:04:29 UTC
Function: GLubyte* _mesa_make_extension_string(struct gl_context *ctx)
Module:   mesa/main/extensions.c
Mesa library found version: the currently presented version of library development 

http://cgit.freedesktop.org/mesa/mesa/commit/?id=a13eed4b826d0bb5dfcb5e63651987a232df8a06

The function makes the deallocation at null pointer at lines 854,861 if "extra_extensions == NULL" in case when memory allocation error occurred:

811: GLubyte*
812:_mesa_make_extension_string(struct gl_context *ctx)
813:{
814:/* The extension string. */
815:char *exts = 0;
816:/* Length of extension string. */
817:size_t length = 0;
818:/* Number of extensions */
819:unsigned count;
820:/* Indices of the extensions sorted by year */
821:extension_index *extension_indices;
822:/* String of extra extensions. */
823:char *extra_extensions = get_extension_override(ctx);
824:GLboolean *base = (GLboolean *) &ctx->Extensions;
825:const struct extension *i;
826:unsigned j;
827:unsigned maxYear = ~0;
828:
829:/* Check if the MESA_EXTENSION_MAX_YEAR env var is set */
830:{
831:  const char *env = getenv("MESA_EXTENSION_MAX_YEAR");
832:  if (env) {
833:     maxYear = atoi(env);
834:     _mesa_debug(ctx, "Note: limiting GL extensions to %u or earlier\n",
835:                 maxYear);
836:  }
837:}
838:
839:/* Compute length of the extension string. */
840:count = 0;
841:for (i = extension_table; i->name != 0; ++i) {
842:   if (base[i->offset] &&
843:      i->year <= maxYear &&
844:      (i->api_set & (1 << ctx->API))) {
845:    length += strlen(i->name) + 1; /* +1 for space */
846:	 ++count;
847:  }
848:}
849:if (extra_extensions != NULL)
850:  length += 1 + strlen(extra_extensions); /* +1 for space */
851: 
852:exts = (char *) calloc(ALIGN(length + 1, 4), sizeof(char));
853:if (exts == NULL) {
854:  free(extra_extensions);
855:  return NULL;
856:}
857:
858:extension_indices = malloc(count * sizeof(extension_index));
859:if (extension_indices == NULL) {
860:  free(exts);
861:  free(extra_extensions);
862:  return NULL;
863:}
...
}
Comment 1 Jose Fonseca 2011-10-11 06:19:37 UTC
free(NULL) is allowed, at least on linux.

I could fix this, but there are many other cases in the source where this happens, and it would be a distraction from real issues to fix them all now.

It looks like this issue was spotted by a static code analysis tool. Could you reconfigure the tool to not report free(NULL) issues instead?
Comment 2 Vinson Lee 2011-10-11 09:32:53 UTC
free(NULL) is allowed by the C standard.


See ISO-IEC 9899:1999 from http://open-std.org/JTC1/SC22/WG14/www/standards.

7.20.3.2
The free function causes the space pointed to by ptr to be deallocated, that is, made available for further allocation. If ptr is a null pointer, no action occurs.


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.