Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/cpu/hygon: Add missing resctrl_cpu_detect() in bsp_init helper<br /> <br /> Since<br /> <br /> 923f3a2b48bd ("x86/resctrl: Query LLC monitoring properties once during boot")<br /> <br /> resctrl_cpu_detect() has been moved from common CPU initialization code to<br /> the vendor-specific BSP init helper, while Hygon didn&amp;#39;t put that call in their<br /> code.<br /> <br /> This triggers a division by zero fault during early booting stage on our<br /> machines with X86_FEATURE_CQM* supported, where get_rdt_mon_resources() tries<br /> to calculate mon_l3_config with uninitialized boot_cpu_data.x86_cache_occ_scale.<br /> <br /> Add the missing resctrl_cpu_detect() in the Hygon BSP init helper.<br /> <br /> [ bp: Massage commit message. ]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tls: fix handling of zero-length records on the rx_list<br /> <br /> Each recvmsg() call must process either<br /> - only contiguous DATA records (any number of them)<br /> - one non-DATA record<br /> <br /> If the next record has different type than what has already been<br /> processed we break out of the main processing loop. If the record<br /> has already been decrypted (which may be the case for TLS 1.3 where<br /> we don&amp;#39;t know type until decryption) we queue the pending record<br /> to the rx_list. Next recvmsg() will pick it up from there.<br /> <br /> Queuing the skb to rx_list after zero-copy decrypt is not possible,<br /> since in that case we decrypted directly to the user space buffer,<br /> and we don&amp;#39;t have an skb to queue (darg.skb points to the ciphertext<br /> skb for access to metadata like length).<br /> <br /> Only data records are allowed zero-copy, and we break the processing<br /> loop after each non-data record. So we should never zero-copy and<br /> then find out that the record type has changed. The corner case<br /> we missed is when the initial record comes from rx_list, and it&amp;#39;s<br /> zero length.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tracing: Limit access to parser-&gt;buffer when trace_get_user failed<br /> <br /> When the length of the string written to set_ftrace_filter exceeds<br /> FTRACE_BUFF_MAX, the following KASAN alarm will be triggered:<br /> <br /> BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0<br /> Read of size 1 at addr ffff0000d00bd5ba by task ash/165<br /> <br /> CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty<br /> Hardware name: linux,dummy-virt (DT)<br /> Call trace:<br /> show_stack+0x34/0x50 (C)<br /> dump_stack_lvl+0xa0/0x158<br /> print_address_description.constprop.0+0x88/0x398<br /> print_report+0xb0/0x280<br /> kasan_report+0xa4/0xf0<br /> __asan_report_load1_noabort+0x20/0x30<br /> strsep+0x18c/0x1b0<br /> ftrace_process_regex.isra.0+0x100/0x2d8<br /> ftrace_regex_release+0x484/0x618<br /> __fput+0x364/0xa58<br /> ____fput+0x28/0x40<br /> task_work_run+0x154/0x278<br /> do_notify_resume+0x1f0/0x220<br /> el0_svc+0xec/0xf0<br /> el0t_64_sync_handler+0xa0/0xe8<br /> el0t_64_sync+0x1ac/0x1b0<br /> <br /> The reason is that trace_get_user will fail when processing a string<br /> longer than FTRACE_BUFF_MAX, but not set the end of parser-&gt;buffer to 0.<br /> Then an OOB access will be triggered in ftrace_regex_release-&gt;<br /> ftrace_process_regex-&gt;strsep-&gt;strpbrk. We can solve this problem by<br /> limiting access to parser-&gt;buffer when trace_get_user failed.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> cifs: Fix oops due to uninitialised variable<br /> <br /> Fix smb3_init_transform_rq() to initialise buffer to NULL before calling<br /> netfs_alloc_folioq_buffer() as netfs assumes it can append to the buffer it<br /> is given. Setting it to NULL means it should start a fresh buffer, but the<br /> value is currently undefined.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ppp: fix race conditions in ppp_fill_forward_path<br /> <br /> ppp_fill_forward_path() has two race conditions:<br /> <br /> 1. The ppp-&gt;channels list can change between list_empty() and<br /> list_first_entry(), as ppp_lock() is not held. If the only channel<br /> is deleted in ppp_disconnect_channel(), list_first_entry() may<br /> access an empty head or a freed entry, and trigger a panic.<br /> <br /> 2. pch-&gt;chan can be NULL. When ppp_unregister_channel() is called,<br /> pch-&gt;chan is set to NULL before pch is removed from ppp-&gt;channels.<br /> <br /> Fix these by using a lockless RCU approach:<br /> - Use list_first_or_null_rcu() to safely test and access the first list<br /> entry.<br /> - Convert list modifications on ppp-&gt;channels to their RCU variants and<br /> add synchronize_net() after removal.<br /> - Check for a NULL pch-&gt;chan before dereferencing it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: ufs-qcom: Fix ESI null pointer dereference<br /> <br /> ESI/MSI is a performance optimization feature that provides dedicated<br /> interrupts per MCQ hardware queue. This is optional feature and UFS MCQ<br /> should work with and without ESI feature.<br /> <br /> Commit e46a28cea29a ("scsi: ufs: qcom: Remove the MSI descriptor abuse")<br /> brings a regression in ESI (Enhanced System Interrupt) configuration that<br /> causes a null pointer dereference when Platform MSI allocation fails.<br /> <br /> The issue occurs in when platform_device_msi_init_and_alloc_irqs() in<br /> ufs_qcom_config_esi() fails (returns -EINVAL) but the current code uses<br /> __free() macro for automatic cleanup free MSI resources that were never<br /> successfully allocated.<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual<br /> address 0000000000000008<br /> <br /> Call trace:<br /> mutex_lock+0xc/0x54 (P)<br /> platform_device_msi_free_irqs_all+0x1c/0x40<br /> ufs_qcom_config_esi+0x1d0/0x220 [ufs_qcom]<br /> ufshcd_config_mcq+0x28/0x104<br /> ufshcd_init+0xa3c/0xf40<br /> ufshcd_pltfrm_init+0x504/0x7d4<br /> ufs_qcom_probe+0x20/0x58 [ufs_qcom]<br /> <br /> Fix by restructuring the ESI configuration to try MSI allocation first,<br /> before any other resource allocation and instead use explicit cleanup<br /> instead of __free() macro to avoid cleanup of unallocated resources.<br /> <br /> Tested on SM8750 platform with MCQ enabled, both with and without<br /> Platform ESI support.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Add null pointer check in mod_hdcp_hdcp1_create_session()<br /> <br /> The function mod_hdcp_hdcp1_create_session() calls the function<br /> get_first_active_display(), but does not check its return value.<br /> The return value is a null pointer if the display list is empty.<br /> This will lead to a null pointer dereference.<br /> <br /> Add a null pointer check for get_first_active_display() and return<br /> MOD_HDCP_STATUS_DISPLAY_NOT_FOUND if the function return null.<br /> <br /> This is similar to the commit c3e9826a2202<br /> ("drm/amd/display: Add null pointer check for get_first_active_display()").<br /> <br /> (cherry picked from commit 5e43eb3cd731649c4f8b9134f857be62a416c893)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: qla4xxx: Prevent a potential error pointer dereference<br /> <br /> The qla4xxx_get_ep_fwdb() function is supposed to return NULL on error,<br /> but qla4xxx_ep_connect() returns error pointers. Propagating the error<br /> pointers will lead to an Oops in the caller, so change the error pointers<br /> to NULL.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: usb: asix_devices: Fix PHY address mask in MDIO bus initialization<br /> <br /> Syzbot reported shift-out-of-bounds exception on MDIO bus initialization.<br /> <br /> The PHY address should be masked to 5 bits (0-31). Without this<br /> mask, invalid PHY addresses could be used, potentially causing issues<br /> with MDIO bus operations.<br /> <br /> Fix this by masking the PHY address with 0x1f (31 decimal) to ensure<br /> it stays within the valid range.

