Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu: Fix two issues in iommu_copy_struct_from_user()<br /> <br /> In the review for iommu_copy_struct_to_user() helper, Matt pointed out that<br /> a NULL pointer should be rejected prior to dereferencing it:<br /> https://lore.kernel.org/all/86881827-8E2D-461C-BDA3-FA8FD14C343C@nvidia.com<br /> <br /> And Alok pointed out a typo at the same time:<br /> https://lore.kernel.org/all/480536af-6830-43ce-a327-adbd13dc3f1d@oracle.com<br /> <br /> Since both issues were copied from iommu_copy_struct_from_user(), fix them<br /> first in the current header.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> irqchip/qcom-mpm: Prevent crash when trying to handle non-wake GPIOs<br /> <br /> On Qualcomm chipsets not all GPIOs are wakeup capable. Those GPIOs do not<br /> have a corresponding MPM pin and should not be handled inside the MPM<br /> driver. The IRQ domain hierarchy is always applied, so it&amp;#39;s required to<br /> explicitly disconnect the hierarchy for those. The pinctrl-msm driver marks<br /> these with GPIO_NO_WAKE_IRQ. qcom-pdc has a check for this, but<br /> irq-qcom-mpm is currently missing the check. This is causing crashes when<br /> setting up interrupts for non-wake GPIOs:<br /> <br /> root@rb1:~# gpiomon -c gpiochip1 10<br /> irq: IRQ159: trimming hierarchy from :soc@0:interrupt-controller@f200000-1<br /> Unable to handle kernel paging request at virtual address ffff8000a1dc3820<br /> Hardware name: Qualcomm Technologies, Inc. Robotics RB1 (DT)<br /> pc : mpm_set_type+0x80/0xcc<br /> lr : mpm_set_type+0x5c/0xcc<br /> Call trace:<br /> mpm_set_type+0x80/0xcc (P)<br /> qcom_mpm_set_type+0x64/0x158<br /> irq_chip_set_type_parent+0x20/0x38<br /> msm_gpio_irq_set_type+0x50/0x530<br /> __irq_set_trigger+0x60/0x184<br /> __setup_irq+0x304/0x6bc<br /> request_threaded_irq+0xc8/0x19c<br /> edge_detector_setup+0x260/0x364<br /> linereq_create+0x420/0x5a8<br /> gpio_ioctl+0x2d4/0x6c0<br /> <br /> Fix this by copying the check for GPIO_NO_WAKE_IRQ from qcom-pdc.c, so that<br /> MPM is removed entirely from the hierarchy for non-wake GPIOs.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix slab-use-after-free in hdcp<br /> <br /> The HDCP code in amdgpu_dm_hdcp.c copies pointers to amdgpu_dm_connector<br /> objects without incrementing the kref reference counts. When using a<br /> USB-C dock, and the dock is unplugged, the corresponding<br /> amdgpu_dm_connector objects are freed, creating dangling pointers in the<br /> HDCP code. When the dock is plugged back, the dangling pointers are<br /> dereferenced, resulting in a slab-use-after-free:<br /> <br /> [ 66.775837] BUG: KASAN: slab-use-after-free in event_property_validate+0x42f/0x6c0 [amdgpu]<br /> [ 66.776171] Read of size 4 at addr ffff888127804120 by task kworker/0:1/10<br /> <br /> [ 66.776179] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.14.0-rc7-00180-g54505f727a38-dirty #233<br /> [ 66.776183] Hardware name: HP HP Pavilion Aero Laptop 13-be0xxx/8916, BIOS F.17 12/18/2024<br /> [ 66.776186] Workqueue: events event_property_validate [amdgpu]<br /> [ 66.776494] Call Trace:<br /> [ 66.776496] <br /> [ 66.776497] dump_stack_lvl+0x70/0xa0<br /> [ 66.776504] print_report+0x175/0x555<br /> [ 66.776507] ? __virt_addr_valid+0x243/0x450<br /> [ 66.776510] ? kasan_complete_mode_report_info+0x66/0x1c0<br /> [ 66.776515] kasan_report+0xeb/0x1c0<br /> [ 66.776518] ? event_property_validate+0x42f/0x6c0 [amdgpu]<br /> [ 66.776819] ? event_property_validate+0x42f/0x6c0 [amdgpu]<br /> [ 66.777121] __asan_report_load4_noabort+0x14/0x20<br /> [ 66.777124] event_property_validate+0x42f/0x6c0 [amdgpu]<br /> [ 66.777342] ? __lock_acquire+0x6b40/0x6b40<br /> [ 66.777347] ? enable_assr+0x250/0x250 [amdgpu]<br /> [ 66.777571] process_one_work+0x86b/0x1510<br /> [ 66.777575] ? pwq_dec_nr_in_flight+0xcf0/0xcf0<br /> [ 66.777578] ? assign_work+0x16b/0x280<br /> [ 66.777580] ? lock_is_held_type+0xa3/0x130<br /> [ 66.777583] worker_thread+0x5c0/0xfa0<br /> [ 66.777587] ? process_one_work+0x1510/0x1510<br /> [ 66.777588] kthread+0x3a2/0x840<br /> [ 66.777591] ? kthread_is_per_cpu+0xd0/0xd0<br /> [ 66.777594] ? trace_hardirqs_on+0x4f/0x60<br /> [ 66.777597] ? _raw_spin_unlock_irq+0x27/0x60<br /> [ 66.777599] ? calculate_sigpending+0x77/0xa0<br /> [ 66.777602] ? kthread_is_per_cpu+0xd0/0xd0<br /> [ 66.777605] ret_from_fork+0x40/0x90<br /> [ 66.777607] ? kthread_is_per_cpu+0xd0/0xd0<br /> [ 66.777609] ret_from_fork_asm+0x11/0x20<br /> [ 66.777614] <br /> <br /> [ 66.777643] Allocated by task 10:<br /> [ 66.777646] kasan_save_stack+0x39/0x60<br /> [ 66.777649] kasan_save_track+0x14/0x40<br /> [ 66.777652] kasan_save_alloc_info+0x37/0x50<br /> [ 66.777655] __kasan_kmalloc+0xbb/0xc0<br /> [ 66.777658] __kmalloc_cache_noprof+0x1c8/0x4b0<br /> [ 66.777661] dm_dp_add_mst_connector+0xdd/0x5c0 [amdgpu]<br /> [ 66.777880] drm_dp_mst_port_add_connector+0x47e/0x770 [drm_display_helper]<br /> [ 66.777892] drm_dp_send_link_address+0x1554/0x2bf0 [drm_display_helper]<br /> [ 66.777901] drm_dp_check_and_send_link_address+0x187/0x1f0 [drm_display_helper]<br /> [ 66.777909] drm_dp_mst_link_probe_work+0x2b8/0x410 [drm_display_helper]<br /> [ 66.777917] process_one_work+0x86b/0x1510<br /> [ 66.777919] worker_thread+0x5c0/0xfa0<br /> [ 66.777922] kthread+0x3a2/0x840<br /> [ 66.777925] ret_from_fork+0x40/0x90<br /> [ 66.777927] ret_from_fork_asm+0x11/0x20<br /> <br /> [ 66.777932] Freed by task 1713:<br /> [ 66.777935] kasan_save_stack+0x39/0x60<br /> [ 66.777938] kasan_save_track+0x14/0x40<br /> [ 66.777940] kasan_save_free_info+0x3b/0x60<br /> [ 66.777944] __kasan_slab_free+0x52/0x70<br /> [ 66.777946] kfree+0x13f/0x4b0<br /> [ 66.777949] dm_dp_mst_connector_destroy+0xfa/0x150 [amdgpu]<br /> [ 66.778179] drm_connector_free+0x7d/0xb0<br /> [ 66.778184] drm_mode_object_put.part.0+0xee/0x160<br /> [ 66.778188] drm_mode_object_put+0x37/0x50<br /> [ 66.778191] drm_atomic_state_default_clear+0x220/0xd60<br /> [ 66.778194] __drm_atomic_state_free+0x16e/0x2a0<br /> [ 66.778197] drm_mode_atomic_ioctl+0x15ed/0x2ba0<br /> [ 66.778200] drm_ioctl_kernel+0x17a/0x310<br /> [ 66.778203] drm_ioctl+0x584/0xd10<br /> [ 66.778206] amdgpu_drm_ioctl+0xd2/0x1c0 [amdgpu]<br /> [ 66.778375] __x64_sys_ioctl+0x139/0x1a0<br /> [ 66.778378] x64_sys_call+0xee7/0xfb0<br /> [ 66.778381] <br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix the inode leak in btrfs_iget()<br /> <br /> [BUG]<br /> There is a bug report that a syzbot reproducer can lead to the following<br /> busy inode at unmount time:<br /> <br /> BTRFS info (device loop1): last unmount of filesystem 1680000e-3c1e-4c46-84b6-56bd3909af50<br /> VFS: Busy inodes after unmount of loop1 (btrfs)<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/super.c:650!<br /> Oops: invalid opcode: 0000 [#1] SMP KASAN NOPTI<br /> CPU: 0 UID: 0 PID: 48168 Comm: syz-executor Not tainted 6.15.0-rc2-00471-g119009db2674 #2 PREEMPT(full)<br /> Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> RIP: 0010:generic_shutdown_super+0x2e9/0x390 fs/super.c:650<br /> Call Trace:<br /> <br /> kill_anon_super+0x3a/0x60 fs/super.c:1237<br /> btrfs_kill_super+0x3b/0x50 fs/btrfs/super.c:2099<br /> deactivate_locked_super+0xbe/0x1a0 fs/super.c:473<br /> deactivate_super fs/super.c:506 [inline]<br /> deactivate_super+0xe2/0x100 fs/super.c:502<br /> cleanup_mnt+0x21f/0x440 fs/namespace.c:1435<br /> task_work_run+0x14d/0x240 kernel/task_work.c:227<br /> resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]<br /> exit_to_user_mode_loop kernel/entry/common.c:114 [inline]<br /> exit_to_user_mode_prepare include/linux/entry-common.h:329 [inline]<br /> __syscall_exit_to_user_mode_work kernel/entry/common.c:207 [inline]<br /> syscall_exit_to_user_mode+0x269/0x290 kernel/entry/common.c:218<br /> do_syscall_64+0xd4/0x250 arch/x86/entry/syscall_64.c:100<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> <br /> [CAUSE]<br /> When btrfs_alloc_path() failed, btrfs_iget() directly returned without<br /> releasing the inode already allocated by btrfs_iget_locked().<br /> <br /> This results the above busy inode and trigger the kernel BUG.<br /> <br /> [FIX]<br /> Fix it by calling iget_failed() if btrfs_alloc_path() failed.<br /> <br /> If we hit error inside btrfs_read_locked_inode(), it will properly call<br /> iget_failed(), so nothing to worry about.<br /> <br /> Although the iget_failed() cleanup inside btrfs_read_locked_inode() is a<br /> break of the normal error handling scheme, let&amp;#39;s fix the obvious bug<br /> and backport first, then rework the error handling later.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> firmware: arm_scmi: Balance device refcount when destroying devices<br /> <br /> Using device_find_child() to lookup the proper SCMI device to destroy<br /> causes an unbalance in device refcount, since device_find_child() calls an<br /> implicit get_device(): this, in turns, inhibits the call of the provided<br /> release methods upon devices destruction.<br /> <br /> As a consequence, one of the structures that is not freed properly upon<br /> destruction is the internal struct device_private dev-&gt;p populated by the<br /> drivers subsystem core.<br /> <br /> KMemleak detects this situation since loading/unloding some SCMI driver<br /> causes related devices to be created/destroyed without calling any<br /> device_release method.<br /> <br /> unreferenced object 0xffff00000f583800 (size 512):<br /> comm "insmod", pid 227, jiffies 4294912190<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........<br /> ff ff ff ff ff ff ff ff 60 36 1d 8a 00 80 ff ff ........`6......<br /> backtrace (crc 114e2eed):<br /> kmemleak_alloc+0xbc/0xd8<br /> __kmalloc_cache_noprof+0x2dc/0x398<br /> device_add+0x954/0x12d0<br /> device_register+0x28/0x40<br /> __scmi_device_create.part.0+0x1bc/0x380<br /> scmi_device_create+0x2d0/0x390<br /> scmi_create_protocol_devices+0x74/0xf8<br /> scmi_device_request_notifier+0x1f8/0x2a8<br /> notifier_call_chain+0x110/0x3b0<br /> blocking_notifier_call_chain+0x70/0xb0<br /> scmi_driver_register+0x350/0x7f0<br /> 0xffff80000a3b3038<br /> do_one_initcall+0x12c/0x730<br /> do_init_module+0x1dc/0x640<br /> load_module+0x4b20/0x5b70<br /> init_module_from_file+0xec/0x158<br /> <br /> $ ./scripts/faddr2line ./vmlinux device_add+0x954/0x12d0<br /> device_add+0x954/0x12d0:<br /> kmalloc_noprof at include/linux/slab.h:901<br /> (inlined by) kzalloc_noprof at include/linux/slab.h:1037<br /> (inlined by) device_private_init at drivers/base/core.c:3510<br /> (inlined by) device_add at drivers/base/core.c:3561<br /> <br /> Balance device refcount by issuing a put_device() on devices found via<br /> device_find_child().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in session logoff<br /> <br /> The sess-&gt;user object can currently be in use by another thread, for<br /> example if another connection has sent a session setup request to<br /> bind to the session being free&amp;#39;d. The handler for that connection could<br /> be in the smb2_sess_setup function which makes use of sess-&gt;user.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

