Logo
componentllvm
Name
llvm
Version
13.0.1
Type
library
Description
-
Licenses
Apache-2.0-with-LLVM-exception
PURL
-
CPE
cpe:2.3:*:llvm:llvm:13.0.1:*:*:*:*:*:*:*

Other Versions#


Project
Branch
Version
master
22.1.8
scarthgap
18.1.8

Patches#


#
Title
Author
Resolve
1
Patch #1
Deepthi Hemraj <Deepthi.Hemraj@windriver.com>
CVE-2024-31852
2
llvm: TargetLibraryInfo: Undefine libc functions if they are macros
Khem Raj <raj.khem@gmail.com>
3
Patch #3
Deepthi Hemraj <Deepthi.Hemraj@windriver.com>
CVE-2023-46049
4
Patch #4
Deepthi Hemraj <Deepthi.Hemraj@windriver.com>
CVE-2024-31852
5
AsmMatcherEmitter: sort ClassInfo lists by name as well
Alexander Kanavin <alex.kanavin@gmail.com>
6
Patch #6
Deepesh Varatharajan <Deepesh.Varatharajan@windriver.com>
CVE-2024-0151
7
[Support] Add missing <cstdint> header to Signals.h
Sergei Trofimovich <slyich@gmail.com>
8
llvm: allow env override of exe path
Martin Kelly <mkelly@xevo.com>

Vulnerabilities#


Name
Analysis
Description
Patched
LLVM before 18.1.3 generates code in which the LR register can be overwritten without data being saved to the stack, and thus there can sometimes be an exploitable error in the flow of control. This affects the ARM backend and can be demonstrated with Clang. NOTE: the vendor perspective is "we don't have strong objections for a CVE to be created ... It does seem that the likelihood of this miscompile enabling an exploit remains very low, because the miscompile resulting in this JOP gadget is such that the function is most likely to crash on most valid inputs to the function. So, if this function is covered by any testing, the miscompile is most likely to be discovered before the binary is shipped to production."
Patched
Insufficient argument checking in Secure state Entry functions in software using Cortex-M Security Extensions (CMSE), that has been compiled using toolchains that implement 'Arm v8-M Security Extensions Requirements on Development Tools' prior to version 1.4, allows an attacker to pass values to Secure state that are out of range for types smaller than 32-bits. Out of range values might lead to incorrect operations in secure state.
Patched
LLVM 15.0.0 has a NULL pointer dereference in the parseOneMetadata() function via a crafted pdflatex.fmt file (or perhaps a crafted .o file) to llvm-lto. NOTE: this is disputed because the relationship between pdflatex.fmt and any LLVM language front end is not explained, and because a crash of the llvm-lto application should be categorized as a usability problem.