In enforceDumpPermissionForPackage of ActivityManagerService.java, there is a possible way to determine if a package is installed due to side channel information disclosure. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation. Product: Android; Versions: Android-11; Android ID: A-166667403.
In Usage Stats Service, there is a possible way to determine whether an app is installed, without query permissions due to side channel information disclosure. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.
Hills ComNav version 3002-19 suffers from a weak communication channel. Traffic across the local network for the configuration pages can be viewed by a malicious actor. The size of certain communications packets are predictable. This would allow an attacker to learn the state of the system if they can observe the traffic. This would be possible even if the traffic were encrypted, e.g., using WPA2, as the packet sizes would remain observable. The communication encryption scheme is theoretically sound, but is not strong enough for the level of protection required.
In TelecomManager, there is a possible way to check if a particular self managed phone account was registered on the device due to side channel information disclosure. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12LAndroid ID: A-191768014
In DevicePolicyManager, there is a possible way to reveal the existence of an installed package without proper query permissions due to side channel information disclosure. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-12LAndroid ID: A-204995407
In the Linux kernel through 5.13.7, an unprivileged BPF program can obtain sensitive information from kernel memory via a Speculative Store Bypass side-channel attack because a certain preempting store operation does not necessarily occur before a store operation that has an attacker-controlled value.
In DevicePolicyManager, there is a possible way to determine whether an app is installed, without query permissions, due to side channel information disclosure. This could lead to local information disclosure with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android-13Android ID: A-205145497
The elliptic curve cryptography (ECC) hardware accelerator, part of the ARM® TrustZone® CryptoCell 310, contained in the NordicSemiconductor nRF52840 through 2021-03-29 has a non-constant time ECDSA implemenation. This allows an adversary to recover the private ECC key used during an ECDSA operation.
Potential floating point value injection in all supported CPU products, in conjunction with software vulnerabilities relating to speculative execution with incorrect floating point results, may cause the use of incorrect data from FPVI and may result in data leakage.
In the Linux kernel, the following vulnerability has been resolved: x86: fix user address masking non-canonical speculation issue It turns out that AMD has a "Meltdown Lite(tm)" issue with non-canonical accesses in kernel space. And so using just the high bit to decide whether an access is in user space or kernel space ends up with the good old "leak speculative data" if you have the right gadget using the result: CVE-2020-12965 “Transient Execution of Non-Canonical Accesses“ Now, the kernel surrounds the access with a STAC/CLAC pair, and those instructions end up serializing execution on older Zen architectures, which closes the speculation window. But that was true only up until Zen 5, which renames the AC bit [1]. That improves performance of STAC/CLAC a lot, but also means that the speculation window is now open. Note that this affects not just the new address masking, but also the regular valid_user_address() check used by access_ok(), and the asm version of the sign bit check in the get_user() helpers. It does not affect put_user() or clear_user() variants, since there's no speculative result to be used in a gadget for those operations.