Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bfq: Make sure bfqg for which we are queueing requests is online<br /> <br /> Bios queued into BFQ IO scheduler can be associated with a cgroup that<br /> was already offlined. This may then cause insertion of this bfq_group<br /> into a service tree. But this bfq_group will get freed as soon as last<br /> bio associated with it is completed leading to use after free issues for<br /> service tree users. Fix the problem by making sure we always operate on<br /> online bfq_group. If the bfq_group associated with the bio is not<br /> online, we pick the first online parent.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bfq: Avoid merging queues with different parents<br /> <br /> It can happen that the parent of a bfqq changes between the moment we<br /> decide two queues are worth to merge (and set bic-&gt;stable_merge_bfqq)<br /> and the moment bfq_setup_merge() is called. This can happen e.g. because<br /> the process submitted IO for a different cgroup and thus bfqq got<br /> reparented. It can even happen that the bfqq we are merging with has<br /> parent cgroup that is already offline and going to be destroyed in which<br /> case the merge can lead to use-after-free issues such as:<br /> <br /> BUG: KASAN: use-after-free in __bfq_deactivate_entity+0x9cb/0xa50<br /> Read of size 8 at addr ffff88800693c0c0 by task runc:[2:INIT]/10544<br /> <br /> CPU: 0 PID: 10544 Comm: runc:[2:INIT] Tainted: G E 5.15.2-0.g5fb85fd-default #1 openSUSE Tumbleweed (unreleased) f1f3b891c72369aebecd2e43e4641a6358867c70<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x46/0x5a<br /> print_address_description.constprop.0+0x1f/0x140<br /> ? __bfq_deactivate_entity+0x9cb/0xa50<br /> kasan_report.cold+0x7f/0x11b<br /> ? __bfq_deactivate_entity+0x9cb/0xa50<br /> __bfq_deactivate_entity+0x9cb/0xa50<br /> ? update_curr+0x32f/0x5d0<br /> bfq_deactivate_entity+0xa0/0x1d0<br /> bfq_del_bfqq_busy+0x28a/0x420<br /> ? resched_curr+0x116/0x1d0<br /> ? bfq_requeue_bfqq+0x70/0x70<br /> ? check_preempt_wakeup+0x52b/0xbc0<br /> __bfq_bfqq_expire+0x1a2/0x270<br /> bfq_bfqq_expire+0xd16/0x2160<br /> ? try_to_wake_up+0x4ee/0x1260<br /> ? bfq_end_wr_async_queues+0xe0/0xe0<br /> ? _raw_write_unlock_bh+0x60/0x60<br /> ? _raw_spin_lock_irq+0x81/0xe0<br /> bfq_idle_slice_timer+0x109/0x280<br /> ? bfq_dispatch_request+0x4870/0x4870<br /> __hrtimer_run_queues+0x37d/0x700<br /> ? enqueue_hrtimer+0x1b0/0x1b0<br /> ? kvm_clock_get_cycles+0xd/0x10<br /> ? ktime_get_update_offsets_now+0x6f/0x280<br /> hrtimer_interrupt+0x2c8/0x740<br /> <br /> Fix the problem by checking that the parent of the two bfqqs we are<br /> merging in bfq_setup_merge() is the same.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bfq: Update cgroup information before merging bio<br /> <br /> When the process is migrated to a different cgroup (or in case of<br /> writeback just starts submitting bios associated with a different<br /> cgroup) bfq_merge_bio() can operate with stale cgroup information in<br /> bic. Thus the bio can be merged to a request from a different cgroup or<br /> it can result in merging of bfqqs for different cgroups or bfqqs of<br /> already dead cgroups and causing possible use-after-free issues. Fix the<br /> problem by updating cgroup information in bfq_merge_bio().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix race condition between ext4_write and ext4_convert_inline_data<br /> <br /> Hulk Robot reported a BUG_ON:<br /> ==================================================================<br /> EXT4-fs error (device loop3): ext4_mb_generate_buddy:805: group 0,<br /> block bitmap and bg descriptor inconsistent: 25 vs 31513 free clusters<br /> kernel BUG at fs/ext4/ext4_jbd2.c:53!<br /> invalid opcode: 0000 [#1] SMP KASAN PTI<br /> CPU: 0 PID: 25371 Comm: syz-executor.3 Not tainted 5.10.0+ #1<br /> RIP: 0010:ext4_put_nojournal fs/ext4/ext4_jbd2.c:53 [inline]<br /> RIP: 0010:__ext4_journal_stop+0x10e/0x110 fs/ext4/ext4_jbd2.c:116<br /> [...]<br /> Call Trace:<br /> ext4_write_inline_data_end+0x59a/0x730 fs/ext4/inline.c:795<br /> generic_perform_write+0x279/0x3c0 mm/filemap.c:3344<br /> ext4_buffered_write_iter+0x2e3/0x3d0 fs/ext4/file.c:270<br /> ext4_file_write_iter+0x30a/0x11c0 fs/ext4/file.c:520<br /> do_iter_readv_writev+0x339/0x3c0 fs/read_write.c:732<br /> do_iter_write+0x107/0x430 fs/read_write.c:861<br /> vfs_writev fs/read_write.c:934 [inline]<br /> do_pwritev+0x1e5/0x380 fs/read_write.c:1031<br /> [...]<br /> ==================================================================<br /> <br /> Above issue may happen as follows:<br /> cpu1 cpu2<br /> __________________________|__________________________<br /> do_pwritev<br /> vfs_writev<br /> do_iter_write<br /> ext4_file_write_iter<br /> ext4_buffered_write_iter<br /> generic_perform_write<br /> ext4_da_write_begin<br /> vfs_fallocate<br /> ext4_fallocate<br /> ext4_convert_inline_data<br /> ext4_convert_inline_data_nolock<br /> ext4_destroy_inline_data_nolock<br /> clear EXT4_STATE_MAY_INLINE_DATA<br /> ext4_map_blocks<br /> ext4_ext_map_blocks<br /> ext4_mb_new_blocks<br /> ext4_mb_regular_allocator<br /> ext4_mb_good_group_nolock<br /> ext4_mb_init_group<br /> ext4_mb_init_cache<br /> ext4_mb_generate_buddy --&gt; error<br /> ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)<br /> ext4_restore_inline_data<br /> set EXT4_STATE_MAY_INLINE_DATA<br /> ext4_block_write_begin<br /> ext4_da_write_end<br /> ext4_test_inode_state(inode, EXT4_STATE_MAY_INLINE_DATA)<br /> ext4_write_inline_data_end<br /> handle=NULL<br /> ext4_journal_stop(handle)<br /> __ext4_journal_stop<br /> ext4_put_nojournal(handle)<br /> ref_cnt = (unsigned long)handle<br /> BUG_ON(ref_cnt == 0) ---&gt; BUG_ON<br /> <br /> The lock held by ext4_convert_inline_data is xattr_sem, but the lock<br /> held by generic_perform_write is i_rwsem. Therefore, the two locks can<br /> be concurrent.<br /> <br /> To solve above issue, we add inode_lock() for ext4_convert_inline_data().<br /> At the same time, move ext4_convert_inline_data() in front of<br /> ext4_punch_hole(), remove similar handling from ext4_punch_hole().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipmi:ipmb: Fix refcount leak in ipmi_ipmb_probe<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when done.<br /> Add missing of_node_put() to avoid refcount leak.

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