Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Add upper bound check for num_of_nodes<br /> <br /> drm/amdkfd: Add upper bound check for num_of_nodes<br /> in kfd_ioctl_get_process_apertures_new.<br /> <br /> (cherry picked from commit 98ff46a5ea090c14d2cdb4f5b993b05d74f3949f)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/vce: Prevent partial address patches<br /> <br /> In the case that only one of lo/hi is valid, the patching could result<br /> in a bad address written to in FW.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: zero-initialize GART table on allocation<br /> <br /> GART TLB is flushed after unmapping but not after mapping. Since<br /> amdgpu_bo_create_kernel() does not zero-initialize the buffer, when a<br /> single PTE is written the TLB may speculatively load other uninitialized<br /> entries from the same cacheline. Those garbage entries can appear valid,<br /> and a subsequent write to another PTE in the same cacheline may cause the<br /> GPU to use a stale garbage PTE from the TLB.<br /> <br /> Fix this by calling memset_io() to zero-initialize the GART table with<br /> gart_pte_flags immediately after allocation.<br /> <br /> Using AMDGPU_GEM_CREATE_VRAM_CLEARED, SDMA-based clear will not work<br /> since SDMA needs GART to be initialized to work.<br /> <br /> (cherry picked from commit d9af8263b82b6eaa60c5718e0c6631c5037e4b24)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm/vma: do not try to unmap a VMA if mmap_prepare() invoked from mmap()<br /> <br /> The mmap_prepare hook functionality includes the ability to invoke<br /> mmap_prepare() from the mmap() hook of existing &amp;#39;stacked&amp;#39; drivers, that is<br /> ones which are capable of calling the mmap hooks of other drivers/file<br /> systems (e.g. overlayfs, shm).<br /> <br /> As part of the mmap_prepare action functionality, we deal with errors by<br /> unmapping the VMA should one arise. This works in the usual mmap_prepare<br /> case, as we invoke this action at the last moment, when the VMA is<br /> established in the maple tree.<br /> <br /> However, the mmap() hook passes a not-fully-established VMA pointer to the<br /> caller (which is the motivation behind the mmap_prepare() work), which is<br /> detached.<br /> <br /> So attempting to unmap a VMA in this state will be problematic, with the<br /> most obvious symptom being a warning in vma_mark_detached(), because the<br /> VMA is already detached.<br /> <br /> It&amp;#39;s also unncessary - the mmap() handler will clean up the VMA on error.<br /> <br /> So to fix this issue, this patch propagates whether or not an mmap action<br /> is being completed via the compatibility layer or directly.<br /> <br /> If the former, then we do not attempt VMA cleanup, if the latter, then we<br /> do.<br /> <br /> This patch also updates the userland VMA tests to reflect the change.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/colorop: Fix blob property reference tracking in state lifecycle<br /> <br /> The colorop state blob property handling had memory leaks during state<br /> duplication, destruction, and reset operations. The implementation<br /> failed to follow the established pattern from drm_crtc&amp;#39;s handling of<br /> DEGAMMA/GAMMA blob properties.<br /> <br /> Issues fixed:<br /> - drm_colorop_atomic_destroy_state() was freeing state memory without<br /> releasing the blob reference, causing a leak<br /> - drm_colorop_reset() was directly freeing old state with kfree()<br /> instead of properly destroying it, leaking blob references<br /> - drm_colorop_cleanup() had duplicate blob cleanup code<br /> <br /> Changes:<br /> - Add __drm_atomic_helper_colorop_destroy_state() helper to properly<br /> release blob references before freeing state memory<br /> - Update drm_colorop_atomic_destroy_state() to call the helper<br /> - Fix drm_colorop_reset() to use drm_colorop_atomic_destroy_state()<br /> for proper cleanup of old state<br /> - Simplify drm_colorop_cleanup() to use the common destruction path<br /> <br /> This matches the well-tested pattern used by drm_crtc since 2016 and<br /> ensures proper reference counting throughout the state lifecycle.<br /> <br /> Co-developed by Claude Sonnet 4.5.

