Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> HID: uclogic: Fix user-memory-access bug in uclogic_params_ugee_v2_init_event_hooks()<br /> <br /> When CONFIG_HID_UCLOGIC=y and CONFIG_KUNIT_ALL_TESTS=y, launch kernel and<br /> then the below user-memory-access bug occurs.<br /> <br /> In hid_test_uclogic_params_cleanup_event_hooks(),it call<br /> uclogic_params_ugee_v2_init_event_hooks() with the first arg=NULL, so<br /> when it calls uclogic_params_ugee_v2_has_battery(), the hid_get_drvdata()<br /> will access hdev-&gt;dev with hdev=NULL, which will cause below<br /> user-memory-access.<br /> <br /> So add a fake_device with quirks member and call hid_set_drvdata()<br /> to assign hdev-&gt;dev-&gt;driver_data which avoids the null-ptr-def bug<br /> for drvdata-&gt;quirks in uclogic_params_ugee_v2_has_battery(). After applying<br /> this patch, the below user-memory-access bug never occurs.<br /> <br /> general protection fault, probably for non-canonical address 0xdffffc0000000329: 0000 [#1] PREEMPT SMP KASAN<br /> KASAN: probably user-memory-access in range [0x0000000000001948-0x000000000000194f]<br /> CPU: 5 PID: 2189 Comm: kunit_try_catch Tainted: G B W N 6.6.0-rc2+ #30<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014<br /> RIP: 0010:uclogic_params_ugee_v2_init_event_hooks+0x87/0x600<br /> Code: f3 f3 65 48 8b 14 25 28 00 00 00 48 89 54 24 60 31 d2 48 89 fa c7 44 24 30 00 00 00 00 48 c7 44 24 28 02 f8 02 01 48 c1 ea 03 3c 02 00 0f 85 2c 04 00 00 48 8b 9d 48 19 00 00 48 b8 00 00 00<br /> RSP: 0000:ffff88810679fc88 EFLAGS: 00010202<br /> RAX: dffffc0000000000 RBX: 0000000000000004 RCX: 0000000000000000<br /> RDX: 0000000000000329 RSI: ffff88810679fd88 RDI: 0000000000001948<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: ffffed1020f639f0<br /> R10: ffff888107b1cf87 R11: 0000000000000400 R12: 1ffff11020cf3f92<br /> R13: ffff88810679fd88 R14: ffff888100b97b08 R15: ffff8881030bb080<br /> FS: 0000000000000000(0000) GS:ffff888119e80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 0000000005286001 CR4: 0000000000770ee0<br /> DR0: ffffffff8fdd6cf4 DR1: ffffffff8fdd6cf5 DR2: ffffffff8fdd6cf6<br /> DR3: ffffffff8fdd6cf7 DR6: 00000000fffe0ff0 DR7: 0000000000000600<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> ? die_addr+0x3d/0xa0<br /> ? exc_general_protection+0x144/0x220<br /> ? asm_exc_general_protection+0x22/0x30<br /> ? uclogic_params_ugee_v2_init_event_hooks+0x87/0x600<br /> ? sched_clock_cpu+0x69/0x550<br /> ? uclogic_parse_ugee_v2_desc_gen_params+0x70/0x70<br /> ? load_balance+0x2950/0x2950<br /> ? rcu_trc_cmpxchg_need_qs+0x67/0xa0<br /> hid_test_uclogic_params_cleanup_event_hooks+0x9e/0x1a0<br /> ? uclogic_params_ugee_v2_init_event_hooks+0x600/0x600<br /> ? __switch_to+0x5cf/0xe60<br /> ? migrate_enable+0x260/0x260<br /> ? __kthread_parkme+0x83/0x150<br /> ? kunit_try_run_case_cleanup+0xe0/0xe0<br /> kunit_generic_run_threadfn_adapter+0x4a/0x90<br /> ? kunit_try_catch_throw+0x80/0x80<br /> kthread+0x2b5/0x380<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x2d/0x70<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork_asm+0x11/0x20<br /> <br /> Modules linked in:<br /> Dumping ftrace buffer:<br /> (ftrace buffer empty)<br /> ---[ end trace 0000000000000000 ]---<br /> RIP: 0010:uclogic_params_ugee_v2_init_event_hooks+0x87/0x600<br /> Code: f3 f3 65 48 8b 14 25 28 00 00 00 48 89 54 24 60 31 d2 48 89 fa c7 44 24 30 00 00 00 00 48 c7 44 24 28 02 f8 02 01 48 c1 ea 03 3c 02 00 0f 85 2c 04 00 00 48 8b 9d 48 19 00 00 48 b8 00 00 00<br /> RSP: 0000:ffff88810679fc88 EFLAGS: 00010202<br /> RAX: dffffc0000000000 RBX: 0000000000000004 RCX: 0000000000000000<br /> RDX: 0000000000000329 RSI: ffff88810679fd88 RDI: 0000000000001948<br /> RBP: 0000000000000000 R08: 0000000000000000 R09: ffffed1020f639f0<br /> R10: ffff888107b1cf87 R11: 0000000000000400 R12: 1ffff11020cf3f92<br /> R13: ffff88810679fd88 R14: ffff888100b97b08 R15: ffff8881030bb080<br /> FS: 0000000000000000(0000) GS:ffff888119e80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000000 CR3: 0000000005286001 CR4: 0000000000770ee0<br /> DR0: ffffffff8fdd6cf4 DR1: <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: possible buffer overflow<br /> <br /> Buffer &amp;#39;afmt_status&amp;#39; of size 6 could overflow, since index &amp;#39;afmt_idx&amp;#39; is<br /> checked after access.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: core: prevent potential string overflow<br /> <br /> The dev-&gt;id value comes from ida_alloc() so it&amp;#39;s a number between zero<br /> and INT_MAX. If it&amp;#39;s too high then these sprintf()s will overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pstore/platform: Add check for kstrdup<br /> <br /> Add check for the return value of kstrdup() and return the error<br /> if it fails in order to avoid NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: mediatek: clk-mt6765: Add check for mtk_alloc_clk_data<br /> <br /> Add the check for the return value of mtk_alloc_clk_data() in order to<br /> avoid NULL pointer dereference.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc: qcom: llcc: Handle a second device without data corruption<br /> <br /> Usually there is only one llcc device. But if there were a second, even<br /> a failed probe call would modify the global drv_data pointer. So check<br /> if drv_data is valid before overwriting it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: n_gsm: fix race condition in status line change on dead connections<br /> <br /> gsm_cleanup_mux() cleans up the gsm by closing all DLCIs, stopping all<br /> timers, removing the virtual tty devices and clearing the data queues.<br /> This procedure, however, may cause subsequent changes of the virtual modem<br /> status lines of a DLCI. More data is being added the outgoing data queue<br /> and the deleted kick timer is restarted to handle this. At this point many<br /> resources have already been removed by the cleanup procedure. Thus, a<br /> kernel panic occurs.<br /> <br /> Fix this by proving in gsm_modem_update() that the cleanup procedure has<br /> not been started and the mux is still alive.<br /> <br /> Note that writing to a virtual tty is already protected by checks against<br /> the DLCI specific connection state.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/mem: Fix shutdown order<br /> <br /> Ira reports that removing cxl_mock_mem causes a crash with the following<br /> trace:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000044<br /> [..]<br /> RIP: 0010:cxl_region_decode_reset+0x7f/0x180 [cxl_core]<br /> [..]<br /> Call Trace:<br /> <br /> cxl_region_detach+0xe8/0x210 [cxl_core]<br /> cxl_decoder_kill_region+0x27/0x40 [cxl_core]<br /> cxld_unregister+0x29/0x40 [cxl_core]<br /> devres_release_all+0xb8/0x110<br /> device_unbind_cleanup+0xe/0x70<br /> device_release_driver_internal+0x1d2/0x210<br /> bus_remove_device+0xd7/0x150<br /> device_del+0x155/0x3e0<br /> device_unregister+0x13/0x60<br /> devm_release_action+0x4d/0x90<br /> ? __pfx_unregister_port+0x10/0x10 [cxl_core]<br /> delete_endpoint+0x121/0x130 [cxl_core]<br /> devres_release_all+0xb8/0x110<br /> device_unbind_cleanup+0xe/0x70<br /> device_release_driver_internal+0x1d2/0x210<br /> bus_remove_device+0xd7/0x150<br /> device_del+0x155/0x3e0<br /> ? lock_release+0x142/0x290<br /> cdev_device_del+0x15/0x50<br /> cxl_memdev_unregister+0x54/0x70 [cxl_core]<br /> <br /> This crash is due to the clearing out the cxl_memdev&amp;#39;s driver context<br /> (@cxlds) before the subsystem is done with it. This is ultimately due to<br /> the region(s), that this memdev is a member, being torn down and expecting<br /> to be able to de-reference @cxlds, like here:<br /> <br /> static int cxl_region_decode_reset(struct cxl_region *cxlr, int count)<br /> ...<br /> if (cxlds-&gt;rcd)<br /> goto endpoint_reset;<br /> ...<br /> <br /> Fix it by keeping the driver context valid until memdev-device<br /> unregistration, and subsequently the entire stack of related<br /> dependencies, unwinds.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: hantro: Check whether reset op is defined before use<br /> <br /> The i.MX8MM/N/P does not define the .reset op since reset of the VPU is<br /> done by genpd. Check whether the .reset op is defined before calling it<br /> to avoid NULL pointer dereference.<br /> <br /> Note that the Fixes tag is set to the commit which removed the reset op<br /> from i.MX8M Hantro G2 implementation, this is because before this commit<br /> all the implementations did define the .reset op.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> IB/mlx5: Fix init stage error handling to avoid double free of same QP and UAF<br /> <br /> In the unlikely event that workqueue allocation fails and returns NULL in<br /> mlx5_mkey_cache_init(), delete the call to<br /> mlx5r_umr_resource_cleanup() (which frees the QP) in<br /> mlx5_ib_stage_post_ib_reg_umr_init(). This will avoid attempted double<br /> free of the same QP when __mlx5_ib_add() does its cleanup.<br /> <br /> Resolves a splat:<br /> <br /> Syzkaller reported a UAF in ib_destroy_qp_user<br /> <br /> workqueue: Failed to create a rescuer kthread for wq "mkey_cache": -EINTR<br /> infiniband mlx5_0: mlx5_mkey_cache_init:981:(pid 1642):<br /> failed to create work queue<br /> infiniband mlx5_0: mlx5_ib_stage_post_ib_reg_umr_init:4075:(pid 1642):<br /> mr cache init failed -12<br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2073)<br /> Read of size 8 at addr ffff88810da310a8 by task repro_upstream/1642<br /> <br /> Call Trace:<br /> <br /> kasan_report (mm/kasan/report.c:590)<br /> ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2073)<br /> mlx5r_umr_resource_cleanup (drivers/infiniband/hw/mlx5/umr.c:198)<br /> __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4178)<br /> mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402)<br /> ...<br /> <br /> <br /> Allocated by task 1642:<br /> __kmalloc (./include/linux/kasan.h:198 mm/slab_common.c:1026<br /> mm/slab_common.c:1039)<br /> create_qp (./include/linux/slab.h:603 ./include/linux/slab.h:720<br /> ./include/rdma/ib_verbs.h:2795 drivers/infiniband/core/verbs.c:1209)<br /> ib_create_qp_kernel (drivers/infiniband/core/verbs.c:1347)<br /> mlx5r_umr_resource_init (drivers/infiniband/hw/mlx5/umr.c:164)<br /> mlx5_ib_stage_post_ib_reg_umr_init (drivers/infiniband/hw/mlx5/main.c:4070)<br /> __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4168)<br /> mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402)<br /> ...<br /> <br /> Freed by task 1642:<br /> __kmem_cache_free (mm/slub.c:1826 mm/slub.c:3809 mm/slub.c:3822)<br /> ib_destroy_qp_user (drivers/infiniband/core/verbs.c:2112)<br /> mlx5r_umr_resource_cleanup (drivers/infiniband/hw/mlx5/umr.c:198)<br /> mlx5_ib_stage_post_ib_reg_umr_init (drivers/infiniband/hw/mlx5/main.c:4076<br /> drivers/infiniband/hw/mlx5/main.c:4065)<br /> __mlx5_ib_add (drivers/infiniband/hw/mlx5/main.c:4168)<br /> mlx5r_probe (drivers/infiniband/hw/mlx5/main.c:4402)<br /> ...

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: compress: fix to avoid use-after-free on dic<br /> <br /> Call trace:<br /> __memcpy+0x128/0x250<br /> f2fs_read_multi_pages+0x940/0xf7c<br /> f2fs_mpage_readpages+0x5a8/0x624<br /> f2fs_readahead+0x5c/0x110<br /> page_cache_ra_unbounded+0x1b8/0x590<br /> do_sync_mmap_readahead+0x1dc/0x2e4<br /> filemap_fault+0x254/0xa8c<br /> f2fs_filemap_fault+0x2c/0x104<br /> __do_fault+0x7c/0x238<br /> do_handle_mm_fault+0x11bc/0x2d14<br /> do_mem_abort+0x3a8/0x1004<br /> el0_da+0x3c/0xa0<br /> el0t_64_sync_handler+0xc4/0xec<br /> el0t_64_sync+0x1b4/0x1b8<br /> <br /> In f2fs_read_multi_pages(), once f2fs_decompress_cluster() was called if<br /> we hit cached page in compress_inode&amp;#39;s cache, dic may be released, it needs<br /> break the loop rather than continuing it, in order to avoid accessing<br /> invalid dic pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hid: cp2112: Fix duplicate workqueue initialization<br /> <br /> Previously the cp2112 driver called INIT_DELAYED_WORK within<br /> cp2112_gpio_irq_startup, resulting in duplicate initilizations of the<br /> workqueue on subsequent IRQ startups following an initial request. This<br /> resulted in a warning in set_work_data in workqueue.c, as well as a rare<br /> NULL dereference within process_one_work in workqueue.c.<br /> <br /> Initialize the workqueue within _probe instead.