*** Pendiente de traducción *** PTZOptics and possibly other ValueHD-based pan-tilt-zoom cameras use default, shared credentials for the administrative web interface.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/xe: Fix vm_bind_ioctl double free bug<br /> <br /> If the argument check during an array bind fails, the bind_ops are freed<br /> twice as seen below. Fix this by setting bind_ops to NULL after freeing.<br /> <br /> ==================================================================<br /> BUG: KASAN: double-free in xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> Free of addr ffff88813bb9b800 by task xe_vm/14198<br /> <br /> CPU: 5 UID: 0 PID: 14198 Comm: xe_vm Not tainted 6.16.0-xe-eudebug-cmanszew+ #520 PREEMPT(full)<br /> Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS ADLPFWI1.R00.2411.A02.2110081023 10/08/2021<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x82/0xd0<br /> print_report+0xcb/0x610<br /> ? __virt_addr_valid+0x19a/0x300<br /> ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> kasan_report_invalid_free+0xc8/0xf0<br /> ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> check_slab_allocation+0x102/0x130<br /> kfree+0x10d/0x440<br /> ? should_fail_ex+0x57/0x2f0<br /> ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]<br /> ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]<br /> ? __lock_acquire+0xab9/0x27f0<br /> ? lock_acquire+0x165/0x300<br /> ? drm_dev_enter+0x53/0xe0 [drm]<br /> ? find_held_lock+0x2b/0x80<br /> ? drm_dev_exit+0x30/0x50 [drm]<br /> ? drm_ioctl_kernel+0x128/0x1c0 [drm]<br /> drm_ioctl_kernel+0x128/0x1c0 [drm]<br /> ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]<br /> ? find_held_lock+0x2b/0x80<br /> ? __pfx_drm_ioctl_kernel+0x10/0x10 [drm]<br /> ? should_fail_ex+0x57/0x2f0<br /> ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]<br /> drm_ioctl+0x352/0x620 [drm]<br /> ? __pfx_drm_ioctl+0x10/0x10 [drm]<br /> ? __pfx_rpm_resume+0x10/0x10<br /> ? do_raw_spin_lock+0x11a/0x1b0<br /> ? find_held_lock+0x2b/0x80<br /> ? __pm_runtime_resume+0x61/0xc0<br /> ? rcu_is_watching+0x20/0x50<br /> ? trace_irq_enable.constprop.0+0xac/0xe0<br /> xe_drm_ioctl+0x91/0xc0 [xe]<br /> __x64_sys_ioctl+0xb2/0x100<br /> ? rcu_is_watching+0x20/0x50<br /> do_syscall_64+0x68/0x2e0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7fa9acb24ded<br /> <br /> (cherry picked from commit a01b704527c28a2fd43a17a85f8996b75ec8492a)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netfilter: nf_reject: don&amp;#39;t leak dst refcount for loopback packets<br /> <br /> recent patches to add a WARN() when replacing skb dst entry found an<br /> old bug:<br /> <br /> WARNING: include/linux/skbuff.h:1165 skb_dst_check_unset include/linux/skbuff.h:1164 [inline]<br /> WARNING: include/linux/skbuff.h:1165 skb_dst_set include/linux/skbuff.h:1210 [inline]<br /> WARNING: include/linux/skbuff.h:1165 nf_reject_fill_skb_dst+0x2a4/0x330 net/ipv4/netfilter/nf_reject_ipv4.c:234<br /> [..]<br /> Call Trace:<br /> nf_send_unreach+0x17b/0x6e0 net/ipv4/netfilter/nf_reject_ipv4.c:325<br /> nft_reject_inet_eval+0x4bc/0x690 net/netfilter/nft_reject_inet.c:27<br /> expr_call_ops_eval net/netfilter/nf_tables_core.c:237 [inline]<br /> ..<br /> <br /> This is because blamed commit forgot about loopback packets.<br /> Such packets already have a dst_entry attached, even at PRE_ROUTING stage.<br /> <br /> Instead of checking hook just check if the skb already has a route<br /> attached to it.