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 /> staging: r8188eu: prevent -&gt;Ssid overflow in rtw_wx_set_scan()<br /> <br /> This code has a check to prevent read overflow but it needs another<br /> check to prevent writing beyond the end of the -&gt;Ssid[] array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dlm: fix plock invalid read<br /> <br /> This patch fixes an invalid read showed by KASAN. A unlock will allocate a<br /> "struct plock_op" and a followed send_op() will append it to a global<br /> send_list data structure. In some cases a followed dev_read() moves it<br /> to recv_list and dev_write() will cast it to "struct plock_xop" and access<br /> fields which are only available in those structures. At this point an<br /> invalid read happens by accessing those fields.<br /> <br /> To fix this issue the "callback" field is moved to "struct plock_op" to<br /> indicate that a cast to "plock_xop" is allowed and does the additional<br /> "plock_xop" handling if set.<br /> <br /> Example of the KASAN output which showed the invalid read:<br /> <br /> [ 2064.296453] ==================================================================<br /> [ 2064.304852] BUG: KASAN: slab-out-of-bounds in dev_write+0x52b/0x5a0 [dlm]<br /> [ 2064.306491] Read of size 8 at addr ffff88800ef227d8 by task dlm_controld/7484<br /> [ 2064.308168]<br /> [ 2064.308575] CPU: 0 PID: 7484 Comm: dlm_controld Kdump: loaded Not tainted 5.14.0+ #9<br /> [ 2064.310292] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011<br /> [ 2064.311618] Call Trace:<br /> [ 2064.312218] dump_stack_lvl+0x56/0x7b<br /> [ 2064.313150] print_address_description.constprop.8+0x21/0x150<br /> [ 2064.314578] ? dev_write+0x52b/0x5a0 [dlm]<br /> [ 2064.315610] ? dev_write+0x52b/0x5a0 [dlm]<br /> [ 2064.316595] kasan_report.cold.14+0x7f/0x11b<br /> [ 2064.317674] ? dev_write+0x52b/0x5a0 [dlm]<br /> [ 2064.318687] dev_write+0x52b/0x5a0 [dlm]<br /> [ 2064.319629] ? dev_read+0x4a0/0x4a0 [dlm]<br /> [ 2064.320713] ? bpf_lsm_kernfs_init_security+0x10/0x10<br /> [ 2064.321926] vfs_write+0x17e/0x930<br /> [ 2064.322769] ? __fget_light+0x1aa/0x220<br /> [ 2064.323753] ksys_write+0xf1/0x1c0<br /> [ 2064.324548] ? __ia32_sys_read+0xb0/0xb0<br /> [ 2064.325464] do_syscall_64+0x3a/0x80<br /> [ 2064.326387] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 2064.327606] RIP: 0033:0x7f807e4ba96f<br /> [ 2064.328470] Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 39 87 f8 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 7c 87 f8 ff 48<br /> [ 2064.332902] RSP: 002b:00007ffd50cfe6e0 EFLAGS: 00000293 ORIG_RAX: 0000000000000001<br /> [ 2064.334658] RAX: ffffffffffffffda RBX: 000055cc3886eb30 RCX: 00007f807e4ba96f<br /> [ 2064.336275] RDX: 0000000000000040 RSI: 00007ffd50cfe7e0 RDI: 0000000000000010<br /> [ 2064.337980] RBP: 00007ffd50cfe7e0 R08: 0000000000000000 R09: 0000000000000001<br /> [ 2064.339560] R10: 000055cc3886eb30 R11: 0000000000000293 R12: 000055cc3886eb80<br /> [ 2064.341237] R13: 000055cc3886eb00 R14: 000055cc3886f590 R15: 0000000000000001<br /> [ 2064.342857]<br /> [ 2064.343226] Allocated by task 12438:<br /> [ 2064.344057] kasan_save_stack+0x1c/0x40<br /> [ 2064.345079] __kasan_kmalloc+0x84/0xa0<br /> [ 2064.345933] kmem_cache_alloc_trace+0x13b/0x220<br /> [ 2064.346953] dlm_posix_unlock+0xec/0x720 [dlm]<br /> [ 2064.348811] do_lock_file_wait.part.32+0xca/0x1d0<br /> [ 2064.351070] fcntl_setlk+0x281/0xbc0<br /> [ 2064.352879] do_fcntl+0x5e4/0xfe0<br /> [ 2064.354657] __x64_sys_fcntl+0x11f/0x170<br /> [ 2064.356550] do_syscall_64+0x3a/0x80<br /> [ 2064.358259] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 2064.360745]<br /> [ 2064.361511] Last potentially related work creation:<br /> [ 2064.363957] kasan_save_stack+0x1c/0x40<br /> [ 2064.365811] __kasan_record_aux_stack+0xaf/0xc0<br /> [ 2064.368100] call_rcu+0x11b/0xf70<br /> [ 2064.369785] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm]<br /> [ 2064.372404] receive_from_sock+0x290/0x770 [dlm]<br /> [ 2064.374607] process_recv_sockets+0x32/0x40 [dlm]<br /> [ 2064.377290] process_one_work+0x9a8/0x16e0<br /> [ 2064.379357] worker_thread+0x87/0xbf0<br /> [ 2064.381188] kthread+0x3ac/0x490<br /> [ 2064.383460] ret_from_fork+0x22/0x30<br /> [ 2064.385588]<br /> [ 2064.386518] Second to last potentially related work creation:<br /> [ 2064.389219] kasan_save_stack+0x1c/0x40<br /> [ 2064.391043] __kasan_record_aux_stack+0xaf/0xc0<br /> [ 2064.393303] call_rcu+0x11b/0xf70<br /> [ 2064.394885] dlm_process_incoming_buffer+0x47d/0xfd0 [dlm]<br /> [ 2064.397694] receive_from_sock+0x290/0x770 <br /> ---truncated---

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().