CVSS: -EPSS: 0%CPEs: 9EXPL: 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/4192adefc9c570698821c5eb9873320eac2fcbf1 https://git.kernel.org/stable/c/3c46d6060d3e38de22196c1fe7706c5a3c696285 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/d58a00e981d3118b91d503da263e640b7 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50005 – mac802154: Fix potential RCU dereference issue in mac802154_scan_worker
https://notcve.org/view.php?id=CVE-2024-50005
In the Linux kernel, the following vulnerability has been resolved: mac802154: Fix potential RCU dereference issue in mac802154_scan_worker In the `mac802154_scan_worker` function, the `scan_req->type` field was accessed after the RCU read-side critical section was unlocked. According to RCU usage rules, this is illegal and can lead to unpredictable behavior, such as accessing memory that has been updated or causing use-after-free issues. This possible bug was identified using a static analysis tool developed by myself, specifically designed to detect RCU-related issues. To address this, the `scan_req->type` value is now stored in a local variable `scan_req_type` while still within the RCU read-side critical section. The `scan_req_type` is then used after the RCU lock is released, ensuring that the type value is safely accessed without violating RCU rules. • https://git.kernel.org/stable/c/e2c3e6f53a7a8a00ffeed127cfd1b397c3b016f8 https://git.kernel.org/stable/c/e676e4ea76bbe7f1156d8c326b9b6753849481c2 https://git.kernel.org/stable/c/540138377b22f601f06f55ebfa3ca171dcab471a https://git.kernel.org/stable/c/d18f669461811dfe2915d5554ab2a9834f810013 https://git.kernel.org/stable/c/bff1709b3980bd7f80be6786f64cc9a9ee9e56da •
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: 6EXPL: 0CVE-2024-50002 – static_call: Handle module init failure correctly in static_call_del_module()
https://notcve.org/view.php?id=CVE-2024-50002
In the Linux kernel, the following vulnerability has been resolved: static_call: Handle module init failure correctly in static_call_del_module() Module insertion invokes static_call_add_module() to initialize the static calls in a module. static_call_add_module() invokes __static_call_init(), which allocates a struct static_call_mod to either encapsulate the built-in static call sites of the associated key into it so further modules can be added or to append the module to the module chain. If that allocation fails the function returns with an error code and the module core invokes static_call_del_module() to clean up eventually added static_call_mod entries. This works correctly, when all keys used by the module were converted over to a module chain before the failure. If not then static_call_del_module() causes a #GP as it blindly assumes that key::mods points to a valid struct static_call_mod. The problem is that key::mods is not a individual struct member of struct static_call_key, it's part of a union to save space: union { /* bit 0: 0 = mods, 1 = sites */ unsigned long type; struct static_call_mod *mods; struct static_call_site *sites; }; key::sites is a pointer to the list of built-in usage sites of the static call. The type of the pointer is differentiated by bit 0. A mods pointer has the bit clear, the sites pointer has the bit set. As static_call_del_module() blidly assumes that the pointer is a valid static_call_mod type, it fails to check for this failure case and dereferences the pointer to the list of built-in call sites, which is obviously bogus. Cure it by checking whether the key has a sites or a mods pointer. If it's a sites pointer then the key is not to be touched. As the sites are walked in the same order as in __static_call_init() the site walk can be terminated because all subsequent sites have not been touched by the init code due to the error exit. If it was converted before the allocation fail, then the inner loop which searches for a module match will find nothing. A fail in the second allocation in __static_call_init() is harmless and does not require special treatment. • https://git.kernel.org/stable/c/9183c3f9ed710a8edf1a61e8a96d497258d26e08 https://git.kernel.org/stable/c/ed4c8ce0f307f2ab8778aeb40a8866d171e8f128 https://git.kernel.org/stable/c/b566c7d8a2de403ccc9d8a06195e19bbb386d0e4 https://git.kernel.org/stable/c/c0abbbe8c98c077292221ec7e2baa667c9f0974c https://git.kernel.org/stable/c/2b494471797bff3d257e99dc0a7abb0c5ff3b4cd https://git.kernel.org/stable/c/9c48c2b53191bf991361998f5bb97b8f2fc5a89c https://git.kernel.org/stable/c/4b30051c4864234ec57290c3d142db7c88f10d8a •