mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #2810] static analysis warnings #1760
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#1760
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
It would be nice to get rid of them. Then the check could also be enabled in the CI.
@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.
@rusty-snake commented on GitHub (Aug 28, 2019):
@netblue30 any progress here? I still get this warnings with firejail
26ae0b2under Fedora.I get also a warning for firemon:
@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
newcalllooks to me like the tool cant keep track of static memory and somehow thinks (due to macros?) that it is dynamic memory.Syslistlooks 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?