Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: OMAP2+: display: Fix refcount leak bug<br /> <br /> In omapdss_init_fbdev(), of_find_node_by_name() will return a node<br /> pointer with refcount incremented. We should use of_node_put() when<br /> it is not used anymore.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: OMAP2+: pdata-quirks: Fix refcount leak bug<br /> <br /> In pdata_quirks_init_clocks(), the loop contains<br /> of_find_node_by_name() but without corresponding of_node_put().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext2: Add more validity checks for inode counts<br /> <br /> Add checks verifying number of inodes stored in the superblock matches<br /> the number computed from number of inodes per group. Also verify we have<br /> at least one block worth of inodes per group. This prevents crashes on<br /> corrupted filesystems.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: fix oops in concurrently setting insn_emulation sysctls<br /> <br /> emulation_proc_handler() changes table-&gt;data for proc_dointvec_minmax<br /> and can generate the following Oops if called concurrently with itself:<br /> <br /> | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010<br /> | Internal error: Oops: 96000006 [#1] SMP<br /> | Call trace:<br /> | update_insn_emulation_mode+0xc0/0x148<br /> | emulation_proc_handler+0x64/0xb8<br /> | proc_sys_call_handler+0x9c/0xf8<br /> | proc_sys_write+0x18/0x20<br /> | __vfs_write+0x20/0x48<br /> | vfs_write+0xe4/0x1d0<br /> | ksys_write+0x70/0xf8<br /> | __arm64_sys_write+0x20/0x28<br /> | el0_svc_common.constprop.0+0x7c/0x1c0<br /> | el0_svc_handler+0x2c/0xa0<br /> | el0_svc+0x8/0x200<br /> <br /> To fix this issue, keep the table-&gt;data as &amp;insn-&gt;current_mode and<br /> use container_of() to retrieve the insn pointer. Another mutex is<br /> used to protect against the current_mode update but not for retrieving<br /> insn_emulation as table-&gt;data is no longer changing.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: bcm: Fix refcount leak in bcm_kona_smc_init<br /> <br /> of_find_matching_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: amlogic: Fix refcount leak in meson-secure-pwrc.c<br /> <br /> In meson_secure_pwrc_probe(), there is a refcount leak in one fail<br /> path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> meson-mx-socinfo: Fix refcount leak in meson_mx_socinfo_init<br /> <br /> of_find_matching_node() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK<br /> <br /> When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,<br /> cpu_max_bits_warn() generates a runtime warning similar as below while<br /> we show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)<br /> instead of NR_CPUS to iterate CPUs.<br /> <br /> [ 3.052463] ------------[ cut here ]------------<br /> [ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0<br /> [ 3.070072] Modules linked in: efivarfs autofs4<br /> [ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052<br /> [ 3.084034] Hardware name: Loongson Loongson-3A4000-7A1000-1w-V0.1-CRB/Loongson-LS3A4000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27<br /> [ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000<br /> [ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430<br /> [ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff<br /> [ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890<br /> [ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa<br /> [ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000<br /> [ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000<br /> [ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000<br /> [ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286<br /> [ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c<br /> [ 3.195868] ...<br /> [ 3.199917] Call Trace:<br /> [ 3.203941] [] show_stack+0x38/0x14c<br /> [ 3.210666] [] dump_stack_lvl+0x60/0x88<br /> [ 3.217625] [] __warn+0xd0/0x100<br /> [ 3.223958] [] warn_slowpath_fmt+0x7c/0xcc<br /> [ 3.231150] [] show_cpuinfo+0x5e8/0x5f0<br /> [ 3.238080] [] seq_read_iter+0x354/0x4b4<br /> [ 3.245098] [] new_sync_read+0x17c/0x1c4<br /> [ 3.252114] [] vfs_read+0x138/0x1d0<br /> [ 3.258694] [] ksys_read+0x70/0x100<br /> [ 3.265265] [] do_syscall+0x7c/0x94<br /> [ 3.271820] [] handle_syscall+0xc4/0x160<br /> [ 3.281824] ---[ end trace 8b484262b4b8c24c ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md-raid10: fix KASAN warning<br /> <br /> There&amp;#39;s a KASAN warning in raid10_remove_disk when running the lvm<br /> test lvconvert-raid-reshape.sh. We fix this warning by verifying that the<br /> value "number" is valid.<br /> <br /> BUG: KASAN: slab-out-of-bounds in raid10_remove_disk+0x61/0x2a0 [raid10]<br /> Read of size 8 at addr ffff889108f3d300 by task mdX_raid10/124682<br /> <br /> CPU: 3 PID: 124682 Comm: mdX_raid10 Not tainted 5.19.0-rc6 #1<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x34/0x44<br /> print_report.cold+0x45/0x57a<br /> ? __lock_text_start+0x18/0x18<br /> ? raid10_remove_disk+0x61/0x2a0 [raid10]<br /> kasan_report+0xa8/0xe0<br /> ? raid10_remove_disk+0x61/0x2a0 [raid10]<br /> raid10_remove_disk+0x61/0x2a0 [raid10]<br /> Buffer I/O error on dev dm-76, logical block 15344, async page read<br /> ? __mutex_unlock_slowpath.constprop.0+0x1e0/0x1e0<br /> remove_and_add_spares+0x367/0x8a0 [md_mod]<br /> ? super_written+0x1c0/0x1c0 [md_mod]<br /> ? mutex_trylock+0xac/0x120<br /> ? _raw_spin_lock+0x72/0xc0<br /> ? _raw_spin_lock_bh+0xc0/0xc0<br /> md_check_recovery+0x848/0x960 [md_mod]<br /> raid10d+0xcf/0x3360 [raid10]<br /> ? sched_clock_cpu+0x185/0x1a0<br /> ? rb_erase+0x4d4/0x620<br /> ? var_wake_function+0xe0/0xe0<br /> ? psi_group_change+0x411/0x500<br /> ? preempt_count_sub+0xf/0xc0<br /> ? _raw_spin_lock_irqsave+0x78/0xc0<br /> ? __lock_text_start+0x18/0x18<br /> ? raid10_sync_request+0x36c0/0x36c0 [raid10]<br /> ? preempt_count_sub+0xf/0xc0<br /> ? _raw_spin_unlock_irqrestore+0x19/0x40<br /> ? del_timer_sync+0xa9/0x100<br /> ? try_to_del_timer_sync+0xc0/0xc0<br /> ? _raw_spin_lock_irqsave+0x78/0xc0<br /> ? __lock_text_start+0x18/0x18<br /> ? _raw_spin_unlock_irq+0x11/0x24<br /> ? __list_del_entry_valid+0x68/0xa0<br /> ? finish_wait+0xa3/0x100<br /> md_thread+0x161/0x260 [md_mod]<br /> ? unregister_md_personality+0xa0/0xa0 [md_mod]<br /> ? _raw_spin_lock_irqsave+0x78/0xc0<br /> ? prepare_to_wait_event+0x2c0/0x2c0<br /> ? unregister_md_personality+0xa0/0xa0 [md_mod]<br /> kthread+0x148/0x180<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x1f/0x30<br /> <br /> <br /> Allocated by task 124495:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_kmalloc+0x80/0xa0<br /> setup_conf+0x140/0x5c0 [raid10]<br /> raid10_run+0x4cd/0x740 [raid10]<br /> md_run+0x6f9/0x1300 [md_mod]<br /> raid_ctr+0x2531/0x4ac0 [dm_raid]<br /> dm_table_add_target+0x2b0/0x620 [dm_mod]<br /> table_load+0x1c8/0x400 [dm_mod]<br /> ctl_ioctl+0x29e/0x560 [dm_mod]<br /> dm_compat_ctl_ioctl+0x7/0x20 [dm_mod]<br /> __do_compat_sys_ioctl+0xfa/0x160<br /> do_syscall_64+0x90/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_record_aux_stack+0x9e/0xc0<br /> kvfree_call_rcu+0x84/0x480<br /> timerfd_release+0x82/0x140<br /> L __fput+0xfa/0x400<br /> task_work_run+0x80/0xc0<br /> exit_to_user_mode_prepare+0x155/0x160<br /> syscall_exit_to_user_mode+0x12/0x40<br /> do_syscall_64+0x42/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> Second to last potentially related work creation:<br /> kasan_save_stack+0x1e/0x40<br /> __kasan_record_aux_stack+0x9e/0xc0<br /> kvfree_call_rcu+0x84/0x480<br /> timerfd_release+0x82/0x140<br /> __fput+0xfa/0x400<br /> task_work_run+0x80/0xc0<br /> exit_to_user_mode_prepare+0x155/0x160<br /> syscall_exit_to_user_mode+0x12/0x40<br /> do_syscall_64+0x42/0xc0<br /> entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> The buggy address belongs to the object at ffff889108f3d200<br /> which belongs to the cache kmalloc-256 of size 256<br /> The buggy address is located 0 bytes to the right of<br /> 256-byte region [ffff889108f3d200, ffff889108f3d300)<br /> <br /> The buggy address belongs to the physical page:<br /> page:000000007ef2a34c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1108f3c<br /> head:000000007ef2a34c order:2 compound_mapcount:0 compound_pincount:0<br /> flags: 0x4000000000010200(slab|head|zone=2)<br /> raw: 4000000000010200 0000000000000000 dead000000000001 ffff889100042b40<br /> raw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000<br /> page dumped because: kasan: bad access detected<br /> <br /> Memory state around the buggy address:<br /> ffff889108f3d200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00<br /> ffff889108f3d280: 00 00<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: aoss: Fix refcount leak in qmp_cooling_devices_register<br /> <br /> Every iteration of for_each_available_child_of_node() decrements<br /> the reference count of the previous node.<br /> When breaking early from a for_each_available_child_of_node() loop,<br /> we need to explicitly call of_node_put() on the child node.<br /> Add missing of_node_put() to avoid refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: dts: qcom: replace gcc PXO with pxo_board fixed clock<br /> <br /> Replace gcc PXO phandle to pxo_board fixed clock declared in the dts.<br /> gcc driver doesn&amp;#39;t provide PXO_SRC as it&amp;#39;s a fixed-clock. This cause a<br /> kernel panic if any driver actually try to use it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: ocmem: Fix refcount leak in of_get_ocmem<br /> <br /> of_parse_phandle() returns a node pointer with refcount<br /> incremented, we should use of_node_put() on it when not need anymore.<br /> Add missing of_node_put() to avoid refcount leak.<br /> of_node_put() will check NULL pointer.