CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-50208 – RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages
https://notcve.org/view.php?id=CVE-2024-50208
In the Linux kernel, the following vulnerability has been resolved: RDMA/bnxt_re: Fix a bug while setting up Level-2 PBL pages Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when num_pages > 256K. There will be a single PDE page address (contiguous pages in the case of > PAGE_SIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE. • https://git.kernel.org/stable/c/0c4dcd602817502bb3dced7a834a13ef717d65a4 https://git.kernel.org/stable/c/df6fed0a2a1a5e57f033bca40dc316b18e0d0ce6 https://git.kernel.org/stable/c/de5857fa7bcc9a496a914c7e21390be873109f26 https://git.kernel.org/stable/c/ea701c1849e7250ea41a4f7493e0a5f136c1d47e https://git.kernel.org/stable/c/87cb3b0054e53e0155b630bdf8fb714ded62565f https://git.kernel.org/stable/c/daac56dd98e1ba814c878ac0acd482a37f2ab94b https://git.kernel.org/stable/c/7988bdbbb85ac85a847baf09879edcd0f70521dc •
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: 7EXPL: 0CVE-2024-50199 – mm/swapfile: skip HugeTLB pages for unuse_vma
https://notcve.org/view.php?id=CVE-2024-50199
In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. • https://git.kernel.org/stable/c/0fe6e20b9c4c53b3e97096ee73a0857f60aad43f https://git.kernel.org/stable/c/ba7f982cdb37ff5a7739dec85d7325ea66fc1496 https://git.kernel.org/stable/c/417d5838ca73c6331ae2fe692fab6c25c00d9a0b https://git.kernel.org/stable/c/e41710f5a61aca9d6baaa8f53908a927dd9e7aa7 https://git.kernel.org/stable/c/6ec0fe3756f941f42f8c57156b8bdf2877b2ebaf https://git.kernel.org/stable/c/bed2b9037806c62166a0ef9a559a1e7e3e1275b8 https://git.kernel.org/stable/c/eb66a833cdd2f7302ee05d05e0fa12a2ca32eb87 https://git.kernel.org/stable/c/7528c4fb1237512ee18049f852f014eba •