Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: Fix missing of_node_put in mt2701_wm8960_machine_probe<br /> <br /> This node pointer is returned by of_parse_phandle() with<br /> refcount 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: SOF: ipc3-topology: Correct get_control_data for non bytes payload<br /> <br /> It is possible to craft a topology where sof_get_control_data() would do<br /> out of bounds access because it expects that it is only called when the<br /> payload is bytes type.<br /> Confusingly it also handles other types of controls, but the payload<br /> parsing implementation is only valid for bytes.<br /> <br /> Fix the code to count the non bytes controls and instead of storing a<br /> pointer to sof_abi_hdr in sof_widget_data (which is only valid for bytes),<br /> store the pointer to the data itself and add a new member to save the size<br /> of the data.<br /> <br /> In case of non bytes controls we store the pointer to the chanv itself,<br /> which is just an array of values at the end.<br /> <br /> In case of bytes control, drop the wrong cdata-&gt;data (wdata[i].pdata) check<br /> against NULL since it is incorrect and invalid in this context.<br /> The data is pointing to the end of cdata struct, so it should never be<br /> null.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath10k: skip ath10k_halt during suspend for driver state RESTARTING<br /> <br /> Double free crash is observed when FW recovery(caused by wmi<br /> timeout/crash) is followed by immediate suspend event. The FW recovery<br /> is triggered by ath10k_core_restart() which calls driver clean up via<br /> ath10k_halt(). When the suspend event occurs between the FW recovery,<br /> the restart worker thread is put into frozen state until suspend completes.<br /> The suspend event triggers ath10k_stop() which again triggers ath10k_halt()<br /> The double invocation of ath10k_halt() causes ath10k_htt_rx_free() to be<br /> called twice(Note: ath10k_htt_rx_alloc was not called by restart worker<br /> thread because of its frozen state), causing the crash.<br /> <br /> To fix this, during the suspend flow, skip call to ath10k_halt() in<br /> ath10k_stop() when the current driver state is ATH10K_STATE_RESTARTING.<br /> Also, for driver state ATH10K_STATE_RESTARTING, call<br /> ath10k_wait_for_suspend() in ath10k_stop(). This is because call to<br /> ath10k_wait_for_suspend() is skipped later in<br /> [ath10k_halt() &gt; ath10k_core_stop()] for the driver state<br /> ATH10K_STATE_RESTARTING.<br /> <br /> The frozen restart worker thread will be cancelled during resume when the<br /> device comes out of suspend.<br /> <br /> Below is the crash stack for reference:<br /> <br /> [ 428.469167] ------------[ cut here ]------------<br /> [ 428.469180] kernel BUG at mm/slub.c:4150!<br /> [ 428.469193] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI<br /> [ 428.469219] Workqueue: events_unbound async_run_entry_fn<br /> [ 428.469230] RIP: 0010:kfree+0x319/0x31b<br /> [ 428.469241] RSP: 0018:ffffa1fac015fc30 EFLAGS: 00010246<br /> [ 428.469247] RAX: ffffedb10419d108 RBX: ffff8c05262b0000<br /> [ 428.469252] RDX: ffff8c04a8c07000 RSI: 0000000000000000<br /> [ 428.469256] RBP: ffffa1fac015fc78 R08: 0000000000000000<br /> [ 428.469276] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 428.469285] Call Trace:<br /> [ 428.469295] ? dma_free_attrs+0x5f/0x7d<br /> [ 428.469320] ath10k_core_stop+0x5b/0x6f<br /> [ 428.469336] ath10k_halt+0x126/0x177<br /> [ 428.469352] ath10k_stop+0x41/0x7e<br /> [ 428.469387] drv_stop+0x88/0x10e<br /> [ 428.469410] __ieee80211_suspend+0x297/0x411<br /> [ 428.469441] rdev_suspend+0x6e/0xd0<br /> [ 428.469462] wiphy_suspend+0xb1/0x105<br /> [ 428.469483] ? name_show+0x2d/0x2d<br /> [ 428.469490] dpm_run_callback+0x8c/0x126<br /> [ 428.469511] ? name_show+0x2d/0x2d<br /> [ 428.469517] __device_suspend+0x2e7/0x41b<br /> [ 428.469523] async_suspend+0x1f/0x93<br /> [ 428.469529] async_run_entry_fn+0x3d/0xd1<br /> [ 428.469535] process_one_work+0x1b1/0x329<br /> [ 428.469541] worker_thread+0x213/0x372<br /> [ 428.469547] kthread+0x150/0x15f<br /> [ 428.469552] ? pr_cont_work+0x58/0x58<br /> [ 428.469558] ? kthread_blkcg+0x31/0x31<br /> <br /> Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: i2c: max9286: fix kernel oops when removing module<br /> <br /> When removing the max9286 module we get a kernel oops:<br /> <br /> Unable to handle kernel paging request at virtual address 000000aa00000094<br /> Mem abort info:<br /> ESR = 0x96000004<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x04: level 0 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000004<br /> CM = 0, WnR = 0<br /> user pgtable: 4k pages, 48-bit VAs, pgdp=0000000880d85000<br /> [000000aa00000094] pgd=0000000000000000, p4d=0000000000000000<br /> Internal error: Oops: 96000004 [#1] PREEMPT SMP<br /> Modules linked in: fsl_jr_uio caam_jr rng_core libdes caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine max9271 authenc crct10dif_ce mxc_jpeg_encdec<br /> CPU: 2 PID: 713 Comm: rmmod Tainted: G C 5.15.5-00057-gaebcd29c8ed7-dirty #5<br /> Hardware name: Freescale i.MX8QXP MEK (DT)<br /> pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : i2c_mux_del_adapters+0x24/0xf0<br /> lr : max9286_remove+0x28/0xd0 [max9286]<br /> sp : ffff800013a9bbf0<br /> x29: ffff800013a9bbf0 x28: ffff00080b6da940 x27: 0000000000000000<br /> x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000<br /> x23: ffff000801a5b970 x22: ffff0008048b0890 x21: ffff800009297000<br /> x20: ffff0008048b0f70 x19: 000000aa00000064 x18: 0000000000000000<br /> x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000<br /> x14: 0000000000000014 x13: 0000000000000000 x12: ffff000802da49e8<br /> x11: ffff000802051918 x10: ffff000802da4920 x9 : ffff000800030098<br /> x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d<br /> x5 : 8080808000000000 x4 : 0000000000000000 x3 : 0000000000000000<br /> x2 : ffffffffffffffff x1 : ffff00080b6da940 x0 : 0000000000000000<br /> Call trace:<br /> i2c_mux_del_adapters+0x24/0xf0<br /> max9286_remove+0x28/0xd0 [max9286]<br /> i2c_device_remove+0x40/0x110<br /> __device_release_driver+0x188/0x234<br /> driver_detach+0xc4/0x150<br /> bus_remove_driver+0x60/0xe0<br /> driver_unregister+0x34/0x64<br /> i2c_del_driver+0x58/0xa0<br /> max9286_i2c_driver_exit+0x1c/0x490 [max9286]<br /> __arm64_sys_delete_module+0x194/0x260<br /> invoke_syscall+0x48/0x114<br /> el0_svc_common.constprop.0+0xd4/0xfc<br /> do_el0_svc+0x2c/0x94<br /> el0_svc+0x28/0x80<br /> el0t_64_sync_handler+0xa8/0x130<br /> el0t_64_sync+0x1a0/0x1a4<br /> <br /> The Oops happens because the I2C client data does not point to<br /> max9286_priv anymore but to v4l2_subdev. The change happened in<br /> max9286_init() which calls v4l2_i2c_subdev_init() later on...<br /> <br /> Besides fixing the max9286_remove() function, remove the call to<br /> i2c_set_clientdata() in max9286_probe(), to avoid confusion, and make<br /> the necessary changes to max9286_init() so that it doesn&amp;#39;t have to use<br /> i2c_get_clientdata() in order to fetch the pointer to priv.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm: Fix null pointer dereferences without iommu<br /> <br /> Check if &amp;#39;aspace&amp;#39; is set before using it as it will stay null without<br /> IOMMU, such as on msm8974.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wl1251: dynamically allocate memory used for DMA<br /> <br /> With introduction of vmap&amp;#39;ed stacks, stack parameters can no<br /> longer be used for DMA and now leads to kernel panic.<br /> <br /> It happens at several places for the wl1251 (e.g. when<br /> accessed through SDIO) making it unuseable on e.g. the<br /> OpenPandora.<br /> <br /> We solve this by allocating temporary buffers or use wl1251_read32().<br /> <br /> Tested on v5.18-rc5 with OpenPandora.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: Run unregister_netdev() before unbind() again<br /> <br /> Commit 2c9d6c2b871d ("usbnet: run unbind() before unregister_netdev()")<br /> sought to fix a use-after-free on disconnect of USB Ethernet adapters.<br /> <br /> It turns out that a different fix is necessary to address the issue:<br /> https://lore.kernel.org/netdev/18b3541e5372bc9b9fc733d422f4e698c089077c.1650177997.git.lukas@wunner.de/<br /> <br /> So the commit was not necessary.<br /> <br /> The commit made binding and unbinding of USB Ethernet asymmetrical:<br /> Before, usbnet_probe() first invoked the -&gt;bind() callback and then<br /> register_netdev(). usbnet_disconnect() mirrored that by first invoking<br /> unregister_netdev() and then -&gt;unbind().<br /> <br /> Since the commit, the order in usbnet_disconnect() is reversed and no<br /> longer mirrors usbnet_probe().<br /> <br /> One consequence is that a PHY disconnected (and stopped) in -&gt;unbind()<br /> is afterwards stopped once more by unregister_netdev() as it closes the<br /> netdev before unregistering. That necessitates a contortion in -&gt;stop()<br /> because the PHY may only be stopped if it hasn&amp;#39;t already been<br /> disconnected.<br /> <br /> Reverting the commit allows making the call to phy_stop() unconditional<br /> in -&gt;stop().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: rga: fix possible memory leak in rga_probe<br /> <br /> rga-&gt;m2m_dev needs to be freed when rga_probe fails.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ath9k_htc: fix potential out of bounds access with invalid rxstatus-&gt;rs_keyix<br /> <br /> The "rxstatus-&gt;rs_keyix" eventually gets passed to test_bit() so we need to<br /> ensure that it is within the bitmap.<br /> <br /> drivers/net/wireless/ath/ath9k/common.c:46 ath9k_cmn_rx_accept()<br /> error: passing untrusted data &amp;#39;rx_stats-&gt;rs_keyix&amp;#39; to &amp;#39;test_bit()&amp;#39;

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: lpfc: Inhibit aborts if external loopback plug is inserted<br /> <br /> After running a short external loopback test, when the external loopback is<br /> removed and a normal cable inserted that is directly connected to a target<br /> device, the system oops in the llpfc_set_rrq_active() routine.<br /> <br /> When the loopback was inserted an FLOGI was transmit. As we&amp;#39;re looped back,<br /> we receive the FLOGI request. The FLOGI is ABTS&amp;#39;d as we recognize the same<br /> wppn thus understand it&amp;#39;s a loopback. However, as the ABTS sends address<br /> information the port is not set to (fffffe), the ABTS is dropped on the<br /> wire. A short 1 frame loopback test is run and completes before the ABTS<br /> times out. The looback is unplugged and the new cable plugged in, and the<br /> an FLOGI to the new device occurs and completes. Due to a mixup in ref<br /> counting the completion of the new FLOGI releases the fabric ndlp. Then the<br /> original ABTS completes and references the released ndlp generating the<br /> oops.<br /> <br /> Correct by no-op&amp;#39;ing the ABTS when in loopback mode (it will be dropped<br /> anyway). Added a flag to track the mode to recognize when it should be<br /> no-op&amp;#39;d.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFC: NULL out the dev-&gt;rfkill to prevent UAF<br /> <br /> Commit 3e3b5dfcd16a ("NFC: reorder the logic in nfc_{un,}register_device")<br /> assumes the device_is_registered() in function nfc_dev_up() will help<br /> to check when the rfkill is unregistered. However, this check only<br /> take effect when device_del(&amp;dev-&gt;dev) is done in nfc_unregister_device().<br /> Hence, the rfkill object is still possible be dereferenced.<br /> <br /> The crash trace in latest kernel (5.18-rc2):<br /> <br /> [ 68.760105] ==================================================================<br /> [ 68.760330] BUG: KASAN: use-after-free in __lock_acquire+0x3ec1/0x6750<br /> [ 68.760756] Read of size 8 at addr ffff888009c93018 by task fuzz/313<br /> [ 68.760756]<br /> [ 68.760756] CPU: 0 PID: 313 Comm: fuzz Not tainted 5.18.0-rc2 #4<br /> [ 68.760756] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [ 68.760756] Call Trace:<br /> [ 68.760756] <br /> [ 68.760756] dump_stack_lvl+0x57/0x7d<br /> [ 68.760756] print_report.cold+0x5e/0x5db<br /> [ 68.760756] ? __lock_acquire+0x3ec1/0x6750<br /> [ 68.760756] kasan_report+0xbe/0x1c0<br /> [ 68.760756] ? __lock_acquire+0x3ec1/0x6750<br /> [ 68.760756] __lock_acquire+0x3ec1/0x6750<br /> [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410<br /> [ 68.760756] ? register_lock_class+0x18d0/0x18d0<br /> [ 68.760756] lock_acquire+0x1ac/0x4f0<br /> [ 68.760756] ? rfkill_blocked+0xe/0x60<br /> [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410<br /> [ 68.760756] ? mutex_lock_io_nested+0x12c0/0x12c0<br /> [ 68.760756] ? nla_get_range_signed+0x540/0x540<br /> [ 68.760756] ? _raw_spin_lock_irqsave+0x4e/0x50<br /> [ 68.760756] _raw_spin_lock_irqsave+0x39/0x50<br /> [ 68.760756] ? rfkill_blocked+0xe/0x60<br /> [ 68.760756] rfkill_blocked+0xe/0x60<br /> [ 68.760756] nfc_dev_up+0x84/0x260<br /> [ 68.760756] nfc_genl_dev_up+0x90/0xe0<br /> [ 68.760756] genl_family_rcv_msg_doit+0x1f4/0x2f0<br /> [ 68.760756] ? genl_family_rcv_msg_attrs_parse.constprop.0+0x230/0x230<br /> [ 68.760756] ? security_capable+0x51/0x90<br /> [ 68.760756] genl_rcv_msg+0x280/0x500<br /> [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0<br /> [ 68.760756] ? lock_acquire+0x1ac/0x4f0<br /> [ 68.760756] ? nfc_genl_dev_down+0xe0/0xe0<br /> [ 68.760756] ? lockdep_hardirqs_on_prepare+0x410/0x410<br /> [ 68.760756] netlink_rcv_skb+0x11b/0x340<br /> [ 68.760756] ? genl_get_cmd+0x3c0/0x3c0<br /> [ 68.760756] ? netlink_ack+0x9c0/0x9c0<br /> [ 68.760756] ? netlink_deliver_tap+0x136/0xb00<br /> [ 68.760756] genl_rcv+0x1f/0x30<br /> [ 68.760756] netlink_unicast+0x430/0x710<br /> [ 68.760756] ? memset+0x20/0x40<br /> [ 68.760756] ? netlink_attachskb+0x740/0x740<br /> [ 68.760756] ? __build_skb_around+0x1f4/0x2a0<br /> [ 68.760756] netlink_sendmsg+0x75d/0xc00<br /> [ 68.760756] ? netlink_unicast+0x710/0x710<br /> [ 68.760756] ? netlink_unicast+0x710/0x710<br /> [ 68.760756] sock_sendmsg+0xdf/0x110<br /> [ 68.760756] __sys_sendto+0x19e/0x270<br /> [ 68.760756] ? __ia32_sys_getpeername+0xa0/0xa0<br /> [ 68.760756] ? fd_install+0x178/0x4c0<br /> [ 68.760756] ? fd_install+0x195/0x4c0<br /> [ 68.760756] ? kernel_fpu_begin_mask+0x1c0/0x1c0<br /> [ 68.760756] __x64_sys_sendto+0xd8/0x1b0<br /> [ 68.760756] ? lockdep_hardirqs_on+0xbf/0x130<br /> [ 68.760756] ? syscall_enter_from_user_mode+0x1d/0x50<br /> [ 68.760756] do_syscall_64+0x3b/0x90<br /> [ 68.760756] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [ 68.760756] RIP: 0033:0x7f67fb50e6b3<br /> ...<br /> [ 68.760756] RSP: 002b:00007f67fa91fe90 EFLAGS: 00000293 ORIG_RAX: 000000000000002c<br /> [ 68.760756] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f67fb50e6b3<br /> [ 68.760756] RDX: 000000000000001c RSI: 0000559354603090 RDI: 0000000000000003<br /> [ 68.760756] RBP: 00007f67fa91ff00 R08: 00007f67fa91fedc R09: 000000000000000c<br /> [ 68.760756] R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe824d496e<br /> [ 68.760756] R13: 00007ffe824d496f R14: 00007f67fa120000 R15: 0000000000000003<br /> <br /> [ 68.760756] <br /> [ 68.760756]<br /> [ 68.760756] Allocated by task 279:<br /> [ 68.760756] kasan_save_stack+0x1e/0x40<br /> [<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: Add vblank register/unregister callback functions<br /> <br /> We encountered a kernel panic issue that callback data will be NULL when<br /> it&amp;#39;s using in ovl irq handler. There is a timing issue between<br /> mtk_disp_ovl_irq_handler() and mtk_ovl_disable_vblank().<br /> <br /> To resolve this issue, we use the flow to register/unregister vblank cb:<br /> - Register callback function and callback data when crtc creates.<br /> - Unregister callback function and callback data when crtc destroies.<br /> <br /> With this solution, we can assure callback data will not be NULL when<br /> vblank is disable.