Vulnerabilities

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/bridge: anx7625: Fix overflow issue on reading EDID<br /> <br /> The length of EDID block can be longer than 256 bytes, so we should use<br /> `int` instead of `u8` for the `edid_pos` variable.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/port: Hold port reference until decoder release<br /> <br /> KASAN + DEBUG_KOBJECT_RELEASE reports a potential use-after-free in<br /> cxl_decoder_release() where it goes to reference its parent, a cxl_port,<br /> to free its id back to port-&gt;decoder_ida.<br /> <br /> BUG: KASAN: use-after-free in to_cxl_port+0x18/0x90 [cxl_core]<br /> Read of size 8 at addr ffff888119270908 by task kworker/35:2/379<br /> <br /> CPU: 35 PID: 379 Comm: kworker/35:2 Tainted: G OE 5.17.0-rc2+ #198<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015<br /> Workqueue: events kobject_delayed_cleanup<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x59/0x73<br /> print_address_description.constprop.0+0x1f/0x150<br /> ? to_cxl_port+0x18/0x90 [cxl_core]<br /> kasan_report.cold+0x83/0xdf<br /> ? to_cxl_port+0x18/0x90 [cxl_core]<br /> to_cxl_port+0x18/0x90 [cxl_core]<br /> cxl_decoder_release+0x2a/0x60 [cxl_core]<br /> device_release+0x5f/0x100<br /> kobject_cleanup+0x80/0x1c0<br /> <br /> The device core only guarantees parent lifetime until all children are<br /> unregistered. If a child needs a parent to complete its -&gt;release()<br /> callback that child needs to hold a reference to extend the lifetime of<br /> the parent.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: ab8500: Fix memory leak in ab8500_fg_sysfs_init<br /> <br /> kobject_init_and_add() takes reference even when it fails.<br /> According to the doc of kobject_init_and_add()：<br /> <br /> If this function returns an error, kobject_put() must be called to<br /> properly clean up the memory associated with the object.<br /> <br /> Fix memory leak by calling kobject_put().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7921s: fix a possible memory leak in mt7921_load_patch<br /> <br /> Always release fw data at the end of mt7921_load_patch routine.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: asix: add proper error handling of usb read errors<br /> <br /> Syzbot once again hit uninit value in asix driver. The problem still the<br /> same -- asix_read_cmd() reads less bytes, than was requested by caller.<br /> <br /> Since all read requests are performed via asix_read_cmd() let&amp;#39;s catch<br /> usb related error there and add __must_check notation to be sure all<br /> callers actually check return value.<br /> <br /> So, this patch adds sanity check inside asix_read_cmd(), that simply<br /> checks if bytes read are not less, than was requested and adds missing<br /> error handling of asix_read_cmd() all across the driver code.