CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50006 – ext4: fix i_data_sem unlock order in ext4_ind_migrate()
https://notcve.org/view.php?id=CVE-2024-50006
In the Linux kernel, the following vulnerability has been resolved: ext4: fix i_data_sem unlock order in ext4_ind_migrate() Fuzzing reports a possible deadlock in jbd2_log_wait_commit. This issue is triggered when an EXT4_IOC_MIGRATE ioctl is set to require synchronous updates because the file descriptor is opened with O_SYNC. This can lead to the jbd2_journal_stop() function calling jbd2_might_wait_for_commit(), potentially causing a deadlock if the EXT4_IOC_MIGRATE call races with a write(2) system call. This problem only arises when CONFIG_PROVE_LOCKING is enabled. In this case, the jbd2_might_wait_for_commit macro locks jbd2_handle in the jbd2_journal_stop function while i_data_sem is locked. This triggers lockdep because the jbd2_journal_start function might also lock the same jbd2_handle simultaneously. Found by Linux Verification Center (linuxtesting.org) with syzkaller. Rule: add • https://git.kernel.org/stable/c/53b1999cfd2c7addf2e581a32865fe8835467b44 https://git.kernel.org/stable/c/ef05572da0c0eb89614ed01cc17d3c882bdbd1ff https://git.kernel.org/stable/c/9fedf51ab8cf7b69bff08f37fe0989fec7f5d870 https://git.kernel.org/stable/c/d43776b907659affef1de888525847d64b244194 https://git.kernel.org/stable/c/6252cb6bde7fc76cb8dcb49d1def7c326b190820 https://git.kernel.org/stable/c/d58a00e981d3118b91d503da263e640b7cde6729 https://git.kernel.org/stable/c/cc749e61c011c255d81b192a822db650c68b313f •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50004 – drm/amd/display: update DML2 policy EnhancedPrefetchScheduleAccelerationFinal DCN35
https://notcve.org/view.php?id=CVE-2024-50004
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: update DML2 policy EnhancedPrefetchScheduleAccelerationFinal DCN35 [WHY & HOW] Mismatch in DCN35 DML2 cause bw validation failed to acquire unexpected DPP pipe to cause grey screen and system hang. Remove EnhancedPrefetchScheduleAccelerationFinal value override to match HW spec. (cherry picked from commit 9dad21f910fcea2bdcff4af46159101d7f9cd8ba) • https://git.kernel.org/stable/c/945dc25eda88b5d6e30c9686dc619ab981c22d0e https://git.kernel.org/stable/c/4010efc8516899981cc3b57be2d4a2d5d9e50228 https://git.kernel.org/stable/c/0d5e5e8a0aa49ea2163abf128da3b509a6c58286 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50003 – drm/amd/display: Fix system hang while resume with TBT monitor
https://notcve.org/view.php?id=CVE-2024-50003
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix system hang while resume with TBT monitor [Why] Connected with a Thunderbolt monitor and do the suspend and the system may hang while resume. The TBT monitor HPD will be triggered during the resume procedure and call the drm_client_modeset_probe() while struct drm_connector connector->dev->master is NULL. It will mess up the pipe topology after resume. [How] Skip the TBT monitor HPD during the resume procedure because we currently will probe the connectors after resume by default. (cherry picked from commit 453f86a26945207a16b8f66aaed5962dc2b95b85) • https://git.kernel.org/stable/c/eb9329cd882aa274e92bdb1003bc088433fdee86 https://git.kernel.org/stable/c/722d2d8fc423108597b97efbf165187d16d9aa1e https://git.kernel.org/stable/c/68d603f467a75618eeae5bfe8af32cda47097010 https://git.kernel.org/stable/c/73e441be033d3ed0bdff09b575da3e7d4606ffc9 https://git.kernel.org/stable/c/c2356296f546326f9f06c109e201d42201e1e783 https://git.kernel.org/stable/c/52d4e3fb3d340447dcdac0e14ff21a764f326907 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49995 – tipc: guard against string buffer overrun
https://notcve.org/view.php?id=CVE-2024-49995
In the Linux kernel, the following vulnerability has been resolved: tipc: guard against string buffer overrun Smatch reports that copying media_name and if_name to name_parts may overwrite the destination. .../bearer.c:166 bearer_name_validate() error: strcpy() 'media_name' too large for 'name_parts->media_name' (32 vs 16) .../bearer.c:167 bearer_name_validate() error: strcpy() 'if_name' too large for 'name_parts->if_name' (1010102 vs 16) This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs. Introduced by commit b97bf3fd8f6a ("[TIPC] Initial merge") Compile tested only. • https://git.kernel.org/stable/c/e2b2558971e02ca33eb637a8350d68a48b3e8e46 https://git.kernel.org/stable/c/54dae0e9063ed23c9acf8d5ab9b18d3426a8ac18 https://git.kernel.org/stable/c/80c0be7bcf940ce9308311575c3aff8983c9b97a https://git.kernel.org/stable/c/12d26aa7fd3cbdbc5149b6e516563478d575026e https://git.kernel.org/stable/c/2ed7f42dfd3edb387034128ca5b0f639836d4ddd https://git.kernel.org/stable/c/a18c7b239d02aafb791ae2c45226f6bb40641792 https://git.kernel.org/stable/c/6555a2a9212be6983d2319d65276484f7c5f431a •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49994 – block: fix integer overflow in BLKSECDISCARD
https://notcve.org/view.php?id=CVE-2024-49994
In the Linux kernel, the following vulnerability has been resolved: block: fix integer overflow in BLKSECDISCARD I independently rediscovered commit 22d24a544b0d49bbcbd61c8c0eaf77d3c9297155 block: fix overflow in blk_ioctl_discard() but for secure erase. Same problem: uint64_t r[2] = {512, 18446744073709551104ULL}; ioctl(fd, BLKSECDISCARD, r); will enter near infinite loop inside blkdev_issue_secure_erase(): a.out: attempt to access beyond end of device loop0: rw=5, sector=3399043073, nr_sectors = 1024 limit=2048 bio_check_eod: 3286214 callbacks suppressed • https://git.kernel.org/stable/c/0842ddd83939eb4db940b9af7d39e79722bc41aa https://git.kernel.org/stable/c/6c9915fa9410cbb9bd75ee283c03120046c56d3d https://git.kernel.org/stable/c/697ba0b6ec4ae04afb67d3911799b5e2043b4455 •