Total
51 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2023-6129 | 2 Openssl, Redhat | 2 Openssl, Enterprise Linux | 2024-11-21 | 6.5 Medium |
| Issue summary: The POLY1305 MAC (message authentication code) implementation contains a bug that might corrupt the internal state of applications running on PowerPC CPU based platforms if the CPU provides vector instructions. Impact summary: If an attacker can influence whether the POLY1305 MAC algorithm is used, the application state might be corrupted with various application dependent consequences. The POLY1305 MAC (message authentication code) implementation in OpenSSL for PowerPC CPUs restores the contents of vector registers in a different order than they are saved. Thus the contents of some of these vector registers are corrupted when returning to the caller. The vulnerable code is used only on newer PowerPC processors supporting the PowerISA 2.07 instructions. The consequences of this kind of internal application state corruption can be various - from no consequences, if the calling application does not depend on the contents of non-volatile XMM registers at all, to the worst consequences, where the attacker could get complete control of the application process. However unless the compiler uses the vector registers for storing pointers, the most likely consequence, if any, would be an incorrect result of some application dependent calculations or a crash leading to a denial of service. The POLY1305 MAC algorithm is most frequently used as part of the CHACHA20-POLY1305 AEAD (authenticated encryption with associated data) algorithm. The most common usage of this AEAD cipher is with TLS protocol versions 1.2 and 1.3. If this cipher is enabled on the server a malicious client can influence whether this AEAD cipher is used. This implies that TLS server applications using OpenSSL can be potentially impacted. However we are currently not aware of any concrete application that would be affected by this issue therefore we consider this a Low severity security issue. | ||||
| CVE-2023-32731 | 2 Grpc, Redhat | 2 Grpc, Enterprise Linux | 2024-11-21 | 7.4 High |
| When gRPC HTTP2 stack raised a header size exceeded error, it skipped parsing the rest of the HPACK frame. This caused any HPACK table mutations to also be skipped, resulting in a desynchronization of HPACK tables between sender and receiver. If leveraged, say, between a proxy and a backend, this could lead to requests from the proxy being interpreted as containing headers from different proxy clients - leading to an information leak that can be used for privilege escalation or data exfiltration. We recommend upgrading beyond the commit contained in https://github.com/grpc/grpc/pull/33005 https://github.com/grpc/grpc/pull/33005 | ||||
| CVE-2023-28322 | 5 Apple, Fedoraproject, Haxx and 2 more | 17 Macos, Fedora, Curl and 14 more | 2024-11-21 | 3.7 Low |
| An information disclosure vulnerability exists in curl <v8.1.0 when doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data to send, even when the `CURLOPT_POSTFIELDS` option has been set, if the same handle previously wasused to issue a `PUT` request which used that callback. This flaw may surprise the application and cause it to misbehave and either send off the wrong data or use memory after free or similar in the second transfer. The problem exists in the logic for a reused handle when it is (expected to be) changed from a PUT to a POST. | ||||
| CVE-2022-3281 | 1 Wago | 156 750-8100, 750-8100 Firmware, 750-8101 and 153 more | 2024-11-21 | 7.5 High |
| WAGO Series PFC100/PFC200, Series Touch Panel 600, Compact Controller CC100 and Edge Controller in multiple versions are prone to a loss of MAC-Address-Filtering after reboot. This may allow an remote attacker to circumvent the reach the network that should be protected by the MAC address filter. | ||||
| CVE-2022-32221 | 6 Apple, Debian, Haxx and 3 more | 16 Macos, Debian Linux, Curl and 13 more | 2024-11-21 | 9.8 Critical |
| When doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data to send, even when the `CURLOPT_POSTFIELDS` option has been set, if the same handle previously was used to issue a `PUT` request which used that callback. This flaw may surprise the application and cause it to misbehave and either send off the wrong data or use memory after free or similar in the subsequent `POST` request. The problem exists in the logic for a reused handle when it is changed from a PUT to a POST. | ||||
| CVE-2022-2668 | 1 Redhat | 3 Keycloak, Red Hat Single Sign On, Single Sign-on | 2024-11-21 | 7.2 High |
| An issue was discovered in Keycloak that allows arbitrary Javascript to be uploaded for the SAML protocol mapper even if the UPLOAD_SCRIPTS feature is disabled | ||||
| CVE-2021-42114 | 3 Micron, Samsung, Skhynix | 12 Ddr4 Sdram, Ddr4 Sdram Firmware, Lddr4 and 9 more | 2024-11-21 | 9 Critical |
| Modern DRAM devices (PC-DDR4, LPDDR4X) are affected by a vulnerability in their internal Target Row Refresh (TRR) mitigation against Rowhammer attacks. Novel non-uniform Rowhammer access patterns, consisting of aggressors with different frequencies, phases, and amplitudes allow triggering bit flips on affected memory modules using our Blacksmith fuzzer. The patterns generated by Blacksmith were able to trigger bitflips on all 40 PC-DDR4 DRAM devices in our test pool, which cover the three major DRAM manufacturers: Samsung, SK Hynix, and Micron. This means that, even when chips advertised as Rowhammer-free are used, attackers may still be able to exploit Rowhammer. For example, this enables privilege-escalation attacks against the kernel or binaries such as the sudo binary, and also triggering bit flips in RSA-2048 keys (e.g., SSH keys) to gain cross-tenant virtual-machine access. We can confirm that DRAM devices acquired in July 2020 with DRAM chips from all three major DRAM vendors (Samsung, SK Hynix, Micron) are affected by this vulnerability. For more details, please refer to our publication. | ||||
| CVE-2021-41035 | 2 Eclipse, Redhat | 3 Openj9, Enterprise Linux, Rhel Extras | 2024-11-21 | 9.8 Critical |
| In Eclipse Openj9 before version 0.29.0, the JVM does not throw IllegalAccessError for MethodHandles that invoke inaccessible interface methods. | ||||
| CVE-2020-25600 | 4 Debian, Fedoraproject, Opensuse and 1 more | 4 Debian Linux, Fedora, Leap and 1 more | 2024-11-21 | 5.5 Medium |
| An issue was discovered in Xen through 4.14.x. Out of bounds event channels are available to 32-bit x86 domains. The so called 2-level event channel model imposes different limits on the number of usable event channels for 32-bit x86 domains vs 64-bit or Arm (either bitness) ones. 32-bit x86 domains can use only 1023 channels, due to limited space in their shared (between guest and Xen) information structure, whereas all other domains can use up to 4095 in this model. The recording of the respective limit during domain initialization, however, has occurred at a time where domains are still deemed to be 64-bit ones, prior to actually honoring respective domain properties. At the point domains get recognized as 32-bit ones, the limit didn't get updated accordingly. Due to this misbehavior in Xen, 32-bit domains (including Domain 0) servicing other domains may observe event channel allocations to succeed when they should really fail. Subsequent use of such event channels would then possibly lead to corruption of other parts of the shared info structure. An unprivileged guest may cause another domain, in particular Domain 0, to misbehave. This may lead to a Denial of Service (DoS) for the entire system. All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only x86 32-bit domains servicing other domains are vulnerable. Arm systems, as well as x86 64-bit domains, are not vulnerable. | ||||
| CVE-2020-25599 | 4 Debian, Fedoraproject, Opensuse and 1 more | 4 Debian Linux, Fedora, Leap and 1 more | 2024-11-21 | 7.0 High |
| An issue was discovered in Xen through 4.14.x. There are evtchn_reset() race conditions. Uses of EVTCHNOP_reset (potentially by a guest on itself) or XEN_DOMCTL_soft_reset (by itself covered by XSA-77) can lead to the violation of various internal assumptions. This may lead to out of bounds memory accesses or triggering of bug checks. In particular, x86 PV guests may be able to elevate their privilege to that of the host. Host and guest crashes are also possible, leading to a Denial of Service (DoS). Information leaks cannot be ruled out. All Xen versions from 4.5 onwards are vulnerable. Xen versions 4.4 and earlier are not vulnerable. | ||||
| CVE-2020-25597 | 2 Fedoraproject, Xen | 2 Fedora, Xen | 2024-11-21 | 6.5 Medium |
| An issue was discovered in Xen through 4.14.x. There is mishandling of the constraint that once-valid event channels may not turn invalid. Logic in the handling of event channel operations in Xen assumes that an event channel, once valid, will not become invalid over the life time of a guest. However, operations like the resetting of all event channels may involve decreasing one of the bounds checked when determining validity. This may lead to bug checks triggering, crashing the host. An unprivileged guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only systems with untrusted guests permitted to create more than the default number of event channels are vulnerable. This number depends on the architecture and type of guest. For 32-bit x86 PV guests, this is 1023; for 64-bit x86 PV guests, and for all ARM guests, this number is 4095. Systems where untrusted guests are limited to fewer than this number are not vulnerable. Note that xl and libxl limit max_event_channels to 1023 by default, so systems using exclusively xl, libvirt+libxl, or their own toolstack based on libxl, and not explicitly setting max_event_channels, are not vulnerable. | ||||
| CVE-2020-25596 | 4 Debian, Fedoraproject, Opensuse and 1 more | 4 Debian Linux, Fedora, Leap and 1 more | 2024-11-21 | 5.5 Medium |
| An issue was discovered in Xen through 4.14.x. x86 PV guest kernels can experience denial of service via SYSENTER. The SYSENTER instruction leaves various state sanitization activities to software. One of Xen's sanitization paths injects a #GP fault, and incorrectly delivers it twice to the guest. This causes the guest kernel to observe a kernel-privilege #GP fault (typically fatal) rather than a user-privilege #GP fault (usually converted into SIGSEGV/etc.). Malicious or buggy userspace can crash the guest kernel, resulting in a VM Denial of Service. All versions of Xen from 3.2 onwards are vulnerable. Only x86 systems are vulnerable. ARM platforms are not vulnerable. Only x86 systems that support the SYSENTER instruction in 64bit mode are vulnerable. This is believed to be Intel, Centaur, and Shanghai CPUs. AMD and Hygon CPUs are not believed to be vulnerable. Only x86 PV guests can exploit the vulnerability. x86 PVH / HVM guests cannot exploit the vulnerability. | ||||
| CVE-2020-15705 | 7 Canonical, Debian, Gnu and 4 more | 18 Ubuntu Linux, Debian Linux, Grub2 and 15 more | 2024-11-21 | 6.4 Medium |
| GRUB2 fails to validate kernel signature when booted directly without shim, allowing secure boot to be bypassed. This only affects systems where the kernel signing certificate has been imported directly into the secure boot database and the GRUB image is booted directly without the use of shim. This issue affects GRUB2 version 2.04 and prior versions. | ||||
| CVE-2020-13776 | 4 Fedoraproject, Netapp, Redhat and 1 more | 6 Fedora, Active Iq Unified Manager, Solidfire \& Hci Management Node and 3 more | 2024-11-21 | 6.7 Medium |
| systemd through v245 mishandles numerical usernames such as ones composed of decimal digits or 0x followed by hex digits, as demonstrated by use of root privileges when privileges of the 0x0 user account were intended. NOTE: this issue exists because of an incomplete fix for CVE-2017-1000082. | ||||
| CVE-2020-10778 | 1 Redhat | 2 Cloudforms, Cloudforms Managementengine | 2024-11-21 | 6.0 Medium |
| In Red Hat CloudForms 4.7 and 5, the read only widgets can be edited by inspecting the forms and dropping the disabled attribute from the fields since there is no server-side validation. This business logic flaw violate the expected behavior. | ||||
| CVE-2020-10768 | 2 Linux, Redhat | 4 Linux Kernel, Enterprise Linux, Rhel E4s and 1 more | 2024-11-21 | 5.5 Medium |
| A flaw was found in the Linux Kernel before 5.8-rc1 in the prctl() function, where it can be used to enable indirect branch speculation after it has been disabled. This call incorrectly reports it as being 'force disabled' when it is not and opens the system to Spectre v2 attacks. The highest threat from this vulnerability is to confidentiality. | ||||
| CVE-2020-10767 | 2 Linux, Redhat | 4 Linux Kernel, Enterprise Linux, Rhel E4s and 1 more | 2024-11-21 | 5.5 Medium |
| A flaw was found in the Linux kernel before 5.8-rc1 in the implementation of the Enhanced IBPB (Indirect Branch Prediction Barrier). The IBPB mitigation will be disabled when STIBP is not available or when the Enhanced Indirect Branch Restricted Speculation (IBRS) is available. This flaw allows a local attacker to perform a Spectre V2 style attack when this configuration is active. The highest threat from this vulnerability is to confidentiality. | ||||
| CVE-2020-10766 | 2 Linux, Redhat | 4 Linux Kernel, Enterprise Linux, Rhel E4s and 1 more | 2024-11-21 | 5.5 Medium |
| A logic bug flaw was found in Linux kernel before 5.8-rc1 in the implementation of SSBD. A bug in the logic handling allows an attacker with a local account to disable SSBD protection during a context switch when additional speculative execution mitigations are in place. This issue was introduced when the per task/process conditional STIPB switching was added on top of the existing SSBD switching. The highest threat from this vulnerability is to confidentiality. | ||||
| CVE-2020-10255 | 3 Micron, Samsung, Skhynix | 6 Ddr4 Sdram, Lpddr4, Ddr4 and 3 more | 2024-11-21 | 9.0 Critical |
| Modern DRAM chips (DDR4 and LPDDR4 after 2015) are affected by a vulnerability in deployment of internal mitigations against RowHammer attacks known as Target Row Refresh (TRR), aka the TRRespass issue. To exploit this vulnerability, the attacker needs to create certain access patterns to trigger bit flips on affected memory modules, aka a Many-sided RowHammer attack. This means that, even when chips advertised as RowHammer-free are used, attackers may still be able to conduct privilege-escalation attacks against the kernel, conduct privilege-escalation attacks against the Sudo binary, and achieve cross-tenant virtual-machine access by corrupting RSA keys. The issue affects chips produced by SK Hynix, Micron, and Samsung. NOTE: tracking DRAM supply-chain issues is not straightforward because a single product model from a single vendor may use DRAM chips from different manufacturers. | ||||
| CVE-2020-0551 | 1 Intel | 1321 Atom C2308, Atom C2316, Atom C2338 and 1318 more | 2024-11-21 | 5.6 Medium |
| Load value injection in some Intel(R) Processors utilizing speculative execution may allow an authenticated user to potentially enable information disclosure via a side channel with local access. The list of affected products is provided in intel-sa-00334: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00334.html | ||||