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

s390: avoid using global register for currentstackpointer

Commit 30de14b1884b ("s390: currentstackpointer shouldn't be a function") made currentstackpointer a global register variable like on many other architectures. Unfortunately on s390 it uncovers old gcc bug which is fixed only since gcc-9.1 [gcc commit 3ad7fed1cc87 ("S/390: Fix PR89775. Stackpointer save/restore instructions removed")] and backported to gcc-8.4 and later. Due to this bug gcc versions prior to 8.4 generate broken code which leads to stack corruptions.

Current minimal gcc version required to build the kernel is declared as 5.1. It is not possible to fix all old gcc versions, so work around this problem by avoiding using global register variable for currentstackpointer.

DISPUTEDA failure in the -fstack-protector feature in GCC-based toolchains that target AArch64 allows an attacker to exploit an existing buffer overflow in dynamically-sized local variables in your application without this being detected. This stack-protector failure only applies to C99-style dynamically-sized local variables or those created using alloca(). The stack-protector operates as intended for statically-sized local variables.

The default behavior when the stack-protector detects an overflow is to terminate your application, resulting in controlled loss of availability. An attacker who can exploit a buffer overflow without triggering the stack-protector might be able to change program flow control to cause an uncontrolled loss of availability or to go further and affect confidentiality or integrity. NOTE: The GCC project argues that this is a missed hardening bug and not a vulnerability by itself.

A vulnerability was found in Libiberty. A heap and stack buffer overflow found in the dlanglname function in d-demangle.c leads to a denial of service.

Integer overflow in the new[] operator in gcc before 4.8.0 allows attackers to have unspecified impacts.

foldbinary in fold-const.c in GNU Compiler Collection (gcc) 4.1 improperly handles pointer overflow when folding a certain expr comparison to a corresponding offset comparison in cases other than EQEXPR and NEEXPR, which might introduce buffer overflow vulnerabilities into applications that could be exploited by context-dependent attackers.NOTE: the vendor states that the essence of the issue is "not correctly interpreting an offset to a pointer as a signed value."