Vulnerabilities

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.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codecs: rx-macro: fix accessing compander for aux<br /> <br /> AUX interpolator does not have compander, so check before accessing<br /> compander data for this.<br /> <br /> Without this checkan array of out bounds access will be made in<br /> comp_enabled[] array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7915: fix possible memory leak in mt7915_mcu_add_sta<br /> <br /> Free allocated skb in mt7915_mcu_add_sta routine in case of failures.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rtw88: fix memory overrun and memory leak during hw_scan<br /> <br /> Previously we allocated less memory than actual required, overwrite<br /> to the buffer causes the mm module to complaint and raise access<br /> violation faults. Along with potential memory leaks when returned<br /> early. Fix these by passing the correct size and proper deinit flow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix a NULL pointer dereference in amdgpu_dm_connector_add_common_modes()<br /> <br /> In amdgpu_dm_connector_add_common_modes(), amdgpu_dm_create_common_mode()<br /> is assigned to mode and is passed to drm_mode_probed_add() directly after<br /> that. drm_mode_probed_add() passes &amp;mode-&gt;head to list_add_tail(), and<br /> there is a dereference of it in list_add_tail() without recoveries, which<br /> could lead to NULL pointer dereference on failure of<br /> amdgpu_dm_create_common_mode().<br /> <br /> Fix this by adding a NULL check of mode.<br /> <br /> This bug was found by a static analyzer.<br /> <br /> Builds with &amp;#39;make allyesconfig&amp;#39; show no new warnings,<br /> and our static analyzer no longer warns about this code.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Call dc_stream_release for remove link enc assignment<br /> <br /> [Why]<br /> A porting error resulted in the stream assignment for the link<br /> being retained without being released - a memory leak.<br /> <br /> [How]<br /> Fix the porting error by adding back the dc_stream_release() intended<br /> as part of the original patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: dsa: Avoid cross-chip syncing of VLAN filtering<br /> <br /> Changes to VLAN filtering are not applicable to cross-chip<br /> notifications.<br /> <br /> On a system like this:<br /> <br /> .-----. .-----. .-----.<br /> | sw1 +---+ sw2 +---+ sw3 |<br /> &amp;#39;-1-2-&amp;#39; &amp;#39;-1-2-&amp;#39; &amp;#39;-1-2-&amp;#39;<br /> <br /> Before this change, upon sw1p1 leaving a bridge, a call to<br /> dsa_port_vlan_filtering would also be made to sw2p1 and sw3p1.<br /> <br /> In this scenario:<br /> <br /> .---------. .-----. .-----.<br /> | sw1 +---+ sw2 +---+ sw3 |<br /> &amp;#39;-1-2-3-4-&amp;#39; &amp;#39;-1-2-&amp;#39; &amp;#39;-1-2-&amp;#39;<br /> <br /> When sw1p4 would leave a bridge, dsa_port_vlan_filtering would be<br /> called for sw2 and sw3 with a non-existing port - leading to array<br /> out-of-bounds accesses and crashes on mv88e6xxx.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath9k_htc: fix uninit value bugs<br /> <br /> Syzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missing<br /> field initialization.<br /> <br /> In htc_connect_service() svc_meta_len and pad are not initialized. Based<br /> on code it looks like in current skb there is no service data, so simply<br /> initialize svc_meta_len to 0.<br /> <br /> htc_issue_send() does not initialize htc_frame_hdr::control array. Based<br /> on firmware code, it will initialize it by itself, so simply zero whole<br /> array to make KMSAN happy<br /> <br /> Fail logs:<br /> <br /> BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430<br /> usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430<br /> hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline]<br /> hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479<br /> htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline]<br /> htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275<br /> ...<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slab.h:524 [inline]<br /> slab_alloc_node mm/slub.c:3251 [inline]<br /> __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974<br /> kmalloc_reserve net/core/skbuff.c:354 [inline]<br /> __alloc_skb+0x545/0xf90 net/core/skbuff.c:426<br /> alloc_skb include/linux/skbuff.h:1126 [inline]<br /> htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258<br /> ...<br /> <br /> Bytes 4-7 of 18 are uninitialized<br /> Memory access of size 18 starts at ffff888027377e00<br /> <br /> BUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430<br /> usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430<br /> hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline]<br /> hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479<br /> htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline]<br /> htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275<br /> ...<br /> <br /> Uninit was created at:<br /> slab_post_alloc_hook mm/slab.h:524 [inline]<br /> slab_alloc_node mm/slub.c:3251 [inline]<br /> __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974<br /> kmalloc_reserve net/core/skbuff.c:354 [inline]<br /> __alloc_skb+0x545/0xf90 net/core/skbuff.c:426<br /> alloc_skb include/linux/skbuff.h:1126 [inline]<br /> htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258<br /> ...<br /> <br /> Bytes 16-17 of 18 are uninitialized<br /> Memory access of size 18 starts at ffff888027377e00

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: Fix UAF due to race between btf_try_get_module and load_module<br /> <br /> While working on code to populate kfunc BTF ID sets for module BTF from<br /> its initcall, I noticed that by the time the initcall is invoked, the<br /> module BTF can already be seen by userspace (and the BPF verifier). The<br /> existing btf_try_get_module calls try_module_get which only fails if<br /> mod-&gt;state == MODULE_STATE_GOING, i.e. it can increment module reference<br /> when module initcall is happening in parallel.<br /> <br /> Currently, BTF parsing happens from MODULE_STATE_COMING notifier<br /> callback. At this point, the module initcalls have not been invoked.<br /> The notifier callback parses and prepares the module BTF, allocates an<br /> ID, which publishes it to userspace, and then adds it to the btf_modules<br /> list allowing the kernel to invoke btf_try_get_module for the BTF.<br /> <br /> However, at this point, the module has not been fully initialized (i.e.<br /> its initcalls have not finished). The code in module.c can still fail<br /> and free the module, without caring for other users. However, nothing<br /> stops btf_try_get_module from succeeding between the state transition<br /> from MODULE_STATE_COMING to MODULE_STATE_LIVE.<br /> <br /> This leads to a use-after-free issue when BPF program loads<br /> successfully in the state transition, load_module&amp;#39;s do_init_module call<br /> fails and frees the module, and BPF program fd on close calls module_put<br /> for the freed module. Future patch has test case to verify we don&amp;#39;t<br /> regress in this area in future.<br /> <br /> There are multiple points after prepare_coming_module (in load_module)<br /> where failure can occur and module loading can return error. We<br /> illustrate and test for the race using the last point where it can<br /> practically occur (in module __init function).<br /> <br /> An illustration of the race:<br /> <br /> CPU 0 CPU 1<br /> load_module<br /> notifier_call(MODULE_STATE_COMING)<br /> btf_parse_module<br /> btf_alloc_id // Published to userspace<br /> list_add(&amp;btf_mod-&gt;list, btf_modules)<br /> mod-&gt;init(...)<br /> ... ^<br /> bpf_check |<br /> check_pseudo_btf_id |<br /> btf_try_get_module |<br /> returns true | ...<br /> ... | module __init in progress<br /> return prog_fd | ...<br /> ... V<br /> if (ret