Vulnerabilidades

*** 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.

*** 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 /> bpf: reject direct access to nullable PTR_TO_BUF pointers<br /> <br /> check_mem_access() matches PTR_TO_BUF via base_type() which strips<br /> PTR_MAYBE_NULL, allowing direct dereference without a null check.<br /> <br /> Map iterator ctx-&gt;key and ctx-&gt;value are PTR_TO_BUF | PTR_MAYBE_NULL.<br /> On stop callbacks these are NULL, causing a kernel NULL dereference.<br /> <br /> Add a type_may_be_null() guard to the PTR_TO_BUF branch, matching the<br /> existing PTR_TO_BTF_ID pattern.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> Bluetooth: SMP: force responder MITM requirements before building the pairing response<br /> <br /> smp_cmd_pairing_req() currently builds the pairing response from the<br /> initiator auth_req before enforcing the local BT_SECURITY_HIGH<br /> requirement. If the initiator omits SMP_AUTH_MITM, the response can<br /> also omit it even though the local side still requires MITM.<br /> <br /> tk_request() then sees an auth value without SMP_AUTH_MITM and may<br /> select JUST_CFM, making method selection inconsistent with the pairing<br /> policy the responder already enforces.<br /> <br /> When the local side requires HIGH security, first verify that MITM can<br /> be achieved from the IO capabilities and then force SMP_AUTH_MITM in the<br /> response in both rsp.auth_req and auth. This keeps the responder auth bits<br /> and later method selection aligned.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> interconnect: qcom: sm8450: Fix NULL pointer dereference in icc_link_nodes()<br /> <br /> The change to dynamic IDs for SM8450 platform interconnects left two links<br /> unconverted, fix it to avoid the NULL pointer dereference in runtime,<br /> when a pointer to a destination interconnect is not valid:<br /> <br /> Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008<br /> <br /> Call trace:<br /> icc_link_nodes+0x3c/0x100 (P)<br /> qcom_icc_rpmh_probe+0x1b4/0x528<br /> platform_probe+0x64/0xc0<br /> really_probe+0xc4/0x2a8<br /> __driver_probe_device+0x80/0x140<br /> driver_probe_device+0x48/0x170<br /> __device_attach_driver+0xc0/0x148<br /> bus_for_each_drv+0x88/0xf0<br /> __device_attach+0xb0/0x1c0<br /> device_initial_probe+0x58/0x68<br /> bus_probe_device+0x40/0xb8<br /> deferred_probe_work_func+0x90/0xd0<br /> process_one_work+0x15c/0x3c0<br /> worker_thread+0x2e8/0x400<br /> kthread+0x150/0x208<br /> ret_from_fork+0x10/0x20<br /> Code: 900310f4 911d6294 91008280 94176078 (f94002a0)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Oops: Fatal exception

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> lib/crypto: chacha: Zeroize permuted_state before it leaves scope<br /> <br /> Since the ChaCha permutation is invertible, the local variable<br /> &amp;#39;permuted_state&amp;#39; is sufficient to compute the original &amp;#39;state&amp;#39;, and thus<br /> the key, even after the permutation has been done.<br /> <br /> While the kernel is quite inconsistent about zeroizing secrets on the<br /> stack (and some prominent userspace crypto libraries don&amp;#39;t bother at all<br /> since it&amp;#39;s not guaranteed to work anyway), the kernel does try to do it<br /> as a best practice, especially in cases involving the RNG.<br /> <br /> Thus, explicitly zeroize &amp;#39;permuted_state&amp;#39; before it goes out of scope.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amd/display: Fix NULL pointer dereference in dcn401_init_hw()<br /> <br /> dcn401_init_hw() assumes that update_bw_bounding_box() is valid when<br /> entering the update path. However, the existing condition:<br /> <br /> ((!fams2_enable &amp;&amp; update_bw_bounding_box) || freq_changed)<br /> <br /> does not guarantee this, as the freq_changed branch can evaluate to true<br /> independently of the callback pointer.<br /> <br /> This can result in calling update_bw_bounding_box() when it is NULL.<br /> <br /> Fix this by separating the update condition from the pointer checks and<br /> ensuring the callback, dc-&gt;clk_mgr, and bw_params are validated before<br /> use.<br /> <br /> Fixes the below:<br /> ../dc/hwss/dcn401/dcn401_hwseq.c:367 dcn401_init_hw() error: we previously assumed &amp;#39;dc-&gt;res_pool-&gt;funcs-&gt;update_bw_bounding_box&amp;#39; could be null (see line 362)<br /> <br /> (cherry picked from commit 86117c5ab42f21562fedb0a64bffea3ee5fcd477)