Total
316927 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-54494 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2025-11-03 | N/A | 5.9 MEDIUM |
| A race condition was addressed with additional validation. This issue is fixed in iPadOS 17.7.3, watchOS 11.2, visionOS 2.2, tvOS 18.2, macOS Sequoia 15.2, iOS 18.2 and iPadOS 18.2, macOS Ventura 13.7.2, macOS Sonoma 14.7.2. An attacker may be able to create a read-only memory mapping that can be written to. | |||||
| CVE-2024-54493 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 3.3 LOW |
| This issue was addressed through improved state management. This issue is fixed in macOS Sequoia 15.2. Privacy indicators for microphone access may be attributed incorrectly. | |||||
| CVE-2024-54492 | 1 Apple | 4 Ipados, Iphone Os, Macos and 1 more | 2025-11-03 | N/A | 5.9 MEDIUM |
| This issue was addressed by using HTTPS when sending information over the network. This issue is fixed in macOS Sequoia 15.2, iOS 18.2 and iPadOS 18.2, iPadOS 17.7.3, visionOS 2.2. An attacker in a privileged network position may be able to alter network traffic. | |||||
| CVE-2024-54491 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 3.3 LOW |
| The issue was resolved by sanitizing logging This issue is fixed in macOS Sequoia 15.2. A malicious application may be able to determine a user's current location. | |||||
| CVE-2024-54490 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 5.5 MEDIUM |
| This issue was addressed by enabling hardened runtime. This issue is fixed in macOS Sequoia 15.2. A local attacker may gain access to user's Keychain items. | |||||
| CVE-2024-54489 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 7.8 HIGH |
| A path handling issue was addressed with improved validation. This issue is fixed in macOS Sequoia 15.2, macOS Ventura 13.7.2, macOS Sonoma 14.7.2. Running a mount command may unexpectedly execute arbitrary code. | |||||
| CVE-2024-54486 | 1 Apple | 6 Ipados, Iphone Os, Macos and 3 more | 2025-11-03 | N/A | 6.5 MEDIUM |
| The issue was addressed with improved checks. This issue is fixed in iPadOS 17.7.3, watchOS 11.2, visionOS 2.2, tvOS 18.2, macOS Sequoia 15.2, iOS 18.2 and iPadOS 18.2, macOS Ventura 13.7.2, macOS Sonoma 14.7.2. Processing a maliciously crafted font may result in the disclosure of process memory. | |||||
| CVE-2024-54485 | 1 Apple | 2 Ipados, Iphone Os | 2025-11-03 | N/A | 2.4 LOW |
| The issue was addressed by adding additional logic. This issue is fixed in iPadOS 17.7.3, iOS 18.2 and iPadOS 18.2. An attacker with physical access to an iOS device may be able to view notification content from the lock screen. | |||||
| CVE-2024-54484 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 5.5 MEDIUM |
| The issue was resolved by sanitizing logging. This issue is fixed in macOS Sequoia 15.2. An app may be able to access user-sensitive data. | |||||
| CVE-2024-54479 | 1 Apple | 7 Ipados, Iphone Os, Macos and 4 more | 2025-11-03 | N/A | 7.5 HIGH |
| The issue was addressed with improved checks. This issue is fixed in iPadOS 17.7.3, watchOS 11.2, visionOS 2.2, tvOS 18.2, macOS Sequoia 15.2, Safari 18.2, iOS 18.2 and iPadOS 18.2. Processing maliciously crafted web content may lead to an unexpected process crash. | |||||
| CVE-2024-54477 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 5.5 MEDIUM |
| The issue was addressed with improved checks. This issue is fixed in macOS Sequoia 15.2, macOS Ventura 13.7.2, macOS Sonoma 14.7.2. An app may be able to access user-sensitive data. | |||||
| CVE-2024-54476 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 5.5 MEDIUM |
| The issue was addressed with improved checks. This issue is fixed in macOS Sequoia 15.2, macOS Ventura 13.7.2, macOS Sonoma 14.7.2. An app may be able to access user-sensitive data. | |||||
| CVE-2024-54474 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 5.5 MEDIUM |
| The issue was addressed with improved checks. This issue is fixed in macOS Sequoia 15.2, macOS Ventura 13.7.2, macOS Sonoma 14.7.2. An app may be able to access user-sensitive data. | |||||
| CVE-2024-54466 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 5.3 MEDIUM |
| An authorization issue was addressed with improved state management. This issue is fixed in macOS Sequoia 15.2, macOS Ventura 13.7.2, macOS Sonoma 14.7.2. An encrypted volume may be accessed by a different user without prompting for the password. | |||||
| CVE-2024-54465 | 1 Apple | 1 Macos | 2025-11-03 | N/A | 9.8 CRITICAL |
| A logic issue was addressed with improved state management. This issue is fixed in macOS Sequoia 15.2. An app may be able to elevate privileges. | |||||
| CVE-2024-53849 | 2025-11-03 | N/A | N/A | ||
| editorconfig-core-c is theEditorConfig core library written in C (for use by plugins supporting EditorConfig parsing). In affected versions several overflows may occur in switch case '[' when the input pattern contains many escaped characters. The added backslashes leave too little space in the output pattern when processing nested brackets such that the remaining input length exceeds the output capacity. This issue has been addressed in release version 0.12.7. Users are advised to upgrade. There are no known workarounds for this vulnerability. | |||||
| CVE-2024-53144 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_event: Align BR/EDR JUST_WORKS paring with LE This aligned BR/EDR JUST_WORKS method with LE which since 92516cd97fd4 ("Bluetooth: Always request for user confirmation for Just Works") always request user confirmation with confirm_hint set since the likes of bluetoothd have dedicated policy around JUST_WORKS method (e.g. main.conf:JustWorksRepairing). CVE: CVE-2024-8805 | |||||
| CVE-2024-53140 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: netlink: terminate outstanding dump on socket close Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket. This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done. The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed. Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one. The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress. Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own. | |||||
| CVE-2024-53138 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: kTLS, Fix incorrect page refcounting The kTLS tx handling code is using a mix of get_page() and page_ref_inc() APIs to increment the page reference. But on the release path (mlx5e_ktls_tx_handle_resync_dump_comp()), only put_page() is used. This is an issue when using pages from large folios: the get_page() references are stored on the folio page while the page_ref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times. This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 ("nfs: add support for large folios")). | |||||
| CVE-2024-53136 | 1 Linux | 1 Linux Kernel | 2025-11-03 | N/A | 4.7 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: mm: revert "mm: shmem: fix data-race in shmem_getattr()" Revert d949d1d14fa2 ("mm: shmem: fix data-race in shmem_getattr()") as suggested by Chuck [1]. It is causing deadlocks when accessing tmpfs over NFS. As Hugh commented, "added just to silence a syzbot sanitizer splat: added where there has never been any practical problem". | |||||