public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug analyzer/109335] New: -Wanalyzer-malloc-leak false positives and false negatives
@ 2023-03-29 14:03 colomar.6.4.3 at gmail dot com
2023-05-05 11:13 ` [Bug analyzer/109335] " colomar.6.4.3 at gmail dot com
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: colomar.6.4.3 at gmail dot com @ 2023-03-29 14:03 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109335
Bug ID: 109335
Summary: -Wanalyzer-malloc-leak false positives and false
negatives
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: colomar.6.4.3 at gmail dot com
Target Milestone: ---
Created attachment 54786
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54786&action=edit
Preprocessed reproducer
Link:
<https://inbox.sourceware.org/gcc/45c0584d-b326-a975-7ebc-cef76e154530@gmail.com/T/#u>
With both GCC 12.2.0 (Debian), and GCC 13.0.1 20230315 (built from source),
I can reproduce these false positives. I'm on Debian Sid with
libbsd-dev 0.11.7-4, and libc-dev 2.36-8.
The reproducer program is a small program that checks a password against a
hardcoded string, and conditionally prints "validated". I wrote it
precisely to demonstrate how [[gnu::malloc(deallocator)]] can be used to
ensure that passwords are not leaked in memory, but I found out that it
fails to detect some conditions.
Here's the program (it uses agetpass(), as defined in the shadow project):
$ cat pass.c
#include <err.h>
#include <errno.h>
#include <limits.h>
#include <readpassphrase.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
#define PASS_MAX BUFSIZ - 1
#define MALLOCARRAY(n, type) ((type *) mallocarray(n, sizeof(type)))
[[gnu::malloc, gnu::malloc(free)]] void *mallocarray(size_t nmemb, size_t
size);
void erase_pass(char *pass);
[[gnu::malloc(erase_pass)]] char *agetpass(const char *prompt);
void
do_work(void)
{
char *pass;
pass = agetpass("Enter your password: ");
if (pass == NULL)
err(EXIT_FAILURE, "agetpass");
if (strcmp(pass, "secret") == 0)
puts("validated");
/* erase_pass() zeroes the memory (think of memset(3), or bzero(3))
and then releases the memory to the system (think of free(3)).
If you only call free(pass), then you release the memory to the
system without zeroing it. Remember it contains a password!
We would be leaking a password into the system memory, which can
later be assigned to a different process.
So, we should call erase_pass() as soon as possible, but let's
say we forgot, and just call free():
*/
#if defined(BUG_1)
// We forgot to zero the memory.
free(pass);
// GCC correctly catches this as -Wmismatched-dealloc
#elif defined(BUG_2)
// We zeroed, but forgot to free(3).
bzero(pass, PASS_MAX + 2);
// GCC misses this.
#elif defined(BUG_3)
// We forgot both of them.
// GCC also misses this.
#else
erase_pass(pass); // OK, but 2 false positives.
#endif
}
int
main(void)
{
do_work();
for (;;)
sleep(1);
}
void *
mallocarray(size_t nmemb, size_t size)
{
return reallocarray(NULL, nmemb, size);
}
char *
agetpass(const char *prompt)
{
char *pass;
size_t len;
pass = MALLOCARRAY(PASS_MAX + 2, char);
if (pass == NULL)
return NULL;
if (readpassphrase(prompt, pass, PASS_MAX + 2, RPP_REQUIRE_TTY) ==
NULL)
goto fail;
len = strlen(pass);
if (len == PASS_MAX + 1) {
errno = ENOBUFS;
goto fail;
}
return pass;
fail:
freezero(pass, PASS_MAX + 2);
return NULL;
}
void
erase_pass(char *pass)
{
freezero(pass, PASS_MAX + 2);
}
This shows the false positives:
$ cc -Wall -Wextra pass.c $(pkgconf --cflags --libs libbsd-overlay) -fanalyzer
-O3
pass.c: In function ‘agetpass’:
pass.c:84:12: warning: leak of ‘pass’ [CWE-401] [-Wanalyzer-malloc-leak]
84 | if (pass == NULL)
| ^
‘do_work’: events 1-3
|
| 22 | do_work(void)
| | ^~~~~~~
| | |
| | (1) entry to ‘do_work’
|......
| 26 | pass = agetpass("Enter your password: ");
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (2) allocated here
| | (3) calling ‘agetpass’ from ‘do_work’
|
+--> ‘agetpass’: events 4-5
|
| 78 | agetpass(const char *prompt)
| | ^~~~~~~~
| | |
| | (4) entry to ‘agetpass’
|......
| 84 | if (pass == NULL)
| | ~
| | |
| | (5) ‘pass’ leaks here; was allocated at (2)
|
pass.c:91:12: warning: leak of ‘pass’ [CWE-401] [-Wanalyzer-malloc-leak]
91 | if (len == PASS_MAX + 1) {
| ^
‘do_work’: events 1-3
|
| 22 | do_work(void)
| | ^~~~~~~
| | |
| | (1) entry to ‘do_work’
|......
| 26 | pass = agetpass("Enter your password: ");
| | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (2) allocated here
| | (3) calling ‘agetpass’ from ‘do_work’
|
+--> ‘agetpass’: events 4-9
|
| 78 | agetpass(const char *prompt)
| | ^~~~~~~~
| | |
| | (4) entry to ‘agetpass’
|......
| 84 | if (pass == NULL)
| | ~
| | |
| | (5) following ‘false’ branch...
|......
| 87 | if (readpassphrase(prompt, pass, PASS_MAX + 2,
RPP_REQUIRE_TTY) == NULL)
| |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | ||
| | |(6) ...to here
| | (7) following ‘false’ branch...
|......
| 90 | len = strlen(pass);
| | ~~~~~~~~~~~~
| | |
| | (8) ...to here
| 91 | if (len == PASS_MAX + 1) {
| | ~
| | |
| | (9) following ‘false’ branch (when ‘len !=
8192’)...
|
‘agetpass’: event 10
|
|cc1:
| (10): ...to here
|
‘agetpass’: event 11
|
| 91 | if (len == PASS_MAX + 1) {
| | ^
| | |
| | (11) ‘pass’ leaks here; was allocated at (2)
|
Maybe I'm missing something, but I don't think falanyzer is correct here.
For the false negatives you just need to compile the above with -DBUG_2 or
-DBUG_3.
I didn't copy here the results, because well, it's a negative, so it simply
shows
the same as the above (so the false negatives and false positives happen in the
same compilation, which is quite confusing).
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug analyzer/109335] -Wanalyzer-malloc-leak false positives and false negatives
2023-03-29 14:03 [Bug analyzer/109335] New: -Wanalyzer-malloc-leak false positives and false negatives colomar.6.4.3 at gmail dot com
@ 2023-05-05 11:13 ` colomar.6.4.3 at gmail dot com
2024-05-15 7:16 ` alx at kernel dot org
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: colomar.6.4.3 at gmail dot com @ 2023-05-05 11:13 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109335
Alejandro Colomar <colomar.6.4.3 at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |colomar.6.4.3 at gmail dot com
--- Comment #1 from Alejandro Colomar <colomar.6.4.3 at gmail dot com> ---
I can still reproduce it with GCC-13 and glibc 2.36:
$ cat glibc.c
#include <stdio.h>
int main(void)
{
printf("glibc version: %d.%d\n", __GLIBC__, __GLIBC_MINOR__);
}
$ gcc-13 -Wall -Wextra glibc.c
$ ./a.out
glibc version: 2.36
$ gcc-13 --version
gcc-13 (Debian 13.1.0-1) 13.1.0
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug analyzer/109335] -Wanalyzer-malloc-leak false positives and false negatives
2023-03-29 14:03 [Bug analyzer/109335] New: -Wanalyzer-malloc-leak false positives and false negatives colomar.6.4.3 at gmail dot com
2023-05-05 11:13 ` [Bug analyzer/109335] " colomar.6.4.3 at gmail dot com
@ 2024-05-15 7:16 ` alx at kernel dot org
2024-05-15 7:42 ` alx at kernel dot org
2024-05-15 13:58 ` alx at kernel dot org
3 siblings, 0 replies; 5+ messages in thread
From: alx at kernel dot org @ 2024-05-15 7:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109335
--- Comment #2 from Alejandro Colomar <alx at kernel dot org> ---
This is probably because there's no way to mark a function as being a valid
deallocator (i.e., the converse of [[gnu::malloc()]]).
As a workaround, such deallocators could be defined (C99) inline, so that the
analyzer can see that they are internally calling the actual deallocator, but
that's hard when the deallocator is in a library, which might support C89, as
is probably the case in libbsd.
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug analyzer/109335] -Wanalyzer-malloc-leak false positives and false negatives
2023-03-29 14:03 [Bug analyzer/109335] New: -Wanalyzer-malloc-leak false positives and false negatives colomar.6.4.3 at gmail dot com
2023-05-05 11:13 ` [Bug analyzer/109335] " colomar.6.4.3 at gmail dot com
2024-05-15 7:16 ` alx at kernel dot org
@ 2024-05-15 7:42 ` alx at kernel dot org
2024-05-15 13:58 ` alx at kernel dot org
3 siblings, 0 replies; 5+ messages in thread
From: alx at kernel dot org @ 2024-05-15 7:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109335
--- Comment #3 from Alejandro Colomar <alx at kernel dot org> ---
Oops, no, that's a different story. The analyzer is thinking it leaks
somewhere where it doesn't seem to leak.
The false positive still reproduces with
gcc-14 (Debian 14-20240429-1) 14.0.1 20240429 (experimental) [gcc-14
r14-10144-g41d7a8ceaaa]
^ permalink raw reply [flat|nested] 5+ messages in thread
* [Bug analyzer/109335] -Wanalyzer-malloc-leak false positives and false negatives
2023-03-29 14:03 [Bug analyzer/109335] New: -Wanalyzer-malloc-leak false positives and false negatives colomar.6.4.3 at gmail dot com
` (2 preceding siblings ...)
2024-05-15 7:42 ` alx at kernel dot org
@ 2024-05-15 13:58 ` alx at kernel dot org
3 siblings, 0 replies; 5+ messages in thread
From: alx at kernel dot org @ 2024-05-15 13:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109335
--- Comment #4 from Alejandro Colomar <alx at kernel dot org> ---
Here's a smaller reproducer:
$ cat pass.c
#include <stdlib.h>
void my_free(char *p);
[[gnu::malloc(my_free)]] char *my_malloc(void);
int main(void)
{
char *p;
p = my_malloc();
my_free(p); // 2 false positives.
}
char *my_malloc(void)
{
return malloc(42);
}
void my_free(char *p)
{
free(p);
}
$ gcc-14 -Wall -Wextra pass.c -fanalyzer -O3
pass.c: In function ‘main’:
pass.c:10:9: warning: ‘p’ should have been deallocated with ‘free’ but was
deallocated with ‘my_free’ [CWE-762] [-Wanalyzer-mismatching-deallocation]
10 | my_free(p); // 2 false positives.
| ^~~~~~~~~~
‘main’: events 1-2
|
| 6 | int main(void)
| | ^~~~
| | |
| | (1) entry to ‘main’
|......
| 9 | p = my_malloc();
| | ~~~~~~~~~~~
| | |
| | (2) calling ‘my_malloc’ from ‘main’
|
+--> ‘my_malloc’: events 3-4
|
| 13 | char *my_malloc(void)
| | ^~~~~~~~~
| | |
| | (3) entry to ‘my_malloc’
| 14 | {
| 15 | return malloc(42);
| | ~~~~~~~~~~
| | |
| | (4) allocated here (expects deallocation
with ‘free’)
|
<------+
|
‘main’: events 5-6
|
| 9 | p = my_malloc();
| | ^~~~~~~~~~~
| | |
| | (5) returning to ‘main’ from ‘my_malloc’
| 10 | my_free(p); // 2 false positives.
| | ~~~~~~~~~~
| | |
| | (6) deallocated with ‘my_free’ here; allocation at (4)
expects deallocation with ‘free’
|
pass.c: In function ‘my_malloc’:
pass.c:15:16: warning: leak of ‘p’ [CWE-401] [-Wanalyzer-malloc-leak]
15 | return malloc(42);
| ^~~~~~~~~~
‘main’: events 1-3
|
| 6 | int main(void)
| | ^~~~
| | |
| | (1) entry to ‘main’
|......
| 9 | p = my_malloc();
| | ~~~~~~~~~~~
| | |
| | (2) allocated here
| | (3) calling ‘my_malloc’ from ‘main’
|
+--> ‘my_malloc’: events 4-5
|
| 13 | char *my_malloc(void)
| | ^~~~~~~~~
| | |
| | (4) entry to ‘my_malloc’
| 14 | {
| 15 | return malloc(42);
| | ~~~~~~~~~~
| | |
| | (5) ‘p’ leaks here; was allocated at (2)
|
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-05-15 13:58 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-29 14:03 [Bug analyzer/109335] New: -Wanalyzer-malloc-leak false positives and false negatives colomar.6.4.3 at gmail dot com
2023-05-05 11:13 ` [Bug analyzer/109335] " colomar.6.4.3 at gmail dot com
2024-05-15 7:16 ` alx at kernel dot org
2024-05-15 7:42 ` alx at kernel dot org
2024-05-15 13:58 ` alx at kernel dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).