Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: finish crypto callback cleanup before peer release<br /> <br /> Crypto completion callbacks hold both key-slot and peer references. The<br /> peer reference pins the netdev, and dropping the last peer reference can<br /> let netdev unregistration and module removal make progress.<br /> <br /> Do not release that peer reference before the callback has finished its<br /> own cleanup. If ovpn_crypto_key_slot_put runs after ovpn_peer_put, it can<br /> schedule an RCU callback backed by module text after ovpn_cleanup<br /> rcu_barrier has already run. The TX error path also freed the remaining<br /> skb after ovpn_peer_put, leaving callback cleanup outside the peer/netdev<br /> lifetime window.<br /> <br /> Release the key slot and free any remaining skb first, then drop the peer<br /> reference as the last callback action.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: fix NULL dereference when killing missing key<br /> <br /> ovpn_crypto_kill_key assumes both crypto slots are populated and<br /> dereferences each slot before checking it. That is not guaranteed: a<br /> peer can have only one installed key, and the kill path may be asked to<br /> remove a key that is not present.<br /> <br /> Read each slot once while holding the crypto state lock, check for NULL<br /> before looking at key_id, and only replace the slot that actually<br /> matches.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Unlink scc_entry in unix_del_edge().<br /> <br /> Kyle Zeng reported that GC could free a dead SCC partially.<br /> <br /> The scenario is as follows:<br /> <br /> 1) Create two SCCs:<br /> <br /> X -. A B<br /> ^--&amp;#39;<br /> <br /> 2) Run the following concurrently:<br /> <br /> 2-1) send() sk-B to sk-B from sk-X<br /> 2-2) close() both A and B<br /> <br /> At 2-1), there is a small window where unix_add_edges()<br /> publishes a new edge (B B) to GC but its skb is not queued<br /> by skb_queue_tail().<br /> <br /> If 2-2) completes before skb_queue_tail() and GC is triggered,<br /> it judges A B as dead, but B is not freed because GC cannot<br /> collect the not-yet-queued skb holding the B B edge.<br /> <br /> X -. A B -. This edge is visible<br /> ^--&amp;#39; ^..&amp;#39; but skb is not<br /> <br /> This itself is not a problem since the next GC run will judge<br /> B as dead as well and free it finally.<br /> <br /> X -. A B -.<br /> ^--&amp;#39; ^--&amp;#39;<br /> <br /> However, X&amp;#39;s SCC forces the next GC to call unix_walk_scc_fast(),<br /> and it iterates over A through B&amp;#39;s scc_entry.<br /> <br /> Let&amp;#39;s unlink scc_entry before freeing the vertex in unix_del_edge().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> crypto: tegra - fix rctx-&gt;cryptlen calculation in tegra_gcm_do_one_req()<br /> <br /> Perform rctx-&gt;cryptlen calculation in tegra_gcm_do_one_req() the same way<br /> it is done in tegra_ccm_crypt_init(). The current formulae may lead to a<br /> crash if a caller does not call tegra_gcm_setauthsize() and so ctx-&gt;authsize<br /> remains zero. Then a decrypt operation with incorrect rctx-&gt;cryptlen will<br /> lead to a write beyound rctx-&gt;dst_sg buffer.<br /> <br /> As a follow-up cleanup delete struct tegra_aead_ctx-&gt;authsize field since<br /> it appears to be completely unused. Also simplify tegra_ccm_setauthsize()<br /> and tegra_gcm_setauthsize() functions respectively.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: spacemit: k3: set hdma clock as critical<br /> <br /> HDMA clock is responsible for the internal TCM access path of X100 RISC-V<br /> core, so set the clock flag as critical to prevent it from being shut off,<br /> otherwise the Linux system will hang, for example in the case of a vector<br /> instruction access generates a page fault.

