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: 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 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-47694 – IB/mlx5: Fix UMR pd cleanup on error flow of driver init
https://notcve.org/view.php?id=CVE-2024-47694
In the Linux kernel, the following vulnerability has been resolved: IB/mlx5: Fix UMR pd cleanup on error flow of driver init The cited commit moves the pd allocation from function mlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup(). So the fix in commit [1] is broken. In error flow, will hit panic [2]. Fix it by checking pd pointer to avoid panic if it is NULL; [1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init [2] [ 347.567063] infiniband mlx5_0: Couldn't register device with driver model [ 347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 347.593438] #PF: supervisor read access in kernel mode [ 347.595176] #PF: error_code(0x0000) - not-present page [ 347.596962] PGD 0 P4D 0 [ 347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core] [ 347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282 [ 347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000 [ 347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000 [ 347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0 [ 347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000 [ 347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001 [ 347.609067] FS: 00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000 [ 347.610094] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0 [ 347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 347.612804] Call Trace: [ 347.613130] <TASK> [ 347.613417] ? __die+0x20/0x60 [ 347.613793] ? page_fault_oops+0x150/0x3e0 [ 347.614243] ? free_msg+0x68/0x80 [mlx5_core] [ 347.614840] ? • https://git.kernel.org/stable/c/638420115cc4ad6c3a2683bf46a052b505abb202 https://git.kernel.org/stable/c/99e2de5942b0390ddc24efada71edc6593e23f05 https://git.kernel.org/stable/c/112e6e83a894260cc7efe79a1fc47d4d51461742 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-47693 – IB/core: Fix ib_cache_setup_one error flow cleanup
https://notcve.org/view.php?id=CVE-2024-47693
In the Linux kernel, the following vulnerability has been resolved: IB/core: Fix ib_cache_setup_one error flow cleanup When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below. Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue. WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff <0f> 0b 4c 8b 75 30 e9 54 ff ff ff 48 8 3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS: 00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? show_regs+0x94/0xa0 ? __warn+0x9e/0x1c0 ? gid_table_release_one+0x181/0x1a0 ? report_bug+0x1f9/0x340 ? • https://git.kernel.org/stable/c/1901b91f99821955eac2bd48fe25ee983385dc00 https://git.kernel.org/stable/c/ee7ce7d7e7c76d5ec4c8067d32bbee9728dc9d29 https://git.kernel.org/stable/c/2a5968f266c7b9dc13917ac573af8d7b7da4023c https://git.kernel.org/stable/c/1730d47d1865af89efd01cf0469a9a739cbf60f2 https://git.kernel.org/stable/c/45f63f4bb9a7128a6209d766c2fc02b3d42fbf3e https://git.kernel.org/stable/c/d08754be993f270e3d296d8f5d8e071fe6638651 https://git.kernel.org/stable/c/af633fd9d9fff59e31c804f47ca0c8a784977773 https://git.kernel.org/stable/c/290fe42fe0165205c4451334d8833a920 •
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 •