Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: Fix refcount leak for cifs_sb_tlink<br /> <br /> Fix three refcount inconsistency issues related to `cifs_sb_tlink`.<br /> <br /> Comments for `cifs_sb_tlink` state that `cifs_put_tlink()` needs to be<br /> called after successful calls to `cifs_sb_tlink()`. Three calls fail to<br /> update refcount accordingly, leading to possible resource leaks.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbevf: fix mailbox API compatibility by negotiating supported features<br /> <br /> There was backward compatibility in the terms of mailbox API. Various<br /> drivers from various OSes supporting 10G adapters from Intel portfolio<br /> could easily negotiate mailbox API.<br /> <br /> This convention has been broken since introducing API 1.4.<br /> Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added support<br /> for IPSec which is specific only for the kernel ixgbe driver. None of the<br /> rest of the Intel 10G PF/VF drivers supports it. And actually lack of<br /> support was not included in the IPSec implementation - there were no such<br /> code paths. No possibility to negotiate support for the feature was<br /> introduced along with introduction of the feature itself.<br /> <br /> Commit 339f28964147 ("ixgbevf: Add support for new mailbox communication<br /> between PF and VF") increasing API version to 1.5 did the same - it<br /> introduced code supported specifically by the PF ESX driver. It altered API<br /> version for the VF driver in the same time not touching the version<br /> defined for the PF ixgbe driver. It led to additional discrepancies,<br /> as the code provided within API 1.6 cannot be supported for Linux ixgbe<br /> driver as it causes crashes.<br /> <br /> The issue was noticed some time ago and mitigated by Jake within the commit<br /> d0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5").<br /> As a result we have regression for IPsec support and after increasing API<br /> to version 1.6 ixgbevf driver stopped to support ESX MBX.<br /> <br /> To fix this mess add new mailbox op asking PF driver about supported<br /> features. Basing on a response determine whether to set support for IPSec<br /> and ESX-specific enhanced mailbox.<br /> <br /> New mailbox op, for compatibility purposes, must be added within new API<br /> revision, as API version of OOT PF &amp; VF drivers is already increased to<br /> 1.6 and doesn&amp;#39;t incorporate features negotiate op.<br /> <br /> Features negotiation mechanism gives possibility to be extended with new<br /> features when needed in the future.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vfs: Don&amp;#39;t leak disconnected dentries on umount<br /> <br /> When user calls open_by_handle_at() on some inode that is not cached, we<br /> will create disconnected dentry for it. If such dentry is a directory,<br /> exportfs_decode_fh_raw() will then try to connect this dentry to the<br /> dentry tree through reconnect_path(). It may happen for various reasons<br /> (such as corrupted fs or race with rename) that the call to<br /> lookup_one_unlocked() in reconnect_one() will fail to find the dentry we<br /> are trying to reconnect and instead create a new dentry under the<br /> parent. Now this dentry will not be marked as disconnected although the<br /> parent still may well be disconnected (at least in case this<br /> inconsistency happened because the fs is corrupted and .. doesn&amp;#39;t point<br /> to the real parent directory). This creates inconsistency in<br /> disconnected flags but AFAICS it was mostly harmless. At least until<br /> commit f1ee616214cb ("VFS: don&amp;#39;t keep disconnected dentries on d_anon")<br /> which removed adding of most disconnected dentries to sb-&gt;s_anon list.<br /> Thus after this commit cleanup of disconnected dentries implicitely<br /> relies on the fact that dput() will immediately reclaim such dentries.<br /> However when some leaf dentry isn&amp;#39;t marked as disconnected, as in the<br /> scenario described above, the reclaim doesn&amp;#39;t happen and the dentries<br /> are "leaked". Memory reclaim can eventually reclaim them but otherwise<br /> they stay in memory and if umount comes first, we hit infamous "Busy<br /> inodes after unmount" bug. Make sure all dentries created under a<br /> disconnected parent are marked as disconnected as well.

*** Pendiente de traducción *** A vulnerability was identified in NeuVector, where the enforcer used environment variables CLUSTER_RPC_PORT and CLUSTER_LAN_PORT to generate a command to be executed via popen, without first sanitising their values.<br /> <br /> <br /> The entry process of the enforcer container is the monitor<br /> process. When the enforcer container stops, the monitor process checks <br /> whether the consul subprocess has exited. To perform this check, the <br /> monitor process uses the popen function to execute a shell command that determines whether the ports used by the consul subprocess are still active.<br /> <br /> <br /> The values of environment variables CLUSTER_RPC_PORT and CLUSTER_LAN_PORT<br /> are used directly to compose shell commands via popen without <br /> validation or sanitization. This behavior could allow a malicious user <br /> to inject malicious commands through these variables within the enforcer<br /> container.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda: Fix missing pointer check in hda_component_manager_init function<br /> <br /> The __component_match_add function may assign the &amp;#39;matchptr&amp;#39; pointer<br /> the value ERR_PTR(-ENOMEM), which will subsequently be dereferenced.<br /> <br /> The call stack leading to the error looks like this:<br /> <br /> hda_component_manager_init<br /> |-&gt; component_match_add<br /> |-&gt; component_match_add_release<br /> |-&gt; __component_match_add ( ... ,**matchptr, ... )<br /> |-&gt; *matchptr = ERR_PTR(-ENOMEM); // assign<br /> |-&gt; component_master_add_with_match( ... match)<br /> |-&gt; component_match_realloc(match, match-&gt;num); // dereference<br /> <br /> Add IS_ERR() check to prevent the crash.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with SVACE.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Define a proc_layoutcommit for the FlexFiles layout type<br /> <br /> Avoid a crash if a pNFS client should happen to send a LAYOUTCOMMIT<br /> operation on a FlexFiles layout.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> hfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()<br /> <br /> The hfsplus_strcasecmp() logic can trigger the issue:<br /> <br /> [ 117.317703][ T9855] ==================================================================<br /> [ 117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490<br /> [ 117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855<br /> [ 117.319577][ T9855]<br /> [ 117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full)<br /> [ 117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014<br /> [ 117.319783][ T9855] Call Trace:<br /> [ 117.319785][ T9855] <br /> [ 117.319788][ T9855] dump_stack_lvl+0x1c1/0x2a0<br /> [ 117.319795][ T9855] ? __virt_addr_valid+0x1c8/0x5c0<br /> [ 117.319803][ T9855] ? __pfx_dump_stack_lvl+0x10/0x10<br /> [ 117.319808][ T9855] ? rcu_is_watching+0x15/0xb0<br /> [ 117.319816][ T9855] ? lock_release+0x4b/0x3e0<br /> [ 117.319821][ T9855] ? __kasan_check_byte+0x12/0x40<br /> [ 117.319828][ T9855] ? __virt_addr_valid+0x1c8/0x5c0<br /> [ 117.319835][ T9855] ? __virt_addr_valid+0x4a5/0x5c0<br /> [ 117.319842][ T9855] print_report+0x17e/0x7e0<br /> [ 117.319848][ T9855] ? __virt_addr_valid+0x1c8/0x5c0<br /> [ 117.319855][ T9855] ? __virt_addr_valid+0x4a5/0x5c0<br /> [ 117.319862][ T9855] ? __phys_addr+0xd3/0x180<br /> [ 117.319869][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490<br /> [ 117.319876][ T9855] kasan_report+0x147/0x180<br /> [ 117.319882][ T9855] ? hfsplus_strcasecmp+0x1bc/0x490<br /> [ 117.319891][ T9855] hfsplus_strcasecmp+0x1bc/0x490<br /> [ 117.319900][ T9855] ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10<br /> [ 117.319906][ T9855] hfs_find_rec_by_key+0xa9/0x1e0<br /> [ 117.319913][ T9855] __hfsplus_brec_find+0x18e/0x470<br /> [ 117.319920][ T9855] ? __pfx_hfsplus_bnode_find+0x10/0x10<br /> [ 117.319926][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10<br /> [ 117.319933][ T9855] ? __pfx___hfsplus_brec_find+0x10/0x10<br /> [ 117.319942][ T9855] hfsplus_brec_find+0x28f/0x510<br /> [ 117.319949][ T9855] ? __pfx_hfs_find_rec_by_key+0x10/0x10<br /> [ 117.319956][ T9855] ? __pfx_hfsplus_brec_find+0x10/0x10<br /> [ 117.319963][ T9855] ? __kmalloc_noprof+0x2a9/0x510<br /> [ 117.319969][ T9855] ? hfsplus_find_init+0x8c/0x1d0<br /> [ 117.319976][ T9855] hfsplus_brec_read+0x2b/0x120<br /> [ 117.319983][ T9855] hfsplus_lookup+0x2aa/0x890<br /> [ 117.319990][ T9855] ? __pfx_hfsplus_lookup+0x10/0x10<br /> [ 117.320003][ T9855] ? d_alloc_parallel+0x2f0/0x15e0<br /> [ 117.320008][ T9855] ? __lock_acquire+0xaec/0xd80<br /> [ 117.320013][ T9855] ? __pfx_d_alloc_parallel+0x10/0x10<br /> [ 117.320019][ T9855] ? __raw_spin_lock_init+0x45/0x100<br /> [ 117.320026][ T9855] ? __init_waitqueue_head+0xa9/0x150<br /> [ 117.320034][ T9855] __lookup_slow+0x297/0x3d0<br /> [ 117.320039][ T9855] ? __pfx___lookup_slow+0x10/0x10<br /> [ 117.320045][ T9855] ? down_read+0x1ad/0x2e0<br /> [ 117.320055][ T9855] lookup_slow+0x53/0x70<br /> [ 117.320065][ T9855] walk_component+0x2f0/0x430<br /> [ 117.320073][ T9855] path_lookupat+0x169/0x440<br /> [ 117.320081][ T9855] filename_lookup+0x212/0x590<br /> [ 117.320089][ T9855] ? __pfx_filename_lookup+0x10/0x10<br /> [ 117.320098][ T9855] ? strncpy_from_user+0x150/0x290<br /> [ 117.320105][ T9855] ? getname_flags+0x1e5/0x540<br /> [ 117.320112][ T9855] user_path_at+0x3a/0x60<br /> [ 117.320117][ T9855] __x64_sys_umount+0xee/0x160<br /> [ 117.320123][ T9855] ? __pfx___x64_sys_umount+0x10/0x10<br /> [ 117.320129][ T9855] ? do_syscall_64+0xb7/0x3a0<br /> [ 117.320135][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 117.320141][ T9855] ? entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 117.320145][ T9855] do_syscall_64+0xf3/0x3a0<br /> [ 117.320150][ T9855] ? exc_page_fault+0x9f/0xf0<br /> [ 117.320154][ T9855] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> [ 117.320158][ T9855] RIP: 0033:0x7f7dd7908b07<br /> [ 117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08<br /> [ 117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202 <br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cxl/features: Add check for no entries in cxl_feature_info<br /> <br /> cxl EDAC calls cxl_feature_info() to get the feature information and<br /> if the hardware has no Features support, cxlfs may be passed in as<br /> NULL.<br /> <br /> [ 51.957498] BUG: kernel NULL pointer dereference, address: 0000000000000008<br /> [ 51.965571] #PF: supervisor read access in kernel mode<br /> [ 51.971559] #PF: error_code(0x0000) - not-present page<br /> [ 51.977542] PGD 17e4f6067 P4D 0<br /> [ 51.981384] Oops: Oops: 0000 [#1] SMP NOPTI<br /> [ 51.986300] CPU: 49 UID: 0 PID: 3782 Comm: systemd-udevd Not tainted 6.17.0dj<br /> test+ #64 PREEMPT(voluntary)<br /> [ 51.997355] Hardware name: <br /> [ 52.009790] RIP: 0010:cxl_feature_info+0xa/0x80 [cxl_core]<br /> <br /> Add a check for cxlfs before dereferencing it and return -EOPNOTSUPP if<br /> there is no cxlfs created due to no hardware support.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ixgbe: fix too early devlink_free() in ixgbe_remove()<br /> <br /> Since ixgbe_adapter is embedded in devlink, calling devlink_free()<br /> prematurely in the ixgbe_remove() path can lead to UAF. Move devlink_free()<br /> to the end.<br /> <br /> KASAN report:<br /> <br /> BUG: KASAN: use-after-free in ixgbe_reset_interrupt_capability+0x140/0x180 [ixgbe]<br /> Read of size 8 at addr ffff0000adf813e0 by task bash/2095<br /> CPU: 1 UID: 0 PID: 2095 Comm: bash Tainted: G S 6.17.0-rc2-tnguy.net-queue+ #1 PREEMPT(full)<br /> [...]<br /> Call trace:<br /> show_stack+0x30/0x90 (C)<br /> dump_stack_lvl+0x9c/0xd0<br /> print_address_description.constprop.0+0x90/0x310<br /> print_report+0x104/0x1f0<br /> kasan_report+0x88/0x180<br /> __asan_report_load8_noabort+0x20/0x30<br /> ixgbe_reset_interrupt_capability+0x140/0x180 [ixgbe]<br /> ixgbe_clear_interrupt_scheme+0xf8/0x130 [ixgbe]<br /> ixgbe_remove+0x2d0/0x8c0 [ixgbe]<br /> pci_device_remove+0xa0/0x220<br /> device_remove+0xb8/0x170<br /> device_release_driver_internal+0x318/0x490<br /> device_driver_detach+0x40/0x68<br /> unbind_store+0xec/0x118<br /> drv_attr_store+0x64/0xb8<br /> sysfs_kf_write+0xcc/0x138<br /> kernfs_fop_write_iter+0x294/0x440<br /> new_sync_write+0x1fc/0x588<br /> vfs_write+0x480/0x6a0<br /> ksys_write+0xf0/0x1e0<br /> __arm64_sys_write+0x70/0xc0<br /> invoke_syscall.constprop.0+0xcc/0x280<br /> el0_svc_common.constprop.0+0xa8/0x248<br /> do_el0_svc+0x44/0x68<br /> el0_svc+0x54/0x160<br /> el0t_64_sync_handler+0xa0/0xe8<br /> el0t_64_sync+0x1b0/0x1b8

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_ncm: Refactor bind path to use __free()<br /> <br /> After an bind/unbind cycle, the ncm-&gt;notify_req is left stale. If a<br /> subsequent bind fails, the unified error label attempts to free this<br /> stale request, leading to a NULL pointer dereference when accessing<br /> ep-&gt;ops-&gt;free_request.<br /> <br /> Refactor the error handling in the bind path to use the __free()<br /> automatic cleanup mechanism.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020<br /> Call trace:<br /> usb_ep_free_request+0x2c/0xec<br /> ncm_bind+0x39c/0x3dc<br /> usb_add_function+0xcc/0x1f0<br /> configfs_composite_bind+0x468/0x588<br /> gadget_bind_driver+0x104/0x270<br /> really_probe+0x190/0x374<br /> __driver_probe_device+0xa0/0x12c<br /> driver_probe_device+0x3c/0x218<br /> __device_attach_driver+0x14c/0x188<br /> bus_for_each_drv+0x10c/0x168<br /> __device_attach+0xfc/0x198<br /> device_initial_probe+0x14/0x24<br /> bus_probe_device+0x94/0x11c<br /> device_add+0x268/0x48c<br /> usb_add_gadget+0x198/0x28c<br /> dwc3_gadget_init+0x700/0x858<br /> __dwc3_set_mode+0x3cc/0x664<br /> process_scheduled_works+0x1d8/0x488<br /> worker_thread+0x244/0x334<br /> kthread+0x114/0x1bc<br /> ret_from_fork+0x10/0x20

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_ecm: Refactor bind path to use __free()<br /> <br /> After an bind/unbind cycle, the ecm-&gt;notify_req is left stale. If a<br /> subsequent bind fails, the unified error label attempts to free this<br /> stale request, leading to a NULL pointer dereference when accessing<br /> ep-&gt;ops-&gt;free_request.<br /> <br /> Refactor the error handling in the bind path to use the __free()<br /> automatic cleanup mechanism.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_acm: Refactor bind path to use __free()<br /> <br /> After an bind/unbind cycle, the acm-&gt;notify_req is left stale. If a<br /> subsequent bind fails, the unified error label attempts to free this<br /> stale request, leading to a NULL pointer dereference when accessing<br /> ep-&gt;ops-&gt;free_request.<br /> <br /> Refactor the error handling in the bind path to use the __free()<br /> automatic cleanup mechanism.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020<br /> Call trace:<br /> usb_ep_free_request+0x2c/0xec<br /> gs_free_req+0x30/0x44<br /> acm_bind+0x1b8/0x1f4<br /> usb_add_function+0xcc/0x1f0<br /> configfs_composite_bind+0x468/0x588<br /> gadget_bind_driver+0x104/0x270<br /> really_probe+0x190/0x374<br /> __driver_probe_device+0xa0/0x12c<br /> driver_probe_device+0x3c/0x218<br /> __device_attach_driver+0x14c/0x188<br /> bus_for_each_drv+0x10c/0x168<br /> __device_attach+0xfc/0x198<br /> device_initial_probe+0x14/0x24<br /> bus_probe_device+0x94/0x11c<br /> device_add+0x268/0x48c<br /> usb_add_gadget+0x198/0x28c<br /> dwc3_gadget_init+0x700/0x858<br /> __dwc3_set_mode+0x3cc/0x664<br /> process_scheduled_works+0x1d8/0x488<br /> worker_thread+0x244/0x334<br /> kthread+0x114/0x1bc<br /> ret_from_fork+0x10/0x20