In the Linux kernel, the following vulnerability has been resolved:

MIPS: Work around LLVM bug when gp is used as global register variable

On MIPS, currentthreadinfo is defined as global register variable locating in $gp, and is simply assigned with new address during kernel relocation.

This however is broken with LLVM, which always restores $gp if it finds $gp is clobbered in any form, including when intentionally through a global register variable. This is against GCC's documentation[1], which requires a callee-saved register used as global register variable not to be restored if it's clobbered.

As a result, $gp will continue to point to the unrelocated kernel after the epilog of relocatekernel(), leading to an early crash in initidle,

[ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000000000, epc == ffffffff81afada8, ra == ffffffff81afad90 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper Tainted: G W 6.19.0-rc5-00262-gd3eeb99bbc99-dirty #188 VOLUNTARY [ 0.000000] Tainted: [W]=WARN [ 0.000000] Hardware name: loongson,loongson64v-4core-virtio [ 0.000000] $ 0 : 0000000000000000 0000000000000000 0000000000000001 0000000000000000 [ 0.000000] $ 4 : ffffffff80b80ec0 ffffffff80b53d48 0000000000000000 00000000000f4240 [ 0.000000] $ 8 : 0000000000000100 ffffffff81d82f80 ffffffff81d82f80 0000000000000001 [ 0.000000] $12 : 0000000000000000 ffffffff81776f58 00000000000005da 0000000000000002 [ 0.000000] $16 : ffffffff80b80e40 0000000000000000 ffffffff80b81614 9800000005dfbe80 [ 0.000000] $20 : 00000000540000e0 ffffffff81980000 0000000000000000 ffffffff80f81c80 [ 0.000000] $24 : 0000000000000a26 ffffffff8114fb90 [ 0.000000] $28 : ffffffff80b50000 ffffffff80b53d40 0000000000000000 ffffffff81afad90 [ 0.000000] Hi : 0000000000000000 [ 0.000000] Lo : 0000000000000000 [ 0.000000] epc : ffffffff81afada8 initidle+0x130/0x270 [ 0.000000] ra : ffffffff81afad90 initidle+0x118/0x270 [ 0.000000] Status: 540000e2 KX SX UX KERNEL EXL [ 0.000000] Cause : 00000008 (ExcCode 02) [ 0.000000] BadVA : 0000000000000000 [ 0.000000] PrId : 00006305 (ICT Loongson-3) [ 0.000000] Process swapper (pid: 0, threadinfo=(ptrval), task=(ptrval), tls=0000000000000000) [ 0.000000] Stack : 9800000005dfbf00 ffffffff8178e950 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81970000 000000000000003f ffffffff810a6528 [ 0.000000] 0000000000000001 9800000005dfbe80 9800000005dfbf00 ffffffff81980000 [ 0.000000] ffffffff810a6450 ffffffff81afb6c0 0000000000000000 ffffffff810a2258 [ 0.000000] ffffffff81d82ec8 ffffffff8198d010 ffffffff81b67e80 ffffffff8197dd98 [ 0.000000] ffffffff81d81c80 ffffffff81930000 0000000000000040 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 000000000000009e ffffffff9fc01000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 ffffffff81ae86dc ffffffff81b3c741 0000000000000002 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [<ffffffff81afada8>] initidle+0x130/0x270 [ 0.000000] [<ffffffff81afb6c0>] schedinit+0x5c8/0x6c0 [ 0.000000] [<ffffffff81ae86dc>] startkernel+0x27c/0x7a8

This bug has been reported to LLVM[2] and affects version from (at least) 18 to 21. Let's work around this by using inline assembly to assign $gp before a fix is widely available.

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."

In the Linux kernel, the following vulnerability has been resolved:

arm64: Restrict CPUBIGENDIAN to GNU as or LLVM IAS 15.x or newer

Prior to LLVM 15.0.0, LLVM's integrated assembler would incorrectly byte-swap NOP when compiling for big-endian, and the resulting series of bytes happened to match the encoding of FNMADD S21, S30, S0, S0.

This went unnoticed until commit:

34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")

Prior to that commit, the kernel would always enable the use of FPSIMD early in boot when cpusetup() initialized CPACREL1, and so usage of FNMADD within the kernel was not detected, but could result in the corruption of user or kernel FPSIMD state.

After that commit, the instructions happen to trap during boot prior to FPSIMD being detected and enabled, e.g.

| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) | pc : pistrcmp+0x1c/0x150 | lr : populateproperties+0xe4/0x254 | sp : ffffd014173d3ad0 | x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000 | x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008 | x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044 | x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005 | x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000 | x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000 | x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000 | x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000 | x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a | x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8 | Kernel panic - not syncing: Unhandled exception | CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1 | Hardware name: linux,dummy-virt (DT) | Call trace: | dumpbacktrace+0xec/0x108 | showstack+0x18/0x2c | dumpstacklvl+0x50/0x68 | dumpstack+0x18/0x24 | panic+0x13c/0x340 | el1t64irqhandler+0x0/0x1c | el1abort+0x0/0x5c | el1h64sync+0x64/0x68 | pistrcmp+0x1c/0x150 | unflattendtnodes+0x1e8/0x2d8 | unflattendevicetree+0x5c/0x15c | unflattendevicetree+0x38/0x50 | setuparch+0x164/0x1e0 | startkernel+0x64/0x38c | primaryswitched+0xbc/0xc4

Restrict CONFIGCPUBIGENDIAN to a known good assembler, which is either GNU as or LLVM's IAS 15.0.0 and newer, which contains the linked commit.

llvm-project commit a0138390 was discovered to contain an assertion failure at !replacements.count(op) && "operation was already replaced.

llvm-project commit a0138390 was discovered to contain a segmentation fault via the component mlir::spirv::TargetEnv::TargetEnv(mlir::spirv::TargetEnvAttr).

llvm-project commit 6c01b5c was discovered to contain a segmentation fault via the component mlir::Type::getDialect().

llvm-project commit fdbc55a5 was discovered to contain a segmentation fault via the component mlir::IROperand<mlir::OpOperand.

llvm-project commit bd456297 was discovered to contain a segmentation fault via the component mlir::Block::getArgument.

llvm-project commit a0138390 was discovered to contain a segmentation fault via the component mlir::Type::isa<mlir::LLVM::LLVMVoidType.

llvm-project commit a0138390 was discovered to contain a segmentation fault via the component matchAndRewriteSortOp<mlir::sparsetensor::SortOp>(mlir::sparsetensor::SortOp.

DISPUTED LLVM a0dab4950 has a segmentation fault in mlir::outlineSingleBlockRegion. NOTE: third parties dispute this because the LLVM security policy excludes "Language front-ends ... for which a malicious input file can cause undesirable behavior."

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.