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: 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: -EPSS: 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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-42259 – drm/i915/gem: Fix Virtual Memory mapping boundaries calculation
https://notcve.org/view.php?id=CVE-2024-42259
In the Linux kernel, the following vulnerability has been resolved: drm/i915/gem: Fix Virtual Memory mapping boundaries calculation Calculating the size of the mapped area as the lesser value between the requested size and the actual size does not consider the partial mapping offset. This can cause page fault access. Fix the calculation of the starting and ending addresses, the total size is now deduced from the difference between the end and start addresses. Additionally, the calculations have been rewritten in a clearer and more understandable form. [Joonas: Add Requires: tag] Requires: 60a2066c5005 ("drm/i915/gem: Adjust vma offset for framebuffer mmap offset") (cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417) Linux i915 suffers from an out-of-bounds PTE write in vm_fault_gtt() that leads to a PTE use-after-free vulnerability. • https://git.kernel.org/stable/c/c58305af1835095ddc25ee6f548ac05915e66ac5 https://git.kernel.org/stable/c/3e06073d24807f04b4694108a8474decb7b99e60 https://git.kernel.org/stable/c/a256d019eaf044864c7e50312f0a65b323c24f39 https://git.kernel.org/stable/c/50111a8098fb9ade621eeff82228a997d42732ab https://git.kernel.org/stable/c/911f8055f175c82775d0fd8cedcd0b75413f4ba7 https://git.kernel.org/stable/c/e8a68aa842d3f8dd04a46b9d632e5f67fde1da9b https://git.kernel.org/stable/c/4b09513ce93b3dcb590baaaff2ce96f2d098312d https://git.kernel.org/stable/c/ead9289a51ea82eb5b27029fcf4c34b2d •