*** Pendiente de traducción *** A vulnerability was detected in SourceCodester Class and Exam Timetabling System 1.0. Affected is an unknown function of the file /edit_schoolyr.php. Performing a manipulation of the argument ID results in sql injection. It is possible to initiate the attack remotely. The exploit is now public and may be used.

*** Pendiente de traducción *** A flaw has been found in itsourcecode Courier Management System up to 1.0. Affected by this vulnerability is an unknown functionality of the file /index.php. Executing a manipulation of the argument page can lead to cross site scripting. It is possible to launch the attack remotely. The exploit has been published and may be used.

*** Pendiente de traducción *** A security vulnerability has been detected in SourceCodester Class and Exam Timetabling System 1.0. This impacts an unknown function of the file /edit_subject.php. Such manipulation of the argument ID leads to sql injection. The attack may be performed from remote. The exploit has been disclosed publicly and may be used.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/vt-d: Block PASID attachment to nested domain with dirty tracking<br /> <br /> Kernel lacks dirty tracking support on nested domain attached to PASID,<br /> fails the attachment early if nesting parent domain is dirty tracking<br /> configured, otherwise dirty pages would be lost.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/ionic: bound node_desc sysfs read with %.64s<br /> <br /> node_desc[64] in struct ib_device is not guaranteed to be NUL-<br /> terminated. The core IB sysfs handler uses "%.64s" for exactly this<br /> reason (drivers/infiniband/core/sysfs.c:1307), since node_desc_store()<br /> performs a raw memcpy of up to IB_DEVICE_NODE_DESC_MAX bytes with no NUL<br /> termination:<br /> <br /> memcpy(desc.node_desc, buf, min_t(int, count, IB_DEVICE_NODE_DESC_MAX));<br /> <br /> If exactly 64 bytes are written via the node_desc sysfs file, the array<br /> contains no NUL byte. The ionic hca_type_show() handler uses unbounded<br /> "%s" and will read past the end of node_desc into adjacent fields of<br /> struct ib_device until it encounters a NUL.<br /> <br /> ionic supports IB_DEVICE_MODIFY_NODE_DESC, so this is triggerable by<br /> userspace.<br /> <br /> Match the core handler and bound the format specifier.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/intel: Improve validation and configuration of ACR masks<br /> <br /> Currently there are several issues on the user space ACR mask validation<br /> and configuration.<br /> - The validation for user space ACR mask (attr.config2) is incomplete,<br /> e.g., the ACR mask could include the index which belongs to another<br /> ACR events group, but it&amp;#39;s not validated.<br /> - An early return on an invalid ACR mask caused all subsequent ACR groups<br /> to be skipped.<br /> - The stale hardware ACR mask (hw.config1) is not cleared before setting<br /> new hardware ACR mask.<br /> <br /> The following changes address all of the above issues.<br /> - Figure out the event index group of an ACR group. Any bits in the<br /> user-space mask not present in the index group are now dropped.<br /> - Instead of an early return on invalid bits, drop only the invalid<br /> portions and continue iterating through all ACR events to ensure full<br /> configuration.<br /> - Explicitly clear the stale hardware ACR mask for each event prior to<br /> writing the new configuration.<br /> <br /> Besides, a non-leader event member of ACR group could be disabled in<br /> theory. This could cause bit-shifting errors in the acr_mask of remaining<br /> group members. But since ACR sampling requires all events to be active,<br /> this should not be a big concern in real use case. Add a "FIXME" comment<br /> to notice this risk.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> udf: reject descriptors with oversized CRC length<br /> <br /> udf_read_tagged() skips CRC verification when descCRCLength +<br /> sizeof(struct tag) exceeds the block size. A crafted UDF image can<br /> set descCRCLength to an oversized value to bypass CRC validation<br /> entirely; the descriptor is then accepted based solely on the 8-bit<br /> tag checksum, which is trivially recomputable.<br /> <br /> Reject such descriptors instead of silently accepting them. A<br /> legitimate single-block descriptor should never have a CRC length that<br /> exceeds the block.