Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ac97: fix possible memory leak in snd_ac97_dev_register()<br /> <br /> If device_register() fails in snd_ac97_dev_register(), it should<br /> call put_device() to give up reference, or the name allocated in<br /> dev_set_name() is leaked.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: imx_dsp_rproc: Add mutex protection for workqueue<br /> <br /> The workqueue may execute late even after remoteproc is stopped or<br /> stopping, some resources (rpmsg device and endpoint) have been<br /> released in rproc_stop_subdevices(), then rproc_vq_interrupt()<br /> accessing these resources will cause kennel dump.<br /> <br /> Call trace:<br /> virtqueue_add_split+0x1ac/0x560<br /> virtqueue_add_inbuf+0x4c/0x60<br /> rpmsg_recv_done+0x15c/0x294<br /> vring_interrupt+0x6c/0xa4<br /> rproc_vq_interrupt+0x30/0x50<br /> imx_dsp_rproc_vq_work+0x24/0x40 [imx_dsp_rproc]<br /> process_one_work+0x1d0/0x354<br /> worker_thread+0x13c/0x470<br /> kthread+0x154/0x160<br /> ret_from_fork+0x10/0x20<br /> <br /> Add mutex protection in imx_dsp_rproc_vq_work(), if the state is<br /> not running, then just skip calling rproc_vq_interrupt().<br /> <br /> Also the flush workqueue operation can&amp;#39;t be added in rproc stop<br /> for the same reason. The call sequence is<br /> <br /> rproc_shutdown<br /> -&gt; rproc_stop<br /> -&gt;rproc_stop_subdevices<br /> -&gt;rproc-&gt;ops-&gt;stop()<br /> -&gt;imx_dsp_rproc_stop<br /> -&gt;flush_work<br /> -&gt; rproc_vq_interrupt<br /> <br /> The resource needed by rproc_vq_interrupt has been released in<br /> rproc_stop_subdevices, so flush_work is not safe to be called in<br /> imx_dsp_rproc_stop.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: vub300: fix warning - do not call blocking ops when !TASK_RUNNING<br /> <br /> vub300_enable_sdio_irq() works with mutex and need TASK_RUNNING here.<br /> Ensure that we mark current as TASK_RUNNING for sleepable context.<br /> <br /> [ 77.554641] do not call blocking ops when !TASK_RUNNING; state=1 set at [] sdio_irq_thread+0x17d/0x5b0<br /> [ 77.554652] WARNING: CPU: 2 PID: 1983 at kernel/sched/core.c:9813 __might_sleep+0x116/0x160<br /> [ 77.554905] CPU: 2 PID: 1983 Comm: ksdioirqd/mmc1 Tainted: G OE 6.1.0-rc5 #1<br /> [ 77.554910] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, BIOS BECFL357.86A.0081.2020.0504.1834 05/04/2020<br /> [ 77.554912] RIP: 0010:__might_sleep+0x116/0x160<br /> [ 77.554920] RSP: 0018:ffff888107b7fdb8 EFLAGS: 00010282<br /> [ 77.554923] RAX: 0000000000000000 RBX: ffff888118c1b740 RCX: 0000000000000000<br /> [ 77.554926] RDX: 0000000000000001 RSI: 0000000000000004 RDI: ffffed1020f6ffa9<br /> [ 77.554928] RBP: ffff888107b7fde0 R08: 0000000000000001 R09: ffffed1043ea60ba<br /> [ 77.554930] R10: ffff88821f5305cb R11: ffffed1043ea60b9 R12: ffffffff93aa3a60<br /> [ 77.554932] R13: 000000000000011b R14: 7fffffffffffffff R15: ffffffffc0558660<br /> [ 77.554934] FS: 0000000000000000(0000) GS:ffff88821f500000(0000) knlGS:0000000000000000<br /> [ 77.554937] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 77.554939] CR2: 00007f8a44010d68 CR3: 000000024421a003 CR4: 00000000003706e0<br /> [ 77.554942] Call Trace:<br /> [ 77.554944] <br /> [ 77.554952] mutex_lock+0x78/0xf0<br /> [ 77.554973] vub300_enable_sdio_irq+0x103/0x3c0 [vub300]<br /> [ 77.554981] sdio_irq_thread+0x25c/0x5b0<br /> [ 77.555006] kthread+0x2b8/0x370<br /> [ 77.555017] ret_from_fork+0x1f/0x30<br /> [ 77.555023] <br /> [ 77.555025] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memory: of: Fix refcount leak bug in of_lpddr3_get_ddr_timings()<br /> <br /> We should add the of_node_put() when breaking out of<br /> for_each_child_of_node() as it will automatically increase<br /> and decrease the refcount.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: hisilicon/hpre - fix resource leak in remove process<br /> <br /> In hpre_remove(), when the disable operation of qm sriov failed,<br /> the following logic should continue to be executed to release the<br /> remaining resources that have been allocated, instead of returning<br /> directly, otherwise there will be resource leakage.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rpmsg: char: Avoid double destroy of default endpoint<br /> <br /> The rpmsg_dev_remove() in rpmsg_core is the place for releasing<br /> this default endpoint.<br /> <br /> So need to avoid destroying the default endpoint in<br /> rpmsg_chrdev_eptdev_destroy(), this should be the same as<br /> rpmsg_eptdev_release(). Otherwise there will be double destroy<br /> issue that ept-&gt;refcount report warning:<br /> <br /> refcount_t: underflow; use-after-free.<br /> <br /> Call trace:<br /> refcount_warn_saturate+0xf8/0x150<br /> virtio_rpmsg_destroy_ept+0xd4/0xec<br /> rpmsg_dev_remove+0x60/0x70<br /> <br /> The issue can be reproduced by stopping remoteproc before<br /> closing the /dev/rpmsgX.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: libsas: Fix use-after-free bug in smp_execute_task_sg()<br /> <br /> When executing SMP task failed, the smp_execute_task_sg() calls del_timer()<br /> to delete "slow_task-&gt;timer". However, if the timer handler<br /> sas_task_internal_timedout() is running, the del_timer() in<br /> smp_execute_task_sg() will not stop it and a UAF will happen. The process<br /> is shown below:<br /> <br /> (thread 1) | (thread 2)<br /> smp_execute_task_sg() | sas_task_internal_timedout()<br /> ... |<br /> del_timer() |<br /> ... | ...<br /> sas_free_task(task) |<br /> kfree(task-&gt;slow_task) //FREE|<br /> | task-&gt;slow_task-&gt;... //USE<br /> <br /> Fix by calling del_timer_sync() in smp_execute_task_sg(), which makes sure<br /> the timer handler have finished before the "task-&gt;slow_task" is<br /> deallocated.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage()<br /> <br /> There is an use-after-free reported by KASAN:<br /> <br /> BUG: KASAN: use-after-free in acpi_ut_remove_reference+0x3b/0x82<br /> Read of size 1 at addr ffff888112afc460 by task modprobe/2111<br /> CPU: 0 PID: 2111 Comm: modprobe Not tainted 6.1.0-rc7-dirty<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),<br /> Call Trace:<br /> <br /> kasan_report+0xae/0xe0<br /> acpi_ut_remove_reference+0x3b/0x82<br /> acpi_ut_copy_iobject_to_iobject+0x3be/0x3d5<br /> acpi_ds_store_object_to_local+0x15d/0x3a0<br /> acpi_ex_store+0x78d/0x7fd<br /> acpi_ex_opcode_1A_1T_1R+0xbe4/0xf9b<br /> acpi_ps_parse_aml+0x217/0x8d5<br /> ...<br /> <br /> <br /> The root cause of the problem is that the acpi_operand_object<br /> is freed when acpi_ut_walk_package_tree() fails in<br /> acpi_ut_copy_ipackage_to_ipackage(), lead to repeated release in<br /> acpi_ut_copy_iobject_to_iobject(). The problem was introduced<br /> by "8aa5e56eeb61" commit, this commit is to fix memory leak in<br /> acpi_ut_copy_iobject_to_iobject(), repeatedly adding remove<br /> operation, lead to "acpi_operand_object" used after free.<br /> <br /> Fix it by removing acpi_ut_remove_reference() in<br /> acpi_ut_copy_ipackage_to_ipackage(). acpi_ut_copy_ipackage_to_ipackage()<br /> is called to copy an internal package object into another internal<br /> package object, when it fails, the memory of acpi_operand_object<br /> should be freed by the caller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7921: resource leaks at mt7921_check_offload_capability()<br /> <br /> Fixed coverity issue with resource leaks at variable "fw" going out of<br /> scope leaks the storage it points to mt7921_check_offload_capability().<br /> <br /> Addresses-Coverity-ID: 1527806 ("Resource leaks")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/fpu: Fix copy_xstate_to_uabi() to copy init states correctly<br /> <br /> When an extended state component is not present in fpstate, but in init<br /> state, the function copies from init_fpstate via copy_feature().<br /> <br /> But, dynamic states are not present in init_fpstate because of all-zeros<br /> init states. Then retrieving them from init_fpstate will explode like this:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> ...<br /> RIP: 0010:memcpy_erms+0x6/0x10<br /> ? __copy_xstate_to_uabi_buf+0x381/0x870<br /> fpu_copy_guest_fpstate_to_uabi+0x28/0x80<br /> kvm_arch_vcpu_ioctl+0x14c/0x1460 [kvm]<br /> ? __this_cpu_preempt_check+0x13/0x20<br /> ? vmx_vcpu_put+0x2e/0x260 [kvm_intel]<br /> kvm_vcpu_ioctl+0xea/0x6b0 [kvm]<br /> ? kvm_vcpu_ioctl+0xea/0x6b0 [kvm]<br /> ? __fget_light+0xd4/0x130<br /> __x64_sys_ioctl+0xe3/0x910<br /> ? debug_smp_processor_id+0x17/0x20<br /> ? fpregs_assert_state_consistent+0x27/0x50<br /> do_syscall_64+0x3f/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> Adjust the &amp;#39;mask&amp;#39; to zero out the userspace buffer for the features that<br /> are not available both from fpstate and from init_fpstate.<br /> <br /> The dynamic features depend on the compacted XSAVE format. Ensure it is<br /> enabled before reading XCOMP_BV in init_fpstate.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix UBSAN shift-out-of-bounds warning<br /> <br /> If get_num_sdma_queues or get_num_xgmi_sdma_queues is 0, we end up<br /> doing a shift operation where the number of bits shifted equals<br /> number of bits in the operand. This behaviour is undefined.<br /> <br /> Set num_sdma_queues or num_xgmi_sdma_queues to ULLONG_MAX, if the<br /> count is &gt;= number of bits in the operand.<br /> <br /> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472

DX Unified Infrastructure Management (Nimsoft/UIM) and below contains an improper ACL handling vulnerability in the robot (controller) component. A remote attacker can execute commands, read from, or write to the target system.