On Mon, 2025-11-03 at 10:46 +0100, Kamil Dudka wrote:
> On Wednesday, 29 October 2025 21:20:12 CET Stephen Gallagher wrote:
> > On Wed, Oct 29, 2025 at 6:00 AM Siteshwar Vashisht
> > <[email protected]>
> > wrote:
> >
> > > Hello,
> > >
> > > I am writing this message to get feedback from the community on
> > > new
> > > findings by static analyzers in Critical Path Packages that have
> > > changed in Fedora 44.
> > >
> > > TLDR: This report[1] contains a total of 47352 findings and 843
> > > new
> > > findings identified since Fedora 43. Please review the report and
> > > provide feedback. False positives can now be recorded in the
> > > known-false-positives[5] repository.
> > >
> > > A mass scan was performed on the packages that have changed in
> > > Fedora
> > > 44. This report[1] contains all the findings that have been
> > > identified
> > > in the Critical Path Packages. Newly added findings since Fedora
> > > 43
> > > are listed under ‘+’ column and these should be prioritized while
> > > reviewing the findings (and fixing them upstream). Not all
> > > findings
> > > reported by OpenScanHub may be actual bugs, so please verify
> > > reported
> > > findings before investing time into fixing or reporting them. We
> > > have
> > > used the current development version of GCC to perform the scans,
> > > which may increase the likelihood of having false positives in
> > > the GCC
> > > reports.
> > >
> > > False positives can now be recorded in the known-false-
> > > positives[5]
> > > repository. These findings are automatically suppressed by
> > > OpenScanHub
> > > in scans that are triggered later. Also, you can filter findings
> > > with
> > > the csgrep utility to make it easier to review reports that may
> > > contain a large amount of false positives. Examples of csgrep
> > > invocation are available on the Fedora wiki[4].
> > >
> > > We hope this is helpful for the packages you maintain and for the
> > > upstream projects. Questions can be asked on the OpenScanHub
> > > mailing
> > > list[2]. If you want to see the full logs of the scans, they are
> > > available on the tasks[3] page. User documentation for performing
> > > a
> > > scan is available on the Fedora wiki[4].
> > >
> > > Please keep the feedback on this thread constructive. Thank you!
> > >
> > > [1]
> > > https://svashisht.fedorapeople.org/openscanhub/mass-scans/f44-28-Oct-2025/
> > >
> > > [2]
> > > https://lists.fedoraproject.org/archives/list/[email protected]/
> > >
> > > [3] https://openscanhub.fedoraproject.org/task/
> > >
> > > [4] https://fedoraproject.org/wiki/OpenScanHub
> > >
> > > [5] https://github.com/openscanhub/known-false-positives
> > >
> > > --
> > >
> >
> >
> > I'm pretty sure
> > https://svashisht.fedorapeople.org/openscanhub/mass-scans/f44-28-Oct-2025/sscg-4.0.0-1.fc44/added.html
> > is a false-positive. The line that it claims "leaks" isn't an exit
> > to the
> > function and the memory is freed just a few lines later. I'm not
> > sure why
> > OSH thinks that there's a problem. The BIO_read() function from
> > OpenSSL is
> > essentially just a memcpy() into the buffer that was passed in.
> >
> > (FWIW, this is also only in a unit test; there's no impact to the
> > actual
> > delivered package.)
>
> I agree this is a false positive. It does not happen with gcc-
> 15.2.1-3.fc44.
> It happens with gcc-latest-16.0.0-5.20250914git38666cbccff5.fc44 from
> COPR.
>
> Dave, any idea what went wrong?
>
> The original SARIF file produced by GCC can be downloaded with the
> following
> command:
>
> curl -s
> 'https://openscanhub.fedoraproject.org/task/78401/log/sscg-4.0.0-1.fc
> 44.tar.xz?format=raw' \
> | xz -cd \
> | tar -xv sscg-4.0.0-1.fc44/debug/raw-results/builddir/gcc-
> results/452-M3DZ.sarif
$ sarif-replay sscg-4.0.0-1.fc44/debug/raw-results/builddir/gcc-
results/452-M3DZ.sarif
In function 'verify_name_constraints':
../test/create_cert_test.c:118:3: warning: leak of ‘ext_str’ [-
Wanalyzer-malloc-leak]
38 | #include <openssl/x509.h>
......
118 | BIO_read (bio, ext_str, ext_len);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
'verify_name_constraints': events 1-18
61 | if (ext_idx < 0)
| ^
| |
| (1) following ‘false’ branch...
......
69 | name_constraints_ext = X509_get_ext (x509, ext_idx);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| (2) ...to here
70 | if (!name_constraints_ext)
| ~
| |
| (3) following ‘false’ branch...
......
77 | ext_data = X509_EXTENSION_get_data (name_constraints_ext);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| (4) ...to here
78 | if (!ext_data)
| ~
| |
| (5) following ‘false’ branch...
......
85 | bio = BIO_new (BIO_s_mem ());
| ~~~~~~~~~~~~~~~~~~~~~~
| |
| (6) ...to here
86 | if (!bio)
| ~Is there a way
| |
| (7) following ‘false’ branch...
......
93 | if (!X509V3_EXT_print (bio, name_constraints_ext, 0, 0))
| ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (8) ...to here
| (9) following ‘false’ branch...
......
101 | ext_len = BIO_pending (bio);
| ~
| |
| (10) ...to here
102 | if (ext_len <= 0)
| ~
| |
| (11) following ‘false’ branch (when ‘ext_len > 0’)...
......
109 | ext_str = malloc (ext_len + 1);
| ~~~~~~~~~~~~~~~~~~~~
| | |
| | (12) ...to here
| (13) allocated here
110 | if (!ext_str)
| ~
| |
| (14) assuming ‘ext_str’ is non-NULL
| (15) following ‘false’ branch (when ‘ext_str’ is non-
NULL)...
......
118 | BIO_read (bio, ext_str, ext_len);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| (16) ...to here
| (17) if ‘BIO_read’ throws an exception...
| (18) ‘ext_str’ leaks here; was allocated at (13)
One of the things I've implemented for GCC 16 is exception-handling
support in the analyzer. Looking at the above, GCC's -fanalyzer
"thinks" that BIO_read could throw an exception, and sure, if it did,
then that malloc at line 109 would leak.
Looking in the SARIF file, I see "-fexceptions" in the command-line
flags. Is that deliberate? Is this code meant to support exceptions?
FWIW I also made an HTML version of the above with:
$ sarif-replay \
-fdiagnostics-add-output=experimental-html:file=452-M3DZ.html \
sscg-4.0.0-1.fc44/debug/raw-results/builddir/gcc-results/452-M3DZ.sarif
and uploaded it here:
https://dmalcolm.fedorapeople.org/gcc/2025-11-03/452-M3DZ.html
Would it be useful if the mass scans provided this to package
maintainers?
(this HTML generation is new in GCC 16; you can use "j" and "k" to
cycle through the events in the log)
Hope this is constructive
Dave
--
_______________________________________________
devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/[email protected]
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
