Vulnerabilities

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

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

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

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

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

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

In the Linux kernel, the following vulnerability has been resolved: drm/msm/disp/dpu1: set vbif hw config to NULL to avoid use after memory free during pm runtime resume BUG: Unable to handle kernel paging request at virtual address 006b6b6b6b6b6be3 Call trace: dpu_vbif_init_memtypes+0x40/0xb8 dpu_runtime_resume+0xcc/0x1c0 pm_generic_runtime_resume+0x30/0x44 __genpd_runtime_resume+0x68/0x7c genpd_runtime_resume+0x134/0x258 __rpm_callback+0x98/0x138 rpm_callback+0x30/0x88 rpm_resume+0x36c/0x49c __pm_runtime_resume+0x80/0xb0 dpu_core_irq_uninstall+0x30/0xb0 dpu_irq_uninstall+0x18/0x24 msm_drm_uninit+0xd8/0x16c Patchwork: https://patchwork.freedesktop.org/patch/483255/ [DB: fixed Fixes tag]

In the Linux kernel, the following vulnerability has been resolved: ASoC: rt5645: Fix errorenous cleanup order There is a logic error when removing rt5645 device as the function rt5645_i2c_remove() first cancel the &rt5645->jack_detect_work and delete the &rt5645->btn_check_timer latter. However, since the timer handler rt5645_btn_check_callback() will re-queue the jack_detect_work, this cleanup order is buggy. That is, once the del_timer_sync in rt5645_i2c_remove is concurrently run with the rt5645_btn_check_callback, the canceled jack_detect_work will be rescheduled again, leading to possible use-after-free. This patch fix the issue by placing the del_timer_sync function before the cancel_delayed_work_sync.

In the Linux kernel, the following vulnerability has been resolved: net: remove two BUG() from skb_checksum_help() I have a syzbot report that managed to get a crash in skb_checksum_help() If syzbot can trigger these BUG(), it makes sense to replace them with more friendly WARN_ON_ONCE() since skb_checksum_help() can instead return an error code. Note that syzbot will still crash there, until real bug is fixed.

In the Linux kernel, the following vulnerability has been resolved: media: mediatek: vcodec: prevent kernel crash when rmmod mtk-vcodec-dec.ko If the driver support subdev mode, the parameter "dev->pm.dev" will be NULL in mtk_vcodec_dec_remove. Kernel will crash when try to rmmod mtk-vcodec-dec.ko. [ 4380.702726] pc : do_raw_spin_trylock+0x4/0x80 [ 4380.707075] lr : _raw_spin_lock_irq+0x90/0x14c [ 4380.711509] sp : ffff80000819bc10 [ 4380.714811] x29: ffff80000819bc10 x28: ffff3600c03e4000 x27: 0000000000000000 [ 4380.721934] x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000 [ 4380.729057] x23: ffff3600c0f34930 x22: ffffd5e923549000 x21: 0000000000000220 [ 4380.736179] x20: 0000000000000208 x19: ffffd5e9213e8ebc x18: 0000000000000020 [ 4380.743298] x17: 0000002000000000 x16: ffffd5e9213e8e90 x15: 696c346f65646976 [ 4380.750420] x14: 0000000000000000 x13: 0000000000000001 x12: 0000000000000040 [ 4380.757542] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000 [ 4380.764664] x8 : 0000000000000000 x7 : ffff3600c7273ae8 x6 : ffffd5e9213e8ebc [ 4380.771786] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000 [ 4380.778908] x2 : 0000000000000000 x1 : ffff3600c03e4000 x0 : 0000000000000208 [ 4380.786031] Call trace: [ 4380.788465] do_raw_spin_trylock+0x4/0x80 [ 4380.792462] __pm_runtime_disable+0x2c/0x1b0 [ 4380.796723] mtk_vcodec_dec_remove+0x5c/0xa0 [mtk_vcodec_dec] [ 4380.802466] platform_remove+0x2c/0x60 [ 4380.806204] __device_release_driver+0x194/0x250 [ 4380.810810] driver_detach+0xc8/0x15c [ 4380.814462] bus_remove_driver+0x5c/0xb0 [ 4380.818375] driver_unregister+0x34/0x64 [ 4380.822288] platform_driver_unregister+0x18/0x24 [ 4380.826979] mtk_vcodec_dec_driver_exit+0x1c/0x888 [mtk_vcodec_dec] [ 4380.833240] __arm64_sys_delete_module+0x190/0x224 [ 4380.838020] invoke_syscall+0x48/0x114 [ 4380.841760] el0_svc_common.constprop.0+0x60/0x11c [ 4380.846540] do_el0_svc+0x28/0x90 [ 4380.849844] el0_svc+0x4c/0x100 [ 4380.852975] el0t_64_sync_handler+0xec/0xf0 [ 4380.857148] el0t_64_sync+0x190/0x194 [ 4380.860801] Code: 94431515 17ffffca d503201f d503245f (b9400004)

In the Linux kernel, the following vulnerability has been resolved: drm/msm/hdmi: check return value after calling platform_get_resource_byname() It will cause null-ptr-deref if platform_get_resource_byname() returns NULL, we need check the return value. Patchwork: https://patchwork.freedesktop.org/patch/482992/

In the Linux kernel, the following vulnerability has been resolved: mtd: rawnand: cadence: fix possible null-ptr-deref in cadence_nand_dt_probe() It will cause null-ptr-deref when using 'res', if platform_get_resource() returns NULL, so move using 'res' after devm_ioremap_resource() that will check it to avoid null-ptr-deref. And use devm_platform_get_and_ioremap_resource() to simplify code.