Total
33519 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2024-54099 | 1 Huawei | 2 Emui, Harmonyos | 2025-09-18 | N/A | 6.7 MEDIUM |
| File replacement vulnerability on some devices Impact: Successful exploitation of this vulnerability will affect integrity and confidentiality. | |||||
| CVE-2024-51525 | 1 Huawei | 1 Harmonyos | 2025-09-18 | N/A | 6.2 MEDIUM |
| Permission control vulnerability in the clipboard module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2024-51516 | 1 Huawei | 1 Harmonyos | 2025-09-18 | N/A | 6.2 MEDIUM |
| Permission control vulnerability in the ability module Impact: Successful exploitation of this vulnerability may cause features to function abnormally. | |||||
| CVE-2024-51513 | 1 Huawei | 1 Harmonyos | 2025-09-18 | N/A | 5.5 MEDIUM |
| Vulnerability of processes not being fully terminated in the VPN module Impact: Successful exploitation of this vulnerability will affect power consumption. | |||||
| CVE-2024-45448 | 1 Huawei | 2 Emui, Harmonyos | 2025-09-18 | N/A | 4.1 MEDIUM |
| Page table protection configuration vulnerability in the trusted firmware module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2024-42039 | 1 Huawei | 2 Emui, Harmonyos | 2025-09-18 | N/A | 4.3 MEDIUM |
| Access control vulnerability in the SystemUI module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2024-42038 | 1 Huawei | 2 Emui, Harmonyos | 2025-09-18 | N/A | 8.8 HIGH |
| Vulnerability of PIN enhancement failures in the screen lock module Impact: Successful exploitation of this vulnerability may affect service confidentiality, integrity, and availability. | |||||
| CVE-2024-42036 | 1 Huawei | 2 Emui, Harmonyos | 2025-09-18 | N/A | 2.5 LOW |
| Access permission verification vulnerability in the Notepad module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2024-42035 | 1 Huawei | 2 Emui, Harmonyos | 2025-09-18 | N/A | 8.4 HIGH |
| Permission control vulnerability in the App Multiplier module Impact:Successful exploitation of this vulnerability may affect functionality and confidentiality. | |||||
| CVE-2024-42033 | 1 Huawei | 2 Emui, Harmonyos | 2025-09-18 | N/A | 6.9 MEDIUM |
| Access control vulnerability in the security verification module mpact: Successful exploitation of this vulnerability will affect integrity and confidentiality. | |||||
| CVE-2024-42032 | 1 Huawei | 2 Emui, Harmonyos | 2025-09-18 | N/A | 4.4 MEDIUM |
| Access permission verification vulnerability in the Contacts module Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2024-39673 | 1 Huawei | 2 Emui, Harmonyos | 2025-09-18 | N/A | 6.8 MEDIUM |
| Vulnerability of serialisation/deserialisation mismatch in the iAware module. Impact: Successful exploitation of this vulnerability may affect service confidentiality. | |||||
| CVE-2024-38566 | 1 Linux | 1 Linux Kernel | 2025-09-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: bpf: Fix verifier assumptions about socket->sk The verifier assumes that 'sk' field in 'struct socket' is valid and non-NULL when 'socket' pointer itself is trusted and non-NULL. That may not be the case when socket was just created and passed to LSM socket_accept hook. Fix this verifier assumption and adjust tests. | |||||
| CVE-2025-8007 | 1 Rockwellautomation | 10 1756-en2tr Series A, 1756-en2tr Series A Firmware, 1756-en2tr Series B and 7 more | 2025-09-17 | N/A | 6.5 MEDIUM |
| A security issue exists in the protected mode of 1756-EN4TR and 1756-EN2TR communication modules, where a Concurrent Forward Close operation can trigger a Major Non-Recoverable (MNFR) fault. This condition may lead to unexpected system crashes and loss of device availability. | |||||
| CVE-2024-40918 | 1 Linux | 1 Linux Kernel | 2025-09-17 | N/A | 6.3 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: parisc: Try to fix random segmentation faults in package builds PA-RISC systems with PA8800 and PA8900 processors have had problems with random segmentation faults for many years. Systems with earlier processors are much more stable. Systems with PA8800 and PA8900 processors have a large L2 cache which needs per page flushing for decent performance when a large range is flushed. The combined cache in these systems is also more sensitive to non-equivalent aliases than the caches in earlier systems. The majority of random segmentation faults that I have looked at appear to be memory corruption in memory allocated using mmap and malloc. My first attempt at fixing the random faults didn't work. On reviewing the cache code, I realized that there were two issues which the existing code didn't handle correctly. Both relate to cache move-in. Another issue is that the present bit in PTEs is racy. 1) PA-RISC caches have a mind of their own and they can speculatively load data and instructions for a page as long as there is a entry in the TLB for the page which allows move-in. TLBs are local to each CPU. Thus, the TLB entry for a page must be purged before flushing the page. This is particularly important on SMP systems. In some of the flush routines, the flush routine would be called and then the TLB entry would be purged. This was because the flush routine needed the TLB entry to do the flush. 2) My initial approach to trying the fix the random faults was to try and use flush_cache_page_if_present for all flush operations. This actually made things worse and led to a couple of hardware lockups. It finally dawned on me that some lines weren't being flushed because the pte check code was racy. This resulted in random inequivalent mappings to physical pages. The __flush_cache_page tmpalias flush sets up its own TLB entry and it doesn't need the existing TLB entry. As long as we can find the pte pointer for the vm page, we can get the pfn and physical address of the page. We can also purge the TLB entry for the page before doing the flush. Further, __flush_cache_page uses a special TLB entry that inhibits cache move-in. When switching page mappings, we need to ensure that lines are removed from the cache. It is not sufficient to just flush the lines to memory as they may come back. This made it clear that we needed to implement all the required flush operations using tmpalias routines. This includes flushes for user and kernel pages. After modifying the code to use tmpalias flushes, it became clear that the random segmentation faults were not fully resolved. The frequency of faults was worse on systems with a 64 MB L2 (PA8900) and systems with more CPUs (rp4440). The warning that I added to flush_cache_page_if_present to detect pages that couldn't be flushed triggered frequently on some systems. Helge and I looked at the pages that couldn't be flushed and found that the PTE was either cleared or for a swap page. Ignoring pages that were swapped out seemed okay but pages with cleared PTEs seemed problematic. I looked at routines related to pte_clear and noticed ptep_clear_flush. The default implementation just flushes the TLB entry. However, it was obvious that on parisc we need to flush the cache page as well. If we don't flush the cache page, stale lines will be left in the cache and cause random corruption. Once a PTE is cleared, there is no way to find the physical address associated with the PTE and flush the associated page at a later time. I implemented an updated change with a parisc specific version of ptep_clear_flush. It fixed the random data corruption on Helge's rp4440 and rp3440, as well as on my c8000. At this point, I realized that I could restore the code where we only flush in flush_cache_page_if_present if the page has been accessed. However, for this, we also need to flush the cache when the accessed bit is cleared in ---truncated--- | |||||
| CVE-2024-40925 | 1 Linux | 1 Linux Kernel | 2025-09-17 | N/A | 5.5 MEDIUM |
| In the Linux kernel, the following vulnerability has been resolved: block: fix request.queuelist usage in flush Friedrich Weber reported a kernel crash problem and bisected to commit 81ada09cc25e ("blk-flush: reuse rq queuelist in flush state machine"). The root cause is that we use "list_move_tail(&rq->queuelist, pending)" in the PREFLUSH/POSTFLUSH sequences. But rq->queuelist.next == xxx since it's popped out from plug->cached_rq in __blk_mq_alloc_requests_batch(). We don't initialize its queuelist just for this first request, although the queuelist of all later popped requests will be initialized. Fix it by changing to use "list_add_tail(&rq->queuelist, pending)" so rq->queuelist doesn't need to be initialized. It should be ok since rq can't be on any list when PREFLUSH or POSTFLUSH, has no move actually. Please note the commit 81ada09cc25e ("blk-flush: reuse rq queuelist in flush state machine") also has another requirement that no drivers would touch rq->queuelist after blk_mq_end_request() since we will reuse it to add rq to the post-flush pending list in POSTFLUSH. If this is not true, we will have to revert that commit IMHO. This updated version adds "list_del_init(&rq->queuelist)" in flush rq callback since the dm layer may submit request of a weird invalid format (REQ_FSEQ_PREFLUSH | REQ_FSEQ_POSTFLUSH), which causes double list_add if without this "list_del_init(&rq->queuelist)". The weird invalid format problem should be fixed in dm layer. | |||||
| CVE-2025-7890 | 1 Dunamu | 1 Stockplus | 2025-09-17 | 4.3 MEDIUM | 5.3 MEDIUM |
| A vulnerability was found in Dunamu StockPlus App up to 7.62.10 on Android. It has been declared as problematic. Affected by this vulnerability is an unknown functionality of the file AndroidManifest.xml of the component com.dunamu.stockplus. The manipulation leads to improper export of android application components. The attack needs to be approached locally. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | |||||
| CVE-2025-7891 | 1 Instantbits | 1 Web Video Cast | 2025-09-17 | 4.3 MEDIUM | 5.3 MEDIUM |
| A vulnerability was found in InstantBits Web Video Cast App up to 5.12.4 on Android. It has been rated as problematic. Affected by this issue is some unknown functionality of the file AndroidManifest.xml of the component com.instantbits.cast.webvideo. The manipulation leads to improper export of android application components. An attack has to be approached locally. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | |||||
| CVE-2025-7892 | 1 Idnow | 1 Idnow | 2025-09-17 | 4.3 MEDIUM | 5.3 MEDIUM |
| A vulnerability classified as problematic has been found in IDnow App up to 9.6.0 on Android. This affects an unknown part of the file AndroidManifest.xml of the component de.idnow. The manipulation leads to improper export of android application components. Local access is required to approach this attack. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | |||||
| CVE-2025-7893 | 1 Foresightnews | 1 Foresight News | 2025-09-17 | 4.3 MEDIUM | 5.3 MEDIUM |
| A vulnerability classified as problematic was found in Foresight News App up to 2.6.4 on Android. This vulnerability affects unknown code of the file AndroidManifest.xml of the component pro.foresightnews.appa. The manipulation leads to improper export of android application components. Attacking locally is a requirement. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way. | |||||