CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42317 – mm/huge_memory: avoid PMD-size page cache if needed
https://notcve.org/view.php?id=CVE-2024-42317
In the Linux kernel, the following vulnerability has been resolved: mm/huge_memory: avoid PMD-size page cache if needed xarray can't support arbitrary page cache size. the largest and supported page cache size is defined as MAX_PAGECACHE_ORDER by commit 099d90642a71 ("mm/filemap: make MAX_PAGECACHE_ORDER acceptable to xarray"). However, it's possible to have 512MB page cache in the huge memory's collapsing path on ARM64 system whose base page size is 64KB. 512MB page cache is breaking the limitation and a warning is raised when the xarray entry is split as shown in the following example. [root@dhcp-10-26-1-207 ~]# cat /proc/1/smaps | grep KernelPageSize KernelPageSize: 64 kB [root@dhcp-10-26-1-207 ~]# cat /tmp/test.c : int main(int argc, char **argv) { const char *filename = TEST_XFS_FILENAME; int fd = 0; void *buf = (void *)-1, *p; int pgsize = getpagesize(); int ret = 0; if (pgsize != 0x10000) { fprintf(stdout, "System with 64KB base page size is required!\n"); return -EPERM; } system("echo 0 > /sys/devices/virtual/bdi/253:0/read_ahead_kb"); system("echo 1 > /proc/sys/vm/drop_caches"); /* Open the xfs file */ fd = open(filename, O_RDONLY); assert(fd > 0); /* Create VMA */ buf = mmap(NULL, TEST_MEM_SIZE, PROT_READ, MAP_SHARED, fd, 0); assert(buf ! • https://git.kernel.org/stable/c/6b24ca4a1a8d4ee3221d6d44ddbb99f542e4bda3 https://git.kernel.org/stable/c/e60f62f75c99740a28e2bf7e6044086033012a16 https://git.kernel.org/stable/c/d659b715e94ac039803d7601505d3473393fc0be •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42316 – mm/mglru: fix div-by-zero in vmpressure_calc_level()
https://notcve.org/view.php?id=CVE-2024-42316
In the Linux kernel, the following vulnerability has been resolved: mm/mglru: fix div-by-zero in vmpressure_calc_level() evict_folios() uses a second pass to reclaim folios that have gone through page writeback and become clean before it finishes the first pass, since folio_rotate_reclaimable() cannot handle those folios due to the isolation. The second pass tries to avoid potential double counting by deducting scan_control->nr_scanned. However, this can result in underflow of nr_scanned, under a condition where shrink_folio_list() does not increment nr_scanned, i.e., when folio_trylock() fails. The underflow can cause the divisor, i.e., scale=scanned+reclaimed in vmpressure_calc_level(), to become zero, resulting in the following crash: [exception RIP: vmpressure_work_fn+101] process_one_work at ffffffffa3313f2b Since scan_control->nr_scanned has no established semantics, the potential double counting has minimal risks. Therefore, fix the problem by not deducting scan_control->nr_scanned in evict_folios(). • https://git.kernel.org/stable/c/359a5e1416caaf9ce28396a65ed3e386cc5de663 https://git.kernel.org/stable/c/8de7bf77f21068a5f602bb1e59adbc5ab533509d https://git.kernel.org/stable/c/d6510f234c7d117790397f9bb150816b0a954a04 https://git.kernel.org/stable/c/a39e38be632f0e1c908d70d1c9cd071c03faf895 https://git.kernel.org/stable/c/8b671fe1a879923ecfb72dda6caf01460dd885ef •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42315 – exfat: fix potential deadlock on __exfat_get_dentry_set
https://notcve.org/view.php?id=CVE-2024-42315
In the Linux kernel, the following vulnerability has been resolved: exfat: fix potential deadlock on __exfat_get_dentry_set When accessing a file with more entries than ES_MAX_ENTRY_NUM, the bh-array is allocated in __exfat_get_entry_set. The problem is that the bh-array is allocated with GFP_KERNEL. It does not make sense. In the following cases, a deadlock for sbi->s_lock between the two processes may occur. CPU0 CPU1 ---- ---- kswapd balance_pgdat lock(fs_reclaim) exfat_iterate lock(&sbi->s_lock) exfat_readdir exfat_get_uniname_from_ext_entry exfat_get_dentry_set __exfat_get_dentry_set kmalloc_array ... lock(fs_reclaim) ... evict exfat_evict_inode lock(&sbi->s_lock) To fix this, let's allocate bh-array with GFP_NOFS. • https://git.kernel.org/stable/c/bd3bdb9e0d656f760b11d0c638d35d7f7068144d https://git.kernel.org/stable/c/92dcd7d6c6068bf4fd35a6f64d606e27d634807e https://git.kernel.org/stable/c/a3ff29a95fde16906304455aa8c0bd84eb770258 https://git.kernel.org/stable/c/632fb232b6bbf8277edcbe9ecd4b4d98ecb122eb https://git.kernel.org/stable/c/c052f775ee6ccacd3c97e4cf41a2a657e63d4259 https://git.kernel.org/stable/c/a7ac198f8dba791e3144c4da48a5a9b95773ee4b https://git.kernel.org/stable/c/1d1970493c289e3f44b9ec847ed26a5dbdf56a62 https://git.kernel.org/stable/c/89fc548767a2155231128cb98726d6d2e •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42314 – btrfs: fix extent map use-after-free when adding pages to compressed bio
https://notcve.org/view.php?id=CVE-2024-42314
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix extent map use-after-free when adding pages to compressed bio At add_ra_bio_pages() we are accessing the extent map to calculate 'add_size' after we dropped our reference on the extent map, resulting in a use-after-free. Fix this by computing 'add_size' before dropping our extent map reference. • https://git.kernel.org/stable/c/6a4049102055250256623ab1875fabd89004bff8 https://git.kernel.org/stable/c/c1cc3326e27b0bd7a2806b40bc48e49afaf951e7 https://git.kernel.org/stable/c/c205565e0f2f439f278a4a94ee97b67ef7b56ae8 https://git.kernel.org/stable/c/b7859ff398b6b656e1689daa860eb34837b4bb89 https://git.kernel.org/stable/c/8e7860543a94784d744c7ce34b78a2e11beefa5c •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42313 – media: venus: fix use after free in vdec_close
https://notcve.org/view.php?id=CVE-2024-42313
In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free in vdec_close There appears to be a possible use after free with vdec_close(). The firmware will add buffer release work to the work queue through HFI callbacks as a normal part of decoding. Randomly closing the decoder device from userspace during normal decoding can incur a read after free for inst. Fix it by cancelling the work in vdec_close. • https://git.kernel.org/stable/c/af2c3834c8ca7cc65d15592ac671933df8848115 https://git.kernel.org/stable/c/ad8cf035baf29467158e0550c7a42b7bb43d1db6 https://git.kernel.org/stable/c/72aff311194c8ceda934f24fd6f250b8827d7567 https://git.kernel.org/stable/c/4c9d235630d35db762b85a4149bbb0be9d504c36 https://git.kernel.org/stable/c/f8e9a63b982a8345470c225679af4ba86e4a7282 https://git.kernel.org/stable/c/da55685247f409bf7f976cc66ba2104df75d8dad https://git.kernel.org/stable/c/66fa52edd32cdbb675f0803b3c4da10ea19b6635 https://git.kernel.org/stable/c/6a96041659e834dc0b172dda4b2df512d •