Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ethernet: ti: am65-cpsw-nuss: Fix some refcount leaks<br /> <br /> of_get_child_by_name() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> am65_cpsw_init_cpts() and am65_cpsw_nuss_probe() don&amp;#39;t release<br /> the refcount in error case.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> watchdog: rzg2l_wdt: Fix 32bit overflow issue<br /> <br /> The value of timer_cycle_us can be 0 due to 32bit overflow.<br /> For eg:- If we assign the counter value "0xfff" for computing<br /> maxval.<br /> <br /> This patch fixes this issue by appending ULL to 1024, so that<br /> it is promoted to 64bit.<br /> <br /> This patch also fixes the warning message, &amp;#39;watchdog: Invalid min and<br /> max timeout values, resetting to 0!&amp;#39;.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubi: ubi_create_volume: Fix use-after-free when volume creation failed<br /> <br /> There is an use-after-free problem for &amp;#39;eba_tbl&amp;#39; in ubi_create_volume()&amp;#39;s<br /> error handling path:<br /> <br /> ubi_eba_replace_table(vol, eba_tbl)<br /> vol-&gt;eba_tbl = tbl<br /> out_mapping:<br /> ubi_eba_destroy_table(eba_tbl) // Free &amp;#39;eba_tbl&amp;#39;<br /> out_unlock:<br /> put_device(&amp;vol-&gt;dev)<br /> vol_release<br /> kfree(tbl-&gt;entries) // UAF<br /> <br /> Fix it by removing redundant &amp;#39;eba_tbl&amp;#39; releasing.<br /> Fetch a reproducer in [Link].

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: usbip: fix a refcount leak in stub_probe()<br /> <br /> usb_get_dev() is called in stub_device_alloc(). When stub_probe() fails<br /> after that, usb_put_dev() needs to be called to release the reference.<br /> <br /> Fix this by moving usb_put_dev() to sdev_free error path handling.<br /> <br /> Find this by code review.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macsec: fix UAF bug for real_dev<br /> <br /> Create a new macsec device but not get reference to real_dev. That can<br /> not ensure that real_dev is freed after macsec. That will trigger the<br /> UAF bug for real_dev as following:<br /> <br /> ==================================================================<br /> BUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662<br /> Call Trace:<br /> ...<br /> macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662<br /> dev_get_iflink+0x73/0xe0 net/core/dev.c:637<br /> default_operstate net/core/link_watch.c:42 [inline]<br /> rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54<br /> linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161<br /> <br /> Allocated by task 22209:<br /> ...<br /> alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549<br /> rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235<br /> veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748<br /> <br /> Freed by task 8:<br /> ...<br /> kfree+0xd6/0x4d0 mm/slub.c:4552<br /> kvfree+0x42/0x50 mm/util.c:615<br /> device_release+0x9f/0x240 drivers/base/core.c:2229<br /> kobject_cleanup lib/kobject.c:673 [inline]<br /> kobject_release lib/kobject.c:704 [inline]<br /> kref_put include/linux/kref.h:65 [inline]<br /> kobject_put+0x1c8/0x540 lib/kobject.c:721<br /> netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327<br /> <br /> After commit faab39f63c1f ("net: allow out-of-order netdev unregistration")<br /> and commit e5f80fcf869a ("ipv6: give an IPv6 dev to blackhole_netdev"), we<br /> can add dev_hold_track() in macsec_dev_init() and dev_put_track() in<br /> macsec_free_netdev() to fix the problem.