Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix memory leak in tracing_read_pipe()<br /> <br /> kmemleak reports this issue:<br /> <br /> unreferenced object 0xffff888105a18900 (size 128):<br /> comm "test_progs", pid 18933, jiffies 4336275356 (age 22801.766s)<br /> hex dump (first 32 bytes):<br /> 25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04 %s......&amp;...B.X.<br /> 03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmalloc_node_track_caller+0x4a/0x140<br /> [] krealloc+0x8d/0xf0<br /> [] trace_iter_expand_format+0x99/0x150<br /> [] trace_check_vprintf+0x1e0/0x11d0<br /> [] trace_event_printf+0xb6/0xf0<br /> [] trace_raw_output_bpf_trace_printk+0x89/0xc0<br /> [] print_trace_line+0x73c/0x1480<br /> [] tracing_read_pipe+0x45c/0x9f0<br /> [] vfs_read+0x17b/0x7c0<br /> [] ksys_read+0xed/0x1c0<br /> [] do_syscall_64+0x3b/0x90<br /> [] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> iter-&gt;fmt alloced in<br /> tracing_read_pipe() -&gt; .. -&gt;trace_iter_expand_format(), but not<br /> freed, to fix, add free in tracing_release_pipe()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Input: iforce - invert valid length check when fetching device IDs<br /> <br /> syzbot is reporting uninitialized value at iforce_init_device() [1], for<br /> commit 6ac0aec6b0a6 ("Input: iforce - allow callers supply data buffer<br /> when fetching device IDs") is checking that valid length is shorter than<br /> bytes to read. Since iforce_get_id_packet() stores valid length when<br /> returning 0, the caller needs to check that valid length is longer than or<br /> equals to bytes to read.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: fix multishot accept request leaks<br /> <br /> Having REQ_F_POLLED set doesn&amp;#39;t guarantee that the request is<br /> executed as a multishot from the polling path. Fortunately for us, if<br /> the code thinks it&amp;#39;s multishot issue when it&amp;#39;s not, it can only ask to<br /> skip completion so leaking the request. Use issue_flags to mark<br /> multipoll issues.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: mp2629: fix potential array out of bound access<br /> <br /> Add sentinel at end of maps to avoid potential array out of<br /> bound access in iio core.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: trigger: sysfs: fix possible memory leak in iio_sysfs_trig_init()<br /> <br /> dev_set_name() allocates memory for name, it need be freed<br /> when device_add() fails, call put_device() to give up the<br /> reference that hold in device_initialize(), so that it can<br /> be freed in kobject_cleanup() when the refcount hit to 0.<br /> <br /> Fault injection test can trigger this:<br /> <br /> unreferenced object 0xffff8e8340a7b4c0 (size 32):<br /> comm "modprobe", pid 243, jiffies 4294678145 (age 48.845s)<br /> hex dump (first 32 bytes):<br /> 69 69 6f 5f 73 79 73 66 73 5f 74 72 69 67 67 65 iio_sysfs_trigge<br /> 72 00 a7 40 83 8e ff ff 00 86 13 c4 f6 ee ff ff r..@............<br /> backtrace:<br /> [] __kmem_cache_alloc_node+0x1e9/0x360<br /> [] __kmalloc_node_track_caller+0x44/0x1a0<br /> [] kstrdup+0x2d/0x60<br /> [] kobject_set_name_vargs+0x1e/0x90<br /> [] dev_set_name+0x4e/0x70

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iio: adc: at91_adc: fix possible memory leak in at91_adc_allocate_trigger()<br /> <br /> If iio_trigger_register() returns error, it should call iio_trigger_free()<br /> to give up the reference that hold in iio_trigger_alloc(), so that it can<br /> call iio_trig_release() to free memory when the refcount hit to 0.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rethook: fix a potential memleak in rethook_alloc()<br /> <br /> In rethook_alloc(), the variable rh is not freed or passed out<br /> if handler is NULL, which could lead to a memleak, fix it.<br /> <br /> [Masami: Add "rethook:" tag to the title.]<br /> <br /> Acke-by: Masami Hiramatsu (Google)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: kprobe: Fix potential null-ptr-deref on trace_event_file in kprobe_event_gen_test_exit()<br /> <br /> When trace_get_event_file() failed, gen_kretprobe_test will be assigned<br /> as the error code. If module kprobe_event_gen_test is removed now, the<br /> null pointer dereference will happen in kprobe_event_gen_test_exit().<br /> Check if gen_kprobe_test or gen_kretprobe_test is error code or NULL<br /> before dereference them.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000012<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP PTI<br /> CPU: 3 PID: 2210 Comm: modprobe Not tainted<br /> 6.1.0-rc1-00171-g2159299a3b74-dirty #217<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:kprobe_event_gen_test_exit+0x1c/0xb5 [kprobe_event_gen_test]<br /> Code: Unable to access opcode bytes at 0xffffffff9ffffff2.<br /> RSP: 0018:ffffc900015bfeb8 EFLAGS: 00010246<br /> RAX: ffffffffffffffea RBX: ffffffffa0002080 RCX: 0000000000000000<br /> RDX: ffffffffa0001054 RSI: ffffffffa0001064 RDI: ffffffffdfc6349c<br /> RBP: ffffffffa0000000 R08: 0000000000000004 R09: 00000000001e95c0<br /> R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000800<br /> R13: ffffffffa0002420 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 00007f56b75be540(0000) GS:ffff88813bc00000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffffff9ffffff2 CR3: 000000010874a006 CR4: 0000000000330ee0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __x64_sys_delete_module+0x206/0x380<br /> ? lockdep_hardirqs_on_prepare+0xd8/0x190<br /> ? syscall_enter_from_user_mode+0x1c/0x50<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: kprobe: Fix potential null-ptr-deref on trace_array in kprobe_event_gen_test_exit()<br /> <br /> When test_gen_kprobe_cmd() failed after kprobe_event_gen_cmd_end(), it<br /> will goto delete, which will call kprobe_event_delete() and release the<br /> corresponding resource. However, the trace_array in gen_kretprobe_test<br /> will point to the invalid resource. Set gen_kretprobe_test to NULL<br /> after called kprobe_event_delete() to prevent null-ptr-deref.<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000070<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP PTI<br /> CPU: 0 PID: 246 Comm: modprobe Tainted: G W<br /> 6.1.0-rc1-00174-g9522dc5c87da-dirty #248<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS<br /> rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:__ftrace_set_clr_event_nolock+0x53/0x1b0<br /> Code: e8 82 26 fc ff 49 8b 1e c7 44 24 0c ea ff ff ff 49 39 de 0f 84 3c<br /> 01 00 00 c7 44 24 18 00 00 00 00 e8 61 26 fc ff 48 8b 6b 10 8b 65<br /> 70 4c 8b 6d 18 41 f7 c4 00 02 00 00 75 2f<br /> RSP: 0018:ffffc9000159fe00 EFLAGS: 00010293<br /> RAX: 0000000000000000 RBX: ffff88810971d268 RCX: 0000000000000000<br /> RDX: ffff8881080be600 RSI: ffffffff811b48ff RDI: ffff88810971d058<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000001<br /> R10: ffffc9000159fe58 R11: 0000000000000001 R12: ffffffffa0001064<br /> R13: ffffffffa000106c R14: ffff88810971d238 R15: 0000000000000000<br /> FS: 00007f89eeff6540(0000) GS:ffff88813b600000(0000)<br /> knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000070 CR3: 000000010599e004 CR4: 0000000000330ef0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> __ftrace_set_clr_event+0x3e/0x60<br /> trace_array_set_clr_event+0x35/0x50<br /> ? 0xffffffffa0000000<br /> kprobe_event_gen_test_exit+0xcd/0x10b [kprobe_event_gen_test]<br /> __x64_sys_delete_module+0x206/0x380<br /> ? lockdep_hardirqs_on_prepare+0xd8/0x190<br /> ? syscall_enter_from_user_mode+0x1c/0x50<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7f89eeb061b7

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram()<br /> <br /> `struct vmci_event_qp` allocated by qp_notify_peer() contains padding,<br /> which may carry uninitialized data to the userspace, as observed by<br /> KMSAN:<br /> <br /> BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121<br /> instrument_copy_to_user ./include/linux/instrumented.h:121<br /> _copy_to_user+0x5f/0xb0 lib/usercopy.c:33<br /> copy_to_user ./include/linux/uaccess.h:169<br /> vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431<br /> vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925<br /> vfs_ioctl fs/ioctl.c:51<br /> ...<br /> <br /> Uninit was stored to memory at:<br /> kmemdup+0x74/0xb0 mm/util.c:131<br /> dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271<br /> vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339<br /> qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479<br /> qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662<br /> qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750<br /> vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940<br /> vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488<br /> vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927<br /> ...<br /> <br /> Local variable ev created at:<br /> qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456<br /> qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662<br /> qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750<br /> <br /> Bytes 28-31 of 48 are uninitialized<br /> Memory access of size 48 starts at ffff888035155e00<br /> Data copied to user address 0000000020000100<br /> <br /> Use memset() to prevent the infoleaks.<br /> <br /> Also speculatively fix qp_notify_peer_local(), which may suffer from the<br /> same problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: zfcp: Fix double free of FSF request when qdio send fails<br /> <br /> We used to use the wrong type of integer in &amp;#39;zfcp_fsf_req_send()&amp;#39; to cache<br /> the FSF request ID when sending a new FSF request. This is used in case the<br /> sending fails and we need to remove the request from our internal hash<br /> table again (so we don&amp;#39;t keep an invalid reference and use it when we free<br /> the request again).<br /> <br /> In &amp;#39;zfcp_fsf_req_send()&amp;#39; we used to cache the ID as &amp;#39;int&amp;#39; (signed and 32<br /> bit wide), but the rest of the zfcp code (and the firmware specification)<br /> handles the ID as &amp;#39;unsigned long&amp;#39;/&amp;#39;u64&amp;#39; (unsigned and 64 bit wide [s390x<br /> ELF ABI]). For one this has the obvious problem that when the ID grows<br /> past 32 bit (this can happen reasonably fast) it is truncated to 32 bit<br /> when storing it in the cache variable and so doesn&amp;#39;t match the original ID<br /> anymore. The second less obvious problem is that even when the original ID<br /> has not yet grown past 32 bit, as soon as the 32nd bit is set in the<br /> original ID (0x80000000 = 2&amp;#39;147&amp;#39;483&amp;#39;648) we will have a mismatch when we<br /> cast it back to &amp;#39;unsigned long&amp;#39;. As the cached variable is of a signed<br /> type, the compiler will choose a sign-extending instruction to load the 32<br /> bit variable into a 64 bit register (e.g.: &amp;#39;lgf %r11,188(%r15)&amp;#39;). So once<br /> we pass the cached variable into &amp;#39;zfcp_reqlist_find_rm()&amp;#39; to remove the<br /> request again all the leading zeros will be flipped to ones to extend the<br /> sign and won&amp;#39;t match the original ID anymore (this has been observed in<br /> practice).<br /> <br /> If we can&amp;#39;t successfully remove the request from the hash table again after<br /> &amp;#39;zfcp_qdio_send()&amp;#39; fails (this happens regularly when zfcp cannot notify<br /> the adapter about new work because the adapter is already gone during<br /> e.g. a ChpID toggle) we will end up with a double free. We unconditionally<br /> free the request in the calling function when &amp;#39;zfcp_fsf_req_send()&amp;#39; fails,<br /> but because the request is still in the hash table we end up with a stale<br /> memory reference, and once the zfcp adapter is either reset during recovery<br /> or shutdown we end up freeing the same memory twice.<br /> <br /> The resulting stack traces vary depending on the kernel and have no direct<br /> correlation to the place where the bug occurs. Here are three examples that<br /> have been seen in practice:<br /> <br /> list_del corruption. next-&gt;prev should be 00000001b9d13800, but was 00000000dead4ead. (next=00000001bd131a00)<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/list_debug.c:62!<br /> monitor event: 0040 ilc:2 [#1] PREEMPT SMP<br /> Modules linked in: ...<br /> CPU: 9 PID: 1617 Comm: zfcperp0.0.1740 Kdump: loaded<br /> Hardware name: ...<br /> Krnl PSW : 0704d00180000000 00000003cbeea1f8 (__list_del_entry_valid+0x98/0x140)<br /> R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 PM:0 RI:0 EA:3<br /> Krnl GPRS: 00000000916d12f1 0000000080000000 000000000000006d 00000003cb665cd6<br /> 0000000000000001 0000000000000000 0000000000000000 00000000d28d21e8<br /> 00000000d3844000 00000380099efd28 00000001bd131a00 00000001b9d13800<br /> 00000000d3290100 0000000000000000 00000003cbeea1f4 00000380099efc70<br /> Krnl Code: 00000003cbeea1e8: c020004f68a7 larl %r2,00000003cc8d7336<br /> 00000003cbeea1ee: c0e50027fd65 brasl %r14,00000003cc3e9cb8<br /> #00000003cbeea1f4: af000000 mc 0,0<br /> &gt;00000003cbeea1f8: c02000920440 larl %r2,00000003cd12aa78<br /> 00000003cbeea1fe: c0e500289c25 brasl %r14,00000003cc3fda48<br /> 00000003cbeea204: b9040043 lgr %r4,%r3<br /> 00000003cbeea208: b9040051 lgr %r5,%r1<br /> 00000003cbeea20c: b9040032 lgr %r3,%r2<br /> Call Trace:<br /> [] __list_del_entry_valid+0x98/0x140<br /> ([] __list_del_entry_valid+0x94/0x140)<br /> [] zfcp_fsf_req_dismiss_all+0xde/0x150 [zfcp]<br /> [] zfcp_erp_strategy_do_action+0x160/0x280 [zfcp]<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kprobes: Skip clearing aggrprobe&amp;#39;s post_handler in kprobe-on-ftrace case<br /> <br /> In __unregister_kprobe_top(), if the currently unregistered probe has<br /> post_handler but other child probes of the aggrprobe do not have<br /> post_handler, the post_handler of the aggrprobe is cleared. If this is<br /> a ftrace-based probe, there is a problem. In later calls to<br /> disarm_kprobe(), we will use kprobe_ftrace_ops because post_handler is<br /> NULL. But we&amp;#39;re armed with kprobe_ipmodify_ops. This triggers a WARN in<br /> __disarm_kprobe_ftrace() and may even cause use-after-free:<br /> <br /> Failed to disarm kprobe-ftrace at kernel_clone+0x0/0x3c0 (error -2)<br /> WARNING: CPU: 5 PID: 137 at kernel/kprobes.c:1135 __disarm_kprobe_ftrace.isra.21+0xcf/0xe0<br /> Modules linked in: testKprobe_007(-)<br /> CPU: 5 PID: 137 Comm: rmmod Not tainted 6.1.0-rc4-dirty #18<br /> [...]<br /> Call Trace:<br /> <br /> __disable_kprobe+0xcd/0xe0<br /> __unregister_kprobe_top+0x12/0x150<br /> ? mutex_lock+0xe/0x30<br /> unregister_kprobes.part.23+0x31/0xa0<br /> unregister_kprobe+0x32/0x40<br /> __x64_sys_delete_module+0x15e/0x260<br /> ? do_user_addr_fault+0x2cd/0x6b0<br /> do_syscall_64+0x3a/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [...]<br /> <br /> For the kprobe-on-ftrace case, we keep the post_handler setting to<br /> identify this aggrprobe armed with kprobe_ipmodify_ops. This way we<br /> can disarm it correctly.