Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: ccree - Fix use after free in cc_cipher_exit()<br /> <br /> kfree_sensitive(ctx_p-&gt;user.key) will free the ctx_p-&gt;user.key. But<br /> ctx_p-&gt;user.key is still used in the next line, which will lead to a<br /> use after free.<br /> <br /> We can call kfree_sensitive() after dev_dbg() to avoid the uaf.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: don&amp;#39;t delete queue kobject before its children<br /> <br /> kobjects aren&amp;#39;t supposed to be deleted before their child kobjects are<br /> deleted. Apparently this is usually benign; however, a WARN will be<br /> triggered if one of the child kobjects has a named attribute group:<br /> <br /> sysfs group &amp;#39;modes&amp;#39; not found for kobject &amp;#39;crypto&amp;#39;<br /> WARNING: CPU: 0 PID: 1 at fs/sysfs/group.c:278 sysfs_remove_group+0x72/0x80<br /> ...<br /> Call Trace:<br /> sysfs_remove_groups+0x29/0x40 fs/sysfs/group.c:312<br /> __kobject_del+0x20/0x80 lib/kobject.c:611<br /> kobject_cleanup+0xa4/0x140 lib/kobject.c:696<br /> kobject_release lib/kobject.c:736 [inline]<br /> kref_put include/linux/kref.h:65 [inline]<br /> kobject_put+0x53/0x70 lib/kobject.c:753<br /> blk_crypto_sysfs_unregister+0x10/0x20 block/blk-crypto-sysfs.c:159<br /> blk_unregister_queue+0xb0/0x110 block/blk-sysfs.c:962<br /> del_gendisk+0x117/0x250 block/genhd.c:610<br /> <br /> Fix this by moving the kobject_del() and the corresponding<br /> kobject_uevent() to the correct place.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: hisilicon/sec - fix the aead software fallback for engine<br /> <br /> Due to the subreq pointer misuse the private context memory. The aead<br /> soft crypto occasionally casues the OS panic as setting the 64K page.<br /> Here is fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: atmel: Fix error handling in sam9x5_wm8731_driver_probe<br /> <br /> The device_node pointer is returned by of_parse_phandle() with refcount<br /> incremented. We should use of_node_put() on it when done.<br /> <br /> This function only calls of_node_put() in the regular path.<br /> And it will cause refcount leak in error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mxs: Fix error handling in mxs_sgtl5000_probe<br /> <br /> This function only calls of_node_put() in the regular path.<br /> And it will cause refcount leak in error paths.<br /> For example, when codec_np is NULL, saif_np[0] and saif_np[1]<br /> are not NULL, it will cause leaks.<br /> <br /> of_node_put() will check if the node pointer is NULL, so we can<br /> call it directly to release the refcount of regular pointers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: atmel: Add missing of_node_put() in at91sam9g20ek_audio_probe<br /> <br /> This node pointer is returned by of_parse_phandle() with refcount<br /> incremented in this function.<br /> Calling of_node_put() to avoid the refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: mt8192-mt6359: Fix error handling in mt8192_mt6359_dev_probe<br /> <br /> The device_node pointer is returned by of_parse_phandle() with refcount<br /> incremented. We should use of_node_put() on it when done.<br /> <br /> This function only calls of_node_put() in the regular path.<br /> And it will cause refcount leak in error paths.<br /> Fix this by calling of_node_put() in error handling too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: rockchip: Fix PM usage reference of rockchip_i2s_tdm_resume<br /> <br /> pm_runtime_get_sync will increment pm usage counter<br /> even it failed. Forgetting to putting operation will<br /> result in reference leak here. We fix it by replacing<br /> it with pm_runtime_resume_and_get to keep usage counter<br /> balanced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: atmel: Fix error handling in snd_proto_probe<br /> <br /> The device_node pointer is returned by of_parse_phandle() with refcount<br /> incremented. We should use of_node_put() on it when done.<br /> <br /> This function only calls of_node_put() in the regular path.<br /> And it will cause refcount leak in error paths.<br /> Fix this by calling of_node_put() in error handling too.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: stk1160: If start stream fails, return buffers with VB2_BUF_STATE_QUEUED<br /> <br /> If the callback &amp;#39;start_streaming&amp;#39; fails, then all<br /> queued buffers in the driver should be returned with<br /> state &amp;#39;VB2_BUF_STATE_QUEUED&amp;#39;. Currently, they are<br /> returned with &amp;#39;VB2_BUF_STATE_ERROR&amp;#39; which is wrong.<br /> Fix this. This also fixes the warning:<br /> <br /> [ 65.583633] WARNING: CPU: 5 PID: 593 at drivers/media/common/videobuf2/videobuf2-core.c:1612 vb2_start_streaming+0xd4/0x160 [videobuf2_common]<br /> [ 65.585027] Modules linked in: snd_usb_audio snd_hwdep snd_usbmidi_lib snd_rawmidi snd_soc_hdmi_codec dw_hdmi_i2s_audio saa7115 stk1160 videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc crct10dif_ce panfrost snd_soc_simple_card snd_soc_audio_graph_card snd_soc_spdif_tx snd_soc_simple_card_utils gpu_sched phy_rockchip_pcie snd_soc_rockchip_i2s rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi cec drm_kms_helper drm rtc_rk808 rockchip_saradc industrialio_triggered_buffer kfifo_buf rockchip_thermal pcie_rockchip_host ip_tables x_tables ipv6<br /> [ 65.589383] CPU: 5 PID: 593 Comm: v4l2src0:src Tainted: G W 5.16.0-rc4-62408-g32447129cb30-dirty #14<br /> [ 65.590293] Hardware name: Radxa ROCK Pi 4B (DT)<br /> [ 65.590696] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 65.591304] pc : vb2_start_streaming+0xd4/0x160 [videobuf2_common]<br /> [ 65.591850] lr : vb2_start_streaming+0x6c/0x160 [videobuf2_common]<br /> [ 65.592395] sp : ffff800012bc3ad0<br /> [ 65.592685] x29: ffff800012bc3ad0 x28: 0000000000000000 x27: ffff800012bc3cd8<br /> [ 65.593312] x26: 0000000000000000 x25: ffff00000d8a7800 x24: 0000000040045612<br /> [ 65.593938] x23: ffff800011323000 x22: ffff800012bc3cd8 x21: ffff00000908a8b0<br /> [ 65.594562] x20: ffff00000908a8c8 x19: 00000000fffffff4 x18: ffffffffffffffff<br /> [ 65.595188] x17: 000000040044ffff x16: 00400034b5503510 x15: ffff800011323f78<br /> [ 65.595813] x14: ffff000013163886 x13: ffff000013163885 x12: 00000000000002ce<br /> [ 65.596439] x11: 0000000000000028 x10: 0000000000000001 x9 : 0000000000000228<br /> [ 65.597064] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff726c5e78<br /> [ 65.597690] x5 : ffff800012bc3990 x4 : 0000000000000000 x3 : ffff000009a34880<br /> [ 65.598315] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000007cd99f0<br /> [ 65.598940] Call trace:<br /> [ 65.599155] vb2_start_streaming+0xd4/0x160 [videobuf2_common]<br /> [ 65.599672] vb2_core_streamon+0x17c/0x1a8 [videobuf2_common]<br /> [ 65.600179] vb2_streamon+0x54/0x88 [videobuf2_v4l2]<br /> [ 65.600619] vb2_ioctl_streamon+0x54/0x60 [videobuf2_v4l2]<br /> [ 65.601103] v4l_streamon+0x3c/0x50 [videodev]<br /> [ 65.601521] __video_do_ioctl+0x1a4/0x428 [videodev]<br /> [ 65.601977] video_usercopy+0x320/0x828 [videodev]<br /> [ 65.602419] video_ioctl2+0x3c/0x58 [videodev]<br /> [ 65.602830] v4l2_ioctl+0x60/0x90 [videodev]<br /> [ 65.603227] __arm64_sys_ioctl+0xa8/0xe0<br /> [ 65.603576] invoke_syscall+0x54/0x118<br /> [ 65.603911] el0_svc_common.constprop.3+0x84/0x100<br /> [ 65.604332] do_el0_svc+0x34/0xa0<br /> [ 65.604625] el0_svc+0x1c/0x50<br /> [ 65.604897] el0t_64_sync_handler+0x88/0xb0<br /> [ 65.605264] el0t_64_sync+0x16c/0x170<br /> [ 65.605587] ---[ end trace 578e0ba07742170d ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: firewire-lib: fix uninitialized flag for AV/C deferred transaction<br /> <br /> AV/C deferred transaction was supported at a commit 00a7bb81c20f ("ALSA:<br /> firewire-lib: Add support for deferred transaction") while &amp;#39;deferrable&amp;#39;<br /> flag can be uninitialized for non-control/notify AV/C transactions.<br /> UBSAN reports it:<br /> <br /> kernel: ================================================================================<br /> kernel: UBSAN: invalid-load in /build/linux-aa0B4d/linux-5.15.0/sound/firewire/fcp.c:363:9<br /> kernel: load of value 158 is not a valid value for type &amp;#39;_Bool&amp;#39;<br /> kernel: CPU: 3 PID: 182227 Comm: irq/35-firewire Tainted: P OE 5.15.0-18-generic #18-Ubuntu<br /> kernel: Hardware name: Gigabyte Technology Co., Ltd. AX370-Gaming 5/AX370-Gaming 5, BIOS F42b 08/01/2019<br /> kernel: Call Trace:<br /> kernel: <br /> kernel: show_stack+0x52/0x58<br /> kernel: dump_stack_lvl+0x4a/0x5f<br /> kernel: dump_stack+0x10/0x12<br /> kernel: ubsan_epilogue+0x9/0x45<br /> kernel: __ubsan_handle_load_invalid_value.cold+0x44/0x49<br /> kernel: fcp_response.part.0.cold+0x1a/0x2b [snd_firewire_lib]<br /> kernel: fcp_response+0x28/0x30 [snd_firewire_lib]<br /> kernel: fw_core_handle_request+0x230/0x3d0 [firewire_core]<br /> kernel: handle_ar_packet+0x1d9/0x200 [firewire_ohci]<br /> kernel: ? handle_ar_packet+0x1d9/0x200 [firewire_ohci]<br /> kernel: ? transmit_complete_callback+0x9f/0x120 [firewire_core]<br /> kernel: ar_context_tasklet+0xa8/0x2e0 [firewire_ohci]<br /> kernel: tasklet_action_common.constprop.0+0xea/0xf0<br /> kernel: tasklet_action+0x22/0x30<br /> kernel: __do_softirq+0xd9/0x2e3<br /> kernel: ? irq_finalize_oneshot.part.0+0xf0/0xf0<br /> kernel: do_softirq+0x75/0xa0<br /> kernel: <br /> kernel: <br /> kernel: __local_bh_enable_ip+0x50/0x60<br /> kernel: irq_forced_thread_fn+0x7e/0x90<br /> kernel: irq_thread+0xba/0x190<br /> kernel: ? irq_thread_fn+0x60/0x60<br /> kernel: kthread+0x11e/0x140<br /> kernel: ? irq_thread_check_affinity+0xf0/0xf0<br /> kernel: ? set_kthread_struct+0x50/0x50<br /> kernel: ret_from_fork+0x22/0x30<br /> kernel: <br /> kernel: ================================================================================<br /> <br /> This commit fixes the bug. The bug has no disadvantage for the non-<br /> control/notify AV/C transactions since the flag has an effect for AV/C<br /> response with INTERIM (0x0f) status which is not used for the transactions<br /> in AV/C general specification.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codecs: wc938x: fix accessing array out of bounds for enum type<br /> <br /> Accessing enums using integer would result in array out of bounds access<br /> on platforms like aarch64 where sizeof(long) is 8 compared to enum size<br /> which is 4 bytes.<br /> <br /> Fix this by using enumerated items instead of integers.