CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50233 – staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg()
https://notcve.org/view.php?id=CVE-2024-50233
In the Linux kernel, the following vulnerability has been resolved: staging: iio: frequency: ad9832: fix division by zero in ad9832_calc_freqreg() In the ad9832_write_frequency() function, clk_get_rate() might return 0. This can lead to a division by zero when calling ad9832_calc_freqreg(). The check if (fout > (clk_get_rate(st->mclk) / 2)) does not protect against the case when fout is 0. The ad9832_write_frequency() function is called from ad9832_write(), and fout is derived from a text buffer, which can contain any value. • https://git.kernel.org/stable/c/ea707584bac187c9c6c64c4eacd1c09bcc08f37b https://git.kernel.org/stable/c/fcd6b59f7a774558e2525251c68aa37aff748e55 https://git.kernel.org/stable/c/442f786c5bff8cfd756ebdeaa4aadbf05c22aa5a https://git.kernel.org/stable/c/2f39548f45693d86e950647012a214da6917dc9f https://git.kernel.org/stable/c/ccbc10647aafe2b7506edb4b10e19c6c2416c162 https://git.kernel.org/stable/c/adfbc08b94e7df08b9ed5fa26b969cc1b54c84ec https://git.kernel.org/stable/c/dd9e1cf619c945f320e686dcaf13e37ef0b05fdd https://git.kernel.org/stable/c/6bd301819f8f69331a55ae2336c8b111f •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50232 – iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr()
https://notcve.org/view.php?id=CVE-2024-50232
In the Linux kernel, the following vulnerability has been resolved: iio: adc: ad7124: fix division by zero in ad7124_set_channel_odr() In the ad7124_write_raw() function, parameter val can potentially be zero. This may lead to a division by zero when DIV_ROUND_CLOSEST() is called within ad7124_set_channel_odr(). The ad7124_write_raw() function is invoked through the sequence: iio_write_channel_raw() -> iio_write_channel_attribute() -> iio_channel_write(), with no checks in place to ensure val is non-zero. • https://git.kernel.org/stable/c/7b8d045e497a04dd88546da51f34fa3b102778d2 https://git.kernel.org/stable/c/4f588fffc307a4bc2761aee6ff275bb4b433e451 https://git.kernel.org/stable/c/f51343f346e6abde094548a7fb34472b0d4cae91 https://git.kernel.org/stable/c/3dc0eda2cd5c653b162852ae5f0631bfe4ca5e95 https://git.kernel.org/stable/c/0ac0beb4235a9a474f681280a3bd4e2a5bb66569 https://git.kernel.org/stable/c/efa353ae1b0541981bc96dbf2e586387d0392baa •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50231 – iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table()
https://notcve.org/view.php?id=CVE-2024-50231
In the Linux kernel, the following vulnerability has been resolved: iio: gts-helper: Fix memory leaks in iio_gts_build_avail_scale_table() modprobe iio-test-gts and rmmod it, then the following memory leak occurs: unreferenced object 0xffffff80c810be00 (size 64): comm "kunit_try_catch", pid 1654, jiffies 4294913981 hex dump (first 32 bytes): 02 00 00 00 08 00 00 00 20 00 00 00 40 00 00 00 ........ ...@... 80 00 00 00 00 02 00 00 00 04 00 00 00 08 00 00 ................ backtrace (crc a63d875e): [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 [<0000000071bb4b09>] 0xffffffdf052a62e0 [<000000000315bc18>] 0xffffffdf052a6488 [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000f505065d>] kthread+0x2e8/0x374 [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 unreferenced object 0xffffff80cbfe9e70 (size 16): comm "kunit_try_catch", pid 1658, jiffies 4294914015 hex dump (first 16 bytes): 10 00 00 00 40 00 00 00 80 00 00 00 00 00 00 00 ....@........... backtrace (crc 857f0cb4): [<0000000028c1b3c2>] kmemleak_alloc+0x34/0x40 [<000000001d6ecc87>] __kmalloc_noprof+0x2bc/0x3c0 [<00000000393795c1>] devm_iio_init_iio_gts+0x4b4/0x16f4 [<0000000071bb4b09>] 0xffffffdf052a62e0 [<000000007d089d45>] 0xffffffdf052a6864 [<00000000f9dc55b5>] kunit_try_run_case+0x13c/0x3ac [<00000000175a3fd4>] kunit_generic_run_threadfn_adapter+0x80/0xec [<00000000f505065d>] kthread+0x2e8/0x374 [<00000000bbfb0e5d>] ret_from_fork+0x10/0x20 ...... It includes 5*5 times "size 64" memory leaks, which correspond to 5 times test_init_iio_gain_scale() calls with gts_test_gains size 10 (10*size(int)) and gts_test_itimes size 5. It also includes 5*1 times "size 16" memory leak, which correspond to one time __test_init_iio_gain_scale() call with gts_test_gains_gain_low size 3 (3*size(int)) and gts_test_itimes size 5. The reason is that the per_time_gains[i] is not freed which is allocated in the "gts->num_itime" for loop in iio_gts_build_avail_scale_table(). • https://git.kernel.org/stable/c/38416c28e16890b52fdd5eb73479299ec3f062f3 https://git.kernel.org/stable/c/38d6e8be234d87b0eedca50309e25051888b39d1 https://git.kernel.org/stable/c/16e41593825c3044efca0eb34b2d6ffba306e4ec https://git.kernel.org/stable/c/691e79ffc42154a9c91dc3b7e96a307037b4be74 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-50230 – nilfs2: fix kernel bug due to missing clearing of checked flag
https://notcve.org/view.php?id=CVE-2024-50230
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix kernel bug due to missing clearing of checked flag Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, __block_write_begin_int(), which is called to prepare block writes, may fail the BUG_ON check for accesses exceeding the folio/page size, triggering a kernel bug. This was found to be because the "checked" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that. This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files. • https://git.kernel.org/stable/c/8c26c4e2694a163d525976e804d81cd955bbb40c https://git.kernel.org/stable/c/994b2fa13a6c9cf3feca93090a9c337d48e3d60d https://git.kernel.org/stable/c/64afad73e4623308d8943645e5631f2c7a2d7971 https://git.kernel.org/stable/c/aa0cee46c5d3fd9a39575a4c8a4f65f25f095b89 https://git.kernel.org/stable/c/f05dbebb8ee34882505d53d83af7d18f28a49248 https://git.kernel.org/stable/c/cd0cdb51b15203fa27d4b714be83b7dfffa0b752 https://git.kernel.org/stable/c/f2f1fa446676c21edb777e6d2bc4fa8f956fab68 https://git.kernel.org/stable/c/56c6171932a7fb267ac6cb4ff8759b93e •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-50229 – nilfs2: fix potential deadlock with newly created symlinks
https://notcve.org/view.php?id=CVE-2024-50229
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential deadlock with newly created symlinks Syzbot reported that page_symlink(), called by nilfs_symlink(), triggers memory reclamation involving the filesystem layer, which can result in circular lock dependencies among the reader/writer semaphore nilfs->ns_segctor_sem, s_writers percpu_rwsem (intwrite) and the fs_reclaim pseudo lock. This is because after commit 21fc61c73c39 ("don't put symlink bodies in pagecache into highmem"), the gfp flags of the page cache for symbolic links are overwritten to GFP_KERNEL via inode_nohighmem(). This is not a problem for symlinks read from the backing device, because the __GFP_FS flag is dropped after inode_nohighmem() is called. However, when a new symlink is created with nilfs_symlink(), the gfp flags remain overwritten to GFP_KERNEL. Then, memory allocation called from page_symlink() etc. triggers memory reclamation including the FS layer, which may call nilfs_evict_inode() or nilfs_dirty_inode(). And these can cause a deadlock if they are called while nilfs->ns_segctor_sem is held: Fix this issue by dropping the __GFP_FS flag from the page cache GFP flags of newly created symlinks in the same way that nilfs_new_inode() and __nilfs_read_inode() do, as a workaround until we adopt nofs allocation scope consistently or improve the locking constraints. • https://git.kernel.org/stable/c/21fc61c73c3903c4c312d0802da01ec2b323d174 https://git.kernel.org/stable/c/076e4ab3279eb3ddb206de44d04df7aeb2428e09 https://git.kernel.org/stable/c/cc38c596e648575ce58bfc31623a6506eda4b94a https://git.kernel.org/stable/c/a1686db1e59f8fc016c4c9361e2119dd206f479a https://git.kernel.org/stable/c/c72e0df0b56c1166736dc8eb62070ebb12591447 https://git.kernel.org/stable/c/69548bb663fcb63f9ee0301be808a36b9d78dac3 https://git.kernel.org/stable/c/58c7f44c7b9e5ac7e3b1e5da2572ed7767a12f38 https://git.kernel.org/stable/c/1246d86e7bbde265761932c6e2dce28c6 •