[GH-ISSUE #2810] static analysis warnings #1760

Open
opened 2026-05-05 08:25:55 -06:00 by gitea-mirror · 3 comments
Owner

Originally created by @reinerh on GitHub (Jun 29, 2019).
Original GitHub issue: https://github.com/netblue30/firejail/issues/2810

When building firejail with the clang static analyzer (scan-build), it reports a few warnings.

syscall.c:563:4: warning: Potential leak of memory pointed to by 'newcall'
                        free(newcall);
                        ^~~~
syscall.c:563:4: warning: Potential memory leak
                        free(newcall);
                        ^~~~
syscall.c:568:1: warning: Potential memory leak
}
paths.c:76:2: warning: Potential leak of memory pointed to by 'elt'
        assert(paths[i] == 0);
        ^~~~~~~~~~~~~~~~~~~~~

It would be nice to get rid of them. Then the check could also be enabled in the CI.

Originally created by @reinerh on GitHub (Jun 29, 2019). Original GitHub issue: https://github.com/netblue30/firejail/issues/2810 When building firejail with the clang static analyzer (scan-build), it reports a few warnings. ``` syscall.c:563:4: warning: Potential leak of memory pointed to by 'newcall' free(newcall); ^~~~ syscall.c:563:4: warning: Potential memory leak free(newcall); ^~~~ syscall.c:568:1: warning: Potential memory leak } ``` ``` paths.c:76:2: warning: Potential leak of memory pointed to by 'elt' assert(paths[i] == 0); ^~~~~~~~~~~~~~~~~~~~~ ``` It would be nice to get rid of them. Then the check could also be enabled in the CI.
gitea-mirror added the
bug
label 2026-05-05 08:25:55 -06:00
Author
Owner

@netblue30 commented on GitHub (Jun 30, 2019):

I'll fix them, they are part of "make scan-build". I assume you are on the upcoming Debian version.

<!-- gh-comment-id:507049971 --> @netblue30 commented on GitHub (Jun 30, 2019): I'll fix them, they are part of "make scan-build". I assume you are on the upcoming Debian version.
Author
Owner

@rusty-snake commented on GitHub (Aug 28, 2019):

@netblue30 any progress here? I still get this warnings with firejail 26ae0b2 under Fedora.
I get also a warning for firemon:

firemon.c:107:2: warning: The left expression of the compound assignment is an uninitialized value. The computed value will also be garbage
        FD_SET(0,&fds);
        ^~~~~~~~~~~~~~
/usr/include/sys/select.h:85:28: note: expanded from macro 'FD_SET'
#define FD_SET(fd, fdsetp)      __FD_SET (fd, fdsetp)
                                ^~~~~~~~~~~~~~~~~~~~~
/usr/include/bits/select.h:59:43: note: expanded from macro '__FD_SET'
  ((void) (__FDS_BITS (set)[__FD_ELT (d)] |= __FD_MASK (d)))
<!-- gh-comment-id:525846295 --> @rusty-snake commented on GitHub (Aug 28, 2019): @netblue30 any progress here? I still get this warnings with firejail 26ae0b2 under Fedora. I get also a warning for firemon: ``` firemon.c:107:2: warning: The left expression of the compound assignment is an uninitialized value. The computed value will also be garbage FD_SET(0,&fds); ^~~~~~~~~~~~~~ /usr/include/sys/select.h:85:28: note: expanded from macro 'FD_SET' #define FD_SET(fd, fdsetp) __FD_SET (fd, fdsetp) ^~~~~~~~~~~~~~~~~~~~~ /usr/include/bits/select.h:59:43: note: expanded from macro '__FD_SET' ((void) (__FDS_BITS (set)[__FD_ELT (d)] |= __FD_MASK (d))) ```
Author
Owner

@matu3ba commented on GitHub (Dec 29, 2019):

@netblue30 Having a look into the scan-build in line 1604 and 1609 there were 3 cases of memory leak detected.
BugGroup BugType File Function/Method Line PathLength
Memoryerror Memoryleak syscall.c syscall_in_list 1609 71
Memoryerror Memoryleak syscall.c syscall_in_list 1604 81
Memoryerror Memoryleak syscall.c syscall_in_list 1604 54

Sadly the tool does not give the exact path to the file (only syscall.c instead of fseccomp/syscall.c)
and in two cases for paths not the exact ressource(s), which were leaking.

Potential leak of memory pointed to by newcall looks to me like the tool cant keep track of static memory and somehow thinks (due to macros?) that it is dynamic memory.
Syslist looks like a compile-time generated static memory assignment.
What is your opinion on that?

It is interesting, that there is no implicit memory freeing on call of errExit. How is this handled?

<!-- gh-comment-id:569511058 --> @matu3ba commented on GitHub (Dec 29, 2019): @netblue30 Having a look into the scan-build in line 1604 and 1609 there were 3 cases of memory leak detected. BugGroup BugType File Function/Method Line PathLength Memoryerror Memoryleak syscall.c syscall_in_list 1609 71 Memoryerror Memoryleak syscall.c syscall_in_list 1604 81 Memoryerror Memoryleak syscall.c syscall_in_list 1604 54 Sadly the tool does not give the exact path to the file (only syscall.c instead of fseccomp/syscall.c) and in two cases for paths not the exact ressource(s), which were leaking. Potential leak of memory pointed to by `newcall` looks to me like the tool cant keep track of static memory and somehow thinks (due to macros?) that it is dynamic memory. `Syslist` looks like a compile-time generated static memory assignment. What is your opinion on that? It is interesting, that there is no implicit memory freeing on call of `errExit`. How is this handled?
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/firejail#1760
No description provided.