CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50207 – ring-buffer: Fix reader locking when changing the sub buffer order
https://notcve.org/view.php?id=CVE-2024-50207
In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Fix reader locking when changing the sub buffer order The function ring_buffer_subbuf_order_set() updates each ring_buffer_per_cpu and installs new sub buffers that match the requested page order. This operation may be invoked concurrently with readers that rely on some of the modified data, such as the head bit (RB_PAGE_HEAD), or the ring_buffer_per_cpu.pages and reader_page pointers. However, no exclusive access is acquired by ring_buffer_subbuf_order_set(). Modifying the mentioned data while a reader also operates on them can then result in incorrect memory access and various crashes. Fix the problem by taking the reader_lock when updating a specific ring_buffer_per_cpu in ring_buffer_subbuf_order_set(). • https://git.kernel.org/stable/c/8e7b58c27b3c567316a51079b375b846f9223bba https://git.kernel.org/stable/c/a569290525a05162d5dd26d9845591eaf46e5802 https://git.kernel.org/stable/c/09661f75e75cb6c1d2d8326a70c311d46729235f •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50205 – ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size()
https://notcve.org/view.php?id=CVE-2024-50205
In the Linux kernel, the following vulnerability has been resolved: ALSA: firewire-lib: Avoid division by zero in apply_constraint_to_size() The step variable is initialized to zero. It is changed in the loop, but if it's not changed it will remain zero. Add a variable check before the division. The observed behavior was introduced by commit 826b5de90c0b ("ALSA: firewire-lib: fix insufficient PCM rule for period/buffer size"), and it is difficult to show that any of the interval parameters will satisfy the snd_interval_test() condition with data from the amdtp_rate_table[] table. Found by Linux Verification Center (linuxtesting.org) with SVACE. • https://git.kernel.org/stable/c/826b5de90c0bca4e9de6231da9e1730480621588 https://git.kernel.org/stable/c/d575414361630b8b0523912532fcd7c79e43468c https://git.kernel.org/stable/c/5e431f85c87bbffd93a9830d5a576586f9855291 https://git.kernel.org/stable/c/7d4eb9e22131ec154e638cbd56629195c9bcbe9a https://git.kernel.org/stable/c/d2826873db70a6719cdd9212a6739f3e6234cfc4 https://git.kernel.org/stable/c/4bdc21506f12b2d432b1f2667e5ff4c75eee58e3 https://git.kernel.org/stable/c/3452d39c4704aa12504e4190298c721fb01083c3 https://git.kernel.org/stable/c/72cafe63b35d06b5cfbaf807e90ae6579 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50202 – nilfs2: propagate directory read errors from nilfs_find_entry()
https://notcve.org/view.php?id=CVE-2024-50202
In the Linux kernel, the following vulnerability has been resolved: nilfs2: propagate directory read errors from nilfs_find_entry() Syzbot reported that a task hang occurs in vcs_open() during a fuzzing test for nilfs2. The root cause of this problem is that in nilfs_find_entry(), which searches for directory entries, ignores errors when loading a directory page/folio via nilfs_get_folio() fails. If the filesystem images is corrupted, and the i_size of the directory inode is large, and the directory page/folio is successfully read but fails the sanity check, for example when it is zero-filled, nilfs_check_folio() may continue to spit out error messages in bursts. Fix this issue by propagating the error to the callers when loading a page/folio fails in nilfs_find_entry(). The current interface of nilfs_find_entry() and its callers is outdated and cannot propagate error codes such as -EIO and -ENOMEM returned via nilfs_find_entry(), so fix it together. • https://git.kernel.org/stable/c/2ba466d74ed74f073257f86e61519cb8f8f46184 https://git.kernel.org/stable/c/bb857ae1efd3138c653239ed1e7aef14e1242c81 https://git.kernel.org/stable/c/b4b3dc9e7e604be98a222e9f941f5e93798ca475 https://git.kernel.org/stable/c/c1d0476885d708a932980b0f28cd90d9bd71db39 https://git.kernel.org/stable/c/edf8146057264191d5bfe5b91773f13d936dadd3 https://git.kernel.org/stable/c/270a6f9df35fa2aea01ec23770dc9b3fc9a12989 https://git.kernel.org/stable/c/9698088ac7704e260f492d9c254e29ed7dd8729a https://git.kernel.org/stable/c/efa810b15a25531cbc2f527330947b9fe •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50201 – drm/radeon: Fix encoder->possible_clones
https://notcve.org/view.php?id=CVE-2024-50201
In the Linux kernel, the following vulnerability has been resolved: drm/radeon: Fix encoder->possible_clones Include the encoder itself in its possible_clones bitmask. In the past nothing validated that drivers were populating possible_clones correctly, but that changed in commit 74d2aacbe840 ("drm: Validate encoder->possible_clones"). Looks like radeon never got the memo and is still not following the rules 100% correctly. This results in some warnings during driver initialization: Bogus possible_clones: [ENCODER:46:TV-46] possible_clones=0x4 (full encoder mask=0x7) WARNING: CPU: 0 PID: 170 at drivers/gpu/drm/drm_mode_config.c:615 drm_mode_config_validate+0x113/0x39c ... (cherry picked from commit 3b6e7d40649c0d75572039aff9d0911864c689db) • https://git.kernel.org/stable/c/74d2aacbe84042d89f572a3112a146fca05bfcb1 https://git.kernel.org/stable/c/df75c78bfeff99f9b4815c3e79e2b1b1e34fe264 https://git.kernel.org/stable/c/fda5dc80121b12871dc343ab37e0c3f0d138825d https://git.kernel.org/stable/c/c3cd27d85f0778f4ec07384d7516b33153759b8e https://git.kernel.org/stable/c/1a235af0216411a32ab4db54f7bd19020b46c86d https://git.kernel.org/stable/c/68801730ebb9393460b30cd3885e407f15da27a9 https://git.kernel.org/stable/c/28127dba64d8ae1a0b737b973d6d029908599611 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50200 – maple_tree: correct tree corruption on spanning store
https://notcve.org/view.php?id=CVE-2024-50200
In the Linux kernel, the following vulnerability has been resolved: maple_tree: correct tree corruption on spanning store Patch series "maple_tree: correct tree corruption on spanning store", v3. There has been a nasty yet subtle maple tree corruption bug that appears to have been in existence since the inception of the algorithm. This bug seems far more likely to happen since commit f8d112a4e657 ("mm/mmap: avoid zeroing vma tree in mmap_region()"), which is the point at which reports started to be submitted concerning this bug. We were made definitely aware of the bug thanks to the kind efforts of Bert Karwatzki who helped enormously in my being able to track this down and identify the cause of it. The bug arises when an attempt is made to perform a spanning store across two leaf nodes, where the right leaf node is the rightmost child of the shared parent, AND the store completely consumes the right-mode node. This results in mas_wr_spanning_store() mitakenly duplicating the new and existing entries at the maximum pivot within the range, and thus maple tree corruption. The fix patch corrects this by detecting this scenario and disallowing the mistaken duplicate copy. The fix patch commit message goes into great detail as to how this occurs. This series also includes a test which reliably reproduces the issue, and asserts that the fix works correctly. Bert has kindly tested the fix and confirmed it resolved his issues. Also Mikhail Gavrilov kindly reported what appears to be precisely the same bug, which this fix should also resolve. This patch (of 2): There has been a subtle bug present in the maple tree implementation from its inception. This arises from how stores are performed - when a store occurs, it will overwrite overlapping ranges and adjust the tree as necessary to accommodate this. A range may always ultimately span two leaf nodes. In this instance we walk the two leaf nodes, determine which elements are not overwritten to the left and to the right of the start and end of the ranges respectively and then rebalance the tree to contain these entries and the newly inserted one. This kind of store is dubbed a 'spanning store' and is implemented by mas_wr_spanning_store(). In order to reach this stage, mas_store_gfp() invokes mas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to walk the tree and update the object (mas) to traverse to the location where the write should be performed, determining its store type. When a spanning store is required, this function returns false stopping at the parent node which contains the target range, and mas_wr_store_type() marks the mas->store_type as wr_spanning_store to denote this fact. When we go to perform the store in mas_wr_spanning_store(), we first determine the elements AFTER the END of the range we wish to store (that is, to the right of the entry to be inserted) - we do this by walking to the NEXT pivot in the tree (i.e. r_mas.last + 1), starting at the node we have just determined contains the range over which we intend to write. We then turn our attention to the entries to the left of the entry we are inserting, whose state is represented by l_mas, and copy these into a 'big node', which is a special node which contains enough slots to contain two leaf node's worth of data. We then copy the entry we wish to store immediately after this - the copy and the insertion of the new entry is performed by mas_store_b_node(). After this we copy the elements to the right of the end of the range which we are inserting, if we have not exceeded the length of the node (i.e. r_mas.offset <= r_mas.end). Herein lies the bug - under very specific circumstances, this logic can break and corrupt the maple tree. Consider the following tree: Height 0 Root Node / \ pivot = 0xffff / \ pivot = ULONG_MAX / ---truncated--- • https://git.kernel.org/stable/c/54a611b605901c7d5d05b6b8f5d04a6ceb0962aa https://git.kernel.org/stable/c/7c7874977da9e47ca0f53d8b9a5b17385fed83f2 https://git.kernel.org/stable/c/677f1df179cb68c12ddf7707ec325eb50e99c7d9 https://git.kernel.org/stable/c/982dd0d26d1f015ed34866579480d2be5250b0ef https://git.kernel.org/stable/c/bea07fd63192b61209d48cbb81ef474cc3ee4c62 •