Vulnerabilidades

*** Pendiente de traducción *** SEPPmail Secure Email Gateway before version 15.0.4 fails to enforce authorization checks for multiple endpoints in the new GINA UI, allowing unauthenticated remote attackers to access functionality that should require a valid session.

*** Pendiente de traducción *** SEPPmail Secure Email Gateway before version 15.0.4 insecurely deserializes untrusted data, which can be reached from the new GINA UI and may allow unauthenticated remote attackers to execute code via a crafted serialized object.

*** Pendiente de traducción *** SEPPmail Secure Email Gateway before version 15.0.4 contains an unauthenticated path traversal vulnerability in the identifier parameter of /api.app/attachment/preview that allows remote attackers to read arbitrary local files and trigger deletion of files in the targeted directory with the privileges of the api.app process.

*** Pendiente de traducción *** SEPPmail Secure Email Gateway before version 15.0.2.1 allows unauthenticated remote code execution in the new GINA UI because an endpoint passes attacker-controlled input from a parameter to Perl's eval.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: client: require a full NFS mode SID before reading mode bits<br /> <br /> parse_dacl() treats an ACE SID matching sid_unix_NFS_mode as an NFS<br /> mode SID and reads sid.sub_auth[2] to recover the mode bits.<br /> <br /> That assumes the ACE carries three subauthorities, but compare_sids()<br /> only compares min(a, b) subauthorities. A malicious server can return<br /> an ACE with num_subauth = 2 and sub_auth[] = {88, 3}, which still<br /> matches sid_unix_NFS_mode and then drives the sub_auth[2] read four<br /> bytes past the end of the ACE.<br /> <br /> Require num_subauth &gt;= 3 before treating the ACE as an NFS mode SID.<br /> This keeps the fix local to the special-SID mode path without changing<br /> compare_sids() semantics for the rest of cifsacl.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/ipv6: ioam6: prevent schema length wraparound in trace fill<br /> <br /> ioam6_fill_trace_data() stores the schema contribution to the trace<br /> length in a u8. With bit 22 enabled and the largest schema payload,<br /> sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the<br /> remaining-space check. __ioam6_fill_trace_data() then positions the<br /> write cursor without reserving the schema area but still copies the<br /> 4-byte schema header and the full schema payload, overrunning the trace<br /> buffer.<br /> <br /> Keep sclen in an unsigned int so the remaining-space check and the write<br /> cursor calculation both see the full schema length.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: ipa: fix event ring index not programmed for IPA v5.0+<br /> <br /> For IPA v5.0+, the event ring index field moved from CH_C_CNTXT_0 to<br /> CH_C_CNTXT_1. The v5.0 register definition intended to define this<br /> field in the CH_C_CNTXT_1 fmask array but used the old identifier of<br /> ERINDEX instead of CH_ERINDEX.<br /> <br /> Without a valid event ring, GSI channels could never signal transfer<br /> completions. This caused gsi_channel_trans_quiesce() to block<br /> forever in wait_for_completion().<br /> <br /> At least for IPA v5.2 this resolves an issue seen where runtime<br /> suspend, system suspend, and remoteproc stop all hanged forever. It<br /> also meant the IPA data path was completely non functional.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ice: ptp: don&amp;#39;t WARN when controlling PF is unavailable<br /> <br /> In VFIO passthrough setups, it is possible to pass through only a PF<br /> which doesn&amp;#39;t own the source timer. In that case the PTP controlling PF<br /> (adapter-&gt;ctrl_pf) is never initialized in the VM, so ice_get_ctrl_ptp()<br /> returns NULL and triggers WARN_ON() in ice_ptp_setup_pf().<br /> <br /> Since this is an expected behavior in that configuration, replace<br /> WARN_ON() with an informational message and return -EOPNOTSUPP.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> arm64: dts: qcom: monaco: Reserve full Gunyah metadata region<br /> <br /> We observe spurious "Synchronous External Abort" exceptions<br /> (ESR=0x96000010) and kernel crashes on Monaco-based platforms.<br /> These faults are caused by the kernel inadvertently accessing<br /> hypervisor-owned memory that is not properly marked as reserved.<br /> <br /> &gt;From boot log, The Qualcomm hypervisor reports the memory range<br /> at 0x91a80000 of size 0x80000 (512 KiB) as hypervisor-owned:<br /> qhee_hyp_assign_remove_memory: 0x91a80000/0x80000 -&gt; ret 0<br /> <br /> However, the EFI memory map provided by firmware only reserves the<br /> subrange 0x91a40000–0x91a87fff (288 KiB). The remaining portion<br /> (0x91a88000–0x91afffff) is incorrectly reported as conventional<br /> memory (from efi debug):<br /> efi: 0x000091a40000-0x000091a87fff [Reserved...]<br /> efi: 0x000091a88000-0x0000938fffff [Conventional...]<br /> <br /> As a result, the allocator may hand out PFNs inside the hypervisor<br /> owned region, causing fatal aborts when the kernel accesses those<br /> addresses.<br /> <br /> Add a reserved-memory carveout for the Gunyah hypervisor metadata<br /> at 0x91a80000 (512 KiB) and mark it as no-map so Linux does not<br /> map or allocate from this area.<br /> <br /> For the record:<br /> Hyp version: gunyah-e78adb36e debug (2025-11-17 05:38:05 UTC)<br /> UEFI Ver: 6.0.260122.BOOT.MXF.1.0.c1-00449-KODIAKLA-1

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mshv_vtl: Fix vmemmap_shift exceeding MAX_FOLIO_ORDER<br /> <br /> When registering VTL0 memory via MSHV_ADD_VTL0_MEMORY, the kernel<br /> computes pgmap-&gt;vmemmap_shift as the number of trailing zeros in the<br /> OR of start_pfn and last_pfn, intending to use the largest compound<br /> page order both endpoints are aligned to.<br /> <br /> However, this value is not clamped to MAX_FOLIO_ORDER, so a<br /> sufficiently aligned range (e.g. physical range<br /> [0x800000000000, 0x800080000000), corresponding to start_pfn=0x800000000<br /> with 35 trailing zeros) can produce a shift larger than what<br /> memremap_pages() accepts, triggering a WARN and returning -EINVAL:<br /> <br /> WARNING: ... memremap_pages+0x512/0x650<br /> requested folio size unsupported<br /> <br /> The MAX_FOLIO_ORDER check was added by<br /> commit 646b67d57589 ("mm/memremap: reject unreasonable folio/compound<br /> page sizes in memremap_pages()").<br /> <br /> Fix this by clamping vmemmap_shift to MAX_FOLIO_ORDER so we always<br /> request the largest order the kernel supports, in those cases, rather<br /> than an out-of-range value.<br /> <br /> Also fix the error path to propagate the actual error code from<br /> devm_memremap_pages() instead of hard-coding -EFAULT, which was<br /> masking the real -EINVAL return.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to avoid uninit-value access in f2fs_sanity_check_node_footer<br /> <br /> syzbot reported a f2fs bug as below:<br /> <br /> BUG: KMSAN: uninit-value in f2fs_sanity_check_node_footer+0x374/0xa20 fs/f2fs/node.c:1520<br /> f2fs_sanity_check_node_footer+0x374/0xa20 fs/f2fs/node.c:1520<br /> f2fs_finish_read_bio+0xe1e/0x1d60 fs/f2fs/data.c:177<br /> f2fs_read_end_io+0x6ab/0x2220 fs/f2fs/data.c:-1<br /> bio_endio+0x1006/0x1160 block/bio.c:1792<br /> submit_bio_noacct+0x533/0x2960 block/blk-core.c:891<br /> submit_bio+0x57a/0x620 block/blk-core.c:926<br /> blk_crypto_submit_bio include/linux/blk-crypto.h:203 [inline]<br /> f2fs_submit_read_bio+0x12c/0x360 fs/f2fs/data.c:557<br /> f2fs_submit_page_bio+0xee2/0x1450 fs/f2fs/data.c:775<br /> read_node_folio+0x384/0x4b0 fs/f2fs/node.c:1481<br /> __get_node_folio+0x5db/0x15d0 fs/f2fs/node.c:1576<br /> f2fs_get_inode_folio+0x40/0x50 fs/f2fs/node.c:1623<br /> do_read_inode fs/f2fs/inode.c:425 [inline]<br /> f2fs_iget+0x1209/0x9380 fs/f2fs/inode.c:596<br /> f2fs_fill_super+0x8f5a/0xb2e0 fs/f2fs/super.c:5184<br /> get_tree_bdev_flags+0x6e6/0x920 fs/super.c:1694<br /> get_tree_bdev+0x38/0x50 fs/super.c:1717<br /> f2fs_get_tree+0x35/0x40 fs/f2fs/super.c:5436<br /> vfs_get_tree+0xb3/0x5d0 fs/super.c:1754<br /> fc_mount fs/namespace.c:1193 [inline]<br /> do_new_mount_fc fs/namespace.c:3763 [inline]<br /> do_new_mount+0x885/0x1dd0 fs/namespace.c:3839<br /> path_mount+0x7a2/0x20b0 fs/namespace.c:4159<br /> do_mount fs/namespace.c:4172 [inline]<br /> __do_sys_mount fs/namespace.c:4361 [inline]<br /> __se_sys_mount+0x704/0x7f0 fs/namespace.c:4338<br /> __x64_sys_mount+0xe4/0x150 fs/namespace.c:4338<br /> x64_sys_call+0x39f0/0x3ea0 arch/x86/include/generated/asm/syscalls_64.h:166<br /> do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]<br /> do_syscall_64+0x134/0xf80 arch/x86/entry/syscall_64.c:94<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> The root cause is: in f2fs_finish_read_bio(), we may access uninit data<br /> in folio if we failed to read the data from device into folio, let&amp;#39;s add<br /> a check condition to avoid such issue.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_rndis: Protect RNDIS options with mutex<br /> <br /> The class/subclass/protocol options are suspectible to race conditions<br /> as they can be accessed concurrently through configfs.<br /> <br /> Use existing mutex to protect these options. This issue was identified<br /> during code inspection.