CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-43828 – ext4: fix infinite loop when replaying fast_commit
https://notcve.org/view.php?id=CVE-2024-43828
In the Linux kernel, the following vulnerability has been resolved: ext4: fix infinite loop when replaying fast_commit When doing fast_commit replay an infinite loop may occur due to an uninitialized extent_status struct. ext4_ext_determine_insert_hole() does not detect the replay and calls ext4_es_find_extent_range(), which will return immediately without initializing the 'es' variable. Because 'es' contains garbage, an integer overflow may happen causing an infinite loop in this function, easily reproducible using fstest generic/039. This commit fixes this issue by unconditionally initializing the structure in function ext4_es_find_extent_range(). Thanks to Zhang Yi, for figuring out the real problem! • https://git.kernel.org/stable/c/8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2 https://git.kernel.org/stable/c/5ed0496e383cb6de120e56991385dce70bbb87c1 https://git.kernel.org/stable/c/0619f7750f2b178a1309808832ab20d85e0ad121 https://git.kernel.org/stable/c/181e63cd595c688194e07332f9944b3a63193de2 https://git.kernel.org/stable/c/c6e67df64783e99a657ef2b8c834ba2bf54c539c https://git.kernel.org/stable/c/81f819c537d29932e4b9267f02411cbc8b355178 https://git.kernel.org/stable/c/907c3fe532253a6ef4eb9c4d67efb71fab58c706 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43827 – drm/amd/display: Add null check before access structs
https://notcve.org/view.php?id=CVE-2024-43827
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Add null check before access structs In enable_phantom_plane, we should better check null pointer before accessing various structs. • https://git.kernel.org/stable/c/09a4ec5da92c84952db117f0d576fdd8368c873a https://git.kernel.org/stable/c/081ff4c0ef1884ae55f7adb8944efd22e22d8724 https://git.kernel.org/stable/c/c96140000915b610d86f941450e15ca552de154a •
CVSS: 4.4EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43826 – nfs: pass explicit offset/count to trace events
https://notcve.org/view.php?id=CVE-2024-43826
In the Linux kernel, the following vulnerability has been resolved: nfs: pass explicit offset/count to trace events nfs_folio_length is unsafe to use without having the folio locked and a check for a NULL ->f_mapping that protects against truncations and can lead to kernel crashes. E.g. when running xfstests generic/065 with all nfs trace points enabled. Follow the model of the XFS trace points and pass in an explŃ–cit offset and length. This has the additional benefit that these values can be more accurate as some of the users touch partial folio ranges. • https://git.kernel.org/stable/c/eb5654b3b89d5e836312cea9f3fdb49457852e89 https://git.kernel.org/stable/c/387e6e9d110250946df4d4ebef9c2def5c7a4722 https://git.kernel.org/stable/c/fada32ed6dbc748f447c8d050a961b75d946055a https://access.redhat.com/security/cve/CVE-2024-43826 https://bugzilla.redhat.com/show_bug.cgi?id=2305484 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-43825 – iio: Fix the sorting functionality in iio_gts_build_avail_time_table
https://notcve.org/view.php?id=CVE-2024-43825
In the Linux kernel, the following vulnerability has been resolved: iio: Fix the sorting functionality in iio_gts_build_avail_time_table The sorting in iio_gts_build_avail_time_table is not working as intended. It could result in an out-of-bounds access when the time is zero. Here are more details: 1. When the gts->itime_table[i].time_us is zero, e.g., the time sequence is `3, 0, 1`, the inner for-loop will not terminate and do out-of-bound writes. This is because once `times[j] > new`, the value `new` will be added in the current position and the `times[j]` will be moved to `j+1` position, which makes the if-condition always hold. Meanwhile, idx will be added one, making the loop keep running without termination and out-of-bound write. 2. If none of the gts->itime_table[i].time_us is zero, the elements will just be copied without being sorted as described in the comment "Sort times from all tables to one and remove duplicates". For more details, please refer to https://lore.kernel.org/all/6dd0d822-046c-4dd2-9532-79d7ab96ec05@gmail.com. • https://git.kernel.org/stable/c/38416c28e16890b52fdd5eb73479299ec3f062f3 https://git.kernel.org/stable/c/31ff8464ef540785344994986a010031410f9ff3 https://git.kernel.org/stable/c/b5046de32fd1532c3f67065197fc1da82f0b5193 https://git.kernel.org/stable/c/5acc3f971a01be48d5ff4252d8f9cdb87998cdfb •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43824 – PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init()
https://notcve.org/view.php?id=CVE-2024-43824
In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init() Instead of getting the epc_features from pci_epc_get_features() API, use the cached pci_epf_test::epc_features value to avoid the NULL check. Since the NULL check is already performed in pci_epf_test_bind(), having one more check in pci_epf_test_core_init() is redundant and it is not possible to hit the NULL pointer dereference. Also with commit a01e7214bef9 ("PCI: endpoint: Remove "core_init_notifier" flag"), 'epc_features' got dereferenced without the NULL check, leading to the following false positive Smatch warning: drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed 'epc_features' could be null (see line 747) Thus, remove the redundant NULL check and also use the epc_features:: {msix_capable/msi_capable} flags directly to avoid local variables. [kwilczynski: commit log] • https://git.kernel.org/stable/c/5e50ee27d4a52a817ab152128c48690ec7c5cdf1 https://git.kernel.org/stable/c/af4ad016abb1632ff7ee598a6037952b495e5b80 https://git.kernel.org/stable/c/5a5095a8bd1bd349cce1c879e5e44407a34dda8a •