Vulnerabilities

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.

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.

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.

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()

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.

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.

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.

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]

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 ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> macvlan: inherit needed_headroom and needed_tailroom from lowerdev<br /> <br /> macvlan devices inherit hard_header_len from lowerdev during macvlan_init(),<br /> but leave needed_headroom and needed_tailroom set to 0.<br /> <br /> When the underlying lowerdev requires extra headroom or tailroom for<br /> headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or veth with rx<br /> headroom), upper layers calculating packet headroom and tailroom fail to<br /> reserve sufficient space.<br /> <br /> This can result in reallocation overhead, skb headroom underflows, or KASAN<br /> slab-use-after-free crashes when dev_hard_header() / macvlan_hard_header()<br /> prepends header data or when lower devices append tailroom.<br /> <br /> Fix this by:<br /> 1. Inheriting needed_headroom and needed_tailroom from lowerdev in macvlan_init().<br /> 2. Propagating needed_headroom and needed_tailroom updates to attached macvlans<br /> in macvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipvlan: inherit needed_headroom and needed_tailroom from phy_dev<br /> <br /> ipvlan devices inherit hard_header_len from phy_dev during ipvlan_init(),<br /> but leave needed_headroom and needed_tailroom set to 0.<br /> <br /> When the underlying phy_dev (or stacked lower device) requires extra headroom<br /> or tailroom for headers/trailers (e.g. macsec, ipsec, wireguard, tunnels, or<br /> veth with rx headroom), upper layers calculating packet headroom and tailroom<br /> fail to reserve sufficient space.<br /> <br /> This can result in reallocation overhead, skb headroom underflows, or KASAN<br /> slab-use-after-free crashes when dev_hard_header() / ipvlan_hard_header()<br /> prepends header data or when lower devices append tailroom.<br /> <br /> Fix this by:<br /> 1. Inheriting needed_headroom and needed_tailroom from phy_dev in ipvlan_init().<br /> 2. Propagating needed_headroom and needed_tailroom updates to attached ipvlans<br /> in ipvlan_device_event() when receiving NETDEV_FEAT_CHANGE events.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> eth: bnxt: avoid deadlock when canceling IRQ affinity notifier<br /> <br /> Unregistering IRQ affinity notifiers waits for the callback synchronously.<br /> bnxt takes the netdev instance lock in the notifier (to restart the queue)<br /> and cancels the work under the same lock. This may obviously deadlock.<br /> <br /> Move the restart to the async service task. The queue restart isn&amp;#39;t<br /> super time sensitive. Store the new TPH tag, schedule the task.<br /> Safely canceling the service task is already ironed out.<br /> <br /> In bnxt_request_irq() the order of registering notifier, affinity and<br /> initial TPH programming has to be inverted. I think it was racy<br /> previously since user may trigger an update as soon as notifier<br /> is installed.<br /> <br /> There&amp;#39;s a small known gap - if pcie_tph_get_cpu_st() fails at init<br /> and the target tag is 0 we may miss programming the entry.<br /> This does not seem worth fixing, the code has skip-on-failure<br /> all over the place, anyway.