CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42270 – netfilter: iptables: Fix null-ptr-deref in iptable_nat_table_init().
https://notcve.org/view.php?id=CVE-2024-42270
In the Linux kernel, the following vulnerability has been resolved: netfilter: iptables: Fix null-ptr-deref in iptable_nat_table_init(). We had a report that iptables-restore sometimes triggered null-ptr-deref at boot time. [0] The problem is that iptable_nat_table_init() is exposed to user space before the kernel fully initialises netns. In the small race window, a user could call iptable_nat_table_init() that accesses net_generic(net, iptable_nat_net_id), which is available only after registering iptable_nat_net_ops. Let's call register_pernet_subsys() before xt_register_template(). [0]: bpfilter: Loaded bpfilter_umh pid 11702 Started bpfilter BUG: kernel NULL pointer dereference, address: 0000000000000013 PF: supervisor write access in kernel mode PF: error_code(0x0002) - not-present page PGD 0 P4D 0 PREEMPT SMP NOPTI CPU: 2 PID: 11879 Comm: iptables-restor Not tainted 6.1.92-99.174.amzn2023.x86_64 #1 Hardware name: Amazon EC2 c6i.4xlarge/, BIOS 1.0 10/16/2017 RIP: 0010:iptable_nat_table_init (net/ipv4/netfilter/iptable_nat.c:87 net/ipv4/netfilter/iptable_nat.c:121) iptable_nat Code: 10 4c 89 f6 48 89 ef e8 0b 19 bb ff 41 89 c4 85 c0 75 38 41 83 c7 01 49 83 c6 28 41 83 ff 04 75 dc 48 8b 44 24 08 48 8b 0c 24 <48> 89 08 4c 89 ef e8 a2 3b a2 cf 48 83 c4 10 44 89 e0 5b 5d 41 5c RSP: 0018:ffffbef902843cd0 EFLAGS: 00010246 RAX: 0000000000000013 RBX: ffff9f4b052caa20 RCX: ffff9f4b20988d80 RDX: 0000000000000000 RSI: 0000000000000064 RDI: ffffffffc04201c0 RBP: ffff9f4b29394000 R08: ffff9f4b07f77258 R09: ffff9f4b07f77240 R10: 0000000000000000 R11: ffff9f4b09635388 R12: 0000000000000000 R13: ffff9f4b1a3c6c00 R14: ffff9f4b20988e20 R15: 0000000000000004 FS: 00007f6284340000(0000) GS:ffff9f51fe280000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000013 CR3: 00000001d10a6005 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259) ? xt_find_table_lock (net/netfilter/x_tables.c:1259) ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420) ? • https://git.kernel.org/stable/c/fdacd57c79b79a03c7ca88f706ad9fb7b46831c1 https://git.kernel.org/stable/c/b98ddb65fa1674b0e6b52de8af9103b63f51b643 https://git.kernel.org/stable/c/95590a4929027769af35b153645c0ab6fd22b29b https://git.kernel.org/stable/c/70014b73d7539fcbb6b4ff5f37368d7241d8e626 https://git.kernel.org/stable/c/08ed888b69a22647153fe2bec55b7cd0a46102cc https://git.kernel.org/stable/c/5830aa863981d43560748aa93589c0695191d95d •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-42269 – netfilter: iptables: Fix potential null-ptr-deref in ip6table_nat_table_init().
https://notcve.org/view.php?id=CVE-2024-42269
In the Linux kernel, the following vulnerability has been resolved: netfilter: iptables: Fix potential null-ptr-deref in ip6table_nat_table_init(). ip6table_nat_table_init() accesses net->gen->ptr[ip6table_nat_net_ops.id], but the function is exposed to user space before the entry is allocated via register_pernet_subsys(). Let's call register_pernet_subsys() before xt_register_template(). • https://git.kernel.org/stable/c/fdacd57c79b79a03c7ca88f706ad9fb7b46831c1 https://git.kernel.org/stable/c/419ee6274c5153b89c4393c1946faa4c3cad4f9e https://git.kernel.org/stable/c/91b6df6611b7edb28676c4f63f90c56c30d3e601 https://git.kernel.org/stable/c/e85b9b6a87be4cb3710082038b677e97f2389003 https://git.kernel.org/stable/c/87dba44e9471b79b255d0736858a897332db9226 https://git.kernel.org/stable/c/c22921df777de5606f1047b1345b8d22ef1c0b34 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-42268 – net/mlx5: Fix missing lock on sync reset reload
https://notcve.org/view.php?id=CVE-2024-42268
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Fix missing lock on sync reset reload On sync reset reload work, when remote host updates devlink on reload actions performed on that host, it misses taking devlink lock before calling devlink_remote_reload_actions_performed() which results in triggering lock assert like the following: WARNING: CPU: 4 PID: 1164 at net/devlink/core.c:261 devl_assert_locked+0x3e/0x50 … CPU: 4 PID: 1164 Comm: kworker/u96:6 Tainted: G S W 6.10.0-rc2+ #116 Hardware name: Supermicro SYS-2028TP-DECTR/X10DRT-PT, BIOS 2.0 12/18/2015 Workqueue: mlx5_fw_reset_events mlx5_sync_reset_reload_work [mlx5_core] RIP: 0010:devl_assert_locked+0x3e/0x50 … Call Trace: <TASK> ? __warn+0xa4/0x210 ? devl_assert_locked+0x3e/0x50 ? report_bug+0x160/0x280 ? handle_bug+0x3f/0x80 ? • https://git.kernel.org/stable/c/84a433a40d0ebf3bbf36b8bfa58c6f45dc782344 https://git.kernel.org/stable/c/5d07d1d40aabfd61bab21115639bd4f641db6002 https://git.kernel.org/stable/c/98884e89c90d077f6fe6ba18e6cf6f914642f04e https://git.kernel.org/stable/c/091268f3c27a5b6d7858a3bb2a0dbcc9cd26ddb5 https://git.kernel.org/stable/c/572f9caa9e7295f8c8822e4122c7ae8f1c412ff9 •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-42267 – riscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error()
https://notcve.org/view.php?id=CVE-2024-42267
In the Linux kernel, the following vulnerability has been resolved: riscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error() Handle VM_FAULT_SIGSEGV in the page fault path so that we correctly kill the process and we don't BUG() the kernel. • https://git.kernel.org/stable/c/07037db5d479f90377c998259a4f9a469c404edf https://git.kernel.org/stable/c/59be4a167782d68e21068a761b90b01fadc09146 https://git.kernel.org/stable/c/20dbdebc5580cd472a310d56a6e252275ee4c864 https://git.kernel.org/stable/c/d7ccf2ca772bfe33e2c53ef80fa20d2d87eb6144 https://git.kernel.org/stable/c/917f598209f3f5e4ab175d5079d8aeb523e58b1f https://git.kernel.org/stable/c/d4e7db757e2d7f4c407a007e92c98477eab215d2 https://git.kernel.org/stable/c/0c710050c47d45eb77b28c271cddefc5c785cb40 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42265 – protect the fetch of ->fd[fd] in do_dup2() from mispredictions
https://notcve.org/view.php?id=CVE-2024-42265
In the Linux kernel, the following vulnerability has been resolved: protect the fetch of ->fd[fd] in do_dup2() from mispredictions both callers have verified that fd is not greater than ->max_fds; however, misprediction might end up with tofree = fdt->fd[fd]; being speculatively executed. That's wrong for the same reasons why it's wrong in close_fd()/file_close_fd_locked(); the same solution applies - array_index_nospec(fd, fdt->max_fds) could differ from fd only in case of speculative execution on mispredicted path. • https://git.kernel.org/stable/c/ed42e8ff509d2a61c6642d1825032072dab79f26 https://git.kernel.org/stable/c/41a6c31df77bd8e050136b0a200b537da9e1084a https://git.kernel.org/stable/c/08775b3d6ed117cf4518754ec7300ee42b6a5368 https://git.kernel.org/stable/c/3f480493550b6a23d3a65d095d6569d4a7f56a0f https://git.kernel.org/stable/c/5db999fff545b924b24c9afd368ef5c17279b176 https://git.kernel.org/stable/c/da72e783afd27d9f487836b2e6738146c0edd149 https://git.kernel.org/stable/c/1171ceccabfd596ca370c5d2cbb47d110c3f2fe1 https://git.kernel.org/stable/c/8aa37bde1a7b645816cda8b80df4753ec • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •