CVSS: -EPSS: %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: %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: %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 •
CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2024-50198 – iio: light: veml6030: fix IIO device retrieval from embedded device
https://notcve.org/view.php?id=CVE-2024-50198
In the Linux kernel, the following vulnerability has been resolved: iio: light: veml6030: fix IIO device retrieval from embedded device The dev pointer that is received as an argument in the in_illuminance_period_available_show function references the device embedded in the IIO device, not in the i2c client. dev_to_iio_dev() must be used to accessthe right data. The current implementation leads to a segmentation fault on every attempt to read the attribute because indio_dev gets a NULL assignment. This bug has been present since the first appearance of the driver, apparently since the last version (V6) before getting applied. A constant attribute was used until then, and the last modifications might have not been tested again. • https://git.kernel.org/stable/c/7b779f573c48e1ad6da1d6ea5f181f3ecd666bf6 https://git.kernel.org/stable/c/bf3ab8e1c28f10df0823d4ff312f83c952b06a15 https://git.kernel.org/stable/c/50039aec43a82ad2495f2d0fb0c289c8717b4bb2 https://git.kernel.org/stable/c/bcb90518ccd9e10bf6ab29e31994aab93e4a4361 https://git.kernel.org/stable/c/2cbb41abae65626736b8b52cf3b9339612c5a86a https://git.kernel.org/stable/c/905166531831beb067fffe2bdfc98031ffe89087 https://git.kernel.org/stable/c/c7c44e57750c31de43906d97813273fdffcf7d02 •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2024-50196 – pinctrl: ocelot: fix system hang on level based interrupts
https://notcve.org/view.php?id=CVE-2024-50196
In the Linux kernel, the following vulnerability has been resolved: pinctrl: ocelot: fix system hang on level based interrupts The current implementation only calls chained_irq_enter() and chained_irq_exit() if it detects pending interrupts. ``` for (i = 0; i < info->stride; i++) { uregmap_read(info->map, id_reg + 4 * i, ®); if (!reg) continue; chained_irq_enter(parent_chip, desc); ``` However, in case of GPIO pin configured in level mode and the parent controller configured in edge mode, GPIO interrupt might be lowered by the hardware. In the result, if the interrupt is short enough, the parent interrupt is still pending while the GPIO interrupt is cleared; chained_irq_enter() never gets called and the system hangs trying to service the parent interrupt. Moving chained_irq_enter() and chained_irq_exit() outside the for loop ensures that they are called even when GPIO interrupt is lowered by the hardware. The similar code with chained_irq_enter() / chained_irq_exit() functions wrapping interrupt checking loop may be found in many other drivers: ``` grep -r -A 10 chained_irq_enter drivers/pinctrl ``` • https://git.kernel.org/stable/c/655f5d4662b958122b260be05aa6dfdf8768efe6 https://git.kernel.org/stable/c/4a81800ef05bea5a9896f199677f7b7f5020776a https://git.kernel.org/stable/c/20728e86289ab463b99b7ab4425515bd26aba417 https://git.kernel.org/stable/c/dcbe9954634807ec54e22bde278b5b269f921381 https://git.kernel.org/stable/c/93b8ddc54507a227087c60a0013ed833b6ae7d3c •