CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47699 – nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()
https://notcve.org/view.php?id=CVE-2024-47699
In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential null-ptr-deref in nilfs_btree_insert() Patch series "nilfs2: fix potential issues with empty b-tree nodes". This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot. This patch (of 3): If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert(). This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called. Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency. Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on. • https://git.kernel.org/stable/c/17c76b0104e4a6513983777e1a17e0297a12b0c4 https://git.kernel.org/stable/c/24bf40740a3da6b4056721da34997ae6938f3da1 https://git.kernel.org/stable/c/73d23ecf234b7a6d47fb883f2dabe10e3230b31d https://git.kernel.org/stable/c/f68523e0f26faade18833fbef577a4295d8e2c94 https://git.kernel.org/stable/c/21839b6fbc3c41b3e374ecbdb0cabbbb2c53cf34 https://git.kernel.org/stable/c/db73500d3f0e558eb642aae1d4782e7726b4a03f https://git.kernel.org/stable/c/3644554d308ddf2669e459a1551a7edf60b2d62b https://git.kernel.org/stable/c/9403001ad65ae4f4c5de368bdda3a0636 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47698 – drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error
https://notcve.org/view.php?id=CVE-2024-47698
In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2832: fix an out-of-bounds write error Ensure index in rtl2832_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. [hverkuil: added fixes tag, rtl2830_pid_filter -> rtl2832_pid_filter in logmsg] • https://git.kernel.org/stable/c/4b01e01a81b6629878344430531ced347cc2ed5b https://git.kernel.org/stable/c/6ae3b9aee42616ee93c4585174f40c767828006d https://git.kernel.org/stable/c/a879b6cdd48134a3d58949ea4f075c75fa2d7d71 https://git.kernel.org/stable/c/15bea004e939d938a6771dfcf2a26cc899ffd20a https://git.kernel.org/stable/c/527ab3eb3b0b4a6ee00e183c1de6a730239e2835 https://git.kernel.org/stable/c/66dbe0df6eccc7ee53a2c35016ce81e13b3ff447 https://git.kernel.org/stable/c/bedd42e07988dbdd124b23e758ffef7a681b9c60 https://git.kernel.org/stable/c/8ae06f360cfaca2b88b98ca89144548b3 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-47697 – drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error
https://notcve.org/view.php?id=CVE-2024-47697
In the Linux kernel, the following vulnerability has been resolved: drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access. dev->filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index > 32 to index >= 32 to resolve this issue. • https://git.kernel.org/stable/c/df70ddad81b47c57bcccffc805fbd75f2f1b2dc6 https://git.kernel.org/stable/c/badbd736e6649c4e6d7b4ff7e2b9857acfa9ea94 https://git.kernel.org/stable/c/86d920d2600c3a48efc2775c1666c1017eec6956 https://git.kernel.org/stable/c/3dba83d3c81de1368d15a39f22df7b53e306052f https://git.kernel.org/stable/c/58f31be7dfbc0c84a6497ad51924949cf64b86a2 https://git.kernel.org/stable/c/7fd6aae7e53b94f4035b1bfce28b8dfa0d0ae470 https://git.kernel.org/stable/c/042b101d7bf70616c4967c286ffa6fcca65babfb https://git.kernel.org/stable/c/46d7ebfe6a75a454a5fa28604f0ef1491 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-47696 – RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency
https://notcve.org/view.php?id=CVE-2024-47696
In the Linux kernel, the following vulnerability has been resolved: RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency In the commit aee2424246f9 ("RDMA/iwcm: Fix a use-after-free related to destroying CM IDs"), the function flush_workqueue is invoked to flush the work queue iwcm_wq. But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM. Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn't have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn't have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock. The call trace is as below: [ 125.350876][ T1430] Call Trace: [ 125.356281][ T1430] <TASK> [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? • https://git.kernel.org/stable/c/94ee7ff99b87435ec63211f632918dc7f44dac79 https://git.kernel.org/stable/c/557d035fe88d78dd51664f4dc0e1896c04c97cf6 https://git.kernel.org/stable/c/dc8074b8901caabb97c2d353abd6b4e7fa5a59a5 https://git.kernel.org/stable/c/ff5bbbdee08287d75d72e65b72a2b76d9637892a https://git.kernel.org/stable/c/ee39384ee787e86e9db4efb843818ef0ea9cb8ae https://git.kernel.org/stable/c/aee2424246f9f1dadc33faa78990c1e2eb7826e4 https://git.kernel.org/stable/c/d91d253c87fd1efece521ff2612078a35af673c6 https://git.kernel.org/stable/c/7f25f296fc9bd0435be14e89bf657cd61 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-47695 – RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds
https://notcve.org/view.php?id=CVE-2024-47695
In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: Reset cid to con_num - 1 to stay in bounds In the function init_conns(), after the create_con() and create_cm() for loop if something fails. In the cleanup for loop after the destroy tag, we access out of bound memory because cid is set to clt_path->s.con_num. This commits resets the cid to clt_path->s.con_num - 1, to stay in bounds in the cleanup loop later. • https://git.kernel.org/stable/c/6a98d71daea186247005099758af549e6afdd244 https://git.kernel.org/stable/c/0429a4e972082e3a2351da414b1c017daaf8aed2 https://git.kernel.org/stable/c/5ac73f8191f3de41fef4f934d84d97f3aadb301f https://git.kernel.org/stable/c/01b9be936ee8839ab9f83a7e84ee02ac6c8303c4 https://git.kernel.org/stable/c/1c50e0265fa332c94a4a182e4efa0fc70d8fad94 https://git.kernel.org/stable/c/c8b7f3d9fada0d4b4b7db86bf7345cd61f1d972e https://git.kernel.org/stable/c/3e4289b29e216a55d08a89e126bc0b37cbad9f38 •