Total
29495 CVE
CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
---|---|---|---|---|---|
CVE-2024-42233 | 1 Linux | 1 Linux Kernel | 2024-08-08 | N/A | 3.3 LOW |
In the Linux kernel, the following vulnerability has been resolved: filemap: replace pte_offset_map() with pte_offset_map_nolock() The vmf->ptl in filemap_fault_recheck_pte_none() is still set from handle_pte_fault(). But at the same time, we did a pte_unmap(vmf->pte). After a pte_unmap(vmf->pte) unmap and rcu_read_unlock(), the page table may be racily changed and vmf->ptl maybe fails to protect the actual page table. Fix this by replacing pte_offset_map() with pte_offset_map_nolock(). As David said, the PTL pointer might be stale so if we continue to use it infilemap_fault_recheck_pte_none(), it might trigger UAF. Also, if the PTL fails, the issue fixed by commit 58f327f2ce80 ("filemap: avoid unnecessary major faults in filemap_fault()") might reappear. | |||||
CVE-2024-42243 | 1 Linux | 1 Linux Kernel | 2024-08-08 | N/A | 5.5 MEDIUM |
In the Linux kernel, the following vulnerability has been resolved: mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray Patch series "mm/filemap: Limit page cache size to that supported by xarray", v2. Currently, xarray can't support arbitrary page cache size. More details can be found from the WARN_ON() statement in xas_split_alloc(). In our test whose code is attached below, we hit the WARN_ON() on ARM64 system where the base page size is 64KB and huge page size is 512MB. The issue was reported long time ago and some discussions on it can be found here [1]. [1] https://www.spinics.net/lists/linux-xfs/msg75404.html In order to fix the issue, we need to adjust MAX_PAGECACHE_ORDER to one supported by xarray and avoid PMD-sized page cache if needed. The code changes are suggested by David Hildenbrand. PATCH[1] adjusts MAX_PAGECACHE_ORDER to that supported by xarray PATCH[2-3] avoids PMD-sized page cache in the synchronous readahead path PATCH[4] avoids PMD-sized page cache for shmem files if needed Test program ============ # cat test.c #define _GNU_SOURCE #include <stdio.h> #include <stdlib.h> #include <unistd.h> #include <string.h> #include <fcntl.h> #include <errno.h> #include <sys/syscall.h> #include <sys/mman.h> #define TEST_XFS_FILENAME "/tmp/data" #define TEST_SHMEM_FILENAME "/dev/shm/data" #define TEST_MEM_SIZE 0x20000000 int main(int argc, char **argv) { const char *filename; int fd = 0; void *buf = (void *)-1, *p; int pgsize = getpagesize(); int ret; if (pgsize != 0x10000) { fprintf(stderr, "64KB base page size is required\n"); return -EPERM; } system("echo force > /sys/kernel/mm/transparent_hugepage/shmem_enabled"); system("rm -fr /tmp/data"); system("rm -fr /dev/shm/data"); system("echo 1 > /proc/sys/vm/drop_caches"); /* Open xfs or shmem file */ filename = TEST_XFS_FILENAME; if (argc > 1 && !strcmp(argv[1], "shmem")) filename = TEST_SHMEM_FILENAME; fd = open(filename, O_CREAT | O_RDWR | O_TRUNC); if (fd < 0) { fprintf(stderr, "Unable to open <%s>\n", filename); return -EIO; } /* Extend file size */ ret = ftruncate(fd, TEST_MEM_SIZE); if (ret) { fprintf(stderr, "Error %d to ftruncate()\n", ret); goto cleanup; } /* Create VMA */ buf = mmap(NULL, TEST_MEM_SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0); if (buf == (void *)-1) { fprintf(stderr, "Unable to mmap <%s>\n", filename); goto cleanup; } fprintf(stdout, "mapped buffer at 0x%p\n", buf); ret = madvise(buf, TEST_MEM_SIZE, MADV_HUGEPAGE); if (ret) { fprintf(stderr, "Unable to madvise(MADV_HUGEPAGE)\n"); goto cleanup; } /* Populate VMA */ ret = madvise(buf, TEST_MEM_SIZE, MADV_POPULATE_WRITE); if (ret) { fprintf(stderr, "Error %d to madvise(MADV_POPULATE_WRITE)\n", ret); goto cleanup; } /* Punch the file to enforce xarray split */ ret = fallocate(fd, FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE, TEST_MEM_SIZE - pgsize, pgsize); if (ret) fprintf(stderr, "Error %d to fallocate()\n", ret); cleanup: if (buf != (void *)-1) munmap(buf, TEST_MEM_SIZE); if (fd > 0) close(fd); return 0; } # gcc test.c -o test # cat /proc/1/smaps | grep KernelPageSize | head -n 1 KernelPageSize: 64 kB # ./test shmem : ------------[ cut here ]------------ WARNING: CPU: 17 PID: 5253 at lib/xarray.c:1025 xas_split_alloc+0xf8/0x128 Modules linked in: nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib \ nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct \ nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 \ ip_set nf_tables rfkill nfnetlink vfat fat virtio_balloon \ drm fuse xfs libcrc32c crct10dif_ce ghash_ce sha2_ce sha256_arm64 \ virtio_net sha1_ce net_failover failover virtio_console virtio_blk \ dimlib virtio_mmio CPU: 17 PID: 5253 Comm: test Kdump: loaded Tainted: G W 6.10.0-rc5-gavin+ #12 Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-1.el9 05/24/2024 pstate: 83400005 (Nzcv daif +PAN -UAO +TC ---truncated--- | |||||
CVE-2024-42244 | 1 Linux | 1 Linux Kernel | 2024-08-08 | N/A | 5.5 MEDIUM |
In the Linux kernel, the following vulnerability has been resolved: USB: serial: mos7840: fix crash on resume Since commit c49cfa917025 ("USB: serial: use generic method if no alternative is provided in usb serial layer"), USB serial core calls the generic resume implementation when the driver has not provided one. This can trigger a crash on resume with mos7840 since support for multiple read URBs was added back in 2011. Specifically, both port read URBs are now submitted on resume for open ports, but the context pointer of the second URB is left set to the core rather than mos7840 port structure. Fix this by implementing dedicated suspend and resume functions for mos7840. Tested with Delock 87414 USB 2.0 to 4x serial adapter. [ johan: analyse crash and rewrite commit message; set busy flag on resume; drop bulk-in check; drop unnecessary usb_kill_urb() ] | |||||
CVE-2024-7001 | 1 Google | 1 Chrome | 2024-08-07 | N/A | 4.3 MEDIUM |
Inappropriate implementation in HTML in Google Chrome prior to 127.0.6533.72 allowed a remote attacker who convinced a user to engage in specific UI gestures to perform UI spoofing via a crafted HTML page. (Chromium security severity: Medium) | |||||
CVE-2024-23464 | 1 Zscaler | 1 Client Connector | 2024-08-07 | N/A | 4.9 MEDIUM |
In certain cases, Zscaler Internet Access (ZIA) can be disabled by PowerShell commands with admin rights. This affects Zscaler Client Connector on Windows <4.2.1 | |||||
CVE-2024-41990 | 1 Djangoproject | 1 Django | 2024-08-07 | N/A | 7.5 HIGH |
An issue was discovered in Django 5.0 before 5.0.8 and 4.2 before 4.2.15. The urlize() and urlizetrunc() template filters are subject to a potential denial-of-service attack via very large inputs with a specific sequence of characters. | |||||
CVE-2024-6995 | 1 Google | 2 Android, Chrome | 2024-08-07 | N/A | 4.7 MEDIUM |
Inappropriate implementation in Fullscreen in Google Chrome on Android prior to 127.0.6533.72 allowed a remote attacker who convinced a user to engage in specific UI gestures to spoof the contents of the Omnibox (URL bar) via a crafted HTML page. (Chromium security severity: Medium) | |||||
CVE-2024-7005 | 1 Google | 1 Chrome | 2024-08-07 | N/A | 4.3 MEDIUM |
Insufficient validation of untrusted input in Safe Browsing in Google Chrome prior to 127.0.6533.72 allowed a remote attacker who convinced a user to engage in specific UI gestures to bypass discretionary access control via a malicious file. (Chromium security severity: Low) | |||||
CVE-2018-17793 | 2024-02-28 | N/A | N/A | ||
Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none | |||||
CVE-2012-2639 | 2024-02-28 | N/A | N/A | ||
Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2011-4940. Reason: This candidate is a reservation duplicate of CVE-2011-4940. Notes: All CVE users should reference CVE-2011-4940 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage | |||||
CVE-2010-0200 | 2024-02-28 | N/A | N/A | ||
Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2010-1241. Reason: This candidate is a duplicate of CVE-2010-1241. Notes: All CVE users should reference CVE-2010-1241 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage | |||||
CVE-2008-2033 | 2024-02-28 | N/A | N/A | ||
Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2008-1381. Reason: This candidate is a duplicate of CVE-2008-1381. Notes: All CVE users should reference CVE-2008-1381 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage | |||||
CVE-2007-4576 | 2024-02-28 | N/A | N/A | ||
Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2007-4575. Reason: This candidate is a reservation duplicate of CVE-2007-4575. Notes: All CVE users should reference CVE-2007-4575 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage | |||||
CVE-2007-6440 | 2024-02-28 | N/A | N/A | ||
Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2007-6112. Reason: This candidate is a duplicate of CVE-2007-6112. Notes: All CVE users should reference CVE-2007-6112 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage | |||||
CVE-2007-6445 | 2024-02-28 | N/A | N/A | ||
Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2007-6117. Reason: This candidate is a duplicate of CVE-2007-6117. Notes: All CVE users should reference CVE-2007-6117 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage |