Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pnfs/flexfiles: Fix memory leak in nfs4_ff_alloc_deviceid_node()<br /> <br /> In nfs4_ff_alloc_deviceid_node(), if the allocation for ds_versions fails,<br /> the function jumps to the out_scratch label without freeing the already<br /> allocated dsaddrs list, leading to a memory leak.<br /> <br /> Fix this by jumping to the out_err_drain_dsaddrs label, which properly<br /> frees the dsaddrs list before cleaning up other resources.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gud: fix NULL fb and crtc dereferences on USB disconnect<br /> <br /> On disconnect drm_atomic_helper_disable_all() is called which<br /> sets both the fb and crtc for a plane to NULL before invoking a commit.<br /> <br /> This causes a kernel oops on every display disconnect.<br /> <br /> Add guards for those dereferences.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: KVM: Fix kvm_device leak in kvm_pch_pic_destroy()<br /> <br /> In kvm_ioctl_create_device(), kvm_device has allocated memory,<br /> kvm_device-&gt;destroy() seems to be supposed to free its kvm_device<br /> struct, but kvm_pch_pic_destroy() is not currently doing this, that<br /> would lead to a memory leak.<br /> <br /> So, fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: KVM: Fix kvm_device leak in kvm_ipi_destroy()<br /> <br /> In kvm_ioctl_create_device(), kvm_device has allocated memory,<br /> kvm_device-&gt;destroy() seems to be supposed to free its kvm_device<br /> struct, but kvm_ipi_destroy() is not currently doing this, that<br /> would lead to a memory leak.<br /> <br /> So, fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> LoongArch: KVM: Fix kvm_device leak in kvm_eiointc_destroy()<br /> <br /> In kvm_ioctl_create_device(), kvm_device has allocated memory,<br /> kvm_device-&gt;destroy() seems to be supposed to free its kvm_device<br /> struct, but kvm_eiointc_destroy() is not currently doing this, that<br /> would lead to a memory leak.<br /> <br /> So, fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> phy: rockchip: inno-usb2: Fix a double free bug in rockchip_usb2phy_probe()<br /> <br /> The for_each_available_child_of_node() calls of_node_put() to<br /> release child_np in each success loop. After breaking from the<br /> loop with the child_np has been released, the code will jump to<br /> the put_child label and will call the of_node_put() again if the<br /> devm_request_threaded_irq() fails. These cause a double free bug.<br /> <br /> Fix by returning directly to avoid the duplicate of_node_put().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> can: gs_usb: gs_usb_receive_bulk_callback(): fix URB memory leak<br /> <br /> In gs_can_open(), the URBs for USB-in transfers are allocated, added to the<br /> parent-&gt;rx_submitted anchor and submitted. In the complete callback<br /> gs_usb_receive_bulk_callback(), the URB is processed and resubmitted. In<br /> gs_can_close() the URBs are freed by calling<br /> usb_kill_anchored_urbs(parent-&gt;rx_submitted).<br /> <br /> However, this does not take into account that the USB framework unanchors<br /> the URB before the complete function is called. This means that once an<br /> in-URB has been completed, it is no longer anchored and is ultimately not<br /> released in gs_can_close().<br /> <br /> Fix the memory leak by anchoring the URB in the<br /> gs_usb_receive_bulk_callback() to the parent-&gt;rx_submitted anchor.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> null_blk: fix kmemleak by releasing references to fault configfs items<br /> <br /> When CONFIG_BLK_DEV_NULL_BLK_FAULT_INJECTION is enabled, the null-blk<br /> driver sets up fault injection support by creating the timeout_inject,<br /> requeue_inject, and init_hctx_fault_inject configfs items as children<br /> of the top-level nullbX configfs group.<br /> <br /> However, when the nullbX device is removed, the references taken to<br /> these fault-config configfs items are not released. As a result,<br /> kmemleak reports a memory leak, for example:<br /> <br /> unreferenced object 0xc00000021ff25c40 (size 32):<br /> comm "mkdir", pid 10665, jiffies 4322121578<br /> hex dump (first 32 bytes):<br /> 69 6e 69 74 5f 68 63 74 78 5f 66 61 75 6c 74 5f init_hctx_fault_<br /> 69 6e 6a 65 63 74 00 88 00 00 00 00 00 00 00 00 inject..........<br /> backtrace (crc 1a018c86):<br /> __kmalloc_node_track_caller_noprof+0x494/0xbd8<br /> kvasprintf+0x74/0xf4<br /> config_item_set_name+0xf0/0x104<br /> config_group_init_type_name+0x48/0xfc<br /> fault_config_init+0x48/0xf0<br /> 0xc0080000180559e4<br /> configfs_mkdir+0x304/0x814<br /> vfs_mkdir+0x49c/0x604<br /> do_mkdirat+0x314/0x3d0<br /> sys_mkdir+0xa0/0xd8<br /> system_call_exception+0x1b0/0x4f0<br /> system_call_vectored_common+0x15c/0x2ec<br /> <br /> Fix this by explicitly releasing the references to the fault-config<br /> configfs items when dropping the reference to the top-level nullbX<br /> configfs group.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> dmaengine: omap-dma: fix dma_pool resource leak in error paths<br /> <br /> The dma_pool created by dma_pool_create() is not destroyed when<br /> dma_async_device_register() or of_dma_controller_register() fails,<br /> causing a resource leak in the probe error paths.<br /> <br /> Add dma_pool_destroy() in both error paths to properly release the<br /> allocated dma_pool resource.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/userq: Fix fence reference leak on queue teardown v2<br /> <br /> The user mode queue keeps a pointer to the most recent fence in<br /> userq-&gt;last_fence. This pointer holds an extra dma_fence reference.<br /> <br /> When the queue is destroyed, we free the fence driver and its xarray,<br /> but we forgot to drop the last_fence reference.<br /> <br /> Because of the missing dma_fence_put(), the last fence object can stay<br /> alive when the driver unloads. This leaves an allocated object in the<br /> amdgpu_userq_fence slab cache and triggers<br /> <br /> This is visible during driver unload as:<br /> <br /> BUG amdgpu_userq_fence: Objects remaining on __kmem_cache_shutdown()<br /> kmem_cache_destroy amdgpu_userq_fence: Slab cache still has objects<br /> Call Trace:<br /> kmem_cache_destroy<br /> amdgpu_userq_fence_slab_fini<br /> amdgpu_exit<br /> __do_sys_delete_module<br /> <br /> Fix this by putting userq-&gt;last_fence and clearing the pointer during<br /> amdgpu_userq_fence_driver_free().<br /> <br /> This makes sure the fence reference is released and the slab cache is<br /> empty when the module exits.<br /> <br /> v2: Update to only release userq-&gt;last_fence with dma_fence_put()<br /> (Christian)<br /> <br /> (cherry picked from commit 8e051e38a8d45caf6a866d4ff842105b577953bb)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Pass netdev to mlx5e_destroy_netdev instead of priv<br /> <br /> mlx5e_priv is an unstable structure that can be memset(0) if profile<br /> attaching fails.<br /> <br /> Pass netdev to mlx5e_destroy_netdev() to guarantee it will work on a<br /> valid netdev.<br /> <br /> On mlx5e_remove: Check validity of priv-&gt;profile, before attempting<br /> to cleanup any resources that might be not there.<br /> <br /> This fixes a kernel oops in mlx5e_remove when switchdev mode fails due<br /> to change profile failure.<br /> <br /> $ devlink dev eswitch set pci/0000:00:03.0 mode switchdev<br /> Error: mlx5_core: Failed setting eswitch to offloads.<br /> dmesg:<br /> workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12<br /> mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12<br /> workqueue: Failed to create a rescuer kthread for wq "mlx5e": -EINTR<br /> mlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12<br /> mlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12<br /> <br /> $ devlink dev reload pci/0000:00:03.0 ==&gt; oops<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000370<br /> PGD 0 P4D 0<br /> Oops: Oops: 0000 [#1] SMP NOPTI<br /> CPU: 15 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc5+ #115 PREEMPT(voluntary)<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014<br /> RIP: 0010:mlx5e_dcbnl_dscp_app+0x23/0x100<br /> RSP: 0018:ffffc9000083f8b8 EFLAGS: 00010286<br /> RAX: ffff8881126fc380 RBX: ffff8881015ac400 RCX: ffffffff826ffc45<br /> RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881035109c0<br /> RBP: ffff8881035109c0 R08: ffff888101e3e838 R09: ffff888100264e10<br /> R10: ffffc9000083f898 R11: ffffc9000083f8a0 R12: ffff888101b921a0<br /> R13: ffff888101b921a0 R14: ffff8881015ac9a0 R15: ffff8881015ac400<br /> FS: 00007f789a3c8740(0000) GS:ffff88856aa59000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000370 CR3: 000000010b6c0001 CR4: 0000000000370ef0<br /> Call Trace:<br /> <br /> mlx5e_remove+0x57/0x110<br /> device_release_driver_internal+0x19c/0x200<br /> bus_remove_device+0xc6/0x130<br /> device_del+0x160/0x3d0<br /> ? devl_param_driverinit_value_get+0x2d/0x90<br /> mlx5_detach_device+0x89/0xe0<br /> mlx5_unload_one_devl_locked+0x3a/0x70<br /> mlx5_devlink_reload_down+0xc8/0x220<br /> devlink_reload+0x7d/0x260<br /> devlink_nl_reload_doit+0x45b/0x5a0<br /> genl_family_rcv_msg_doit+0xe8/0x140

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: release path before iget_failed() in btrfs_read_locked_inode()<br /> <br /> In btrfs_read_locked_inode() if we fail to lookup the inode, we jump to<br /> the &amp;#39;out&amp;#39; label with a path that has a read locked leaf and then we call<br /> iget_failed(). This can result in a ABBA deadlock, since iget_failed()<br /> triggers inode eviction and that causes the release of the delayed inode,<br /> which must lock the delayed inode&amp;#39;s mutex, and a task updating a delayed<br /> inode starts by taking the node&amp;#39;s mutex and then modifying the inode&amp;#39;s<br /> subvolume btree.<br /> <br /> Syzbot reported the following lockdep splat for this:<br /> <br /> ======================================================<br /> WARNING: possible circular locking dependency detected<br /> syzkaller #0 Not tainted<br /> ------------------------------------------------------<br /> btrfs-cleaner/8725 is trying to acquire lock:<br /> ffff0000d6826a48 (&amp;delayed_node-&gt;mutex){+.+.}-{4:4}, at: __btrfs_release_delayed_node+0xa0/0x9b0 fs/btrfs/delayed-inode.c:290<br /> <br /> but task is already holding lock:<br /> ffff0000dbeba878 (btrfs-tree-00){++++}-{4:4}, at: btrfs_tree_read_lock_nested+0x44/0x2ec fs/btrfs/locking.c:145<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #1 (btrfs-tree-00){++++}-{4:4}:<br /> __lock_release kernel/locking/lockdep.c:5574 [inline]<br /> lock_release+0x198/0x39c kernel/locking/lockdep.c:5889<br /> up_read+0x24/0x3c kernel/locking/rwsem.c:1632<br /> btrfs_tree_read_unlock+0xdc/0x298 fs/btrfs/locking.c:169<br /> btrfs_tree_unlock_rw fs/btrfs/locking.h:218 [inline]<br /> btrfs_search_slot+0xa6c/0x223c fs/btrfs/ctree.c:2133<br /> btrfs_lookup_inode+0xd8/0x38c fs/btrfs/inode-item.c:395<br /> __btrfs_update_delayed_inode+0x124/0xed0 fs/btrfs/delayed-inode.c:1032<br /> btrfs_update_delayed_inode fs/btrfs/delayed-inode.c:1118 [inline]<br /> __btrfs_commit_inode_delayed_items+0x15f8/0x1748 fs/btrfs/delayed-inode.c:1141<br /> __btrfs_run_delayed_items+0x1ac/0x514 fs/btrfs/delayed-inode.c:1176<br /> btrfs_run_delayed_items_nr+0x28/0x38 fs/btrfs/delayed-inode.c:1219<br /> flush_space+0x26c/0xb68 fs/btrfs/space-info.c:828<br /> do_async_reclaim_metadata_space+0x110/0x364 fs/btrfs/space-info.c:1158<br /> btrfs_async_reclaim_metadata_space+0x90/0xd8 fs/btrfs/space-info.c:1226<br /> process_one_work+0x7e8/0x155c kernel/workqueue.c:3263<br /> process_scheduled_works kernel/workqueue.c:3346 [inline]<br /> worker_thread+0x958/0xed8 kernel/workqueue.c:3427<br /> kthread+0x5fc/0x75c kernel/kthread.c:463<br /> ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:844<br /> <br /> -&gt; #0 (&amp;delayed_node-&gt;mutex){+.+.}-{4:4}:<br /> check_prev_add kernel/locking/lockdep.c:3165 [inline]<br /> check_prevs_add kernel/locking/lockdep.c:3284 [inline]<br /> validate_chain kernel/locking/lockdep.c:3908 [inline]<br /> __lock_acquire+0x1774/0x30a4 kernel/locking/lockdep.c:5237<br /> lock_acquire+0x14c/0x2e0 kernel/locking/lockdep.c:5868<br /> __mutex_lock_common+0x1d0/0x2678 kernel/locking/mutex.c:598<br /> __mutex_lock kernel/locking/mutex.c:760 [inline]<br /> mutex_lock_nested+0x2c/0x38 kernel/locking/mutex.c:812<br /> __btrfs_release_delayed_node+0xa0/0x9b0 fs/btrfs/delayed-inode.c:290<br /> btrfs_release_delayed_node fs/btrfs/delayed-inode.c:315 [inline]<br /> btrfs_remove_delayed_node+0x68/0x84 fs/btrfs/delayed-inode.c:1326<br /> btrfs_evict_inode+0x578/0xe28 fs/btrfs/inode.c:5587<br /> evict+0x414/0x928 fs/inode.c:810<br /> iput_final fs/inode.c:1914 [inline]<br /> iput+0x95c/0xad4 fs/inode.c:1966<br /> iget_failed+0xec/0x134 fs/bad_inode.c:248<br /> btrfs_read_locked_inode+0xe1c/0x1234 fs/btrfs/inode.c:4101<br /> btrfs_iget+0x1b0/0x264 fs/btrfs/inode.c:5837<br /> btrfs_run_defrag_inode fs/btrfs/defrag.c:237 [inline]<br /> btrfs_run_defrag_inodes+0x520/0xdc4 fs/btrf<br /> ---truncated---