Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> um: Fix out-of-bounds read in LDT setup<br /> <br /> syscall_stub_data() expects the data_count parameter to be the number of<br /> longs, not bytes.<br /> <br /> ==================================================================<br /> BUG: KASAN: stack-out-of-bounds in syscall_stub_data+0x70/0xe0<br /> Read of size 128 at addr 000000006411f6f0 by task swapper/1<br /> <br /> CPU: 0 PID: 1 Comm: swapper Not tainted 5.18.0+ #18<br /> Call Trace:<br /> show_stack.cold+0x166/0x2a7<br /> __dump_stack+0x3a/0x43<br /> dump_stack_lvl+0x1f/0x27<br /> print_report.cold+0xdb/0xf81<br /> kasan_report+0x119/0x1f0<br /> kasan_check_range+0x3a3/0x440<br /> memcpy+0x52/0x140<br /> syscall_stub_data+0x70/0xe0<br /> write_ldt_entry+0xac/0x190<br /> init_new_ldt+0x515/0x960<br /> init_new_context+0x2c4/0x4d0<br /> mm_init.constprop.0+0x5ed/0x760<br /> mm_alloc+0x118/0x170<br /> 0x60033f48<br /> do_one_initcall+0x1d7/0x860<br /> 0x60003e7b<br /> kernel_init+0x6e/0x3d4<br /> new_thread_handler+0x1e7/0x2c0<br /> <br /> The buggy address belongs to stack of task swapper/1<br /> and is located at offset 64 in frame:<br /> init_new_ldt+0x0/0x960<br /> <br /> This frame has 2 objects:<br /> [32, 40) &amp;#39;addr&amp;#39;<br /> [64, 80) &amp;#39;desc&amp;#39;<br /> ==================================================================

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: qcom-qmp: fix reset-controller leak on probe errors<br /> <br /> Make sure to release the lane reset controller in case of a late probe<br /> error (e.g. probe deferral).<br /> <br /> Note that due to the reset controller being defined in devicetree in<br /> "lane" child nodes, devm_reset_control_get_exclusive() cannot be used<br /> directly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: qcom-qmp: fix struct clk leak on probe errors<br /> <br /> Make sure to release the pipe clock reference in case of a late probe<br /> error (e.g. probe deferral).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: dwc3: gadget: Replace list_for_each_entry_safe() if using giveback<br /> <br /> The list_for_each_entry_safe() macro saves the current item (n) and<br /> the item after (n+1), so that n can be safely removed without<br /> corrupting the list. However, when traversing the list and removing<br /> items using gadget giveback, the DWC3 lock is briefly released,<br /> allowing other routines to execute. There is a situation where, while<br /> items are being removed from the cancelled_list using<br /> dwc3_gadget_ep_cleanup_cancelled_requests(), the pullup disable<br /> routine is running in parallel (due to UDC unbind). As the cleanup<br /> routine removes n, and the pullup disable removes n+1, once the<br /> cleanup retakes the DWC3 lock, it references a request who was already<br /> removed/handled. With list debug enabled, this leads to a panic.<br /> Ensure all instances of the macro are replaced where gadget giveback<br /> is used.<br /> <br /> Example call stack:<br /> <br /> Thread#1:<br /> __dwc3_gadget_ep_set_halt() - CLEAR HALT<br /> -&gt; dwc3_gadget_ep_cleanup_cancelled_requests()<br /> -&gt;list_for_each_entry_safe()<br /> -&gt;dwc3_gadget_giveback(n)<br /> -&gt;dwc3_gadget_del_and_unmap_request()- n deleted[cancelled_list]<br /> -&gt;spin_unlock<br /> -&gt;Thread#2 executes<br /> ...<br /> -&gt;dwc3_gadget_giveback(n+1)<br /> -&gt;Already removed!<br /> <br /> Thread#2:<br /> dwc3_gadget_pullup()<br /> -&gt;waiting for dwc3 spin_lock<br /> ...<br /> -&gt;Thread#1 released lock<br /> -&gt;dwc3_stop_active_transfers()<br /> -&gt;dwc3_remove_requests()<br /> -&gt;fetches n+1 item from cancelled_list (n removed by Thread#1)<br /> -&gt;dwc3_gadget_giveback()<br /> -&gt;dwc3_gadget_del_and_unmap_request()- n+1 deleted[cancelled_list]<br /> -&gt;spin_unlock

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: goldfish: Use tty_port_destroy() to destroy port<br /> <br /> In goldfish_tty_probe(), the port initialized through tty_port_init()<br /> should be destroyed in error paths.In goldfish_tty_remove(), qtty-&gt;port<br /> also should be destroyed or else might leak resources.<br /> <br /> Fix the above by calling tty_port_destroy().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: Don&amp;#39;t set mddev private to NULL in raid0 pers-&gt;free<br /> <br /> In normal stop process, it does like this:<br /> do_md_stop<br /> |<br /> __md_stop (pers-&gt;free(); mddev-&gt;private=NULL)<br /> |<br /> md_free (free mddev)<br /> __md_stop sets mddev-&gt;private to NULL after pers-&gt;free. The raid device<br /> will be stopped and mddev memory is free. But in reshape, it doesn&amp;#39;t<br /> free the mddev and mddev will still be used in new raid.<br /> <br /> In reshape, it first sets mddev-&gt;private to new_pers and then runs<br /> old_pers-&gt;free(). Now raid0 sets mddev-&gt;private to NULL in raid0_free.<br /> The new raid can&amp;#39;t work anymore. It will panic when dereference<br /> mddev-&gt;private because of NULL pointer dereference.<br /> <br /> It can panic like this:<br /> [63010.814972] kernel BUG at drivers/md/raid10.c:928!<br /> [63010.819778] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [63010.825011] CPU: 3 PID: 44437 Comm: md0_resync Kdump: loaded Not tainted 5.14.0-86.el9.x86_64 #1<br /> [63010.833789] Hardware name: Dell Inc. PowerEdge R6415/07YXFK, BIOS 1.15.0 09/11/2020<br /> [63010.841440] RIP: 0010:raise_barrier+0x161/0x170 [raid10]<br /> [63010.865508] RSP: 0018:ffffc312408bbc10 EFLAGS: 00010246<br /> [63010.870734] RAX: 0000000000000000 RBX: ffffa00bf7d39800 RCX: 0000000000000000<br /> [63010.877866] RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffa00bf7d39800<br /> [63010.884999] RBP: 0000000000000000 R08: fffffa4945e74400 R09: 0000000000000000<br /> [63010.892132] R10: ffffa00eed02f798 R11: 0000000000000000 R12: ffffa00bbc435200<br /> [63010.899266] R13: ffffa00bf7d39800 R14: 0000000000000400 R15: 0000000000000003<br /> [63010.906399] FS: 0000000000000000(0000) GS:ffffa00eed000000(0000) knlGS:0000000000000000<br /> [63010.914485] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [63010.920229] CR2: 00007f5cfbe99828 CR3: 0000000105efe000 CR4: 00000000003506e0<br /> [63010.927363] Call Trace:<br /> [63010.929822] ? bio_reset+0xe/0x40<br /> [63010.933144] ? raid10_alloc_init_r10buf+0x60/0xa0 [raid10]<br /> [63010.938629] raid10_sync_request+0x756/0x1610 [raid10]<br /> [63010.943770] md_do_sync.cold+0x3e4/0x94c<br /> [63010.947698] md_thread+0xab/0x160<br /> [63010.951024] ? md_write_inc+0x50/0x50<br /> [63010.954688] kthread+0x149/0x170<br /> [63010.957923] ? set_kthread_struct+0x40/0x40<br /> [63010.962107] ret_from_fork+0x22/0x30<br /> <br /> Removing the code that sets mddev-&gt;private to NULL in raid0 can fix<br /> problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/page_owner: use strscpy() instead of strlcpy()<br /> <br /> current-&gt;comm[] is not a string (no guarantee for a zero byte in it).<br /> <br /> strlcpy(s1, s2, l) is calling strlen(s2), potentially<br /> causing out-of-bound access, as reported by syzbot:<br /> <br /> detected buffer overflow in __fortify_strlen<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/string_helpers.c:980!<br /> invalid opcode: 0000 [#1] PREEMPT SMP KASAN<br /> CPU: 0 PID: 4087 Comm: dhcpcd-run-hooks Not tainted 5.18.0-rc3-syzkaller-01537-g20b87e7c29df #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011<br /> RIP: 0010:fortify_panic+0x18/0x1a lib/string_helpers.c:980<br /> Code: 8c e8 c5 ba e1 fa e9 23 0f bf fa e8 0b 5d 8c f8 eb db 55 48 89 fd e8 e0 49 40 f8 48 89 ee 48 c7 c7 80 f5 26 8a e8 99 09 f1 ff 0b e8 ca 49 40 f8 48 8b 54 24 18 4c 89 f1 48 c7 c7 00 00 27 8a<br /> RSP: 0018:ffffc900000074a8 EFLAGS: 00010286<br /> <br /> RAX: 000000000000002c RBX: ffff88801226b728 RCX: 0000000000000000<br /> RDX: ffff8880198e0000 RSI: ffffffff81600458 RDI: fffff52000000e87<br /> RBP: ffffffff89da2aa0 R08: 000000000000002c R09: 0000000000000000<br /> R10: ffffffff815fae2e R11: 0000000000000000 R12: ffff88801226b700<br /> R13: ffff8880198e0830 R14: 0000000000000000 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f5876ad6ff8 CR3: 000000001a48c000 CR4: 00000000003506f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600<br /> Call Trace:<br /> <br /> __fortify_strlen include/linux/fortify-string.h:128 [inline]<br /> strlcpy include/linux/fortify-string.h:143 [inline]<br /> __set_page_owner_handle+0x2b1/0x3e0 mm/page_owner.c:171<br /> __set_page_owner+0x3e/0x50 mm/page_owner.c:190<br /> prep_new_page mm/page_alloc.c:2441 [inline]<br /> get_page_from_freelist+0xba2/0x3e00 mm/page_alloc.c:4182<br /> __alloc_pages+0x1b2/0x500 mm/page_alloc.c:5408<br /> alloc_pages+0x1aa/0x310 mm/mempolicy.c:2272<br /> alloc_slab_page mm/slub.c:1799 [inline]<br /> allocate_slab+0x26c/0x3c0 mm/slub.c:1944<br /> new_slab mm/slub.c:2004 [inline]<br /> ___slab_alloc+0x8df/0xf20 mm/slub.c:3005<br /> __slab_alloc.constprop.0+0x4d/0xa0 mm/slub.c:3092<br /> slab_alloc_node mm/slub.c:3183 [inline]<br /> slab_alloc mm/slub.c:3225 [inline]<br /> __kmem_cache_alloc_lru mm/slub.c:3232 [inline]<br /> kmem_cache_alloc+0x360/0x3b0 mm/slub.c:3242<br /> dst_alloc+0x146/0x1f0 net/core/dst.c:92

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ftrace: Clean up hash direct_functions on register failures<br /> <br /> We see the following GPF when register_ftrace_direct fails:<br /> <br /> [ ] general protection fault, probably for non-canonical address \<br /> 0x200000000000010: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI<br /> [...]<br /> [ ] RIP: 0010:ftrace_find_rec_direct+0x53/0x70<br /> [ ] Code: 48 c1 e0 03 48 03 42 08 48 8b 10 31 c0 48 85 d2 74 [...]<br /> [ ] RSP: 0018:ffffc9000138bc10 EFLAGS: 00010206<br /> [ ] RAX: 0000000000000000 RBX: ffffffff813e0df0 RCX: 000000000000003b<br /> [ ] RDX: 0200000000000000 RSI: 000000000000000c RDI: ffffffff813e0df0<br /> [ ] RBP: ffffffffa00a3000 R08: ffffffff81180ce0 R09: 0000000000000001<br /> [ ] R10: ffffc9000138bc18 R11: 0000000000000001 R12: ffffffff813e0df0<br /> [ ] R13: ffffffff813e0df0 R14: ffff888171b56400 R15: 0000000000000000<br /> [ ] FS: 00007fa9420c7780(0000) GS:ffff888ff6a00000(0000) knlGS:000000000<br /> [ ] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ ] CR2: 000000000770d000 CR3: 0000000107d50003 CR4: 0000000000370ee0<br /> [ ] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ ] Call Trace:<br /> [ ] <br /> [ ] register_ftrace_direct+0x54/0x290<br /> [ ] ? render_sigset_t+0xa0/0xa0<br /> [ ] bpf_trampoline_update+0x3f5/0x4a0<br /> [ ] ? 0xffffffffa00a3000<br /> [ ] bpf_trampoline_link_prog+0xa9/0x140<br /> [ ] bpf_tracing_prog_attach+0x1dc/0x450<br /> [ ] bpf_raw_tracepoint_open+0x9a/0x1e0<br /> [ ] ? find_held_lock+0x2d/0x90<br /> [ ] ? lock_release+0x150/0x430<br /> [ ] __sys_bpf+0xbd6/0x2700<br /> [ ] ? lock_is_held_type+0xd8/0x130<br /> [ ] __x64_sys_bpf+0x1c/0x20<br /> [ ] do_syscall_64+0x3a/0x80<br /> [ ] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ ] RIP: 0033:0x7fa9421defa9<br /> [ ] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 9 f8 [...]<br /> [ ] RSP: 002b:00007ffed743bd78 EFLAGS: 00000246 ORIG_RAX: 0000000000000141<br /> [ ] RAX: ffffffffffffffda RBX: 00000000069d2480 RCX: 00007fa9421defa9<br /> [ ] RDX: 0000000000000078 RSI: 00007ffed743bd80 RDI: 0000000000000011<br /> [ ] RBP: 00007ffed743be00 R08: 0000000000bb7270 R09: 0000000000000000<br /> [ ] R10: 00000000069da210 R11: 0000000000000246 R12: 0000000000000001<br /> [ ] R13: 00007ffed743c4b0 R14: 00000000069d2480 R15: 0000000000000001<br /> [ ] <br /> [ ] Modules linked in: klp_vm(OK)<br /> [ ] ---[ end trace 0000000000000000 ]---<br /> <br /> One way to trigger this is:<br /> 1. load a livepatch that patches kernel function xxx;<br /> 2. run bpftrace -e &amp;#39;kfunc:xxx {}&amp;#39;, this will fail (expected for now);<br /> 3. repeat #2 =&gt; gpf.<br /> <br /> This is because the entry is added to direct_functions, but not removed.<br /> Fix this by remove the entry from direct_functions when<br /> register_ftrace_direct fails.<br /> <br /> Also remove the last trailing space from ftrace.c, so we don&amp;#39;t have to<br /> worry about it anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/string_helpers: fix not adding strarray to device&amp;#39;s resource list<br /> <br /> Add allocated strarray to device&amp;#39;s resource list. This is a must to<br /> automatically release strarray when the device disappears.<br /> <br /> Without this fix we have a memory leak in the few drivers which use<br /> devm_kasprintf_strarray().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/hfi1: Fix potential integer multiplication overflow errors<br /> <br /> When multiplying of different types, an overflow is possible even when<br /> storing the result in a larger type. This is because the conversion is<br /> done after the multiplication. So arithmetic overflow and thus in<br /> incorrect value is possible.<br /> <br /> Correct an instance of this in the inter packet delay calculation. Fix by<br /> ensuring one of the operands is u64 which will promote the other to u64 as<br /> well ensuring no overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md: fix double free of io_acct_set bioset<br /> <br /> Now io_acct_set is alloc and free in personality. Remove the codes that<br /> free io_acct_set in md_free and md_stop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> driver: base: fix UAF when driver_attach failed<br /> <br /> When driver_attach(drv); failed, the driver_private will be freed.<br /> But it has been added to the bus, which caused a UAF.<br /> <br /> To fix it, we need to delete it from the bus when failed.