[Bug c/81524] Bogus or missing warnings when dereferencing pointer to deallocated stack memory

[fredrik.hederstierna--- via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81524

--- Comment #7 from Fredrik Hederstierna 
 ---
I tested GCC-12 and it now correctly warns for these test cases.
Great work, thanks!

[Bug c/81524] Bogus or missing warnings when dereferencing pointer to deallocated stack memory

[msebor at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81524

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Status|NEW |RESOLVED
   Target Milestone|--- |12.0
 Resolution|--- |FIXED
 Blocks||104077

--- Comment #6 from Martin Sebor  ---
As far as I can see this works as requested without sanitization in GCC 12:

$ (set -x; for p in PARAM RETURN BLOCK; do for m in READ WRITE; do gcc
-DTEST_${p}_$m -S -Wall pr81524.c; done; done)
+ for p in PARAM RETURN BLOCK
+ for m in READ WRITE
+ gcc -DTEST_PARAM_READ -S -Wall pr81524.c
pr81524.c: In function ‘test_param_local’:
pr81524.c:33:7: warning: storing the address of local variable ‘local’ in ‘*pp’
[-Wdangling-pointer=]
   33 |   *pp = 
  |   ^~~~
pr81524.c:32:7: note: ‘local’ declared here
   32 |   int local = 1;
  |   ^
pr81524.c:32:7: note: ‘pp’ declared here
+ for m in READ WRITE
+ gcc -DTEST_PARAM_WRITE -S -Wall pr81524.c
pr81524.c: In function ‘test_param_local’:
pr81524.c:33:7: warning: storing the address of local variable ‘local’ in ‘*pp’
[-Wdangling-pointer=]
   33 |   *pp = 
  |   ^~~~
pr81524.c:32:7: note: ‘local’ declared here
   32 |   int local = 1;
  |   ^
pr81524.c:32:7: note: ‘pp’ declared here
+ for p in PARAM RETURN BLOCK
+ for m in READ WRITE
+ gcc -DTEST_RETURN_READ -S -Wall pr81524.c
pr81524.c: In function ‘test_return_local’:
pr81524.c:42:10: warning: function returns address of local variable
[-Wreturn-local-addr]
   42 |   return 
  |  ^~
+ for m in READ WRITE
+ gcc -DTEST_RETURN_WRITE -S -Wall pr81524.c
pr81524.c: In function ‘test_return_local’:
pr81524.c:42:10: warning: function returns address of local variable
[-Wreturn-local-addr]
   42 |   return 
  |  ^~
+ for p in PARAM RETURN BLOCK
+ for m in READ WRITE
+ gcc -DTEST_BLOCK_READ -S -Wall pr81524.c
pr81524.c: In function ‘main’:
pr81524.c:88:10: warning: using dangling pointer ‘p’ to ‘local’
[-Wdangling-pointer=]
   88 |   return *p;
  |  ^~
pr81524.c:76:9: note: ‘local’ declared here
   76 | int local = 1;
  | ^
pr81524.c:81:3: warning: using dangling pointer ‘p’ to ‘local’
[-Wdangling-pointer=]
   81 |   printf("%d\n", *p);
  |   ^~
pr81524.c:76:9: note: ‘local’ declared here
   76 | int local = 1;
  | ^
+ for m in READ WRITE
+ gcc -DTEST_BLOCK_WRITE -S -Wall pr81524.c
pr81524.c: In function ‘main’:
pr81524.c:88:10: warning: using dangling pointer ‘p’ to ‘local’
[-Wdangling-pointer=]
   88 |   return *p;
  |  ^~
pr81524.c:76:9: note: ‘local’ declared here
   76 | int local = 1;
  | ^
pr81524.c:84:6: warning: using dangling pointer ‘p’ to ‘local’
[-Wdangling-pointer=]
   84 |   *p = 1;
  |   ~~~^~~
pr81524.c:76:9: note: ‘local’ declared here
   76 | int local = 1;
  | ^


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104077
[Bug 104077] bogus/missing -Wdangling-pointer

[Bug c/81524] Bogus or missing warnings when dereferencing pointer to deallocated stack memory

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81524

--- Comment #5 from Martin Liška  ---
> No, it verifies stuff just in compile time. Well I understand the arm-eabi

Sorry, 'just in run-time'.

[Bug c/81524] Bogus or missing warnings when dereferencing pointer to deallocated stack memory

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81524

--- Comment #4 from Martin Liška  ---
(In reply to Fredrik Hederstierna from comment #3)
> Isn't AddressSanitizer checking in run-time? There are several tools that
> can find this bugs in runtime I think like Valgrind, but I need to find this
> at compile-time.

Yes, it's run-time checking.

> 
> I use embedded arm-eabi target and cannot add memory for instrumentation
> with compile AddressSanitizer, or can AddressSanitizer do jobs alos in
> compile-time without adding code size for run-time instrumentation?

No, it verifies stuff just in compile time. Well I understand the arm-eabi is
not a good target for AddressSanization. Maybe you will be able to run the code
on x86_64 in a testing environment where you can catch various undefined
behavior stuff.

Please be note that AddressSanitizer is much powerful tool that a compile-time
checking, because due to multiple compilation modules or conservative
assumptions that compiler has to do, one can't find these issues in compile
time.

[Bug c/81524] Bogus or missing warnings when dereferencing pointer to deallocated stack memory

[fredrik.hederstie...@securitas-direct.com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81524

--- Comment #3 from Fredrik Hederstierna 
 ---
Isn't AddressSanitizer checking in run-time? There are several tools that can
find this bugs in runtime I think like Valgrind, but I need to find this at
compile-time.

I use embedded arm-eabi target and cannot add memory for instrumentation with
compile AddressSanitizer, or can AddressSanitizer do jobs alos in compile-time
without adding code size for run-time instrumentation?

[Bug c/81524] Bogus or missing warnings when dereferencing pointer to deallocated stack memory

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81524

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-07-24
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Yes, I can confirm that GCC 7 can detect all 6 situations with:

gcc pr81524.c  -fsanitize=address -g &&
ASAN_OPTIONS="detect_stack_use_after_return=1"  ./a.out

Can we close the PR? As resolved?

[Bug c/81524] Bogus or missing warnings when dereferencing pointer to deallocated stack memory

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81524

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
If you want to reliably detect this, just use -fsanitize=address, starting with
GCC 7.x there is use after scope sanitization that should report this.