CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-47661 – drm/amd/display: Avoid overflow from uint32_t to uint8_t
https://notcve.org/view.php?id=CVE-2024-47661
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Avoid overflow from uint32_t to uint8_t [WHAT & HOW] dmub_rb_cmd's ramping_boundary has size of uint8_t and it is assigned 0xFFFF. Fix it by changing it to uint8_t with value of 0xFF. This fixes 2 INTEGER_OVERFLOW issues reported by Coverity. • https://git.kernel.org/stable/c/30d1b783b6eeaf49d311a072c70d618d993d01ec https://git.kernel.org/stable/c/d6b54900c564e35989cf6813e4071504fa0a90e0 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-47660 – fsnotify: clear PARENT_WATCHED flags lazily
https://notcve.org/view.php?id=CVE-2024-47660
In the Linux kernel, the following vulnerability has been resolved: fsnotify: clear PARENT_WATCHED flags lazily In some setups directories can have many (usually negative) dentries. Hence __fsnotify_update_child_dentry_flags() function can take a significant amount of time. Since the bulk of this function happens under inode->i_lock this causes a significant contention on the lock when we remove the watch from the directory as the __fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask() races with __fsnotify_update_child_dentry_flags() calls from __fsnotify_parent() happening on children. This can lead upto softlockup reports reported by users. Fix the problem by calling fsnotify_update_children_dentry_flags() to set PARENT_WATCHED flags only when parent starts watching children. When parent stops watching children, clear false positive PARENT_WATCHED flags lazily in __fsnotify_parent() for each accessed child. • https://git.kernel.org/stable/c/3f3ef1d9f66b93913ce2171120d9226b55acd41d https://git.kernel.org/stable/c/f9a48bc3dd9099935751458a5bbbea4b7c28abc8 https://git.kernel.org/stable/c/d8c42405fc3507cc43ba7e4986a773c3fc633f6e https://git.kernel.org/stable/c/fc1b1e135c3f72382f792e6c319fc088d5523ad5 https://git.kernel.org/stable/c/7ef1d2e240c32b1f337a37232d037b07e3919e1a https://git.kernel.org/stable/c/172e422ffea20a89bfdc672741c1aad6fbb5044e •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-47659 – smack: tcp: ipv4, fix incorrect labeling
https://notcve.org/view.php?id=CVE-2024-47659
In the Linux kernel, the following vulnerability has been resolved: smack: tcp: ipv4, fix incorrect labeling Currently, Smack mirrors the label of incoming tcp/ipv4 connections: when a label 'foo' connects to a label 'bar' with tcp/ipv4, 'foo' always gets 'foo' in returned ipv4 packets. So, 1) returned packets are incorrectly labeled ('foo' instead of 'bar') 2) 'bar' can write to 'foo' without being authorized to write. Here is a scenario how to see this: * Take two machines, let's call them C and S, with active Smack in the default state (no settings, no rules, no labeled hosts, only builtin labels) * At S, add Smack rule 'foo bar w' (labels 'foo' and 'bar' are instantiated at S at this moment) * At S, at label 'bar', launch a program that listens for incoming tcp/ipv4 connections * From C, at label 'foo', connect to the listener at S. (label 'foo' is instantiated at C at this moment) Connection succeedes and works. * Send some data in both directions. * Collect network traffic of this connection. All packets in both directions are labeled with the CIPSO of the label 'foo'. Hence, label 'bar' writes to 'foo' without being authorized, and even without ever being known at C. If anybody cares: exactly the same happens with DCCP. This behavior 1st manifested in release 2.6.29.4 (see Fixes below) and it looks unintentional. At least, no explanation was provided. I changed returned packes label into the 'bar', to bring it into line with the Smack documentation claims. • https://git.kernel.org/stable/c/d3f56c653c65f170b172d3c23120bc64ada645d8 https://git.kernel.org/stable/c/5b4b304f196c070342e32a4752e1fa2e22fc0671 https://git.kernel.org/stable/c/a948ec993541db4ef392b555c37a1186f4d61670 https://git.kernel.org/stable/c/0aea09e82eafa50a373fc8a4b84c1d4734751e2c https://git.kernel.org/stable/c/0776bcf9cb6de46fdd94d10118de1cf9b05f83b9 https://git.kernel.org/stable/c/4be9fd15c3c88775bdf6fa37acabe6de85beebff https://git.kernel.org/stable/c/d3703fa94116fed91f64c7d1c7d284fb4369070f https://git.kernel.org/stable/c/2fe209d0ad2e2729f7e22b9b31a86cc3f •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-47658 – crypto: stm32/cryp - call finalize with bh disabled
https://notcve.org/view.php?id=CVE-2024-47658
In the Linux kernel, the following vulnerability has been resolved: crypto: stm32/cryp - call finalize with bh disabled The finalize operation in interrupt mode produce a produces a spinlock recursion warning. The reason is the fact that BH must be disabled during this process. • https://git.kernel.org/stable/c/d93a2f86b0a998aa1f0870c85a2a60a0771ef89a https://git.kernel.org/stable/c/5d734665cd5d93270731e0ff1dd673fec677f447 https://git.kernel.org/stable/c/56ddb9aa3b324c2d9645b5a7343e46010cf3f6ce •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-46871 – drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX
https://notcve.org/view.php?id=CVE-2024-46871
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Correct the defined value for AMDGPU_DMUB_NOTIFICATION_MAX [Why & How] It actually exposes '6' types in enum dmub_notification_type. Not 5. Using smaller number to create array dmub_callback & dmub_thread_offload has potential to access item out of array bound. Fix it. • https://git.kernel.org/stable/c/9f404b0bc2df3880758fb3c3bc7496f596f347d7 https://git.kernel.org/stable/c/800a5ab673c4a61ca220cce177386723d91bdb37 https://git.kernel.org/stable/c/c592b6355b9b57b8e59fc5978ce1e14f64488a98 https://git.kernel.org/stable/c/ad28d7c3d989fc5689581664653879d664da76f0 •