Vulnerabilidades

*** Pendiente de traducción *** 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.

*** Pendiente de traducción *** 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)

*** Pendiente de traducción *** 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

*** Pendiente de traducción *** 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---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix error handling in the init_task on load<br /> <br /> If the init_task fails during a driver load, we end up without vports and<br /> netdevs, effectively failing the entire process. In that state a<br /> subsequent reset will result in a crash as the service task attempts to<br /> access uninitialized resources. Following trace is from an error in the<br /> init_task where the CREATE_VPORT (op 501) is rejected by the FW:<br /> <br /> [40922.763136] idpf 0000:83:00.0: Device HW Reset initiated<br /> [40924.449797] idpf 0000:83:00.0: Transaction failed (op 501)<br /> [40958.148190] idpf 0000:83:00.0: HW reset detected<br /> [40958.161202] BUG: kernel NULL pointer dereference, address: 00000000000000a8<br /> ...<br /> [40958.168094] Workqueue: idpf-0000:83:00.0-vc_event idpf_vc_event_task [idpf]<br /> [40958.168865] RIP: 0010:idpf_vc_event_task+0x9b/0x350 [idpf]<br /> ...<br /> [40958.177932] Call Trace:<br /> [40958.178491] <br /> [40958.179040] process_one_work+0x226/0x6d0<br /> [40958.179609] worker_thread+0x19e/0x340<br /> [40958.180158] ? __pfx_worker_thread+0x10/0x10<br /> [40958.180702] kthread+0x10f/0x250<br /> [40958.181238] ? __pfx_kthread+0x10/0x10<br /> [40958.181774] ret_from_fork+0x251/0x2b0<br /> [40958.182307] ? __pfx_kthread+0x10/0x10<br /> [40958.182834] ret_from_fork_asm+0x1a/0x30<br /> [40958.183370] <br /> <br /> Fix the error handling in the init_task to make sure the service and<br /> mailbox tasks are disabled if the error happens during load. These are<br /> started in idpf_vc_core_init(), which spawns the init_task and has no way<br /> of knowing if it failed. If the error happens on reset, following<br /> successful driver load, the tasks can still run, as that will allow the<br /> netdevs to attempt recovery through another reset. Stop the PTP callbacks<br /> either way as those will be restarted by the call to idpf_vc_core_init()<br /> during a successful reset.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: release path before initializing extent tree in btrfs_read_locked_inode()<br /> <br /> In btrfs_read_locked_inode() we are calling btrfs_init_file_extent_tree()<br /> while holding a path with a read locked leaf from a subvolume tree, and<br /> btrfs_init_file_extent_tree() may do a GFP_KERNEL allocation, which can<br /> trigger reclaim.<br /> <br /> This can create a circular lock dependency which lockdep warns about with<br /> the following splat:<br /> <br /> [6.1433] ======================================================<br /> [6.1574] WARNING: possible circular locking dependency detected<br /> [6.1583] 6.18.0+ #4 Tainted: G U<br /> [6.1591] ------------------------------------------------------<br /> [6.1599] kswapd0/117 is trying to acquire lock:<br /> [6.1606] ffff8d9b6333c5b8 (&amp;delayed_node-&gt;mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node.part.0+0x39/0x2f0<br /> [6.1625]<br /> but task is already holding lock:<br /> [6.1633] ffffffffa4ab8ce0 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat+0x195/0xc60<br /> [6.1646]<br /> which lock already depends on the new lock.<br /> <br /> [6.1657]<br /> the existing dependency chain (in reverse order) is:<br /> [6.1667]<br /> -&gt; #2 (fs_reclaim){+.+.}-{0:0}:<br /> [6.1677] fs_reclaim_acquire+0x9d/0xd0<br /> [6.1685] __kmalloc_cache_noprof+0x59/0x750<br /> [6.1694] btrfs_init_file_extent_tree+0x90/0x100<br /> [6.1702] btrfs_read_locked_inode+0xc3/0x6b0<br /> [6.1710] btrfs_iget+0xbb/0xf0<br /> [6.1716] btrfs_lookup_dentry+0x3c5/0x8e0<br /> [6.1724] btrfs_lookup+0x12/0x30<br /> [6.1731] lookup_open.isra.0+0x1aa/0x6a0<br /> [6.1739] path_openat+0x5f7/0xc60<br /> [6.1746] do_filp_open+0xd6/0x180<br /> [6.1753] do_sys_openat2+0x8b/0xe0<br /> [6.1760] __x64_sys_openat+0x54/0xa0<br /> [6.1768] do_syscall_64+0x97/0x3e0<br /> [6.1776] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [6.1784]<br /> -&gt; #1 (btrfs-tree-00){++++}-{3:3}:<br /> [6.1794] lock_release+0x127/0x2a0<br /> [6.1801] up_read+0x1b/0x30<br /> [6.1808] btrfs_search_slot+0x8e0/0xff0<br /> [6.1817] btrfs_lookup_inode+0x52/0xd0<br /> [6.1825] __btrfs_update_delayed_inode+0x73/0x520<br /> [6.1833] btrfs_commit_inode_delayed_inode+0x11a/0x120<br /> [6.1842] btrfs_log_inode+0x608/0x1aa0<br /> [6.1849] btrfs_log_inode_parent+0x249/0xf80<br /> [6.1857] btrfs_log_dentry_safe+0x3e/0x60<br /> [6.1865] btrfs_sync_file+0x431/0x690<br /> [6.1872] do_fsync+0x39/0x80<br /> [6.1879] __x64_sys_fsync+0x13/0x20<br /> [6.1887] do_syscall_64+0x97/0x3e0<br /> [6.1894] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> [6.1903]<br /> -&gt; #0 (&amp;delayed_node-&gt;mutex){+.+.}-{3:3}:<br /> [6.1913] __lock_acquire+0x15e9/0x2820<br /> [6.1920] lock_acquire+0xc9/0x2d0<br /> [6.1927] __mutex_lock+0xcc/0x10a0<br /> [6.1934] __btrfs_release_delayed_node.part.0+0x39/0x2f0<br /> [6.1944] btrfs_evict_inode+0x20b/0x4b0<br /> [6.1952] evict+0x15a/0x2f0<br /> [6.1958] prune_icache_sb+0x91/0xd0<br /> [6.1966] super_cache_scan+0x150/0x1d0<br /> [6.1974] do_shrink_slab+0x155/0x6f0<br /> [6.1981] shrink_slab+0x48e/0x890<br /> [6.1988] shrink_one+0x11a/0x1f0<br /> [6.1995] shrink_node+0xbfd/0x1320<br /> [6.1002] balance_pgdat+0x67f/0xc60<br /> [6.1321] kswapd+0x1dc/0x3e0<br /> [6.1643] kthread+0xff/0x240<br /> [6.1965] ret_from_fork+0x223/0x280<br /> [6.1287] ret_from_fork_asm+0x1a/0x30<br /> [6.1616]<br /> other info that might help us debug this:<br /> <br /> [6.1561] Chain exists of:<br /> &amp;delayed_node-&gt;mutex --&gt; btrfs-tree-00 --&gt; fs_reclaim<br /> <br /> [6.1503] Possible unsafe locking scenario:<br /> <br /> [6.1110] CPU0 CPU1<br /> [6.1411] ---- ----<br /> [6.1707] lock(fs_reclaim);<br /> [6.1998] lock(btrfs-tree-00);<br /> [6.1291] lock(fs_reclaim);<br /> [6.1581] lock(&amp;del<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: marvell: prestera: fix NULL dereference on devlink_alloc() failure<br /> <br /> devlink_alloc() may return NULL on allocation failure, but<br /> prestera_devlink_alloc() unconditionally calls devlink_priv() on<br /> the returned pointer.<br /> <br /> This leads to a NULL pointer dereference if devlink allocation fails.<br /> Add a check for a NULL devlink pointer and return NULL early to avoid<br /> the crash.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: 3com: 3c59x: fix possible null dereference in vortex_probe1()<br /> <br /> pdev can be null and free_ring: can be called in 1297 with a null<br /> pdev.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: pegasus: fix memory leak in update_eth_regs_async()<br /> <br /> When asynchronously writing to the device registers and if usb_submit_urb()<br /> fail, the code fail to release allocated to this point resources.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix memory leak in idpf_vc_core_deinit()<br /> <br /> Make sure to free hw-&gt;lan_regs. Reported by kmemleak during reset:<br /> <br /> unreferenced object 0xff1b913d02a936c0 (size 96):<br /> comm "kworker/u258:14", pid 2174, jiffies 4294958305<br /> hex dump (first 32 bytes):<br /> 00 00 00 c0 a8 ba 2d ff 00 00 00 00 00 00 00 00 ......-.........<br /> 00 00 40 08 00 00 00 00 00 00 25 b3 a8 ba 2d ff ..@.......%...-.<br /> backtrace (crc 36063c4f):<br /> __kmalloc_noprof+0x48f/0x890<br /> idpf_vc_core_init+0x6ce/0x9b0 [idpf]<br /> idpf_vc_event_task+0x1fb/0x350 [idpf]<br /> process_one_work+0x226/0x6d0<br /> worker_thread+0x19e/0x340<br /> kthread+0x10f/0x250<br /> ret_from_fork+0x251/0x2b0<br /> ret_from_fork_asm+0x1a/0x30

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix memory leak in idpf_vport_rel()<br /> <br /> Free vport-&gt;rx_ptype_lkup in idpf_vport_rel() to avoid leaking memory<br /> during a reset. Reported by kmemleak:<br /> <br /> unreferenced object 0xff450acac838a000 (size 4096):<br /> comm "kworker/u258:5", pid 7732, jiffies 4296830044<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 10 00 00 00 10 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 ................<br /> backtrace (crc 3da81902):<br /> __kmalloc_cache_noprof+0x469/0x7a0<br /> idpf_send_get_rx_ptype_msg+0x90/0x570 [idpf]<br /> idpf_init_task+0x1ec/0x8d0 [idpf]<br /> process_one_work+0x226/0x6d0<br /> worker_thread+0x19e/0x340<br /> kthread+0x10f/0x250<br /> ret_from_fork+0x251/0x2b0<br /> ret_from_fork_asm+0x1a/0x30

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> idpf: fix memory leak of flow steer list on rmmod<br /> <br /> The flow steering list maintains entries that are added and removed as<br /> ethtool creates and deletes flow steering rules. Module removal with active<br /> entries causes memory leak as the list is not properly cleaned up.<br /> <br /> Prevent this by iterating through the remaining entries in the list and<br /> freeing the associated memory during module removal. Add a spinlock<br /> (flow_steer_list_lock) to protect the list access from multiple threads.