blob: a857e676880f82231bfed2adab8cfe7f87f8e8f7 [file] [log] [blame]
LLVM Security Group Transparency Reports
This page lists the yearly LLVM Security group transparency reports.
The :doc:`LLVM security group <Security>` was established on the 10th of July
2020 by the act of the `initial
commit <>`_ describing
the purpose of the group and the processes it follows. Many of the group's
processes were still not well-defined enough for the group to operate well.
Over the course of 2021, the key processes were defined well enough to enable
the group to operate reasonably well:
* We defined details on how to report security issues, see `this commit on
20th of May 2021 <>`_
* We refined the nomination process for new group members, see `this
commit on 30th of July 2021 <>`_
* We started writing an annual transparency report (you're reading the 2021
report here).
Over the course of 2021, we had 2 people leave the LLVM Security group and 4
people join.
In 2021, the security group received 13 issue reports that were made publicly
visible before 31st of December 2021. The security group judged 2 of these
reports to be security issues:
Both issues were addressed with source changes: #5 in clangd/vscode-clangd, and
#11 in llvm-project. No dedicated LLVM release was made for either.
We believe that with the publishing of this first annual transparency report,
the security group now has implemented all necessary processes for the group to
operate as promised. The group's processes can be improved further, and we do
expect further improvements to get implemented in 2022. Many of the potential
improvements end up being discussed on the `monthly public call on LLVM's
security group <>`_.
In this section we report on the issues the group received in 2022, or on issues
that were received earlier, but were disclosed in 2022.
In 2022, the llvm security group received 15 issues that have been disclosed at
the time of writing this transparency report.
5 of these were judged to be security issues:
* reports a miscompile in
LLVM that can result in the frame pointer and return address being
overwritten. This was fixed.
* reports a vulnerability
in `std::filesystem::remove_all` in libc++. This was fixed.
* reports a new Spectre
gadget variant that Speculative Load Hardening (SLH) does not mitigate. No
extension to SLH was implemented to also mitigate against this variant.
* reports missing memory
safety protection on the (C++) exception handling path. A number of fixes
were implemented.
* reports the RETBLEED
vulnerability. The outcome was clang growing a new security hardening feature
`-mfunction-return=thunk-extern`, see
No dedicated LLVM releases were made for any of the above issues.