*** Pendiente de traducción *** Improper Neutralization of Directives in Dynamically Evaluated Code (&amp;#39;Eval Injection&amp;#39;) in the default lf.query Python protocol in Google langfun versions prior to 0.1.2 allows remote unauthenticated attackers to execute arbitrary Python code in the context of the host application via crafted prompt inputs that cause the model to generate executable Python expressions evaluated without a sandbox.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: core: pair EH runtime PM get and put<br /> <br /> shost-&gt;eh_noresume is currently consulted twice in one error handling<br /> iteration: once before scsi_autopm_get_host() and once again before<br /> scsi_autopm_put_host().<br /> <br /> That is racy when a PM-triggered error path flips shost-&gt;eh_noresume<br /> while the SCSI EH thread is still running.<br /> <br /> The problem flow looks like this:<br /> PM path<br /> ufshcd_set_dev_pwr_mode()<br /> shost-&gt;eh_noresume = 1<br /> ufshcd_execute_start_stop eh_noresume = 0<br /> <br /> EH path<br /> scsi_error_handler()<br /> if (!shost-&gt;eh_noresume)<br /> scsi_autopm_get_host() eh_noresume)<br /> scsi_autopm_put_host()

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ovpn: defer key slot crypto freeing to workqueue<br /> <br /> Key slots are released through a kref and the existing release path<br /> frees the AEAD transforms from an RCU callback. That is not safe for all<br /> crypto implementations: crypto_free_aead can sleep, for example when an<br /> async or hardware implementation has teardown work to complete.<br /> <br /> Use queue_rcu_work for key-slot release. This keeps the RCU grace period<br /> needed by lockless key-slot readers, but runs the actual crypto teardown<br /> from workqueue context where sleeping is allowed. Once the rcu_work<br /> callback runs, pre-existing RCU readers are gone, and the final kref put<br /> already proves that no transform user remains, so the worker can release<br /> the AEAD transforms and free the slot directly.<br /> <br /> The previous patch drains ovpn_wq during module exit, so queued key-slot<br /> teardown work cannot outlive module text.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> riscv: lib: Fix ZBB strnlen reading past count boundary<br /> <br /> The ZBB-optimized strnlen loop loads one word ahead before checking the<br /> aligned boundary:<br /> <br /> REG_L t1, SZREG(t0) // load next word<br /> addi t0, t0, SZREG // advance<br /> orc.b t1, t1<br /> bgeu t0, t4, 4f // boundary check AFTER load<br /> <br /> where t4 = (s + count) &amp; -SZREG. When s is aligned and count is a<br /> multiple of SZREG, t4 equals s + count and the loop loads a full word<br /> starting at exactly s + count. If s + count falls on a page boundary<br /> with the next page unmapped, this faults.<br /> <br /> Fix by computing the aligned boundary from the last valid byte<br /> (s + count - 1) instead of s + count. This makes the loop stop at the<br /> word containing the last valid byte rather than potentially loading the<br /> word after it. The count == 0 case is already handled by the beqz<br /> early exit.<br /> <br /> Also add a pre-loop guard (bgeu t0, t4) for the case where all valid<br /> bytes fit within the first word. With the adjusted boundary, t4 can<br /> equal t0, and entering the loop with stale register state from the<br /> first-word processing would produce incorrect results.<br /> <br /> The final minu clamp ensures the result is still correct when the last<br /> loaded word extends past s + count - 1 within the same aligned word.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: validate cookie AUTH state before use<br /> <br /> When cookie authentication is disabled, COOKIE_ECHO restores fixed-size<br /> AUTH fields directly from peer-controlled cookie bytes. A forged RANDOM<br /> length, HMAC list, or CHUNKS list can then reach association consumers<br /> with lengths or identifiers that were never validated against the local<br /> backing arrays.<br /> <br /> A forged RANDOM length can cause out-of-bounds reads during key-vector<br /> construction. A forged HMAC identifier also caused a 32-byte write past<br /> a zero-length AUTH chunk, providing a primitive for a local privilege<br /> escalation chain.<br /> <br /> Validate the cookie&amp;#39;s RANDOM, HMACS, and CHUNKS parameters at the cookie<br /> trust boundary before copying them into the association. Reject invalid<br /> types, malformed lengths, unsupported HMAC identifiers, HMAC lists<br /> without SHA1, and forbidden chunk ids.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: Reject exited events as group leaders<br /> <br /> perf_event_remove_on_exec() sets remove-on-exec events to the EXIT state<br /> and detaches their group relationships. The event&amp;#39;s file descriptor can<br /> remain open, however, and perf_event_open() currently accepts that event<br /> as a group leader because its early validation rejects only REVOKED and<br /> DEAD events.<br /> <br /> A new sibling can consequently be linked to the detached leader. When<br /> the leader is closed, perf_group_detach() observes that its<br /> PERF_ATTACH_GROUP bit is already clear and skips the new sibling. The<br /> sibling then retains a group_leader pointer to the freed event.<br /> <br /> Reject group leaders in the EXIT state. Perform the check while holding<br /> the shared context mutex so that an exec in the target task cannot detach<br /> the leader between validation and group attachment.<br /> <br /> [peterz: make the earlier test fully consistent]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> rseq: Prevent hard lockup on granted time slice extension<br /> <br /> __exit_to_user_mode_loop() invokes rseq_grant_timeslice_extension() with<br /> interrupts enabled. If the extension is granted it invokes<br /> hrtimer_rearm_deferred_tif() to ensure that a pending deferred hrtimer<br /> rearm is handled before exiting to user space.<br /> <br /> Though this invokes __hrtimer_rearm_deferred() which expects to be invoked<br /> with interrupts disabled as it takes hrtimer_cpu_base::lock with<br /> raw_spin_lock(). That&amp;#39;s a livelock waiting to happen and caught by lockdep:<br /> <br /> WARNING: ./include/linux/hrtimer_rearm.h:17 at irqentry_exit, CPU#1: slice_test<br /> WARNING: inconsistent lock state<br /> inconsistent {IN-HARDIRQ-W} -&gt; {HARDIRQ-ON-W} usage.<br /> <br /> Prevent this by disabling interrupts around the invocation of<br /> hrtimer_rearm_deferred_tif() in rseq_grant_timeslice_extension().<br /> <br /> [ tglx: Massaged change log ]