CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-43829 – drm/qxl: Add check for drm_cvt_mode
https://notcve.org/view.php?id=CVE-2024-43829
In the Linux kernel, the following vulnerability has been resolved: drm/qxl: Add check for drm_cvt_mode Add check for the return value of drm_cvt_mode() and return the error if it fails in order to avoid NULL pointer dereference. • https://git.kernel.org/stable/c/1b043677d4be206c96b51811855502e50057f343 https://git.kernel.org/stable/c/62ef8d7816c8e4a6088275553818b9afc0ffaa03 https://git.kernel.org/stable/c/4e87f592a46bb804d8f833da6ce702ae4b55053f https://git.kernel.org/stable/c/3efe34f95b1ac8c138a46b14ce75956db0d6ee7c https://git.kernel.org/stable/c/f28b353c0c6c7831a70ccca881bf2db5e6785cdd https://git.kernel.org/stable/c/4b1f303bdeceac049e56e4b20eb5280bd9e02f4f https://git.kernel.org/stable/c/d4c57354a06cb4a77998ff8aa40af89eee30e07b https://git.kernel.org/stable/c/7bd09a2db0f617377027a2bb0b9179e69 •
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: -EPSS: 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 •
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 •