An inappropriate implementation flaw was found in the V8 component of the Chromium browser.
Upstream bug(s):
https://code.google.com/p/chromium/issues/detail?id=1052647
External References:
https://chromereleases.googleblog.com/2020/03/stable-channel-update-for-desktop18.html
An industry-wide issue was found in the way many modern microprocessor designs have implemented speculative execution of instructions (a commonly used performance optimization). There are three primary variants of the issue which differ in the way the speculative execution can be exploited.
Variant CVE-2017-5753 triggers the speculative execution by performing a bounds-check bypass. It relies on the presence of a precisely-defined instruction sequence in the privileged code as well as the fact that memory accesses may cause allocation into the microprocessor's data cache even for speculatively executed instructions that never actually commit (retire). As a result, an unprivileged attacker could use this flaw to cross the syscall boundary and read privileged memory by conducting targeted cache side-channel attacks.
Mozilla Firefox before 28.0, Firefox ESR 24.x before 24.4, Thunderbird before 24.4, and SeaMonkey before 2.25 might allow local users to gain privileges by modifying the extracted Mar contents during an update.
It is unexpected and not allowed to call TTY buffer helpers like ttyinsertflipstring concurrently. This may lead to crashes when ECHOing is enabled and concurrect writers call ptywrite in the meantime. In that case the two writers: the ECHOing from a workqueue and ptywrite from the process race and can overflow the corresponding TTY buffer.
An unprivileged local user could use this flaw to crash the system or, potentially, escalate their privileges on the system.
References: http://seclists.org/oss-sec/2014/q2/243
The Portable Tool Library (aka PTLib) before 2.10.10, as used in Ekiga before 4.0.1, does not properly detect recursion during entity expansion, which allows remote attackers to cause a denial of service (memory and CPU consumption) via a crafted PXML document containing a large number of nested entity references, aka a "billion laughs attack."
Description of problem: The XFSIOCFSGETXATTR ioctl allows unprivileged users to read 12 bytes of uninitialized stack memory, because the fsxattr struct declared on the stack in xfsiocfsgetxattr() does not alter (or zero) the 12-byte fsxpad member before copying it back to the user.
http://www.linux.sgi.com/archives/xfs-masters/2010-09/msg00002.html
Acknowledgements:
Red Hat would like to thank Dan Rosenberg for reporting this issue.
Description of problem: We leak at least 32bits of kernel memory to user land in tc dump, because we dont init all fields (capab ?) of the dumped structure.
Use C99 initializers so that holes and non explicit fields are zeroed.
http://patchwork.ozlabs.org/patch/61857/
Description of problem: To avoid exposing ourselves to the risk of finding another field like .mapbh.bstate where we rely on zeroing but don't enforce it in the code. The fix uses kzalloc to zero all the struct dio rather than manually trying to track which fields we rely on being zero.
Reference: http://lkml.org/lkml/2007/7/26/88