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: 8EXPL: 0CVE-2024-47663 – staging: iio: frequency: ad9834: Validate frequency parameter value
https://notcve.org/view.php?id=CVE-2024-47663
In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9834: Validate frequency parameter value In ad9834_write_frequency() clk_get_rate() can return 0. In such case ad9834_calc_freqreg() call will lead to division by zero. Checking 'if (fout > (clk_freq / 2))' doesn't protect in case of 'fout' is 0. ad9834_write_frequency() is called from ad9834_write(), where fout is taken from text buffer, which can contain any value. Modify parameters checking. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/12b9d5bf76bfa20d3207ef24fca9c8254a586a58 https://git.kernel.org/stable/c/5edc3a45ef428501000a7b23d0e1777a548907f6 https://git.kernel.org/stable/c/0e727707a239d5c519fc9abc2f0fd913516a7e47 https://git.kernel.org/stable/c/41cc91e3138fe52f8da92a81bebcd0e6cf488c53 https://git.kernel.org/stable/c/d8b09a5edc4a634373158c1a405491de3c52e58a https://git.kernel.org/stable/c/3ba9abfcaa9e16bb91ed7e0e2b42e94a157a953e https://git.kernel.org/stable/c/dc12e49f970b08d8b007b8981b97e2eb93c0e89d https://git.kernel.org/stable/c/8961b245e8f92bccbaacfbbdf69eba60e •
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 •