Missing support for GCC's attribute malloc (deallocator) and malloc (deallocator, ptr-index)

[davidbolvansky]

Clang currently only supports basic version - attribute((malloc)). (in LLVM as noalias)

[davidbolvansky]

cc @nikic as you presented similar topic recently: https://lists.llvm.org/pipermail/llvm-dev/2022-January/154538.html
cc @jdoerfert

[davidbolvansky]

and also maybe cc @nickdesaulniers as this was implemented in GCC mainly with linux kernel use cases in mind.

[dilyanpalauzov]

With clang 14.0.0 this compiles:

#include <stdlib.h>

void fr(char* x) {
  free(x);
}

__attribute__((malloc)) char * al() {
  return (char*) malloc(10);
}

int main() {
  char* x = al();
  fr(x);
  return 0;
}

and this fails:

#include <stdlib.h>

void fr(char* x) {
  free(x);
}

__attribute__((malloc, malloc(fr, 1))) char * al() {
  return (char*) malloc(10);
}

int main() {
  char* x = al();
  fr(x);
  return 0;
}

a.c:7:25: error: 'malloc' attribute takes no arguments
 __attribute__((malloc, malloc(fr, 1))) char * al() {
                        ^
1 error generated.

GCC does accept the malloc (deallocator, ptr-index) form.

Please extend clang to accept the malloc (deallocator, ptr-index) __attribute__(()) form. It shall at least ignore it, rather than throwing an error for wrong syntax. This way the malloc (deallocator, ptr-index) form can always be used, irrespective of the compiler. Some compilers will handle it, other will ignore it.

[llvmbot]

@llvm/issue-subscribers-clang-codegen

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[nickdesaulniers]

this was implemented in GCC mainly with linux kernel use cases in mind.

@davidbolvansky do you have more context or a link to that discussion?

[davidbolvansky]

https://developers.redhat.com/blog/2021/04/30/detecting-memory-management-bugs-with-gcc-11-part-1-understanding-dynamic-allocation

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=dce6c58db87ebf7f4477bd3126228e73e4eeee97

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c7e276b869bdeb4a95735c1f037ee1a5f629de3d

seems like “CVE-2019-1907” was motivation

@msebor could probably tell us more about motivating cases.

[alejandro-colomar]

@msebor could probably tell us more about motivating cases.

@davidbolvansky
Above this comment is a link to a pull request in shadow-utils, regarding the introduction of a new API called agetpass() and its deallocator called erase_pass(). It should provide an example of a use case for this feature.

We tried to use the attribute, and noticed that clang doesn't support it.