Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath11k: add missing of_node_put() to avoid leak<br /> <br /> The node pointer is returned by of_find_node_by_type()<br /> or of_parse_phandle() with refcount incremented. Calling<br /> of_node_put() to aovid the refcount leak.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath11k: free peer for station when disconnect from AP for QCA6390/WCN6855<br /> <br /> Commit b4a0f54156ac ("ath11k: move peer delete after vdev stop of station<br /> for QCA6390 and WCN6855") is to fix firmware crash by changing the WMI<br /> command sequence, but actually skip all the peer delete operation, then<br /> it lead commit 58595c9874c6 ("ath11k: Fixing dangling pointer issue upon<br /> peer delete failure") not take effect, and then happened a use-after-free<br /> warning from KASAN. because the peer-&gt;sta is not set to NULL and then used<br /> later.<br /> <br /> Change to only skip the WMI_PEER_DELETE_CMDID for QCA6390/WCN6855.<br /> <br /> log of user-after-free:<br /> <br /> [ 534.888665] BUG: KASAN: use-after-free in ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k]<br /> [ 534.888696] Read of size 8 at addr ffff8881396bb1b8 by task rtcwake/2860<br /> <br /> [ 534.888705] CPU: 4 PID: 2860 Comm: rtcwake Kdump: loaded Tainted: G W 5.15.0-wt-ath+ #523<br /> [ 534.888712] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021<br /> [ 534.888716] Call Trace:<br /> [ 534.888720] <br /> [ 534.888726] dump_stack_lvl+0x57/0x7d<br /> [ 534.888736] print_address_description.constprop.0+0x1f/0x170<br /> [ 534.888745] ? ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k]<br /> [ 534.888771] kasan_report.cold+0x83/0xdf<br /> [ 534.888783] ? ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k]<br /> [ 534.888810] ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k]<br /> [ 534.888840] ath11k_dp_rx_process_mon_status+0x529/0xa70 [ath11k]<br /> [ 534.888874] ? ath11k_dp_rx_mon_status_bufs_replenish+0x3f0/0x3f0 [ath11k]<br /> [ 534.888897] ? check_prev_add+0x20f0/0x20f0<br /> [ 534.888922] ? __lock_acquire+0xb72/0x1870<br /> [ 534.888937] ? find_held_lock+0x33/0x110<br /> [ 534.888954] ath11k_dp_rx_process_mon_rings+0x297/0x520 [ath11k]<br /> [ 534.888981] ? rcu_read_unlock+0x40/0x40<br /> [ 534.888990] ? ath11k_dp_rx_pdev_alloc+0xd90/0xd90 [ath11k]<br /> [ 534.889026] ath11k_dp_service_mon_ring+0x67/0xe0 [ath11k]<br /> [ 534.889053] ? ath11k_dp_rx_process_mon_rings+0x520/0x520 [ath11k]<br /> [ 534.889075] call_timer_fn+0x167/0x4a0<br /> [ 534.889084] ? add_timer_on+0x3b0/0x3b0<br /> [ 534.889103] ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370<br /> [ 534.889117] __run_timers.part.0+0x539/0x8b0<br /> [ 534.889123] ? ath11k_dp_rx_process_mon_rings+0x520/0x520 [ath11k]<br /> [ 534.889157] ? call_timer_fn+0x4a0/0x4a0<br /> [ 534.889164] ? mark_lock_irq+0x1c30/0x1c30<br /> [ 534.889173] ? clockevents_program_event+0xdd/0x280<br /> [ 534.889189] ? mark_held_locks+0xa5/0xe0<br /> [ 534.889203] run_timer_softirq+0x97/0x180<br /> [ 534.889213] __do_softirq+0x276/0x86a<br /> [ 534.889230] __irq_exit_rcu+0x11c/0x180<br /> [ 534.889238] irq_exit_rcu+0x5/0x20<br /> [ 534.889244] sysvec_apic_timer_interrupt+0x8e/0xc0<br /> [ 534.889251] <br /> [ 534.889254] <br /> [ 534.889259] asm_sysvec_apic_timer_interrupt+0x12/0x20<br /> [ 534.889265] RIP: 0010:_raw_spin_unlock_irqrestore+0x38/0x70<br /> [ 534.889271] Code: 74 24 10 e8 ea c2 bf fd 48 89 ef e8 12 53 c0 fd 81 e3 00 02 00 00 75 25 9c 58 f6 c4 02 75 2d 48 85 db 74 01 fb bf 01 00 00 00 13 a7 b5 fd 65 8b 05 cc d9 9c 5e 85 c0 74 0a 5b 5d c3 e8 a0 ee<br /> [ 534.889276] RSP: 0018:ffffc90002e5f880 EFLAGS: 00000206<br /> [ 534.889284] RAX: 0000000000000006 RBX: 0000000000000200 RCX: ffffffff9f256f10<br /> [ 534.889289] RDX: 0000000000000000 RSI: ffffffffa1c6e420 RDI: 0000000000000001<br /> [ 534.889293] RBP: ffff8881095e6200 R08: 0000000000000001 R09: ffffffffa40d2b8f<br /> [ 534.889298] R10: fffffbfff481a571 R11: 0000000000000001 R12: ffff8881095e6e68<br /> [ 534.889302] R13: ffffc90002e5f908 R14: 0000000000000246 R15: 0000000000000000<br /> [ 534.889316] ? mark_lock+0xd0/0x14a0<br /> [ 534.889332] klist_next+0x1d4/0x450<br /> [ 534.889340] ? dpm_wait_for_subordinate+0x2d0/0x2d0<br /> [ 534.889350] device_for_each_child+0xa8/0x140<br /> [ 534.889360] ? device_remove_class_symlinks+0x1b0/0x1b0<br /> [ 534.889370] ? __lock_release+0x4bd/0x9f0<br /> [ 534.889378] ? dpm_suspend+0x26b/0x3f0<br /> [ 534.889390] dpm_wait_for_subordinate+<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: codecs: wcd934x: Add missing of_node_put() in wcd934x_codec_parse_data<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 /> This is similar to commit 64b92de9603f<br /> ("ASoC: wcd9335: fix a leaked reference by adding missing of_node_put")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: mt8195: Fix error handling in mt8195_mt6359_rt1019_rt5682_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 path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dax: make sure inodes are flushed before destroy cache<br /> <br /> A bug can be triggered by following command<br /> <br /> $ modprobe nd_pmem &amp;&amp; modprobe -r nd_pmem<br /> <br /> [ 10.060014] BUG dax_cache (Not tainted): Objects remaining in dax_cache on __kmem_cache_shutdown()<br /> [ 10.060938] Slab 0x0000000085b729ac objects=9 used=1 fp=0x000000004f5ae469 flags=0x200000000010200(slab|head|node)<br /> [ 10.062433] Call Trace:<br /> [ 10.062673] dump_stack_lvl+0x34/0x44<br /> [ 10.062865] slab_err+0x90/0xd0<br /> [ 10.063619] __kmem_cache_shutdown+0x13b/0x2f0<br /> [ 10.063848] kmem_cache_destroy+0x4a/0x110<br /> [ 10.064058] __x64_sys_delete_module+0x265/0x300<br /> <br /> This is caused by dax_fs_exit() not flushing inodes before destroy cache.<br /> To fix this issue, call rcu_barrier() before destroy cache.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dp: populate connector of struct dp_panel<br /> <br /> DP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose<br /> and expect DP source return correct checksum. During drm edid read,<br /> correct edid checksum is calculated and stored at<br /> connector::real_edid_checksum.<br /> <br /> The problem is struct dp_panel::connector never be assigned, instead the<br /> connector is stored in struct msm_dp::connector. When we run compliance<br /> testing test case 4.2.2.6 dp_panel_handle_sink_request() won&amp;#39;t have a valid<br /> edid set in struct dp_panel::edid so we&amp;#39;ll try to use the connectors<br /> real_edid_checksum and hit a NULL pointer dereference error because the<br /> connector pointer is never assigned.<br /> <br /> Changes in V2:<br /> -- populate panel connector at msm_dp_modeset_init() instead of at dp_panel_read_sink_caps()<br /> <br /> Changes in V3:<br /> -- remove unhelpful kernel crash trace commit text<br /> -- remove renaming dp_display parameter to dp<br /> <br /> Changes in V4:<br /> -- add more details to commit text<br /> <br /> Changes in v10:<br /> -- group into one series<br /> <br /> Changes in v11:<br /> -- drop drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read<br /> <br /> Signee-off-by: Kuogee Hsieh