Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: da9121: Fix uninit-value in da9121_assign_chip_model()<br /> <br /> KASAN report slab-out-of-bounds in __regmap_init as follows:<br /> <br /> BUG: KASAN: slab-out-of-bounds in __regmap_init drivers/base/regmap/regmap.c:841<br /> Read of size 1 at addr ffff88803678cdf1 by task xrun/9137<br /> <br /> CPU: 0 PID: 9137 Comm: xrun Tainted: G W 5.18.0-rc2<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xe8/0x15a lib/dump_stack.c:88<br /> print_report.cold+0xcd/0x69b mm/kasan/report.c:313<br /> kasan_report+0x8e/0xc0 mm/kasan/report.c:491<br /> __regmap_init+0x4540/0x4ba0 drivers/base/regmap/regmap.c:841<br /> __devm_regmap_init+0x7a/0x100 drivers/base/regmap/regmap.c:1266<br /> __devm_regmap_init_i2c+0x65/0x80 drivers/base/regmap/regmap-i2c.c:394<br /> da9121_i2c_probe+0x386/0x6d1 drivers/regulator/da9121-regulator.c:1039<br /> i2c_device_probe+0x959/0xac0 drivers/i2c/i2c-core-base.c:563<br /> <br /> This happend when da9121 device is probe by da9121_i2c_id, but with<br /> invalid dts. Thus, chip-&gt;subvariant_id is set to -EINVAL, and later<br /> da9121_assign_chip_model() will access &amp;#39;regmap&amp;#39; without init it.<br /> <br /> Fix it by return -EINVAL from da9121_assign_chip_model() if<br /> &amp;#39;chip-&gt;subvariant_id&amp;#39; is invalid.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: elan: Fix potential double free in elan_input_configured<br /> <br /> &amp;#39;input&amp;#39; is a managed resource allocated with devm_input_allocate_device(),<br /> so there is no need to call input_free_device() explicitly or<br /> there will be a double free.<br /> <br /> According to the doc of devm_input_allocate_device():<br /> * Managed input devices do not need to be explicitly unregistered or<br /> * freed as it will be done automatically when owner device unbinds from<br /> * its driver (or binding fails).

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/mdp5: Return error code in mdp5_pipe_release when deadlock is detected<br /> <br /> mdp5_get_global_state runs the risk of hitting a -EDEADLK when acquiring<br /> the modeset lock, but currently mdp5_pipe_release doesn&amp;#39;t check for if<br /> an error is returned. Because of this, there is a possibility of<br /> mdp5_pipe_release hitting a NULL dereference error.<br /> <br /> To avoid this, let&amp;#39;s have mdp5_pipe_release check if<br /> mdp5_get_global_state returns an error and propogate that error.<br /> <br /> Changes since v1:<br /> - Separated declaration and initialization of *new_state to avoid<br /> compiler warning<br /> - Fixed some spelling mistakes in commit message<br /> <br /> Changes since v2:<br /> - Return 0 in case where hwpipe is NULL as this is considered normal<br /> behavior<br /> - Added 2nd patch in series to fix a similar NULL dereference issue in<br /> mdp5_mixer_release<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/485179/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/rockchip: vop: fix possible null-ptr-deref in vop_bind()<br /> <br /> It will cause null-ptr-deref in resource_size(), if platform_get_resource()<br /> returns NULL, move calling resource_size() after devm_ioremap_resource() that<br /> will check &amp;#39;res&amp;#39; to avoid null-ptr-deref.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvme-pci: fix a NULL pointer dereference in nvme_alloc_admin_tags<br /> <br /> In nvme_alloc_admin_tags, the admin_q can be set to an error (typically<br /> -ENOMEM) if the blk_mq_init_queue call fails to set up the queue, which<br /> is checked immediately after the call. However, when we return the error<br /> message up the stack, to nvme_reset_work the error takes us to<br /> nvme_remove_dead_ctrl()<br /> nvme_dev_disable()<br /> nvme_suspend_queue(&amp;dev-&gt;queues[0]).<br /> <br /> Here, we only check that the admin_q is non-NULL, rather than not<br /> an error or NULL, and begin quiescing a queue that never existed, leading<br /> to bad / NULL pointer dereference.

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

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

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

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

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

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: pcm: Check for null pointer of pointer substream before dereferencing it<br /> <br /> Pointer substream is being dereferenced on the assignment of pointer card<br /> before substream is being null checked with the macro PCM_RUNTIME_CHECK.<br /> Although PCM_RUNTIME_CHECK calls BUG_ON, it still is useful to perform the<br /> the pointer check before card is assigned.