Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/msm/dpu: fix mismatch between power and frequency<br /> <br /> During DPU runtime suspend, calling dev_pm_opp_set_rate(dev, 0) drops<br /> the MMCX rail to MIN_SVS while the core clock frequency remains at its<br /> original (highest) rate. When runtime resume re-enables the clock, this<br /> may result in a mismatch between the rail voltage and the clock rate.<br /> <br /> For example, in the DPU bind path, the sequence could be:<br /> cpu0: dev_sync_state -&gt; rpmhpd_sync_state<br /> cpu1: dpu_kms_hw_init<br /> timeline 0 ------------------------------------------------&gt; t<br /> <br /> After rpmhpd_sync_state, the voltage performance is no longer guaranteed<br /> to stay at the highest level. During dpu_kms_hw_init, calling<br /> dev_pm_opp_set_rate(dev, 0) drops the voltage, causing the MMCX rail to<br /> fall to MIN_SVS while the core clock is still at its maximum frequency.<br /> When the power is re-enabled, only the clock is enabled, leading to a<br /> situation where the MMCX rail is at MIN_SVS but the core clock is at its<br /> highest rate. In this state, the rail cannot sustain the clock rate,<br /> which may cause instability or system crash.<br /> <br /> Remove the call to dev_pm_opp_set_rate(dev, 0) from dpu_runtime_suspend<br /> to ensure the correct vote is restored when DPU resumes.<br /> <br /> Patchwork: https://patchwork.freedesktop.org/patch/710077/

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iommu/riscv: Add IOTINVAL after updating DDT/PDT entries<br /> <br /> Add riscv_iommu_iodir_iotinval() to perform required TLB and context cache<br /> invalidations after updating DDT or PDT entries, as mandated by the RISC-V<br /> IOMMU specification (Section 6.3.1 and 6.3.2).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> memory: tegra124-emc: Fix dll_change check<br /> <br /> The code checking whether the specified memory timing enables DLL<br /> in the EMRS register was reversed. DLL is enabled if bit A0 is low.<br /> Fix the check.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free from async crypto on Qualcomm crypto engine<br /> <br /> ksmbd_crypt_message() sets a NULL completion callback on AEAD requests<br /> and does not handle the -EINPROGRESS return code from async hardware<br /> crypto engines like the Qualcomm Crypto Engine (QCE). When QCE returns<br /> -EINPROGRESS, ksmbd treats it as an error and immediately frees the<br /> request while the hardware DMA operation is still in flight. The DMA<br /> completion callback then dereferences freed memory, causing a NULL<br /> pointer crash:<br /> <br /> pc : qce_skcipher_done+0x24/0x174<br /> lr : vchan_complete+0x230/0x27c<br /> ...<br /> el1h_64_irq+0x68/0x6c<br /> ksmbd_free_work_struct+0x20/0x118 [ksmbd]<br /> ksmbd_exit_file_cache+0x694/0xa4c [ksmbd]<br /> <br /> Use the standard crypto_wait_req() pattern with crypto_req_done() as<br /> the completion callback, matching the approach used by the SMB client<br /> in fs/smb/client/smb2ops.c. This properly handles both synchronous<br /> engines (immediate return) and async engines (-EINPROGRESS followed<br /> by callback notification).

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> efi/capsule-loader: fix incorrect sizeof in phys array reallocation<br /> <br /> The krealloc() call for cap_info-&gt;phys in __efi_capsule_setup_info() uses<br /> sizeof(phys_addr_t *) instead of sizeof(phys_addr_t), which might be<br /> causing an undersized allocation.<br /> <br /> The allocation is also inconsistent with the initial array allocation in<br /> efi_capsule_open() that allocates one entry with sizeof(phys_addr_t),<br /> and the efi_capsule_write() function that stores phys_addr_t values (not<br /> pointers) via page_to_phys().<br /> <br /> On 64-bit systems where sizeof(phys_addr_t) == sizeof(phys_addr_t *), this<br /> goes unnoticed. On 32-bit systems with PAE where phys_addr_t is 64-bit but<br /> pointers are 32-bit, this allocates half the required space, which might<br /> lead to a heap buffer overflow when storing physical addresses.<br /> <br /> This is similar to the bug fixed in commit fccfa646ef36 ("efi/capsule-loader:<br /> fix incorrect allocation size") which fixed the same issue at the initial<br /> allocation site.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: prevent NULL pointer dereference during unmount<br /> <br /> When flushing out outstanding glock work during an unmount, gfs2_log_flush()<br /> can be called when sdp-&gt;sd_jdesc has already been deallocated and sdp-&gt;sd_jdesc<br /> is NULL. Commit 35264909e9d1 ("gfs2: Fix NULL pointer dereference in<br /> gfs2_log_flush") added a check for that to gfs2_log_flush() itself, but it<br /> missed the sdp-&gt;sd_jdesc dereference in gfs2_log_release(). Fix that.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> gfs2: add some missing log locking<br /> <br /> Function gfs2_logd() calls the log flushing functions gfs2_ail1_start(),<br /> gfs2_ail1_wait(), and gfs2_ail1_empty() without holding sdp-&gt;sd_log_flush_lock,<br /> but these functions require exclusion against concurrent transactions.<br /> <br /> To fix that, add a non-locking __gfs2_log_flush() function. Then, in<br /> gfs2_logd(), take sdp-&gt;sd_log_flush_lock before calling the above mentioned log<br /> flushing functions and __gfs2_log_flush().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> quota: Fix race of dquot_scan_active() with quota deactivation<br /> <br /> dquot_scan_active() can race with quota deactivation in<br /> quota_release_workfn() like:<br /> <br /> CPU0 (quota_release_workfn) CPU1 (dquot_scan_active)<br /> ============================== ==============================<br /> spin_lock(&amp;dq_list_lock);<br /> list_replace_init(<br /> &amp;releasing_dquots, &amp;rls_head);<br /> /* dquot X on rls_head,<br /> dq_count == 0,<br /> DQ_ACTIVE_B still set */<br /> spin_unlock(&amp;dq_list_lock);<br /> synchronize_srcu(&amp;dquot_srcu);<br /> spin_lock(&amp;dq_list_lock);<br /> list_for_each_entry(dquot,<br /> &amp;inuse_list, dq_inuse) {<br /> /* finds dquot X */<br /> dquot_active(X) -&gt; true<br /> atomic_inc(&amp;X-&gt;dq_count);<br /> }<br /> spin_unlock(&amp;dq_list_lock);<br /> spin_lock(&amp;dq_list_lock);<br /> dquot = list_first_entry(&amp;rls_head);<br /> WARN_ON_ONCE(atomic_read(&amp;dquot-&gt;dq_count));<br /> <br /> The problem is not only a cosmetic one as under memory pressure the<br /> caller of dquot_scan_active() can end up working on freed dquot.<br /> <br /> Fix the problem by making sure the dquot is removed from releasing list<br /> when we acquire a reference to it.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> soc/tegra: cbb: Fix incorrect ARRAY_SIZE in fabric lookup tables<br /> <br /> Fix incorrect ARRAY_SIZE usage in fabric lookup tables which could<br /> cause out-of-bounds access during target timeout lookup.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ocfs2/dlm: validate qr_numregions in dlm_match_regions()<br /> <br /> Patch series "ocfs2/dlm: fix two bugs in dlm_match_regions()".<br /> <br /> In dlm_match_regions(), the qr_numregions field from a DLM_QUERY_REGION<br /> network message is used to drive loops over the qr_regions buffer without<br /> sufficient validation. This series fixes two issues:<br /> <br /> - Patch 1 adds a bounds check to reject messages where qr_numregions<br /> exceeds O2NM_MAX_REGIONS. The o2net layer only validates message<br /> byte length; it does not constrain field values, so a crafted message<br /> can set qr_numregions up to 255 and trigger out-of-bounds reads past<br /> the 1024-byte qr_regions buffer.<br /> <br /> - Patch 2 fixes an off-by-one in the local-vs-remote comparison loop,<br /> which uses &amp;#39;

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf, arm64: Fix off-by-one in check_imm signed range check<br /> <br /> check_imm(bits, imm) is used in the arm64 BPF JIT to verify that<br /> a branch displacement (in arm64 instruction units) fits into the<br /> signed N-bit immediate field of a B, B.cond or CBZ/CBNZ encoding<br /> before it is handed to the encoder. The macro currently tests for<br /> (imm &gt; 0 &amp;&amp; imm &gt;&gt; bits) || (imm &gt; bits) which admits<br /> values in [-2^N, 2^N) — effectively a signed (N+1)-bit range. A<br /> signed N-bit field only holds [-2^(N-1), 2^(N-1)), so the check<br /> admits one extra bit of range on each side.<br /> <br /> In particular, for check_imm19(), values in [2^18, 2^19) slip past<br /> the check but do not fit into the 19-bit signed imm19 field of<br /> B.cond. aarch64_insn_encode_immediate() then masks the raw value<br /> into the 19-bit field, setting bit 18 (the sign bit) and flipping<br /> a forward branch into a backward one. Same class of issue exists<br /> for check_imm26() and the B/BL encoding. Shift by (bits - 1)<br /> instead of bits so the actual signed N-bit range is enforced.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fwctl: Fix class init ordering to avoid NULL pointer dereference on device removal<br /> <br /> CXL is linked before fwctl in drivers/Makefile. Both use `module_init, so<br /> `cxl_pci_driver_init()` runs first. When `cxl_pci_probe()` calls<br /> `fwctl_register()` and then `device_add()`, fwctl_class is not yet<br /> registered because fwctl_init() hasn&amp;#39;t run, causing `class_to_subsys()` to<br /> return NULL and skip knode_class initialization.<br /> <br /> On device removal, `class_to_subsys()` returns non-NULL, and<br /> `device_del()` calls `klist_del()` on the uninitialized knode, triggering<br /> a NULL pointer dereference.