Total
492 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2017-18659 | 1 Google | 1 Android | 2024-11-21 | 5.0 MEDIUM | 5.3 MEDIUM |
| An issue was discovered on Samsung mobile devices with KK(4.4), L(5.0/5.1), M(6.0), and N(7.x) software. Attackers can crash system processes via a broadcast to AdaptiveDisplayColorService. The Samsung ID is SVE-2017-8290 (July 2017). | |||||
| CVE-2017-17172 | 1 Huawei | 2 Lyo-l21, Lyo-l21 Firmware | 2024-11-21 | 4.4 MEDIUM | 7.3 HIGH |
| Huawei smart phones LYO-L21 with software LYO-L21C479B107, LYO-L21C479B107 have a privilege escalation vulnerability. An authenticated, local attacker can crafts malformed packets after tricking a user to install a malicious application and exploit this vulnerability when in the exception handling process. Successful exploitation may cause the attacker to obtain a higher privilege of the smart phones. | |||||
| CVE-2017-14178 | 1 Snapcraft | 1 Snapd | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| In snapd 2.27 through 2.29.2 the 'snap logs' command could be made to call journalctl without match arguments and therefore allow unprivileged, unauthenticated users to bypass systemd-journald's access restrictions. | |||||
| CVE-2017-13199 | 1 Google | 1 Android | 2024-11-21 | 7.8 HIGH | 7.5 HIGH |
| In Bitmap.ccp if Bitmap.nativeCreate fails an out of memory exception is not thrown leading to a java.io.IOException later on. This could lead to a remote denial of service of a critical system process with no additional execution privileges needed. User interaction is not needed for exploitation. Product: Android. Versions: 8.0, 8.1. Android ID: A-33846679. | |||||
| CVE-2016-11034 | 1 Google | 1 Android | 2024-11-21 | 7.1 HIGH | 6.5 MEDIUM |
| An issue was discovered on Samsung mobile devices with L(5.0/5.1) and M(6.0) software. The decode function in Qjpeg in Qt 5.7 allows attackers to trigger a system crash via a malformed image. The Samsung ID is SVE-2016-6560 (October 2016). | |||||
| CVE-2016-11026 | 1 Google | 1 Android | 2024-11-21 | 7.8 HIGH | 7.5 HIGH |
| An issue was discovered on Samsung mobile devices with KK(4.4), L(5.0/5.1), and M(6.0) software. BootReceiver allows attackers to trigger a system crash because of incorrect exception handling. The Samsung ID is SVE-2016-7118 (December 2016). | |||||
| CVE-2015-2688 | 1 Torproject | 1 Tor | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| buf_pullup in Tor before 0.2.4.26 and 0.2.5.x before 0.2.5.11 does not properly handle unexpected arrival times of buffers with invalid layouts, which allows remote attackers to cause a denial of service (assertion failure and daemon exit) via crafted packets. | |||||
| CVE-2013-4584 | 2 Debian, Horms | 2 Debian Linux, Perdition | 2024-11-21 | 4.3 MEDIUM | 5.9 MEDIUM |
| Perdition before 2.2 may have weak security when handling outbound connections, caused by an error in the STARTTLS IMAP and POP server. ssl_outgoing_ciphers not being applied to STARTTLS connections | |||||
| CVE-2012-1109 | 1 Pediapress | 1 Mwlib | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| mwlib 0.13 through 0.13.4 has a denial of service vulnerability when parsing #iferror magic functions | |||||
| CVE-2011-4625 | 2 Debian, Simplesamlphp | 2 Debian Linux, Simplesamlphp | 2024-11-21 | 5.0 MEDIUM | 7.5 HIGH |
| simplesamlphp before 1.6.3 (squeeze) and before 1.8.2 (sid) incorrectly handles XML encryption which could allow remote attackers to decrypt or forge messages. | |||||
| CVE-2011-2807 | 1 Google | 1 Blink | 2024-11-21 | 4.3 MEDIUM | 6.5 MEDIUM |
| Incorrect handling of timer information in Timer.cpp in WebKit in Google Chrome before Blink M13. | |||||
| CVE-2011-2336 | 1 Google | 1 Blink | 2024-11-21 | 4.3 MEDIUM | 6.5 MEDIUM |
| An issue exists in WebKit in Google Chrome before Blink M12. when clearing lists in AnimationControllerPrivate that signal when a hardware animation starts. | |||||
| CVE-2009-5043 | 2 Burn Project, Debian | 2 Burn, Debian Linux | 2024-11-21 | 7.5 HIGH | 9.8 CRITICAL |
| burn allows file names to escape via mishandled quotation marks | |||||
| CVE-2024-50202 | 1 Linux | 1 Linux Kernel | 2024-11-19 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together. | |||||
| CVE-2024-8376 | 1 Eclipse | 1 Mosquitto | 2024-11-15 | N/A | 7.5 HIGH |
| In Eclipse Mosquitto up to version 2.0.18a, an attacker can achieve memory leaking, segmentation fault or heap-use-after-free by sending specific sequences of "CONNECT", "DISCONNECT", "SUBSCRIBE", "UNSUBSCRIBE" and "PUBLISH" packets. | |||||
| CVE-2024-51744 | 2024-11-05 | N/A | 3.1 LOW | ||
| golang-jwt is a Go implementation of JSON Web Tokens. Unclear documentation of the error behavior in `ParseWithClaims` can lead to situation where users are potentially not checking errors in the way they should be. Especially, if a token is both expired and invalid, the errors returned by `ParseWithClaims` return both error codes. If users only check for the `jwt.ErrTokenExpired ` using `error.Is`, they will ignore the embedded `jwt.ErrTokenSignatureInvalid` and thus potentially accept invalid tokens. A fix has been back-ported with the error handling logic from the `v5` branch to the `v4` branch. In this logic, the `ParseWithClaims` function will immediately return in "dangerous" situations (e.g., an invalid signature), limiting the combined errors only to situations where the signature is valid, but further validation failed (e.g., if the signature is valid, but is expired AND has the wrong audience). This fix is part of the 4.5.1 release. We are aware that this changes the behaviour of an established function and is not 100 % backwards compatible, so updating to 4.5.1 might break your code. In case you cannot update to 4.5.0, please make sure that you are properly checking for all errors ("dangerous" ones first), so that you are not running in the case detailed above. | |||||
| CVE-2024-50001 | 1 Linux | 1 Linux Kernel | 2024-10-30 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix error path in multi-packet WQE transmit Remove the erroneous unmap in case no DMA mapping was established The multi-packet WQE transmit code attempts to obtain a DMA mapping for the skb. This could fail, e.g. under memory pressure, when the IOMMU driver just can't allocate more memory for page tables. While the code tries to handle this in the path below the err_unmap label it erroneously unmaps one entry from the sq's FIFO list of active mappings. Since the current map attempt failed this unmap is removing some random DMA mapping that might still be required. If the PCI function now presents that IOVA, the IOMMU may assumes a rogue DMA access and e.g. on s390 puts the PCI function in error state. The erroneous behavior was seen in a stress-test environment that created memory pressure. | |||||
| CVE-2024-50002 | 1 Linux | 1 Linux Kernel | 2024-10-30 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; }; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. The first allocation succeeded and converted the key to a module chain. That first entry has mod::mod == NULL and mod::next == NULL, so the inner loop of static_call_del_module() will neither find a module match nor a module chain. The next site in the walk was either already converted, but can't match the module, or it will exit the outer loop because it has a static_call_site pointer and not a static_call_mod pointer. | |||||
| CVE-2024-47491 | 2024-10-17 | N/A | 5.9 MEDIUM | ||
| An Improper Handling of Exceptional Conditions vulnerability in the Routing Protocol Daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows a network-based, unauthenticated attacker to cause Denial of Service (DoS). When a BGP UPDATE with malformed path attribute is received over an established BGP session, rpd crashes and restarts. Continuous receipt of a BGP UPDATE with a specifically malformed path attribute will create a sustained Denial of Service (DoS) condition for impacted devices. While this issue affects systems running 32-bit and 64-bit systems, the probability of impact on 64-bit system is extremely low. According to KB25803 https://supportportal.juniper.net/s/article/Junos-How-to-check-if-Junos-OS-is-64-or-32-bit-on-a-router , customers can confirm 32-bit or 64-bit system via the ' show version detail ' command: lab@router> show version detail| match 32 JUNOS 32-bit kernel Software Suite lab@router> show version detail| match 64 JUNOS 64-bit kernel Software Suite This issue affects: Juniper Networks Junos OS: * All versions before 21.4R3-S8, * from 22.2 before 22.2R3-S4, * from 22.4 before 22.4R3-S3, * from 23.2 before 23.2R2-S1, * from 23.4 before 23.4R1-S2, 23.4R2. Juniper Networks Junos OS Evolved: * All versions before 21.4R3-S8-EVO, * from 22.2 before 22.2R3-S4-EVO, * from 22.4 before 22.4R3-S3-EVO, * from 23.2 before 23.2R2-S1-EVO, * from 23.4 before 23.4R1-S2-EVO, 23.4R2-EVO. | |||||
| CVE-2024-47767 | 1 Enalean | 1 Tuleap | 2024-10-17 | N/A | 4.3 MEDIUM |
| Tuleap is a tool for end to end traceability of application and system developments. Prior to Tuleap Community Edition 15.13.99.113, Tuleap Enterprise Edition 15.13-5, and Tuleap Enterprise Edition 15.12-5, users might see tracker names they should not have access to. Tuleap Community Edition 15.13.99.113, Tuleap Enterprise Edition 15.13-5, and Tuleap Enterprise Edition 15.12-8 fix this issue. | |||||