Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbdev: defio: fix the pagelist corruption<br /> <br /> Easily hit the below list corruption:<br /> ==<br /> list_add corruption. prev-&gt;next should be next (ffffffffc0ceb090), but<br /> was ffffec604507edc8. (prev=ffffec604507edc8).<br /> WARNING: CPU: 65 PID: 3959 at lib/list_debug.c:26<br /> __list_add_valid+0x53/0x80<br /> CPU: 65 PID: 3959 Comm: fbdev Tainted: G U<br /> RIP: 0010:__list_add_valid+0x53/0x80<br /> Call Trace:<br /> <br /> fb_deferred_io_mkwrite+0xea/0x150<br /> do_page_mkwrite+0x57/0xc0<br /> do_wp_page+0x278/0x2f0<br /> __handle_mm_fault+0xdc2/0x1590<br /> handle_mm_fault+0xdd/0x2c0<br /> do_user_addr_fault+0x1d3/0x650<br /> exc_page_fault+0x77/0x180<br /> ? asm_exc_page_fault+0x8/0x30<br /> asm_exc_page_fault+0x1e/0x30<br /> RIP: 0033:0x7fd98fc8fad1<br /> ==<br /> <br /> Figure out the race happens when one process is adding &amp;page-&gt;lru into<br /> the pagelist tail in fb_deferred_io_mkwrite(), another process is<br /> re-initializing the same &amp;page-&gt;lru in fb_deferred_io_fault(), which is<br /> not protected by the lock.<br /> <br /> This fix is to init all the page lists one time during initialization,<br /> it not only fixes the list corruption, but also avoids INIT_LIST_HEAD()<br /> redundantly.<br /> <br /> V2: change "int i" to "unsigned int i" (Geert Uytterhoeven)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: rawnand: denali: Use managed device resources<br /> <br /> All of the resources used by this driver has managed interfaces, so use<br /> them. Otherwise we will get the following splat:<br /> <br /> [ 4.472703] denali-nand-pci 0000:00:05.0: timeout while waiting for irq 0x1000<br /> [ 4.474071] denali-nand-pci: probe of 0000:00:05.0 failed with error -5<br /> [ 4.473538] nand: No NAND device found<br /> [ 4.474068] BUG: unable to handle page fault for address: ffffc90005000410<br /> [ 4.475169] #PF: supervisor write access in kernel mode<br /> [ 4.475579] #PF: error_code(0x0002) - not-present page<br /> [ 4.478362] RIP: 0010:iowrite32+0x9/0x50<br /> [ 4.486068] Call Trace:<br /> [ 4.486269] <br /> [ 4.486443] denali_isr+0x15b/0x300 [denali]<br /> [ 4.486788] ? denali_direct_write+0x50/0x50 [denali]<br /> [ 4.487189] __handle_irq_event_percpu+0x161/0x3b0<br /> [ 4.487571] handle_irq_event+0x7d/0x1b0<br /> [ 4.487884] handle_fasteoi_irq+0x2b0/0x770<br /> [ 4.488219] __common_interrupt+0xc8/0x1b0<br /> [ 4.488549] common_interrupt+0x9a/0xc0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cpufreq: governor: Use kobject release() method to free dbs_data<br /> <br /> The struct dbs_data embeds a struct gov_attr_set and<br /> the struct gov_attr_set embeds a kobject. Since every kobject must have<br /> a release() method and we can&amp;#39;t use kfree() to free it directly,<br /> so introduce cpufreq_dbs_data_release() to release the dbs_data via<br /> the kobject::release() method. This fixes the calltrace like below:<br /> <br /> ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x34<br /> WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100<br /> Modules linked in:<br /> CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536<br /> Hardware name: Marvell OcteonTX CN96XX board (DT)<br /> pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : debug_print_object+0xb8/0x100<br /> lr : debug_print_object+0xb8/0x100<br /> sp : ffff80001dfcf9a0<br /> x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000<br /> x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210<br /> x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118<br /> x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000<br /> x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8<br /> x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14<br /> x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0<br /> x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001<br /> x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000<br /> x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040<br /> Call trace:<br /> debug_print_object+0xb8/0x100<br /> __debug_check_no_obj_freed+0x1d0/0x25c<br /> debug_check_no_obj_freed+0x24/0xa0<br /> kfree+0x11c/0x440<br /> cpufreq_dbs_governor_exit+0xa8/0xac<br /> cpufreq_exit_governor+0x44/0x90<br /> cpufreq_set_policy+0x29c/0x570<br /> store_scaling_governor+0x110/0x154<br /> store+0xb0/0xe0<br /> sysfs_kf_write+0x58/0x84<br /> kernfs_fop_write_iter+0x12c/0x1c0<br /> new_sync_write+0xf0/0x18c<br /> vfs_write+0x1cc/0x220<br /> ksys_write+0x74/0x100<br /> __arm64_sys_write+0x28/0x3c<br /> invoke_syscall.constprop.0+0x58/0xf0<br /> do_el0_svc+0x70/0x170<br /> el0_svc+0x54/0x190<br /> el0t_64_sync_handler+0xa4/0x130<br /> el0t_64_sync+0x1a0/0x1a4<br /> irq event stamp: 189006<br /> hardirqs last enabled at (189005): [] finish_task_switch.isra.0+0xe0/0x2c0<br /> hardirqs last disabled at (189006): [] el1_dbg+0x24/0xa0<br /> softirqs last enabled at (188966): [] __do_softirq+0x4b0/0x6a0<br /> softirqs last disabled at (188957): [] __irq_exit_rcu+0x108/0x1a4<br /> <br /> [ rjw: Because can be freed by the gov_attr_set_put() in<br /> cpufreq_dbs_governor_exit() now, it is also necessary to put the<br /> invocation of the governor -&gt;exit() callback into the new<br /> cpufreq_dbs_data_release() function. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: mediatek: Fix error handling in mt8173_max98090_dev_probe<br /> <br /> Call of_node_put(platform_node) to avoid refcount leak in<br /> the error path.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: cs35l41: Fix an out-of-bounds access in otp_packed_element_t<br /> <br /> The CS35L41_NUM_OTP_ELEM is 100, but only 99 entries are defined in<br /> the array otp_map_1/2[CS35L41_NUM_OTP_ELEM], this will trigger UBSAN<br /> to report a shift-out-of-bounds warning in the cs35l41_otp_unpack()<br /> since the last entry in the array will result in GENMASK(-1, 0).<br /> <br /> UBSAN reports this problem:<br /> UBSAN: shift-out-of-bounds in /home/hwang4/build/jammy/jammy/sound/soc/codecs/cs35l41-lib.c:836:8<br /> shift exponent 64 is too large for 64-bit type &amp;#39;long unsigned int&amp;#39;<br /> CPU: 10 PID: 595 Comm: systemd-udevd Not tainted 5.15.0-23-generic #23<br /> Hardware name: LENOVO \x02MFG_IN_GO/\x02MFG_IN_GO, BIOS N3GET19W (1.00 ) 03/11/2022<br /> Call Trace:<br /> <br /> show_stack+0x52/0x58<br /> dump_stack_lvl+0x4a/0x5f<br /> dump_stack+0x10/0x12<br /> ubsan_epilogue+0x9/0x45<br /> __ubsan_handle_shift_out_of_bounds.cold+0x61/0xef<br /> ? regmap_unlock_mutex+0xe/0x10<br /> cs35l41_otp_unpack.cold+0x1c6/0x2b2 [snd_soc_cs35l41_lib]<br /> cs35l41_hda_probe+0x24f/0x33a [snd_hda_scodec_cs35l41]<br /> cs35l41_hda_i2c_probe+0x65/0x90 [snd_hda_scodec_cs35l41_i2c]<br /> ? cs35l41_hda_i2c_remove+0x20/0x20 [snd_hda_scodec_cs35l41_i2c]<br /> i2c_device_probe+0x252/0x2b0

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: always check VF VSI pointer values<br /> <br /> The ice_get_vf_vsi function can return NULL in some cases, such as if<br /> handling messages during a reset where the VSI is being removed and<br /> recreated.<br /> <br /> Several places throughout the driver do not bother to check whether this<br /> VSI pointer is valid. Static analysis tools maybe report issues because<br /> they detect paths where a potentially NULL pointer could be dereferenced.<br /> <br /> Fix this by checking the return value of ice_get_vf_vsi everywhere.

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.