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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42070 – netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers
https://notcve.org/view.php?id=CVE-2024-42070
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registers register store validation for NFT_DATA_VALUE is conditional, however, the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. This only requires a new helper function to infer the register type from the set datatype so this conditional check can be removed. Otherwise, pointer to chain object can be leaked through the registers. • https://git.kernel.org/stable/c/96518518cc417bb0a8c80b9fb736202e28acdf96 https://git.kernel.org/stable/c/40188a25a9847dbeb7ec67517174a835a677752f https://git.kernel.org/stable/c/23752737c6a618e994f9a310ec2568881a6b49c4 https://git.kernel.org/stable/c/5d43d789b57943720dca4181a05f6477362b94cf https://git.kernel.org/stable/c/461302e07f49687ffe7d105fa0a330c07c7646d8 https://git.kernel.org/stable/c/efb27ad05949403848f487823b597ed67060e007 https://git.kernel.org/stable/c/952bf8df222599baadbd4f838a49c4fef81d2564 https://git.kernel.org/stable/c/41a6375d48deaf7f730304b5153848bfa •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-42068 – bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro()
https://notcve.org/view.php?id=CVE-2024-42068
In the Linux kernel, the following vulnerability has been resolved: bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro() set_memory_ro() can fail, leaving memory unprotected. Check its return and take it into account as an error. • https://git.kernel.org/stable/c/a359696856ca9409fb97655c5a8ef0f549cb6e03 https://git.kernel.org/stable/c/e4f602e3ff749ba770bf8ff10196e18358de6720 https://git.kernel.org/stable/c/fdd411af8178edc6b7bf260f8fa4fba1bedd0a6d https://git.kernel.org/stable/c/e3540e5a7054d6daaf9a1415a48aacb092112a89 https://git.kernel.org/stable/c/05412471beba313ecded95aa17b25fe84bb2551a https://git.kernel.org/stable/c/7d2cc63eca0c993c99d18893214abf8f85d566d8 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42067 – bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()
https://notcve.org/view.php?id=CVE-2024-42067
In the Linux kernel, the following vulnerability has been resolved: bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro() set_memory_rox() can fail, leaving memory unprotected. Check return and bail out when bpf_jit_binary_lock_ro() returns an error. • https://git.kernel.org/stable/c/08f6c05feb1db21653e98ca84ea04ca032d014c7 https://git.kernel.org/stable/c/9fef36cad60d4226f9d06953cd56d1d2f9119730 https://git.kernel.org/stable/c/044da7ae7afd4ef60806d73654a2e6a79aa4ed7a https://git.kernel.org/stable/c/e60adf513275c3a38e5cb67f7fd12387e43a3ff5 •