CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-42082 – xdp: Remove WARN() from __xdp_reg_mem_model()
https://notcve.org/view.php?id=CVE-2024-42082
In the Linux kernel, the following vulnerability has been resolved: xdp: Remove WARN() from __xdp_reg_mem_model() syzkaller reports a warning in __xdp_reg_mem_model(). The warning occurs only if __mem_id_init_hash_table() returns an error. It returns the error in two cases: 1. memory allocation fails; 2. rhashtable_init() fails when some fields of rhashtable_params struct are not initialized properly. The second case cannot happen since there is a static const rhashtable_params struct with valid fields. So, warning is only triggered when there is a problem with memory allocation. Thus, there is no sense in using WARN() to handle this error and it can be safely removed. WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299 CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299 Call Trace: xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344 xdp_test_run_setup net/bpf/test_run.c:188 [inline] bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377 bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267 bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240 __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649 __do_sys_bpf kernel/bpf/syscall.c:5738 [inline] __se_sys_bpf kernel/bpf/syscall.c:5736 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75 Found by Linux Verification Center (linuxtesting.org) with syzkaller. • https://git.kernel.org/stable/c/8d5d88527587516bd58ff0f3810f07c38e65e2be https://git.kernel.org/stable/c/1095b8efbb13a6a5fa583ed373ee1ccab29da2d0 https://git.kernel.org/stable/c/1d3e3b3aa2cbe9bc7db9a7f8673a9fa6d2990d54 https://git.kernel.org/stable/c/4e0c539ee265d5c6e7fa7d229cd4aa7bc01816e2 https://git.kernel.org/stable/c/14e51ea78b4ccacb7acb1346b9241bb790a2054c https://git.kernel.org/stable/c/f92298b0467fd77edc4c1a2c3e48833e69840ec4 https://git.kernel.org/stable/c/7e9f79428372c6eab92271390851be34ab26bfb4 https://access.redhat.com/security/cve/CVE-2024-42082 • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-42081 – drm/xe/xe_devcoredump: Check NULL before assignments
https://notcve.org/view.php?id=CVE-2024-42081
In the Linux kernel, the following vulnerability has been resolved: drm/xe/xe_devcoredump: Check NULL before assignments Assign 'xe_devcoredump_snapshot *' and 'xe_device *' only if 'coredump' is not NULL. v2 - Fix commit messages. v3 - Define variables before code.(Ashutosh/Jose) v4 - Drop return check for coredump_to_xe. (Jose/Rodrigo) v5 - Modify misleading commit message. (Matt) • https://git.kernel.org/stable/c/76ec0e33707282d5321555698d902f4e067aff37 https://git.kernel.org/stable/c/b15e65349553b1689d15fbdebea874ca5ae2274a •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42080 – RDMA/restrack: Fix potential invalid address access
https://notcve.org/view.php?id=CVE-2024-42080
In the Linux kernel, the following vulnerability has been resolved: RDMA/restrack: Fix potential invalid address access struct rdma_restrack_entry's kern_name was set to KBUILD_MODNAME in ib_create_cq(), while if the module exited but forgot del this rdma_restrack_entry, it would cause a invalid address access in rdma_restrack_clean() when print the owner of this rdma_restrack_entry. These code is used to help find one forgotten PD release in one of the ULPs. But it is not needed anymore, so delete them. • https://git.kernel.org/stable/c/8656ef8a9288d6c932654f8d3856dc4ab1cfc6b5 https://git.kernel.org/stable/c/782bdaf9d01658281bc813f3f873e6258aa1fd8d https://git.kernel.org/stable/c/8ac281d42337f36cf7061cf1ea094181b84bc1a9 https://git.kernel.org/stable/c/f45b43d17240e9ca67ebf3cc82bb046b07cc1c61 https://git.kernel.org/stable/c/ca537a34775c103f7b14d7bbd976403f1d1525d8 •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-42079 – gfs2: Fix NULL pointer dereference in gfs2_log_flush
https://notcve.org/view.php?id=CVE-2024-42079
In the Linux kernel, the following vulnerability has been resolved: gfs2: Fix NULL pointer dereference in gfs2_log_flush In gfs2_jindex_free(), set sdp->sd_jdesc to NULL under the log flush lock to provide exclusion against gfs2_log_flush(). In gfs2_log_flush(), check if sdp->sd_jdesc is non-NULL before dereferencing it. Otherwise, we could run into a NULL pointer dereference when outstanding glock work races with an unmount (glock_work_func -> run_queue -> do_xmote -> inode_go_sync -> gfs2_log_flush). • https://git.kernel.org/stable/c/3429ef5f50909cee9e498c50f0c499b9397116ce https://git.kernel.org/stable/c/f54f9d5368a4e92ede7dd078a62788dae3a7c6ef https://git.kernel.org/stable/c/35264909e9d1973ab9aaa2a1b07cda70f12bb828 https://access.redhat.com/security/cve/CVE-2024-42079 https://bugzilla.redhat.com/show_bug.cgi?id=2300517 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-42077 – ocfs2: fix DIO failure due to insufficient transaction credits
https://notcve.org/view.php?id=CVE-2024-42077
In the Linux kernel, the following vulnerability has been resolved: ocfs2: fix DIO failure due to insufficient transaction credits The code in ocfs2_dio_end_io_write() estimates number of necessary transaction credits using ocfs2_calc_extend_credits(). This however does not take into account that the IO could be arbitrarily large and can contain arbitrary number of extents. Extent tree manipulations do often extend the current transaction but not in all of the cases. For example if we have only single block extents in the tree, ocfs2_mark_extent_written() will end up calling ocfs2_replace_extent_rec() all the time and we will never extend the current transaction and eventually exhaust all the transaction credits if the IO contains many single block extents. Once that happens a WARN_ON(jbd2_handle_buffer_credits(handle) <= 0) is triggered in jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to this error. This was actually triggered by one of our customers on a heavily fragmented OCFS2 filesystem. To fix the issue make sure the transaction always has enough credits for one extent insert before each call of ocfs2_mark_extent_written(). Heming Zhao said: ------ PANIC: "Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error" PID: xxx TASK: xxxx CPU: 5 COMMAND: "SubmitThread-CA" #0 machine_kexec at ffffffff8c069932 #1 __crash_kexec at ffffffff8c1338fa #2 panic at ffffffff8c1d69b9 #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2] #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2] #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2] #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2] #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2] #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2] #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2] #10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2] #11 dio_complete at ffffffff8c2b9fa7 #12 do_blockdev_direct_IO at ffffffff8c2bc09f #13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2] #14 generic_file_direct_write at ffffffff8c1dcf14 #15 __generic_file_write_iter at ffffffff8c1dd07b #16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2] #17 aio_write at ffffffff8c2cc72e #18 kmem_cache_alloc at ffffffff8c248dde #19 do_io_submit at ffffffff8c2ccada #20 do_syscall_64 at ffffffff8c004984 #21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba • https://git.kernel.org/stable/c/c15471f79506830f80eca0e7fe09b8213953ab5f https://git.kernel.org/stable/c/a68b896aa56e435506453ec8835bc991ec3ae687 https://git.kernel.org/stable/c/320273b5649bbcee87f9e65343077189699d2a7a https://git.kernel.org/stable/c/9ea2d1c6789722d58ec191f14f9a02518d55b6b4 https://git.kernel.org/stable/c/c05ffb693bfb42a48ef3ee88a55b57392984e111 https://git.kernel.org/stable/c/331d1079d58206ff7dc5518185f800b412f89bc6 https://git.kernel.org/stable/c/be346c1a6eeb49d8fda827d2a9522124c2f72f36 •