Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix dereference of stale list iterator after loop body<br /> <br /> The list iterator variable will be a bogus pointer if no break was hit.<br /> Dereferencing it (cur-&gt;page in this case) could load an out-of-bounds/undefined<br /> value making it unsafe to use that in the comparision to determine if the<br /> specific element was found.<br /> <br /> Since &amp;#39;cur-&gt;page&amp;#39; *can* be out-ouf-bounds it cannot be guaranteed that<br /> by chance (or intention of an attacker) it matches the value of &amp;#39;page&amp;#39;<br /> even though the correct element was not found.<br /> <br /> This is fixed by using a separate list iterator variable for the loop<br /> and only setting the original variable if a suitable element was found.<br /> Then determing if the element was found is simply checking if the<br /> variable is set.

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 /> block: Fix potential deadlock in blk_ia_range_sysfs_show()<br /> <br /> When being read, a sysfs attribute is already protected against removal<br /> with the kobject node active reference counter. As a result, in<br /> blk_ia_range_sysfs_show(), there is no need to take the queue sysfs<br /> lock when reading the value of a range attribute. Using the queue sysfs<br /> lock in this function creates a potential deadlock situation with the<br /> disk removal, something that a lockdep signals with a splat when the<br /> device is removed:<br /> <br /> [ 760.703551] Possible unsafe locking scenario:<br /> [ 760.703551]<br /> [ 760.703554] CPU0 CPU1<br /> [ 760.703556] ---- ----<br /> [ 760.703558] lock(&amp;q-&gt;sysfs_lock);<br /> [ 760.703565] lock(kn-&gt;active#385);<br /> [ 760.703573] lock(&amp;q-&gt;sysfs_lock);<br /> [ 760.703579] lock(kn-&gt;active#385);<br /> [ 760.703587]<br /> [ 760.703587] *** DEADLOCK ***<br /> <br /> Solve this by removing the mutex_lock()/mutex_unlock() calls from<br /> blk_ia_range_sysfs_show().

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 /> ext4: fix memory leak in parse_apply_sb_mount_options()<br /> <br /> If processing the on-disk mount options fails after any memory was<br /> allocated in the ext4_fs_context, e.g. s_qf_names, then this memory is<br /> leaked. Fix this by calling ext4_fc_free() instead of kfree() directly.<br /> <br /> Reproducer:<br /> <br /> mkfs.ext4 -F /dev/vdc<br /> tune2fs /dev/vdc -E mount_opts=usrjquota=file<br /> echo clear &gt; /sys/kernel/debug/kmemleak<br /> mount /dev/vdc /vdc<br /> echo scan &gt; /sys/kernel/debug/kmemleak<br /> sleep 5<br /> echo scan &gt; /sys/kernel/debug/kmemleak<br /> cat /sys/kernel/debug/kmemleak

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix bug_on in __es_tree_search<br /> <br /> Hulk Robot reported a BUG_ON:<br /> ==================================================================<br /> kernel BUG at fs/ext4/extents_status.c:199!<br /> [...]<br /> RIP: 0010:ext4_es_end fs/ext4/extents_status.c:199 [inline]<br /> RIP: 0010:__es_tree_search+0x1e0/0x260 fs/ext4/extents_status.c:217<br /> [...]<br /> Call Trace:<br /> ext4_es_cache_extent+0x109/0x340 fs/ext4/extents_status.c:766<br /> ext4_cache_extents+0x239/0x2e0 fs/ext4/extents.c:561<br /> ext4_find_extent+0x6b7/0xa20 fs/ext4/extents.c:964<br /> ext4_ext_map_blocks+0x16b/0x4b70 fs/ext4/extents.c:4384<br /> ext4_map_blocks+0xe26/0x19f0 fs/ext4/inode.c:567<br /> ext4_getblk+0x320/0x4c0 fs/ext4/inode.c:980<br /> ext4_bread+0x2d/0x170 fs/ext4/inode.c:1031<br /> ext4_quota_read+0x248/0x320 fs/ext4/super.c:6257<br /> v2_read_header+0x78/0x110 fs/quota/quota_v2.c:63<br /> v2_check_quota_file+0x76/0x230 fs/quota/quota_v2.c:82<br /> vfs_load_quota_inode+0x5d1/0x1530 fs/quota/dquot.c:2368<br /> dquot_enable+0x28a/0x330 fs/quota/dquot.c:2490<br /> ext4_quota_enable fs/ext4/super.c:6137 [inline]<br /> ext4_enable_quotas+0x5d7/0x960 fs/ext4/super.c:6163<br /> ext4_fill_super+0xa7c9/0xdc00 fs/ext4/super.c:4754<br /> mount_bdev+0x2e9/0x3b0 fs/super.c:1158<br /> mount_fs+0x4b/0x1e4 fs/super.c:1261<br /> [...]<br /> ==================================================================<br /> <br /> Above issue may happen as follows:<br /> -------------------------------------<br /> ext4_fill_super<br /> ext4_enable_quotas<br /> ext4_quota_enable<br /> ext4_iget<br /> __ext4_iget<br /> ext4_ext_check_inode<br /> ext4_ext_check<br /> __ext4_ext_check<br /> ext4_valid_extent_entries<br /> Check for overlapping extents does&amp;#39;t take effect<br /> dquot_enable<br /> vfs_load_quota_inode<br /> v2_check_quota_file<br /> v2_read_header<br /> ext4_quota_read<br /> ext4_bread<br /> ext4_getblk<br /> ext4_map_blocks<br /> ext4_ext_map_blocks<br /> ext4_find_extent<br /> ext4_cache_extents<br /> ext4_es_cache_extent<br /> ext4_es_cache_extent<br /> __es_tree_search<br /> ext4_es_end<br /> BUG_ON(es-&gt;es_lblk + es-&gt;es_len es_lblk)<br /> <br /> The error ext4 extents is as follows:<br /> 0af3 0300 0400 0000 00000000 extent_header<br /> 00000000 0100 0000 12000000 extent1<br /> 00000000 0100 0000 18000000 extent2<br /> 02000000 0400 0000 14000000 extent3<br /> <br /> In the ext4_valid_extent_entries function,<br /> if prev is 0, no error is returned even if lblock

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Fix potential double free in create_var_ref()<br /> <br /> In create_var_ref(), init_var_ref() is called to initialize the fields<br /> of variable ref_field, which is allocated in the previous function call<br /> to create_hist_field(). Function init_var_ref() allocates the<br /> corresponding fields such as ref_field-&gt;system, but frees these fields<br /> when the function encounters an error. The caller later calls<br /> destroy_hist_field() to conduct error handling, which frees the fields<br /> and the variable itself. This results in double free of the fields which<br /> are already freed in the previous function.<br /> <br /> Fix this by storing NULL to the corresponding fields when they are freed<br /> in init_var_ref().

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.