CVSS: -EPSS: 0%CPEs: 9EXPL: 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/7065c05c6d58b9b9a98127aa14e9a5ec68173918 https://git.kernel.org/stable/c/49b33c38d202d3327dcfd058e27f541dcc308b92 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/66dbe0df6eccc7ee53a2c35016ce81e13 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 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/8ffbe7d07b8e76193b151107878ddc1ccc94deb5 https://git.kernel.org/stable/c/883f794c6e498ae24680aead55c16f66b06cfc30 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/7fd6aae7e53b94f4035b1bfce28b8dfa0 •
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/d91d253c87fd1efece521ff2612078a35af673c6 https://git.kernel.org/stable/c/7f25f296fc9bd0435be14e89bf657cd615a23574 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/aee2424246f9f1dadc33faa78990c1e2e •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-47692 – nfsd: return -EINVAL when namelen is 0
https://notcve.org/view.php?id=CVE-2024-47692
In the Linux kernel, the following vulnerability has been resolved: nfsd: return -EINVAL when namelen is 0 When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered. [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205] dump_stack+0x9a/0xd0 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] __kasan_report.cold+0x34/0x84 [ T1205] ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205] kasan_report+0x3a/0x50 [ T1205] nfs4_client_to_reclaim+0xe9/0x260 [ T1205] ? nfsd4_release_lockowner+0x410/0x410 [ T1205] cld_pipe_downcall+0x5ca/0x760 [ T1205] ? • https://git.kernel.org/stable/c/74725959c33c14114fdce1e36e3504d106584d53 https://git.kernel.org/stable/c/6d07040ae5c2214e39c7444d898039c9e655a79a https://git.kernel.org/stable/c/0f1d007bbea38a61cf9c5392708dc70ae9d84a3d https://git.kernel.org/stable/c/b7b7a8df41ef18862dd6b22289fb46c2c12398af https://git.kernel.org/stable/c/84a563d136faf514fdad1ade28d7a142fd313cb8 https://git.kernel.org/stable/c/318f70857caab3da9a6ada9bc8c1f4f7591b695e https://git.kernel.org/stable/c/766d5fbd78f7a52b3888449a0358760477b74602 https://git.kernel.org/stable/c/1ff8be8d008b9ddc8e7043fbddd37d5d4 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-47691 – f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()
https://notcve.org/view.php?id=CVE-2024-47691
In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread() syzbot reports a f2fs bug as below: __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114 print_report+0xe8/0x550 mm/kasan/report.c:491 kasan_report+0x143/0x180 mm/kasan/report.c:601 kasan_check_range+0x282/0x290 mm/kasan/generic.c:189 instrument_atomic_read_write include/linux/instrumented.h:96 [inline] atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline] __refcount_add include/linux/refcount.h:184 [inline] __refcount_inc include/linux/refcount.h:241 [inline] refcount_inc include/linux/refcount.h:258 [inline] get_task_struct include/linux/sched/task.h:118 [inline] kthread_stop+0xca/0x630 kernel/kthread.c:704 f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210 f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283 f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline] __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:907 [inline] __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f The root cause is below race condition, it may cause use-after-free issue in sbi->gc_th pointer. - remount - f2fs_remount - f2fs_stop_gc_thread - kfree(gc_th) - f2fs_ioc_shutdown - f2fs_do_shutdown - f2fs_stop_gc_thread - kthread_stop(gc_th->f2fs_gc_task) : sbi->gc_thread = NULL; We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore for fixing. - for f2fs_shutdown() path, it's safe since caller has already grabbed sb->s_umount semaphore. • https://git.kernel.org/stable/c/7950e9ac638e84518fbdd5c930939ad46a1068c5 https://git.kernel.org/stable/c/fc18e655b62ac6bc9f12f5de0d749b4a3fe1e812 https://git.kernel.org/stable/c/7c339dee7eb0f8e4cadc317c595f898ef04dae30 https://git.kernel.org/stable/c/d79343cd66343709e409d96b2abb139a0a55ce34 https://git.kernel.org/stable/c/c7f114d864ac91515bb07ac271e9824a20f5ed95 •