Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> platform/x86/amd/hsmp: Ensure sock-&gt;metric_tbl_addr is non-NULL<br /> <br /> If metric table address is not allocated, accessing metrics_bin will<br /> result in a NULL pointer dereference, so add a check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/nouveau/nvif: Fix potential memory leak in nvif_vmm_ctor().<br /> <br /> When the nvif_vmm_type is invalid, we will return error directly<br /> without freeing the args in nvif_vmm_ctor(), which leading a memory<br /> leak. Fix it by setting the ret -EINVAL and goto done.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i2c: rtl9300: Fix out-of-bounds bug in rtl9300_i2c_smbus_xfer<br /> <br /> The data-&gt;block[0] variable comes from user. Without proper check,<br /> the variable may be very large to cause an out-of-bounds bug.<br /> <br /> Fix this bug by checking the value of data-&gt;block[0] first.<br /> <br /> 1. commit 39244cc75482 ("i2c: ismt: Fix an out-of-bounds bug in<br /> ismt_access()")<br /> 2. commit 92fbb6d1296f ("i2c: xgene-slimpro: Fix out-of-bounds bug in<br /> xgene_slimpro_i2c_xfer()")

*** 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 /> 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: 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 /> 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: 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 /> 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 *** 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 /> 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 *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gve: prevent ethtool ops after shutdown<br /> <br /> A crash can occur if an ethtool operation is invoked<br /> after shutdown() is called.<br /> <br /> shutdown() is invoked during system shutdown to stop DMA operations<br /> without performing expensive deallocations. It is discouraged to<br /> unregister the netdev in this path, so the device may still be visible<br /> to userspace and kernel helpers.<br /> <br /> In gve, shutdown() tears down most internal data structures. If an<br /> ethtool operation is dispatched after shutdown(), it will dereference<br /> freed or NULL pointers, leading to a kernel panic. While graceful<br /> shutdown normally quiesces userspace before invoking the reboot<br /> syscall, forced shutdowns (as observed on GCP VMs) can still trigger<br /> this path.<br /> <br /> Fix by calling netif_device_detach() in shutdown().<br /> This marks the device as detached so the ethtool ioctl handler<br /> will skip dispatching operations to the driver.