Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> accel/ivpu: Fix locking order in ivpu_job_submit<br /> <br /> Fix deadlock in job submission and abort handling.<br /> When a thread aborts currently executing jobs due to a fault,<br /> it first locks the global lock protecting submitted_jobs (#1).<br /> <br /> After the last job is destroyed, it proceeds to release the related context<br /> and locks file_priv (#2). Meanwhile, in the job submission thread,<br /> the file_priv lock (#2) is taken first, and then the submitted_jobs<br /> lock (#1) is obtained when a job is added to the submitted jobs list.<br /> <br /> CPU0 CPU1<br /> ---- ----<br /> (for example due to a fault) (jobs submissions keep coming)<br /> <br /> lock(&amp;vdev-&gt;submitted_jobs_lock) #1<br /> ivpu_jobs_abort_all()<br /> job_destroy()<br /> lock(&amp;file_priv-&gt;lock) #2<br /> lock(&amp;vdev-&gt;submitted_jobs_lock) #1<br /> file_priv_release()<br /> lock(&amp;vdev-&gt;context_list_lock)<br /> lock(&amp;file_priv-&gt;lock) #2<br /> <br /> This order of locking causes a deadlock. To resolve this issue,<br /> change the order of locking in ivpu_job_submit().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: ets: Fix double list add in class with netem as child qdisc<br /> <br /> As described in Gerrard&amp;#39;s report [1], there are use cases where a netem<br /> child qdisc will make the parent qdisc&amp;#39;s enqueue callback reentrant.<br /> In the case of ets, there won&amp;#39;t be a UAF, but the code will add the same<br /> classifier to the list twice, which will cause memory corruption.<br /> <br /> In addition to checking for qlen being zero, this patch checks whether<br /> the class was already added to the active_list (cl_is_active) before<br /> doing the addition to cater for the reentrant case.<br /> <br /> [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net_sched: qfq: Fix double list add in class with netem as child qdisc<br /> <br /> As described in Gerrard&amp;#39;s report [1], there are use cases where a netem<br /> child qdisc will make the parent qdisc&amp;#39;s enqueue callback reentrant.<br /> In the case of qfq, there won&amp;#39;t be a UAF, but the code will add the same<br /> classifier to the list twice, which will cause memory corruption.<br /> <br /> This patch checks whether the class was already added to the agg-&gt;active<br /> list (cl_is_active) before doing the addition to cater for the reentrant<br /> case.<br /> <br /> [1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ublk: fix race between io_uring_cmd_complete_in_task and ublk_cancel_cmd<br /> <br /> ublk_cancel_cmd() calls io_uring_cmd_done() to complete uring_cmd, but<br /> we may have scheduled task work via io_uring_cmd_complete_in_task() for<br /> dispatching request, then kernel crash can be triggered.<br /> <br /> Fix it by not trying to canceling the command if ublk block request is<br /> started.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: Check VF VSI Pointer Value in ice_vc_add_fdir_fltr()<br /> <br /> As mentioned in the commit baeb705fd6a7 ("ice: always check VF VSI<br /> pointer values"), we need to perform a null pointer check on the return<br /> value of ice_get_vf_vsi() before using it.

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

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 /> wifi: plfxlc: Remove erroneous assert in plfxlc_mac_release<br /> <br /> plfxlc_mac_release() asserts that mac-&gt;lock is held. This assertion is<br /> incorrect, because even if it was possible, it would not be the valid<br /> behaviour. The function is used when probe fails or after the device is<br /> disconnected. In both cases mac-&gt;lock can not be held as the driver is<br /> not working with the device at the moment. All functions that use mac-&gt;lock<br /> unlock it just after it was held. There is also no need to hold mac-&gt;lock<br /> for plfxlc_mac_release() itself, as mac data is not affected, except for<br /> mac-&gt;flags, which is modified atomically.<br /> <br /> This bug leads to the following warning:<br /> ================================================================<br /> WARNING: CPU: 0 PID: 127 at drivers/net/wireless/purelifi/plfxlc/mac.c:106 plfxlc_mac_release+0x7d/0xa0<br /> Modules linked in:<br /> CPU: 0 PID: 127 Comm: kworker/0:2 Not tainted 6.1.124-syzkaller #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024<br /> Workqueue: usb_hub_wq hub_event<br /> RIP: 0010:plfxlc_mac_release+0x7d/0xa0 drivers/net/wireless/purelifi/plfxlc/mac.c:106<br /> Call Trace:<br /> <br /> probe+0x941/0xbd0 drivers/net/wireless/purelifi/plfxlc/usb.c:694<br /> usb_probe_interface+0x5c0/0xaf0 drivers/usb/core/driver.c:396<br /> really_probe+0x2ab/0xcb0 drivers/base/dd.c:639<br /> __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785<br /> driver_probe_device+0x50/0x420 drivers/base/dd.c:815<br /> __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943<br /> bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429<br /> __device_attach+0x359/0x570 drivers/base/dd.c:1015<br /> bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489<br /> device_add+0xb48/0xfd0 drivers/base/core.c:3696<br /> usb_set_configuration+0x19dd/0x2020 drivers/usb/core/message.c:2165<br /> usb_generic_driver_probe+0x84/0x140 drivers/usb/core/generic.c:238<br /> usb_probe_device+0x130/0x260 drivers/usb/core/driver.c:293<br /> really_probe+0x2ab/0xcb0 drivers/base/dd.c:639<br /> __driver_probe_device+0x1a2/0x3d0 drivers/base/dd.c:785<br /> driver_probe_device+0x50/0x420 drivers/base/dd.c:815<br /> __device_attach_driver+0x2cf/0x510 drivers/base/dd.c:943<br /> bus_for_each_drv+0x183/0x200 drivers/base/bus.c:429<br /> __device_attach+0x359/0x570 drivers/base/dd.c:1015<br /> bus_probe_device+0xba/0x1e0 drivers/base/bus.c:489<br /> device_add+0xb48/0xfd0 drivers/base/core.c:3696<br /> usb_new_device+0xbdd/0x18f0 drivers/usb/core/hub.c:2620<br /> hub_port_connect drivers/usb/core/hub.c:5477 [inline]<br /> hub_port_connect_change drivers/usb/core/hub.c:5617 [inline]<br /> port_event drivers/usb/core/hub.c:5773 [inline]<br /> hub_event+0x2efe/0x5730 drivers/usb/core/hub.c:5855<br /> process_one_work+0x8a9/0x11d0 kernel/workqueue.c:2292<br /> worker_thread+0xa47/0x1200 kernel/workqueue.c:2439<br /> kthread+0x28d/0x320 kernel/kthread.c:376<br /> ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295<br /> <br /> ================================================================<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> powerpc64/ftrace: fix module loading without patchable function entries<br /> <br /> get_stubs_size assumes that there must always be at least one patchable<br /> function entry, which is not always the case (modules that export data<br /> but no code), otherwise it returns -ENOEXEC and thus the section header<br /> sh_size is set to that value. During module_memory_alloc() the size is<br /> passed to execmem_alloc() after being page-aligned and thus set to zero<br /> which will cause it to fail the allocation (and thus module loading) as<br /> __vmalloc_node_range() checks for zero-sized allocs and returns null:<br /> <br /> [ 115.466896] module_64: cast_common: doesn&amp;#39;t contain __patchable_function_entries.<br /> [ 115.469189] ------------[ cut here ]------------<br /> [ 115.469496] WARNING: CPU: 0 PID: 274 at mm/vmalloc.c:3778 __vmalloc_node_range_noprof+0x8b4/0x8f0<br /> ...<br /> [ 115.478574] ---[ end trace 0000000000000000 ]---<br /> [ 115.479545] execmem: unable to allocate memory<br /> <br /> Fix this by removing the check completely, since it is anyway not<br /> helpful to propagate this as an error upwards.