Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nvmet-fc: avoid scheduling association deletion twice<br /> <br /> When forcefully shutting down a port via the configfs interface,<br /> nvmet_port_subsys_drop_link() first calls nvmet_port_del_ctrls() and<br /> then nvmet_disable_port(). Both functions will eventually schedule all<br /> remaining associations for deletion.<br /> <br /> The current implementation checks whether an association is about to be<br /> removed, but only after the work item has already been scheduled. As a<br /> result, it is possible for the first scheduled work item to free all<br /> resources, and then for the same work item to be scheduled again for<br /> deletion.<br /> <br /> Because the association list is an RCU list, it is not possible to take<br /> a lock and remove the list entry directly, so it cannot be looked up<br /> again. Instead, a flag (terminating) must be used to determine whether<br /> the association is already in the process of being deleted.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ASoC: Intel: avs: Disable periods-elapsed work when closing PCM<br /> <br /> avs_dai_fe_shutdown() handles the shutdown procedure for HOST HDAudio<br /> stream while period-elapsed work services its IRQs. As the former<br /> frees the DAI&amp;#39;s private context, these two operations shall be<br /> synchronized to avoid slab-use-after-free or worse errors.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/sched: Fix deadlock in drm_sched_entity_kill_jobs_cb<br /> <br /> The Mesa issue referenced below pointed out a possible deadlock:<br /> <br /> [ 1231.611031] Possible interrupt unsafe locking scenario:<br /> <br /> [ 1231.611033] CPU0 CPU1<br /> [ 1231.611034] ---- ----<br /> [ 1231.611035] lock(&amp;xa-&gt;xa_lock#17);<br /> [ 1231.611038] local_irq_disable();<br /> [ 1231.611039] lock(&amp;fence-&gt;lock);<br /> [ 1231.611041] lock(&amp;xa-&gt;xa_lock#17);<br /> [ 1231.611044] <br /> [ 1231.611045] lock(&amp;fence-&gt;lock);<br /> [ 1231.611047]<br /> *** DEADLOCK ***<br /> <br /> In this example, CPU0 would be any function accessing job-&gt;dependencies<br /> through the xa_* functions that don&amp;#39;t disable interrupts (eg:<br /> drm_sched_job_add_dependency(), drm_sched_entity_kill_jobs_cb()).<br /> <br /> CPU1 is executing drm_sched_entity_kill_jobs_cb() as a fence signalling<br /> callback so in an interrupt context. It will deadlock when trying to<br /> grab the xa_lock which is already held by CPU0.<br /> <br /> Replacing all xa_* usage by their xa_*_irq counterparts would fix<br /> this issue, but Christian pointed out another issue: dma_fence_signal<br /> takes fence.lock and so does dma_fence_add_callback.<br /> <br /> dma_fence_signal() // locks f1.lock<br /> -&gt; drm_sched_entity_kill_jobs_cb()<br /> -&gt; foreach dependencies<br /> -&gt; dma_fence_add_callback() // locks f2.lock<br /> <br /> This will deadlock if f1 and f2 share the same spinlock.<br /> <br /> To fix both issues, the code iterating on dependencies and re-arming them<br /> is moved out to drm_sched_entity_kill_jobs_work().<br /> <br /> [phasta: commit message nits]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bnxt_en: Shutdown FW DMA in bnxt_shutdown()<br /> <br /> The netif_close() call in bnxt_shutdown() only stops packet DMA. There<br /> may be FW DMA for trace logging (recently added) that will continue. If<br /> we kexec to a new kernel, the DMA will corrupt memory in the new kernel.<br /> <br /> Add bnxt_hwrm_func_drv_unrgtr() to unregister the driver from the FW.<br /> This will stop the FW DMA. In case the call fails, call pcie_flr() to<br /> reset the function and stop the DMA.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: Prevent TOCTOU out-of-bounds write<br /> <br /> For the following path not holding the sock lock,<br /> <br /> sctp_diag_dump() -&gt; sctp_for_each_endpoint() -&gt; sctp_ep_dump()<br /> <br /> make sure not to exceed bounds in case the address list has grown<br /> between buffer allocation (time-of-check) and write (time-of-use).

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix mmap write lock not release<br /> <br /> If mmap write lock is taken while draining retry fault, mmap write lock<br /> is not released because svm_range_restore_pages calls mmap_read_unlock<br /> then returns. This causes deadlock and system hangs later because mmap<br /> read or write lock cannot be taken.<br /> <br /> Downgrade mmap write lock to read lock if draining retry fault fix this<br /> bug.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix infinite loop in __insert_extent_tree()<br /> <br /> When we get wrong extent info data, and look up extent_node in rb tree,<br /> it will cause infinite loop (CONFIG_F2FS_CHECK_FS=n). Avoiding this by<br /> return NULL and print some kernel messages in that case.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: validate userq buffer virtual address and size<br /> <br /> It needs to validate the userq object virtual address to<br /> determine whether it is residented in a valid vm mapping.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu: validate userq input args<br /> <br /> This will help on validating the userq input args, and<br /> rejecting for the invalid userq request at the IOCTLs<br /> first place.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/gpusvm: fix hmm_pfn_to_map_order() usage<br /> <br /> Handle the case where the hmm range partially covers a huge page (like<br /> 2M), otherwise we can potentially end up doing something nasty like<br /> mapping memory which is outside the range, and maybe not even mapped by<br /> the mm. Fix is based on the xe userptr code, which in a future patch<br /> will directly use gpusvm, so needs alignment here.<br /> <br /> v2:<br /> - Add kernel-doc (Matt B)<br /> - s/fls/ilog2/ (Thomas)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: stmmac: Correctly handle Rx checksum offload errors<br /> <br /> The stmmac_rx function would previously set skb-&gt;ip_summed to<br /> CHECKSUM_UNNECESSARY if hardware checksum offload (CoE) was enabled<br /> and the packet was of a known IP ethertype.<br /> <br /> However, this logic failed to check if the hardware had actually<br /> reported a checksum error. The hardware status, indicating a header or<br /> payload checksum failure, was being ignored at this stage. This could<br /> cause corrupt packets to be passed up the network stack as valid.<br /> <br /> This patch corrects the logic by checking the `csum_none` status flag,<br /> which is set when the hardware reports a checksum error. If this flag<br /> is set, skb-&gt;ip_summed is now correctly set to CHECKSUM_NONE,<br /> ensuring the kernel&amp;#39;s network stack will perform its own validation and<br /> properly handle the corrupt packet.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/core: Fix system hang caused by cpu-clock usage<br /> <br /> cpu-clock usage by the async-profiler tool can trigger a system hang,<br /> which got bisected back to the following commit by Octavia Togami:<br /> <br /> 18dbcbfabfff ("perf: Fix the POLL_HUP delivery breakage") causes this issue<br /> <br /> The root cause of the hang is that cpu-clock is a special type of SW<br /> event which relies on hrtimers. The __perf_event_overflow() callback<br /> is invoked from the hrtimer handler for cpu-clock events, and<br /> __perf_event_overflow() tries to call cpu_clock_event_stop()<br /> to stop the event, which calls htimer_cancel() to cancel the hrtimer.<br /> <br /> But that&amp;#39;s a recursion into the hrtimer code from a hrtimer handler,<br /> which (unsurprisingly) deadlocks.<br /> <br /> To fix this bug, use hrtimer_try_to_cancel() instead, and set<br /> the PERF_HES_STOPPED flag, which causes perf_swevent_hrtimer()<br /> to stop the event once it sees the PERF_HES_STOPPED flag.<br /> <br /> [ mingo: Fixed the comments and improved the changelog. ]