CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-47664 – spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware
https://notcve.org/view.php?id=CVE-2024-47664
In the Linux kernel, the following vulnerability has been resolved: spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmware If the value of max_speed_hz is 0, it may cause a division by zero error in hisi_calc_effective_speed(). The value of max_speed_hz is provided by firmware. Firmware is generally considered as a trusted domain. However, as division by zero errors can cause system failure, for defense measure, the value of max_speed is validated here. So 0 is regarded as invalid and an error code is returned. • https://git.kernel.org/stable/c/16ccaf581da4fcf1e4d66086cf37263f9a656d43 https://git.kernel.org/stable/c/ee73a15d4a8ce8fb02d7866f7cf78fcdd16f0fcc https://git.kernel.org/stable/c/5127c42c77de18651aa9e8e0a3ced190103b449c •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-47662 – drm/amd/display: Remove register from DCN35 DMCUB diagnostic collection
https://notcve.org/view.php?id=CVE-2024-47662
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Remove register from DCN35 DMCUB diagnostic collection [Why] These registers should not be read from driver and triggering the security violation when DMCUB work times out and diagnostics are collected blocks Z8 entry. [How] Remove the register read from DCN35. • https://git.kernel.org/stable/c/eba4b2a38ccdf074a053834509545703d6df1d57 https://git.kernel.org/stable/c/466423c6dd8af23ebb3a69d43434d01aed0db356 •
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 •