IBM Security ReaQta EDR 3.12 could allow an attacker to perform unauthorized actions due to improper SSL certificate validation.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: use sock_gen_put() when sk_state is TCP_TIME_WAIT<br /> <br /> It is possible for a pointer of type struct inet_timewait_sock to be<br /> returned from the functions __inet_lookup_established() and<br /> __inet6_lookup_established(). This can cause a crash when the<br /> returned pointer is of type struct inet_timewait_sock and<br /> sock_put() is called on it. The following is a crash call stack that<br /> shows sk-&gt;sk_wmem_alloc being accessed in sk_free() during the call to<br /> sock_put() on a struct inet_timewait_sock pointer. To avoid this issue,<br /> use sock_gen_put() instead of sock_put() when sk-&gt;sk_state<br /> is TCP_TIME_WAIT.<br /> <br /> mrdump.ko ipanic() + 120<br /> vmlinux notifier_call_chain(nr_to_call=-1, nr_calls=0) + 132<br /> vmlinux atomic_notifier_call_chain(val=0) + 56<br /> vmlinux panic() + 344<br /> vmlinux add_taint() + 164<br /> vmlinux end_report() + 136<br /> vmlinux kasan_report(size=0) + 236<br /> vmlinux report_tag_fault() + 16<br /> vmlinux do_tag_recovery() + 16<br /> vmlinux __do_kernel_fault() + 88<br /> vmlinux do_bad_area() + 28<br /> vmlinux do_tag_check_fault() + 60<br /> vmlinux do_mem_abort() + 80<br /> vmlinux el1_abort() + 56<br /> vmlinux el1h_64_sync_handler() + 124<br /> vmlinux &gt; 0xFFFFFFC080011294()<br /> vmlinux __lse_atomic_fetch_add_release(v=0xF2FFFF82A896087C)<br /> vmlinux __lse_atomic_fetch_sub_release(v=0xF2FFFF82A896087C)<br /> vmlinux arch_atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C)<br /> + 8<br /> vmlinux raw_atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C)<br /> + 8<br /> vmlinux atomic_fetch_sub_release(i=1, v=0xF2FFFF82A896087C) + 8<br /> vmlinux __refcount_sub_and_test(i=1, r=0xF2FFFF82A896087C,<br /> oldp=0) + 8<br /> vmlinux __refcount_dec_and_test(r=0xF2FFFF82A896087C, oldp=0) + 8<br /> vmlinux refcount_dec_and_test(r=0xF2FFFF82A896087C) + 8<br /> vmlinux sk_free(sk=0xF2FFFF82A8960700) + 28<br /> vmlinux sock_put() + 48<br /> vmlinux tcp6_check_fraglist_gro() + 236<br /> vmlinux tcp6_gro_receive() + 624<br /> vmlinux ipv6_gro_receive() + 912<br /> vmlinux dev_gro_receive() + 1116<br /> vmlinux napi_gro_receive() + 196<br /> ccmni.ko ccmni_rx_callback() + 208<br /> ccmni.ko ccmni_queue_recv_skb() + 388<br /> ccci_dpmaif.ko dpmaif_rxq_push_thread() + 1088<br /> vmlinux kthread() + 268<br /> vmlinux 0xFFFFFFC08001F30C()

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Fix error handling path in bnxt_init_chip()<br /> <br /> WARN_ON() is triggered in __flush_work() if bnxt_init_chip() fails<br /> because we call cancel_work_sync() on dim work that has not been<br /> initialized.<br /> <br /> WARNING: CPU: 37 PID: 5223 at kernel/workqueue.c:4201 __flush_work.isra.0+0x212/0x230<br /> <br /> The driver relies on the BNXT_STATE_NAPI_DISABLED bit to check if dim<br /> work has already been cancelled. But in the bnxt_open() path,<br /> BNXT_STATE_NAPI_DISABLED is not set and this causes the error<br /> path to think that it needs to cancel the uninitalized dim work.<br /> Fix it by setting BNXT_STATE_NAPI_DISABLED during initialization.<br /> The bit will be cleared when we enable NAPI and initialize dim work.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: spi-mem: Add fix to avoid divide error<br /> <br /> For some SPI flash memory operations, dummy bytes are not mandatory. For<br /> example, in Winbond SPINAND flash memory devices, the `write_cache` and<br /> `update_cache` operation variants have zero dummy bytes. Calculating the<br /> duration for SPI memory operations with zero dummy bytes causes<br /> a divide error when `ncycles` is calculated in the<br /> spi_mem_calc_op_duration().<br /> <br /> Add changes to skip the &amp;#39;ncylcles&amp;#39; calculation for zero dummy bytes.<br /> <br /> Following divide error is fixed by this change:<br /> <br /> Oops: divide error: 0000 [#1] PREEMPT SMP NOPTI<br /> ...<br /> <br /> ? do_trap+0xdb/0x100<br /> ? do_error_trap+0x75/0xb0<br /> ? spi_mem_calc_op_duration+0x56/0xb0<br /> ? exc_divide_error+0x3b/0x70<br /> ? spi_mem_calc_op_duration+0x56/0xb0<br /> ? asm_exc_divide_error+0x1b/0x20<br /> ? spi_mem_calc_op_duration+0x56/0xb0<br /> ? spinand_select_op_variant+0xee/0x190 [spinand]<br /> spinand_match_and_init+0x13e/0x1a0 [spinand]<br /> spinand_manufacturer_match+0x6e/0xa0 [spinand]<br /> spinand_probe+0x357/0x7f0 [spinand]<br /> ? kernfs_activate+0x87/0xd0<br /> spi_mem_probe+0x7a/0xb0<br /> spi_probe+0x7d/0x130

The vCenter Server contains an authenticated command-execution vulnerability. A malicious actor with privileges to create or modify alarms and run script action may exploit this issue to run arbitrary commands on the vCenter Server.