Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: fsl-lpspi: Fix PM reference leak in lpspi_prepare_xfer_hardware()<br /> <br /> pm_runtime_get_sync will increment pm usage counter even it failed.<br /> Forgetting to putting operation will result in reference leak here.<br /> Fix it by replacing it with pm_runtime_resume_and_get to keep usage<br /> counter balanced.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: sa2ul - Fix memory leak of rxd<br /> <br /> There are two error return paths that are not freeing rxd and causing<br /> memory leaks. Fix these.<br /> <br /> Addresses-Coverity: ("Resource leak")

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: sun8i-ss - Fix memory leak of pad<br /> <br /> It appears there are several failure return paths that don&amp;#39;t seem<br /> to be free&amp;#39;ing pad. Fix these.<br /> <br /> Addresses-Coverity: ("Resource leak")

The Under Construction / Maintenance Mode from Acurax plugin for WordPress is vulnerable to Sensitive Information Exposure in versions up to, and including, 2.6 via the &amp;#39;acx_csma_subscribe_ajax&amp;#39; function. This can allow authenticated attackers to extract sensitive data such as names and email addresses of subscribed visitors.

The Gestpay for WooCommerce plugin for WordPress is vulnerable to Cross-Site Request Forgery in all versions up to, and including, 20221130. This is due to missing or incorrect nonce validation on the &amp;#39;ajax_set_default_card&amp;#39; function. This makes it possible for unauthenticated attackers to set the default card token for a user via a forged request granted they can trick a site administrator into performing an action such as clicking on a link.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc/64: Fix the definition of the fixmap area<br /> <br /> At the time being, the fixmap area is defined at the top of<br /> the address space or just below KASAN.<br /> <br /> This definition is not valid for PPC64.<br /> <br /> For PPC64, use the top of the I/O space.<br /> <br /> Because of circular dependencies, it is not possible to include<br /> asm/fixmap.h in asm/book3s/64/pgtable.h , so define a fixed size<br /> AREA at the top of the I/O space for fixmap and ensure during<br /> build that the size is big enough.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7921: fix possible invalid register access<br /> <br /> Disable the interrupt and synchronze for the pending irq handlers to ensure<br /> the irq tasklet is not being scheduled after the suspend to avoid the<br /> possible invalid register access acts when the host pcie controller is<br /> suspended.<br /> <br /> [17932.910534] mt7921e 0000:01:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 21375 usecs<br /> [17932.910590] pcieport 0000:00:00.0: calling pci_pm_suspend+0x0/0x22c @ 18565, parent: pci0000:00<br /> [17932.910602] pcieport 0000:00:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 8 usecs<br /> [17932.910671] mtk-pcie 11230000.pcie: calling platform_pm_suspend+0x0/0x60 @ 22783, parent: soc<br /> [17932.910674] mtk-pcie 11230000.pcie: platform_pm_suspend+0x0/0x60 returned 0 after 0 usecs<br /> <br /> ...<br /> <br /> 17933.615352] x1 : 00000000000d4200 x0 : ffffff8269ca2300<br /> [17933.620666] Call trace:<br /> [17933.623127] mt76_mmio_rr+0x28/0xf0 [mt76]<br /> [17933.627234] mt7921_rr+0x38/0x44 [mt7921e]<br /> [17933.631339] mt7921_irq_tasklet+0x54/0x1d8 [mt7921e]<br /> [17933.636309] tasklet_action_common+0x12c/0x16c<br /> [17933.640754] tasklet_action+0x24/0x2c<br /> [17933.644418] __do_softirq+0x16c/0x344<br /> [17933.648082] irq_exit+0xa8/0xac<br /> [17933.651224] scheduler_ipi+0xd4/0x148<br /> [17933.654890] handle_IPI+0x164/0x2d4<br /> [17933.658379] gic_handle_irq+0x140/0x178<br /> [17933.662216] el1_irq+0xb8/0x180<br /> [17933.665361] cpuidle_enter_state+0xf8/0x204<br /> [17933.669544] cpuidle_enter+0x38/0x4c<br /> [17933.673122] do_idle+0x1a4/0x2a8<br /> [17933.676352] cpu_startup_entry+0x24/0x28<br /> [17933.680276] rest_init+0xd4/0xe0<br /> [17933.683508] arch_call_rest_init+0x10/0x18<br /> [17933.687606] start_kernel+0x340/0x3b4<br /> [17933.691279] Code: aa0003f5 d503201f f953eaa8 8b344108 (b9400113)<br /> [17933.697373] ---[ end trace a24b8e26ffbda3c5 ]---<br /> [17933.767846] Kernel panic - not syncing: Fatal exception in interrupt

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7915: fix memleak when mt7915_unregister_device()<br /> <br /> mt7915_tx_token_put() should get call before mt76_free_pending_txwi().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mt76: mt7615: fix memleak when mt7615_unregister_device()<br /> <br /> mt7615_tx_token_put() should get call before mt76_free_pending_txwi().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: marvell: prestera: fix port event handling on init<br /> <br /> For some reason there might be a crash during ports creation if port<br /> events are handling at the same time because fw may send initial<br /> port event with down state.<br /> <br /> The crash points to cancel_delayed_work() which is called when port went<br /> is down. Currently I did not find out the real cause of the issue, so<br /> fixed it by cancel port stats work only if previous port&amp;#39;s state was up<br /> &amp; runnig.<br /> <br /> The following is the crash which can be triggered:<br /> <br /> [ 28.311104] Unable to handle kernel paging request at virtual address<br /> 000071775f776600<br /> [ 28.319097] Mem abort info:<br /> [ 28.321914] ESR = 0x96000004<br /> [ 28.324996] EC = 0x25: DABT (current EL), IL = 32 bits<br /> [ 28.330350] SET = 0, FnV = 0<br /> [ 28.333430] EA = 0, S1PTW = 0<br /> [ 28.336597] Data abort info:<br /> [ 28.339499] ISV = 0, ISS = 0x00000004<br /> [ 28.343362] CM = 0, WnR = 0<br /> [ 28.346354] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000100bf7000<br /> [ 28.352842] [000071775f776600] pgd=0000000000000000,<br /> p4d=0000000000000000<br /> [ 28.359695] Internal error: Oops: 96000004 [#1] PREEMPT SMP<br /> [ 28.365310] Modules linked in: prestera_pci(+) prestera<br /> uio_pdrv_genirq<br /> [ 28.372005] CPU: 0 PID: 1291 Comm: kworker/0:1H Not tainted<br /> 5.11.0-rc4 #1<br /> [ 28.378846] Hardware name: DNI AmazonGo1 A7040 board (DT)<br /> [ 28.384283] Workqueue: prestera_fw_wq prestera_fw_evt_work_fn<br /> [prestera_pci]<br /> [ 28.391413] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)<br /> [ 28.397468] pc : get_work_pool+0x48/0x60<br /> [ 28.401442] lr : try_to_grab_pending+0x6c/0x1b0<br /> [ 28.406018] sp : ffff80001391bc60<br /> [ 28.409358] x29: ffff80001391bc60 x28: 0000000000000000<br /> [ 28.414725] x27: ffff000104fc8b40 x26: ffff80001127de88<br /> [ 28.420089] x25: 0000000000000000 x24: ffff000106119760<br /> [ 28.425452] x23: ffff00010775dd60 x22: ffff00010567e000<br /> [ 28.430814] x21: 0000000000000000 x20: ffff80001391bcb0<br /> [ 28.436175] x19: ffff00010775deb8 x18: 00000000000000c0<br /> [ 28.441537] x17: 0000000000000000 x16: 000000008d9b0e88<br /> [ 28.446898] x15: 0000000000000001 x14: 00000000000002ba<br /> [ 28.452261] x13: 80a3002c00000002 x12: 00000000000005f4<br /> [ 28.457622] x11: 0000000000000030 x10: 000000000000000c<br /> [ 28.462985] x9 : 000000000000000c x8 : 0000000000000030<br /> [ 28.468346] x7 : ffff800014400000 x6 : ffff000106119758<br /> [ 28.473708] x5 : 0000000000000003 x4 : ffff00010775dc60<br /> [ 28.479068] x3 : 0000000000000000 x2 : 0000000000000060<br /> [ 28.484429] x1 : 000071775f776600 x0 : ffff00010775deb8<br /> [ 28.489791] Call trace:<br /> [ 28.492259] get_work_pool+0x48/0x60<br /> [ 28.495874] cancel_delayed_work+0x38/0xb0<br /> [ 28.500011] prestera_port_handle_event+0x90/0xa0 [prestera]<br /> [ 28.505743] prestera_evt_recv+0x98/0xe0 [prestera]<br /> [ 28.510683] prestera_fw_evt_work_fn+0x180/0x228 [prestera_pci]<br /> [ 28.516660] process_one_work+0x1e8/0x360<br /> [ 28.520710] worker_thread+0x44/0x480<br /> [ 28.524412] kthread+0x154/0x160<br /> [ 28.527670] ret_from_fork+0x10/0x38<br /> [ 28.531290] Code: a8c17bfd d50323bf d65f03c0 9278dc21 (f9400020)<br /> [ 28.537429] ---[ end trace 5eced933df3a080b ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vsock/virtio: free queued packets when closing socket<br /> <br /> As reported by syzbot [1], there is a memory leak while closing the<br /> socket. We partially solved this issue with commit ac03046ece2b<br /> ("vsock/virtio: free packets during the socket release"), but we<br /> forgot to drain the RX queue when the socket is definitely closed by<br /> the scheduled work.<br /> <br /> To avoid future issues, let&amp;#39;s use the new virtio_transport_remove_sock()<br /> to drain the RX queue before removing the socket from the af_vsock lists<br /> calling vsock_remove_sock().<br /> <br /> [1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/mediatek: Always enable the clk on resume<br /> <br /> In mtk_iommu_runtime_resume always enable the clk, even<br /> if m4u_dom is null. Otherwise the &amp;#39;suspend&amp;#39; cb might<br /> disable the clk which is already disabled causing the warning:<br /> <br /> [ 1.586104] infra_m4u already disabled<br /> [ 1.586133] WARNING: CPU: 0 PID: 121 at drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8<br /> [ 1.594391] mtk-iommu 10205000.iommu: bound 18001000.larb (ops mtk_smi_larb_component_ops)<br /> [ 1.598108] Modules linked in:<br /> [ 1.598114] CPU: 0 PID: 121 Comm: kworker/0:2 Not tainted 5.12.0-rc5 #69<br /> [ 1.609246] mtk-iommu 10205000.iommu: bound 14027000.larb (ops mtk_smi_larb_component_ops)<br /> [ 1.617487] Hardware name: Google Elm (DT)<br /> [ 1.617491] Workqueue: pm pm_runtime_work<br /> [ 1.620545] mtk-iommu 10205000.iommu: bound 19001000.larb (ops mtk_smi_larb_component_ops)<br /> <br /> [ 1.627229] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)<br /> [ 1.659297] pc : clk_core_disable+0xb0/0xb8<br /> [ 1.663475] lr : clk_core_disable+0xb0/0xb8<br /> [ 1.667652] sp : ffff800011b9bbe0<br /> [ 1.670959] x29: ffff800011b9bbe0 x28: 0000000000000000<br /> [ 1.676267] x27: ffff800011448000 x26: ffff8000100cfd98<br /> [ 1.681574] x25: ffff800011b9bd48 x24: 0000000000000000<br /> [ 1.686882] x23: 0000000000000000 x22: ffff8000106fad90<br /> [ 1.692189] x21: 000000000000000a x20: ffff0000c0048500<br /> [ 1.697496] x19: ffff0000c0048500 x18: ffffffffffffffff<br /> [ 1.702804] x17: 0000000000000000 x16: 0000000000000000<br /> [ 1.708112] x15: ffff800011460300 x14: fffffffffffe0000<br /> [ 1.713420] x13: ffff8000114602d8 x12: 0720072007200720<br /> [ 1.718727] x11: 0720072007200720 x10: 0720072007200720<br /> [ 1.724035] x9 : ffff800011b9bbe0 x8 : ffff800011b9bbe0<br /> [ 1.729342] x7 : 0000000000000009 x6 : ffff8000114b8328<br /> [ 1.734649] x5 : 0000000000000000 x4 : 0000000000000000<br /> [ 1.739956] x3 : 00000000ffffffff x2 : ffff800011460298<br /> [ 1.745263] x1 : 1af1d7de276f4500 x0 : 0000000000000000<br /> [ 1.750572] Call trace:<br /> [ 1.753010] clk_core_disable+0xb0/0xb8<br /> [ 1.756840] clk_core_disable_lock+0x24/0x40<br /> [ 1.761105] clk_disable+0x20/0x30<br /> [ 1.764501] mtk_iommu_runtime_suspend+0x88/0xa8<br /> [ 1.769114] pm_generic_runtime_suspend+0x2c/0x48<br /> [ 1.773815] __rpm_callback+0xe0/0x178<br /> [ 1.777559] rpm_callback+0x24/0x88<br /> [ 1.781041] rpm_suspend+0xdc/0x470<br /> [ 1.784523] rpm_idle+0x12c/0x170<br /> [ 1.787831] pm_runtime_work+0xa8/0xc0<br /> [ 1.791573] process_one_work+0x1e8/0x360<br /> [ 1.795580] worker_thread+0x44/0x478<br /> [ 1.799237] kthread+0x150/0x158<br /> [ 1.802460] ret_from_fork+0x10/0x30<br /> [ 1.806034] ---[ end trace 82402920ef64573b ]---<br /> [ 1.810728] ------------[ cut here ]------------<br /> <br /> In addition, we now don&amp;#39;t need to enable the clock from the<br /> function mtk_iommu_hw_init since it is already enabled by the resume.