Repository navigation
[Deepin-Kernel-SIG] [linux 6.18-y] [Upstream] Update kernel base to 6.18.58 - #2247
Conversation
[ Upstream commit 76645c1 ] The driver is relying on the assumption that the invalid interrupt 0 can be freed without any side effects, but that is not the case on architectures like x86 where it would trigger a warning about freeing an already free interrupt. This should not cause any trouble on powerpc where this driver is used, but make the code more portable (and obviously correct) by making sure that the interrupts have been requested before freeing them. Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260423075801.2252318-1-johan@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 7820bca8cb2073811c851abc37d303afeb15c3c4) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 2c863db ] Currently in cdev_alloc() error path no error code is assigned. Assign error code '-ENOMEM'. Detected by Smatch: drivers/usb/gadget/function/f_hid.c:1291 hidg_bind() warn: missing error code 'status' Fixes: 81ebd43 ("usb: gadget: f_hid: don't call cdev_init while cdev in use") Signed-off-by: Ethan Tidmore <ethantidmore06@gmail.com> Acked-by: Peter Korsgaard <peter@korsgaard.com> Reviewed-by: Michael Zimmermann <sigmaepsilon92@gmail.com> Link: https://patch.msgid.link/20260402180008.64233-1-ethantidmore06@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 3c03f6f7c6f2d476f202bc3399359e2c27d7f99e) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 00baead ] Locked QP and CQ lookups from EQ interrupts can deadlock with create-path XArray updates. If an interrupt arrives while the create path holds the plain xa_lock, the lookup spins forever trying to acquire the same lock. Use IRQ-safe XArray helpers for all QP and CQ create-path updates, including the GSI QP store and error paths. Initialize both arrays with XA_FLAGS_LOCK_IRQ so sleeping allocations preserve interrupt state. Fixes: 98df2ae ("RDMA/erdma: Hold CQ references when processing EQ events") Fixes: a52eeff ("RDMA/erdma: Hold QP references for AE and CM processing") Signed-off-by: Cheng Xu <chengyou@linux.alibaba.com> Link: https://patch.msgid.link/20260828030344.88021-1-chengyou@linux.alibaba.com Signed-off-by: Leon Romanovsky <leon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit e32aa1d85126e6d5ef6efd594ced3f75178886ce) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…t found [ Upstream commit 1bcf245 ] The dw_pcie_wait_for_link() function waits up to 1 second for the PCIe link to come up and returns -ETIMEDOUT for all failures without distinguishing cases where no device is present on the bus. But the callers may want to just skip the failure if the device is not found on the bus and handle failure for other reasons. So after timeout, if the LTSSM is in Detect.Quiet or Detect.Active state, return -ENODEV to indicate the callers that the device is not found on the bus and return -ETIMEDOUT otherwise. Also add kernel doc to document the parameter and return values. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Tested-by: Richard Zhu <hongxing.zhu@nxp.com> Tested-by: Vincent Guittot <vincent.guittot@linaro.org> Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Link: https://patch.msgid.link/20260120-pci-dwc-suspend-rework-v4-1-2f32d5082549@oss.qualcomm.com Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit adc0d81b4d415efa3acec7deb326c0b3c6e74752) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…ctive [ Upstream commit 01d16b8 ] There are cases where the PCIe device would be physically connected to the bus, but the device firmware might not be active. So the LTSSM will get stuck in POLL.{Active/Compliance} states. This behavior is common with endpoint devices controlled by the PCI Endpoint framework, where the device will wait for the user to start its operation through configfs. For those cases, print the relevant log and return -EIO to indicate that the device is present, but not active. This will allow the callers to skip the failure as the device might become active in the future. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Link: https://patch.msgid.link/20260120-pci-dwc-suspend-rework-v4-2-2f32d5082549@oss.qualcomm.com Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 903a2ab8325a26d362247776521c1be3223c6622) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 8bc60db ] A tc tunnel_key action can attach a METADATA_IP_TUNNEL dst to an skb, and mirred can redirect it to a native ip6erspan device. The legacy PMTU update in ip6erspan_tunnel_xmit() treats that metadata dst as a route. Since it has no output device, dst_dev(dst)->mtu dereferences NULL. On v7.2 with KASAN, an initial UID/GID 65534 process with CapEff 0 used self-created user and network namespaces to trigger: KASAN: null-ptr-deref RIP: ip6erspan_tunnel_xmit+0x10fc/0x2cc0 Kernel panic - not syncing: Fatal exception in interrupt The update is obsolete. Commit fe1a4ca ("ip6_gre: process toobig in a better way") changed IPv6 GRE Too Big handling to update the underlay route and removed the equivalent block from __gre6_xmit(). ip6_tnl_xmit() then propagates the underlay PMTU to the overlay route. Remove the stale ERSPAN copy and its now-unused dst variable. This eliminates the metadata-dst dereference and keeps ERSPAN aligned with IPv6 GRE PMTU handling. Fixes: 5a963eb ("ip6_gre: Add ERSPAN native tunnel support") Cc: stable@vger.kernel.org Suggested-by: Ido Schimmel <idosch@nvidia.com> Signed-off-by: Daehyeon Ko <4ncienth@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20261002033058.358137-1-4ncienth@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> [ sashal: Adjusted the deletion to match dst6_mtu() instead of dst_mtu(). ] Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 2d06cb25a497d3a7034ef9d172626c2d6620a0f1) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 75c8746 ] Some AMD APU multi-function devices expose an integrated USB xHCI controller. In some circumstances (such as larger VRAM), the PM core can resume can fail when the xHCI controller is resuming in parallel with the GPU/display function. On affected systems, the xHCI controller can complete pci_pm_resume and start resuming USB devices while the GPU is still in its much longer resume path. This race condition leads to USB device resume failures followed by: xhci_hcd ...: xHCI host not responding to stop endpoint command xhci_hcd ...: HC died; cleaning up Create a device link from any xHCI controller sharing the same PCIe root port as the APU display function. The link uses DL_FLAG_STATELESS and DL_FLAG_PM_RUNTIME to ensure the GPU completes its resume before the xHCI controller begins resuming USB devices. This device link is done specifically in amdgpu so that if the platform firmware has been modified such that this issue doesn't happen the version can be detected and the workaround skipped. Suggested-by: Aaron Ma <aaron.ma@canonical.com> Reported-by: mrh@frame.work Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221073 Acked-by: Alex Deucher <alexander.deucher@amd.com> Tested-by: Mark Pearson <mpearson-lenovo@squebb.ca> Tested-by: Alexander F <superveridical@gmail.com> Tested-by: Francis DB <francisdb@gmail.com> Link: https://patch.msgid.link/20260713195313.1739762-1-mario.limonciello@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 07c93d7) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit b030fde644501d0ed5e604fc01719d1daa9cd472) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 8538aae ] This is just a simple cleanup fix. Commit 35a2443 ("iavf: Add waiting for response from PF in set mac") introduced a duplicate ether_addr_equal() check, so the current code tests the new MAC twice against the former MAC. Remove the outer ether_addr_equal() test, remnant of commit c5c922b ("iavf: fix MAC address setting for VFs when filter is rejected") Signed-off-by: Corinna Vinschen <vinschen@redhat.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260609213559.178657-4-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Stable-dep-of: 436729a ("iavf: send MAC change request synchronously") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 5aa9efb5591745d617c2b77d1ac4e2ef685dc0e0) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 436729a ] After commit ad7c7b2 ("net: hold netdev instance lock during sysfs operations"), iavf_set_mac() is called with the netdev instance lock already held. The function queues a MAC address change request via iavf_replace_primary_mac() and then waits for completion. However, in the current flow, the actual virtchnl message is sent by the watchdog task, which also needs to acquire the netdev lock to run. Additionally, the adminq_task which processes virtchnl responses also needs the netdev lock. This creates a deadlock scenario: 1. iavf_set_mac() holds netdev lock and waits for MAC change 2. Watchdog needs netdev lock to send the request -> blocked 3. Even if request is sent, adminq_task needs netdev lock to process PF response -> blocked 4. MAC change times out after 2.5 seconds 5. iavf_set_mac() returns -EAGAIN This particularly affects VFs during bonding setup when multiple VFs are enslaved in quick succession. Fix by implementing a synchronous MAC change operation similar to the approach used in commit fdadbf6 ("iavf: fix incorrect reset handling in callbacks"). The solution: 1. Send the virtchnl ADD_ETH_ADDR message directly (not via watchdog) 2. Poll the admin queue hardware directly for responses 3. Process all received messages (including non-MAC messages) 4. Return when MAC change completes or times out A new generic function iavf_poll_virtchnl_response() is introduced that can be reused for any future synchronous virtchnl operations. It takes a callback to check completion, allowing flexible condition checking. This allows the operation to complete synchronously while holding netdev_lock, without relying on watchdog or adminq_task. The function can sleep for up to 2.5 seconds polling hardware, but this is acceptable since netdev_lock is per-device and only serializes operations on the same interface. To support this, change iavf_add_ether_addrs() to return an error code instead of void, allowing callers to detect failures. Additionally, export iavf_mac_add_reject() to enable proper rollback on local failures (timeouts, send errors) - PF rejections are already handled automatically by iavf_virtchnl_completion(). Remove vc_waitqueue entirely because iavf_set_mac was the only waiter on this waitqueue and after the changes it is not needed. Fixes: ad7c7b2 ("net: hold netdev instance lock during sysfs operations") cc: stable@vger.kernel.org Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit fdf4f011c600416935a002650cc3bad3df8a127d) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 597e4b9 ] The MREMAP_DONTUNMAP feature is highly unusual in that it permits mremap() operations that keep the original VMA in place. Historically this has led to a lot of bugs where non-obvious interactions occur between existing mremap() operations and the original VMA. Fix another of these - partial copies. The long-standing mremap() partial VMA logic has the baked-in assumption that the originating VMA is unmapped and thus moved. However MREMAP_DONTUNMAP defeats this by performing a partial copy instead since it keeps the source VMA around. An mremap(..., MREMAP_DONTUNMAP) operation disallows resizing of the VMA, but the operation can be performed partially: |-----------------| | | | v <------> <------> .new_sz. new_sz |--.------.--| |------| | .source. | | dest | |--.------.--| |------| <------------> old_sz The page tables in the specified range are moved, but the original VMA is kept intact. This interacts poorly with mlock()'d VMAs, as the VMA_LOCKED_BIT flag is cleared for the entire source VMA and set for the entire destination VMA. This results in an mm->locked_vm leak as the change is therefore not accounted correctly. The clear solution here is to make the portion of the source VMA which is mremap()'d distinct from the rest of it, a.k.a. split it. Therefore resolve this issue by splitting it ahead of the rest of the mremap() operation if the VMA is mlock()'d. This is valid, as the source VMA will lose its VMA_LOCKED_BIT flag, so if a partial remap it will become distinct from the rest of the VMA. In order to make this change re-expose split_vma() in vma.h for CONFIG_MMU (nommu doesn't compile mremap.c and uses a static helper instead). Finally, update the sys_map_count check to account for this case. Note that the early check does not use needs_pre_split() - this is because the VMA has not been looked up by this point, so be conservative and assume that the VMA is mlock()'d in this case for the purposes of the sys_map_count check. Link: https://lore.kernel.org/20260930-fix-dontunmap-partial-self-merge-v2-2-f388985a0f0a@kernel.org Fixes: e346b38 ("mm/mremap: add MREMAP_DONTUNMAP to mremap()") Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Pedro Falcato <pfalcato@suse.de> Acked-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Reviewed-by: Jose A. Perez de Azpillaga <azpijr@gmail.com> Tested-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Cc: Liam R. Howlett <liam@infradead.org> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Jann Horn <jannh@google.com> Cc: Brian Geffon <bgeffon@google.com> Cc: Minchan Kim <minchan@kernel.org> Cc: <stable@vger.kernel.org> [ sashal: adapted newer VMA and map-count helpers to direct flag access and existing map-count checks. ] Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 5720bf6b91295688048f0ad8c0ce595be549ebe2) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 838bb60 ] Patch series "mm/mremap: fix two issues with MREMAP_DONTUNMAP", v2. The MREMAP_DONTUNMAP feature is highly unusual in that it permits mremap() operations that keep the original VMA in place. Historically this has led to a lot of bugs where non-obvious interactions occur between existing mremap() operations and the original VMA. Commit 397432c ("mm/mremap: account mm->locked_vm correctly for MREMAP_DONTUNMAP") fixed an accidentally introduced bug around mm->locked_vm accounting, but this wasn't the only issue. And thus history repeats itself, as it turns out that mm->locked_vm accounting is broken by MREMAP_DONTUNMAP yet again by two further cases, and has been broken ever since the feature was introduced. Both relate to the fact that VMA_LOCKED_BIT is cleared on the source VMA (it has to be as all page tables are moved): 1. If an unfaulted VMA_LOCKONFAULT_BIT anonymous VMA self-merges it clears the VMA_LOCKED_BIT flag and permanently leaks mm->locked_vm pages. 2. If a partial mremap() is performed on a locked VMA there is a leak equal to the number of pages not copied. (Both for MREMAP_DONTUNMAP operations only) Both issues can be fixed by treating the source range as distinct from the destination range, which is the definition of what MREMAP_DONTUNMAP does so is appropriate. In case 1, simply disallow the self-merge, keeping adjacent source and destination VMAs distinct. In case 2, split the source range ahead of time if the VMA is mlock()'d, so accounting is always correct. Both changes were tested locally and confirmed to fix the issues. For the purposes of a backport, the fixes are kept distinct, a follow-up series can add self-tests. This patch (of 2): The MREMAP_DONTUNMAP feature is highly unusual in that it permits mremap() operations that keep the original VMA in place. Historically this has led to a lot of bugs where non-obvious interactions occur between existing mremap() operations and the original VMA. Fix another of these - self-merge. Self-merge occurs when a VMA is moved in front of or behind itself and the attributes of the VMA permit such a merge. Practically this can only happen for unfaulted anonymous VMAs due to the page offset equality requirement for merge: |------------| | | | v |...........||-----------||...........| | || unfaulted || | |...........||-----------||...........| ^ | | | |------------| This becomes problematic if the VMA is configured by the user to mlock-on-fault, i.e. the VMA_LOCKED_BIT, VMA_LOCKONFAULT_BIT VMA flags are set. MREMAP_DONTUNMAP clears mlock flags for the source VMA and maintains them for the destination VMA. Self-merge makes this impossible (there is only one VMA) and incorrectly clears the destination VMA's mlock flags. This causes a leak in mm->locked_vm as clearing this flag does not decrement the counter and the VMA no longer has VMA_LOCKED_BIT set so it is not decremented on unmap. Resolve this by simply disallowing a self-merge in this case - the source and destination VMAs are kept distinct and then are able to have distinct mlock() flags. Update dontunmap_complete() to make the now-redundant self-merge check a VM_WARN_ON_ONCE() instead to guard against future regressions. Also update the VMA userland tests to reflect the change. Link: https://lore.kernel.org/20260930-fix-dontunmap-partial-self-merge-v2-0-f388985a0f0a@kernel.org Link: https://lore.kernel.org/20260930-fix-dontunmap-partial-self-merge-v2-1-f388985a0f0a@kernel.org Fixes: e346b38 ("mm/mremap: add MREMAP_DONTUNMAP to mremap()") Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Reviewed-by: Pedro Falcato <pfalcato@suse.de> Acked-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Reviewed-by: Jose A. Perez de Azpillaga <azpijr@gmail.com> Tested-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> Cc: Liam R. Howlett <liam@infradead.org> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Jann Horn <jannh@google.com> Cc: Brian Geffon <bgeffon@google.com> Cc: Minchan Kim <minchan@kernel.org> Cc: <stable@vger.kernel.org> [ sashal: Translated can_self_merge logic to the inverse faulted_in_anon_vma flag. ] Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 0c5595cba722477babc8eb30d984d6085067edfa) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ There is no upstream commit: this fixes the 6.18.y backport of d0beaee. Mainline fixed the problem as part of the async COPY rework in commit f307b4f ("nfsd: split nfsd4_copy into transient and durable async copy objects"), which is too risky to backport. ] Since commit 9b4e5e9ba5ae ("nfsd: fix stale s2s_cp_stateids IDR entry for async COPY"), nfsd4_copy() calls dup_copy_fields() before the copy stateid is created and then writes the new stateid only into the COPY result. The async copy's own cp_res.cb_stateid stays zero, so nfsd4_send_cb_offload() sends CB_OFFLOAD with an all-zero stateid. The client cannot match it to its pending COPY and waits forever in nfs42_proc_copy(). Also copy the new stateid into async_copy->cp_res.cb_stateid. Calling dup_copy_fields() after nfs4_init_copy_state() instead is not an option, because dup_copy_fields() also copies cp_stateid and would overwrite the stateid that the backport moved to the async copy. Tested on 6.18.56 with an NFSv4.2 server-side COPY between two exports: with this change the copy completes and CB_OFFLOAD carries the same stateid as the COPY reply. Without it, cp(1) hangs on 6.18.55; the affected code in nfsd4_copy() is the same in 6.18.56. Fixes: 9b4e5e9ba5ae ("nfsd: fix stale s2s_cp_stateids IDR entry for async COPY") Closes: https://lore.kernel.org/stable/7cc824c4-632d-49df-ae5e-cfcbb5bf76ad@proxmox.com/ Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Lubos Rendek <l.rendek@proxmox.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 22732b0f290ac06b938b60941b12874b341354b1) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 7d4d4f3 ] If the dm-integrity device has the SB_FLAG_DIRTY_BITMAP flag set and the user activates the device in the 'R' mode, a crash in dm_integrity_resume happens because the function attempts to read the journal containing the bitmap. This patch makes dm-integrity skip any writes to the device in dm_integrity_resume if the device is activated in the 'R' mode. Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Fixes: 468dfca ("dm integrity: add a bitmap mode") Cc: stable@vger.kernel.org Stable-dep-of: fc79aeb ("dm-integrity: validate the superblock on resume") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 2e25842f0e4423e0efb243f56153d842ed6b933f) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit fc79aeb ] dm_integrity_resume() re-reads the superblock from the device so that it picks up the flags and the recalculate position. It performs no validation on the result, while the constructor validates the superblock it reads and sizes all the in-memory structures according to it. The user may modify the superblock on the underlying device while the dm-integrity device is suspended, so that the two no longer agree. In particular, access_journal_data() shifts the journal entry index by ic->sb->log2_sectors_per_block, while ic->journal_section_sectors and the journal page list were computed with the value that was present at constructor time. Increasing log2_sectors_per_block makes the index run past the end of the journal, and dm-integrity then writes 512 bytes through lowmem_page_address(NULL). Snapshot the validated superblock in the constructor and refuse to resume if any of the fields that describe the on-disk geometry changed. Reported-by: syzbot+675c91651049ad042c5f@syzkaller.appspotmail.com Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Cc: stable@vger.kernel.org Fixes: 118ba36 ("dm-integrity: fix recalculation in bitmap mode") Assisted-by: Claude:claude-opus-5 Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 454b67fcc28c18502e47dfb9f067b04c28628ada) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…PF scheduler [ Upstream commit d35a535 ] A CPU going down has to empty its own rq. Its hotplug thread waits in sched_cpu_wait_empty() until nothing else is left, and the only thing that wakes it is balance_push(), which runs from __schedule() on the dying CPU and pushes off the migratable tasks the CPU picks. sched_ext breaks this. A task sitting on a user DSQ or held by the BPF scheduler is still counted on its rq, but an inactive CPU no longer calls ops.dispatch() and can't pull the task back. The dying CPU goes idle with the task still counted, and one of two things happens: - Another CPU consumes the task. The rq empties without a __schedule() on the dying CPU, so the hotplug thread is never woken and cpu_down() hangs holding cpu_hotplug_lock. - The task is affine only to the dying CPU. Nothing can move it, and the offline stalls until the watchdog ejects the BPF scheduler. When the rq goes offline, re-enqueue every task on it that isn't already on the local DSQ. An enqueue on an offline rq lands on the local DSQ, so the dying CPU itself picks the tasks and balance_push() pushes them off, the same as for the other sched classes. From then on no sched_ext path on another CPU can pull a task off the rq. ops.dispatch() currently stops as soon as the CPU goes inactive, and CPU hotplug then waits for an RCU grace period before taking the rq offline. A BPF-held task affine only to the dying CPU and preempted inside an RCU read-side critical section would block that grace period, and the rq would never go offline. Test SCX_RQ_ONLINE directly so that ops.dispatch() keeps running until the rq goes offline. Only the dying CPU's own hotplug thread clears the flag during teardown, and task_can_run_on_remote_rq() still keeps other rqs' tasks off the CPU. Fixes: f0e1a06 ("sched_ext: Implement BPF extensible scheduler class") Fixes: 991ef53 ("sched_ext: Make scx_rq_online() also test cpu_active() in addition to SCX_RQ_ONLINE") Cc: stable@vger.kernel.org # v6.12+ Reported-by: Alap Mohan <mohaalap@meta.com> Reported-by: Joonwoo Park <joonwoo@meta.com> Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com> [ sashal: adapted scx_dispatch_sched() changes to balance_one() in the unsplit sched_ext implementation. ] Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 638ee6bca19750934ea13f9c325f46fd8ae60064) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit ac02297 ] An RFCOMM connect() issued while a BR/EDR link is being authenticated makes lockdep report a circular dependency, and the reported cycle is a real AB/BA between rfcomm_mutex and hdev->lock. rfcomm_security_cfm() is called from the HCI event path, which already holds hdev->lock: hci_rx_work() hci_event_packet() hci_cc_read_enc_key_size() [hdev->lock] hci_encrypt_cfm() [hci_cb_list_lock] rfcomm_security_cfm() [rfcomm_mutex] while an RFCOMM connect() from userspace takes the same two locks the other way round: rfcomm_sock_connect() rfcomm_dlc_open() [rfcomm_mutex] __rfcomm_dlc_open() rfcomm_session_create() kernel_connect() l2cap_sock_connect() l2cap_chan_connect() [hdev->lock] WARNING: possible circular locking dependency detected kworker/u131:1/1128 is trying to acquire lock: rfcomm_mutex, at: rfcomm_security_cfm+0x31/0x3e0 [rfcomm] but task is already holding lock: hci_cb_list_lock, at: hci_cc_read_enc_key_size+0x1d2/0xcc0 Chain exists of: rfcomm_mutex --> &hdev->lock --> hci_cb_list_lock hci_auth_complete_evt() and hci_encrypt_change_evt() reach the callback the same way. Both orders have to be seen in the same boot, which is why a BR/EDR connection alone is not enough to show it: a session set up by the remote side is created by rfcomm_accept_connection() in krfcommd, which calls kernel_accept() and never takes hdev->lock under rfcomm_mutex. Connecting a device that authenticates and encrypts the link and then calling connect() on an RFCOMM socket towards any address - the connect does not have to succeed, the order is recorded before the page timeout - reports it every time. Only the session socket has to be connected with the lock held, and it does not: nothing else can see the socket before it is put on the session list. So connect it first and take rfcomm_mutex afterwards, which removes the rfcomm_mutex -> hdev->lock order for good, rather than keeping the HCI event path out of rfcomm_mutex. rfcomm_session_create() becomes rfcomm_session_connect(), which returns the connected socket without touching the session list, and rfcomm_dlc_open() adds the session once it holds the lock again. If another opener added a session for the same pair while this socket was connecting, that session is used and this socket is dropped. __rfcomm_dlc_open() now takes the session it should use, and its state check runs after the lock is re-acquired, so a DLC that was opened or closed in the meantime is still handled. Over an existing ACL link the connection can complete before the session reaches the list, and the wakeup from the socket callback is then lost, so krfcommd is woken once the session is visible. Connecting without the lock opens a window in which the socket can be closed. The DLC is not on a session yet, so rfcomm_dlc_close() finds nothing to do and returns without touching it, and rfcomm_dlc_open() would then attach a DLC whose owner is gone. rfcomm_dlc_close() now marks such a DLC with RFCOMM_CLOSED, and rfcomm_dlc_open() checks the mark once it holds rfcomm_mutex again and drops the socket instead of attaching the DLC. The mark is cleared when an open starts, so a DLC that is reused is not affected. This covers both callers of rfcomm_dlc_open(), the socket and the tty layer. Fixes: 759c185 ("Bluetooth: RFCOMM: serialize security confirmation handling") Suggested-by: Pauli Virtanen <pav@iki.fi> Reported-by: Pauli Virtanen <pav@iki.fi> Closes: https://lore.kernel.org/linux-bluetooth/5e76a95e934e451e7006db28827c2d64af5a88be.camel@iki.fi/ Reported-by: syzbot+74071deb72339c215b2e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-bluetooth/6a92fadc.08e933ee.dbf97.008f.GAE@google.com/ Reported-by: Jiaming Zhang <r772577952@gmail.com> Closes: https://lore.kernel.org/all/CANypQFabseTuRiyz2pGkc_Qj0moGDnY7KEp1qdTOqkw6gAL3hw@mail.gmail.com/ Cc: stable@vger.kernel.org Signed-off-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Tested-by: syzbot+74071deb72339c215b2e@syzkaller.appspotmail.com Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com> [ sashal: Retained the struct sockaddr * cast instead of struct sockaddr_unsized * to match kernel_connect()’s API. ] Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit cc7732b8549ecb6f02457edeb8db1f6d255e381c) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit bcf2573 ] In the dmaengine path the driver pre-submits RX buffers and holds in-flight TX buffers whose SKBs are DMA-mapped by the driver and freed only in the completion callbacks. On ndo_stop() dmaengine_terminate_sync() aborts these descriptors without running their callbacks, and the driver then frees only the ring shells, leaking every SKB still owned by the engine and its DMA mapping on each ifdown. With 128 RX buffers pre-posted per channel, the mapping leak can eventually exhaust a limited IOMMU aperture. Clear the slot's skb in the TX and RX callbacks so a non-NULL skb marks a slot that still owns a live, DMA-mapped buffer, and on stop unmap and free every such buffer. axienet_dma_rx_cb() runs from the DMA tasklet and re-arms the RX ring on each completion, so it can race axienet_stop(): a completion may submit a fresh buffer after dmaengine_terminate_sync() has returned, leaving the channel armed with a buffer the teardown then frees while the engine may still write into it (dma_release_channel() does not stop it either). Add a lock that axienet_dma_rx_cb() holds across the @stopping check and the resubmit, and axienet_stop() holds to set @stopping before terminating. Once @stopping is set no callback can arm a new buffer, and any armed just before is aborted by the terminate, so teardown only frees buffers the engine no longer owns. Fixes: 6a91b84 ("net: axienet: Introduce dmaengine support") Cc: stable@vger.kernel.org Signed-off-by: Suraj Gupta <suraj.gupta2@amd.com> Link: https://patch.msgid.link/20260928184207.2361931-1-suraj.gupta2@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> [ sashal: Adjusted context to retain kcalloc() instead of upstream’s kzalloc_objs(). ] Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit eececf7c3a679d9c08175ad6bacbc8c31848f5af) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 259c4a5 ] Commit 730ff06 ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.") started handing out RX buffers with zero headroom so that two buffers fit into one page at the default MTU. The MANA TX path, however, stores the per scatter-gather entry DMA mappings in `struct mana_skb_head` at skb->head, and mana_start_xmit() therefore calls skb_cow_head(skb, MANA_HEADROOM). The port advertises this requirement as ndev->needed_headroom = MANA_HEADROOM. As a result every packet that is received and then forwarded out of a MANA port fails the skb_cow() in ip_forward() and gets reallocated and copied by pskb_expand_head(). This is invisible to a plain RX or TX workload, but it puts a full skb reallocation plus memcpy on the hot path of every single forwarded packet, which is exactly what a router/NVA workload does. Restore the headroom. Note that reserving MANA_HEADROOM (232) is not enough: ip_forward() asks for LL_RESERVED_SPACE(dev), which rounds hard_header_len + needed_headroom up to HH_DATA_MOD and is 256 bytes on ethernet. Use LL_RESERVED_SPACE() directly so the value keeps tracking both constants. Also, since LL_RESERVED_SPACE() tracks MANA_HEADROOM, it grows with MAX_SKB_FRAGS and for MAX_SKB_FRAGS >= 19 it is greater than 256, so we have to account for that by using the headroom the RX queue actually uses (instead of assuming XDP_PACKET_HEADROOM) and turning MANA_XDP_MTU_MAX into MANA_XDP_MTU_MAX(ndev) (note that at the default CONFIG_MAX_SKB_FRAGS=17 they are equivalent). At the default MTU on a 4K page this means a buffer no longer fits twice into a page (SKB_DATA_ALIGN(1500 + MANA_RXBUF_PAD + 256) = 2112), so the frag-vs-single decision is now made by computing the real buffer size instead of comparing the MTU against PAGE_SIZE / 2. The page_pool fragment path is still used wherever at least two buffers genuinely fit, e.g. on 16K and 64K page sizes. Measured on an Azure VM with a MANA NIC acting as a forwarding NVA (UDP, 1400 byte payload, 4 streams, 8 Gbps offered, only the forwarding node's kernel differs), 8 runs each, median: forwarded pps throughput before 272,830 3.06 Gbps after 390,560 4.37 Gbps (+43%) perf on the forwarding node, same workload: memset_orig __pi_memcpy pskb_expand_head before 10.07% 3.96% present after 0.94% 0.64% gone Cc: stable@vger.kernel.org Fixes: 730ff06 ("net: mana: Use page pool fragments for RX buffers instead of full pages to improve memory efficiency.") Signed-off-by: Hamza Mahfooz <hamzamahfooz@linux.microsoft.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20261003013647.2051416-1-hamzamahfooz@linux.microsoft.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> [ sashal: Kept headroom and buffer-sizing calculations in mana_get_rxbuf_cfg() because full-page RX flag support is absent. ] Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 08275dcfbfc3b2ce2977b45171028ad92e256c94) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 6b60a12 ] Similarly to commit 8d09e2d ("arm64: patching: avoid early page_to_phys()"), avoid using phys_to_page() for the kernel address case in patch_map(). Since this is called from apply_boot_alternatives() in setup_arch(), and commit 4267739 ("arch, mm: consolidate initialization of SPARSE memory model") has moved sparse_init() to after setup_arch(), phys_to_page() is not available there yet, and it panics on boot with SPARSEMEM on RV32, which does not use SPARSEMEM_VMEMMAP. Reported-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Closes: https://lore.kernel.org/r/20260223144108-dcace0b9-02e8-4b67-a7ce-f263bed36f26@linutronix.de/ Fixes: 4267739 ("arch, mm: consolidate initialization of SPARSE memory model") Suggested-by: Mike Rapoport <rppt@kernel.org> Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Tested-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de> Link: https://patch.msgid.link/20260310-riscv-sparsemem-alternatives-fix-v1-1-659d5dd257e2@iscas.ac.cn [pjw@kernel.org: fix the subject line to align with the patch description] Signed-off-by: Paul Walmsley <pjw@kernel.org> Stable-dep-of: a510e1a ("riscv: patch: fix handling of bpf-jit execmem addresses") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 420bf39a22a73d4f06fd66de5b06c2b4639b06a9) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit a510e1a ] Commit 8718e5a ("riscv: patch: skip fixmap mapping when kernel text is already writable") gated the core_kernel_text() branch of patch_map() on CONFIG_STRICT_KERNEL_RWX, and explicitly left the vmalloc branch unchanged. That branch has a separate problem. That branch only creates a temporary writable fixmap alias when CONFIG_STRICT_MODULE_RWX is enabled, and otherwise assumes the target is directly writable and returns the address unchanged. That assumption no longer holds: bpf_prog_pack_alloc calls set_memory_rox() on every pack unconditionally in alloc_new_pack(), independently of any CONFIG_STRICT_*_RWX option, so BPF text in the vmalloc area is read-only regardless of what CONFIG_STRICT_MODULE_RWX says. With CONFIG_STRICT_MODULE_RWX=n, patch_map() returns the read-only address directly, the subsequent copy_to_kernel_nofault() takes a page fault and returns -EFAULT. bpf_arch_text_copy() turns that into -EINVAL, which propagates through bpf_jit_binary_pack_finalize() to the WARN_ON() in bpf_int_jit_compile() and leaves the program un-JITed. Note that BPF cannot be fixed the way kprobes was in commit bdc46e5 ("riscv: mm: make EXECMEM_KPROBES writable without CONFIG_STRICT_MODULE_RWX"). EXECMEM_BPF is already PAGE_KERNEL, i.e. writable at allocation time; the read-only mapping is established afterwards by generic code in alloc_new_pack(), which arch code cannot influence. The only place this can be handled is patch_map(). This is the same problem that was fixed on arm64 by commit b1480ed ("arm64: patching: fix handling of execmem addresses"), and the fix is the same: CONFIG_EXECMEM is what actually tracks whether the vmalloc area can hold executable memory that needs a temporary alias to be written. CONFIG_BPF_JIT, CONFIG_KPROBES and CONFIG_MODULES all select it. Note that this is not limited to CONFIG_MODULES=n. Unlike arm64, riscv selects CONFIG_ARCH_OPTIONAL_KERNEL_RWX, so CONFIG_STRICT_MODULE_RWX can be disabled with CONFIG_MODULES=y as well, and the bug is reachable in that configuration too. The !CONFIG_MMU build is unaffected: it has its own __patch_insn_set() and __patch_insn_write() implementations and never calls patch_map(). Fixes: 2c9e5d4 ("bpf: remove CONFIG_BPF_JIT dependency on CONFIG_MODULES of") Signed-off-by: Wei-Jie Hung <imbigking12@gmail.com> Reviewed-by: Pu Lehui <pulehui@huawei.com> Tested-by: Pu Lehui <pulehui@huawei.com> Link: https://patch.msgid.link/20260914115607.350097-1-imbigking12@gmail.com Cc: stable@vger.kernel.org Signed-off-by: Paul Walmsley <pjw@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 9e8fc7972b398e9dc2415ece283d8f64edac3858) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 469fa05 ] In MCQ mode, ufshcd_mcq_compl_pending_transfer() uses blk_mq_tagset_busy_iter() to iterate over busy requests during error recovery and host reset. However, both iterator callbacks perform whole-queue operations redundantly for each visited request: - force_compl == true: ufshcd_mcq_force_compl_one() calls ufshcd_mcq_compl_all_cqes_lock() on every busy request, sweeping the entire completion ring (hwq->max_entries slots) once per active request under spin_lock_irqsave even though the first sweep already cleared all completion entries. - force_compl == false: ufshcd_mcq_compl_one() acquires cq_lock and polls CQTPy over MMIO via ufshcd_mcq_poll_cqe_lock() for every busy request without doing any per-request work. Sweep or poll each hardware queue (hba->uhq[i]) once at the start of ufshcd_mcq_compl_pending_transfer(). When force_compl is true, run blk_mq_tagset_busy_iter() afterward to complete residual in-flight requests with DID_REQUEUE, and remove the now-unused ufshcd_mcq_compl_one() callback. Fixes: ab24864 ("scsi: ufs: core: Add error handling for MCQ mode") Cc: stable@vger.kernel.org Reviewed-by: Bart Van Assche <bvanassche@acm.org> Signed-off-by: Stanley Jhu <stanleyjhu@google.com> Reviewed-by: Peter Wang <peter.wang@mediatek.com> Link: https://patch.msgid.link/20260928035816.1294326-3-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 8176ec7e369873cb11573779a264d0c8b183f218) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 27c0f71 ] ch_readconfig() looks up the scsi_device of every data transfer element whose SCSI id the changer reports in READ ELEMENT STATUS, and stores it in ch->dt[]. scsi_device_lookup() takes a reference, and nothing ever drops it: ch_destroy() frees the array with kfree(). ch->dt[] is read nowhere else - it only supplies the vendor, model and revision printed in the same loop. Once such a drive is removed, its scsi_device can never be released. It stays on the host's device list at its address, so a new device there is refused by anything that walks the list - target_core_pscsi reports "scsi_device_get() failed for H:C:T:L" - and the low-level driver's module can no longer be unloaded. Only a reboot recovers. It shows with any changer that reports its drives' ids; with the mhvtl virtual library (IBM 3573-TL personality), each create and remove of a library with four drives leaves four references behind, counted by the module's use count in lsmod. With ch not bound the count is unchanged, and with this patch applied it is unchanged too. Drop the reference as soon as the name has been printed, and remove the now unused dt[] array. That also removes the array leaked when ch_probe() fails after ch_readconfig(). The same leak was reported with an RFC patch in 2022, which was not merged. Fixes: daa6eda ("[SCSI] add scsi changer driver") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-scsi/20220719075442.6215-1-yanghao_ht@163.com/ Signed-off-by: Ahmed Abdelhaleem Ahmed <ahmedhal@gmail.com> Reviewed-by: Laurence Oberman <loberman@redhat.com> Fixes: daa6eda ("[SCSI] add scsi changer driver") Link: https://patch.msgid.link/20260929-ch-dt-leak-v2-1-ddda8d635dca@gmail.com Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org> [ sashal: Adapted allocation removal from kzalloc_objs() to the existing two-line kcalloc() call. ] Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit a34a230ccea1b8b667ae59dca11295a2c8f81738) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit dd4299a ] Since 'tag' is only used inside the if-statement, move the 'tag' assignment into the if-statement. This patch prepares for introducing a WARN_ON_ONCE() call in ufshcd_mcq_get_tag() if the tag lookup fails. Reviewed-by: Avri Altman <avri.altman@sandisk.com> Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20251031204029.2883185-9-bvanassche@acm.org Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Stable-dep-of: 375f3a5 ("scsi: ufs: core: Avoid unsafe MMIO reads in ufshcd_mcq_compl_all_cqes_lock()") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit d12c834b97c36e89fdfc0684a869c802c620a076) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 3abe411 ] It is difficult to debug situations where an MCQ command timeout occurs, the corresponding CQ tag response is received, but the request is not completed. Add a one-line log to indicate when the CQ entry is abnormal. Signed-off-by: Peter Wang <peter.wang@mediatek.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20260210070837.1820710-3-peter.wang@mediatek.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Stable-dep-of: 375f3a5 ("scsi: ufs: core: Avoid unsafe MMIO reads in ufshcd_mcq_compl_all_cqes_lock()") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit e36bac5923a3bd50b2ad3932d1e1fefa4855f61b) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…lock() [ Upstream commit 1373df8 ] Document the aspects of ufshcd_mcq_compl_all_cqes_lock() that are nontrivial in a comment block above this function. Signed-off-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Peter Wang <peter.wang@mediatek.com> Link: https://patch.msgid.link/20260401202506.1445324-2-bvanassche@acm.org Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Stable-dep-of: 375f3a5 ("scsi: ufs: core: Avoid unsafe MMIO reads in ufshcd_mcq_compl_all_cqes_lock()") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit ee01d48f0f086fbaa254a69e78dafa244f72642c) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
…_lock() [ Upstream commit 375f3a5 ] During MCQ host reset, ufshcd_host_reset_and_restore() stops the host controller via ufshcd_hba_stop() (HCE = 0) before calling ufshcd_complete_requests(hba, true) -> ufshcd_mcq_compl_pending_transfer(hba, true) -> ufshcd_mcq_force_compl_one() -> ufshcd_mcq_compl_all_cqes_lock(). Because ufshcd_mcq_force_compl_one() is its sole caller, ufshcd_mcq_compl_all_cqes_lock() always runs with HCE = 0. Despite the comment above ufshcd_mcq_compl_all_cqes_lock() stating that reading CQTPy may not be safe with the controller disabled, the function still calls ufshcd_mcq_update_cq_tail_slot() at the end of its sweep: 1. Unsafe CQTPy MMIO read: Calling ufshcd_mcq_update_cq_tail_slot() at the end of the sweep reads CQTPy over MMIO while HCE = 0, directly contradicting the function's documented contract (commit 1373df8 ("scsi: ufs: core: Add a comment block above ufshcd_mcq_compl_all_cqes_lock()")) that reading CQTPy may not be safe with the controller disabled. 2. Spurious error logs on empty slots: Sweeping all max_entries slots visits empty entries where command_desc_base_addr is 0, causing ufshcd_mcq_process_cqe() to log unguarded dev_err(hba->dev, "Abnormal CQ entry!\n") messages. Fix both issues in ufshcd_mcq_compl_all_cqes_lock(): - Remove the ufshcd_mcq_update_cq_tail_slot() call and the redundant hwq->cq_head_slot = hwq->cq_tail_slot assignment without replacement. The two indices are already equal after the sweep: they are equal when the sweep starts, since ufshcd_mcq_poll_cqe_lock() consumes entries until cq_head_slot reaches cq_tail_slot, and the sweep advances cq_head_slot by exactly one full ring. Both indices are also reinitialized before the queue is reused. - Extract ufshcd_mcq_compl_cqe() and invoke it only on non-empty slots during full-ring sweeps, keeping "Abnormal CQ entry!" logging strictly for unexpected empty entries in ufshcd_mcq_poll_cqe_lock(). Fixes: ab24864 ("scsi: ufs: core: Add error handling for MCQ mode") Cc: stable@vger.kernel.org Reviewed-by: Peter Wang <peter.wang@mediatek.com> Signed-off-by: Stanley Jhu <stanleyjhu@google.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20260928035816.1294326-2-stanleyjhu@google.com Signed-off-by: Martin K. Petersen (Oracle) <mkp@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 97e736000731f134cf75f4b4fc920e47bc6a0790) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 611857a ] xe_i2c_notifier() stores the DesignWare adapter in i2c->adapter and schedules i2c->work when the adapter is registered under the xe I2C platform device, and xe_i2c_client_work() then instantiates the AMC client device on that adapter. xe_i2c_remove() tears down the AMC, unregisters the client devices, the bus notifier and the adapter platform device, but it never drains i2c->work. A work item that is still queued or running when the adapter is unregistered dereferences i2c->adapter in i2c_new_client_device() after platform_device_unregister() has released the adapter. The work item is also embedded in the devm-allocated struct xe_i2c, so a work item still queued after the drm device devm unwind frees that allocation runs its callback on freed memory. The bus notifier is the only thing that schedules this work, and it is unregistered after the client devices. An instance that is still queued when the teardown runs can therefore write i2c->client[XE_I2C_CLIENT_AMC] while the loop is unregistering and clearing the same array, and an AMC client it instantiates late is only cleaned up by the adapter's own child sweep in i2c_del_adapter(). Move bus_unregister_notifier() in front of the client teardown loop and cancel the work right after it, so no new instance can be scheduled and a queued instance is drained before the client array is touched. A running instance still finds a live adapter, since the adapter is unregistered later. Fixes: f0e53aa ("drm/xe: Support for I2C attached MCUs") Link: https://lore.kernel.org/intel-xe/20260912085932.101598-1-fanwu01@zju.edu.cn/ Cc: stable@vger.kernel.org Assisted-by: LLM, in-house static analysis tool Co-developed-by: Song Li <songl@zju.edu.cn> Signed-off-by: Song Li <songl@zju.edu.cn> Signed-off-by: Fan Wu <fanwu01@zju.edu.cn> Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://patch.msgid.link/20260928013030.612592-1-fanwu01@zju.edu.cn Link: https://patch.msgid.link/20261006000413.318561-2-rodrigo.vivi@intel.com Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> (cherry picked from commit a23f27d5ec11c3f418c5e5531eea34ccda2b5b20) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> [ sashal: Adjusted xe_i2c_remove() context for the older teardown implementation. ] Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 2efa187fd4c9b8d7edcae0c1acf46739ce39fd01) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit ecababf ] cifs_file_set_size() calls cifs_setsize() on success, which calls i_size_write(), updating i_size to the new value. The subsequent check attrs->ia_size != i_size_read() in both cifs_setattr_unix() and cifs_setattr_nounix() therefore always evaluates false after a successful cifs_file_set_size(), making the smp_store_release() of time_last_write dead code. The truncate path was unprotected against stale readdir size updates. Move the stamp to before the cifs_file_set_size() RPC call, guarded by attrs->ia_size != i_size_read() to exclude no-op same-size ftruncate(2) calls from stamping time_last_write unnecessarily. On the error path the stamp remains rather than being restored: restoring a stale snapshot (prev_tlw) could silently erase a concurrent _cifsFileInfo_put() close stamp if that close arrived between the READ_ONCE and the smp_store_release. readdir is suppressed until the stamp expires, which extends beyond one acregmax if the caller retries failed truncations. stat() is unaffected: the cifs_revalidate_dentry_attr() path calls cifs_fattr_to_inode() with from_readdir=false, which bypasses the time_last_write check in is_size_safe_to_change() entirely and always writes the authoritative QUERY_INFO result to i_size. Remove the now-unreachable stamp from the dead block in both functions. Fixes: e8a8d54 ("cifs: prevent readdir from changing file size due to stale directory metadata") Signed-off-by: Frank Sorenson <sorenson@redhat.com> Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Signed-off-by: Steve French <stfrench@microsoft.com> [ sashal: removed the timestamp write from cifs_file_set_size() because the original size-update blocks were already deleted ] Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit f6c1e709a4f9184577201a3087b1488f248a800f) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 6a28755 upstream. The FAT specification[1] (FAT Directory Structure -> "DIR_Name[0]") states: If DIR_Name[0] == 0x00, then the directory entry is free (same as for 0xE5), and there are no allocated directory entries after this one (all of the DIR_Name[0] bytes in all of the entries after this one are also set to 0). The special 0 value, rather than the 0xE5 value, indicates to FAT file system driver code that the rest of the entries in this directory do not need to be examined because they are all free. Linux did not honour this. fat_get_entry() kept advancing past the 0x00 terminator; if the trailing on-disk slots were not zero-filled (buggy formatters, read-only media written by other operating systems, on-disk corruption) the driver surfaced arbitrary bytes as real directory entries. On a typical affected image, `ls /mnt` returns ~150 bogus entries with random binary names, multi-gigabyte sizes, dates ranging from 1980 to 2106, and a flood of -EIO from stat(). Earlier attempts (v1..v3, see [2][3][4]) added `de->name[0] == 0` guards at each call site. As Hirofumi pointed out on v3, those guards reject the entry but fat_get_entry() has already advanced *pos past it; the next readdir() resumes after the marker and walks straight back into the garbage. His suggestion was to centralise the check. This patch: * Adds fat_get_entry_eod(), a small wrapper around fat_get_entry() that returns -1 when name[0] == 0 and seeks *pos to dir->i_size. Per spec every slot after the 0x00 marker is also zero, so jumping to the end of the directory is correct: subsequent reads return -1 from fat_bmap() without re-fetching trailing zero slots, and callers persisting *pos across invocations (notably readdir's ctx->pos) keep reporting end-of-directory on re-entry. * Converts the read/search paths to use the new wrapper: fat_parse_long(), fat_search_long(), __fat_readdir(), and fat_get_short_entry() -- the last covers fat_get_dotdot_entry(), fat_dir_empty(), fat_subdirs(), fat_scan(), and fat_scan_logstart() transitively. * Leaves fat_add_entries() and __fat_remove_entries() on raw fat_get_entry(): the write paths legitimately need to operate on free/zero slots. fat_add_entries() additionally detects an allocated entry past a 0x00 marker (the spec violation that produces the garbage) and treats it as filesystem corruption: fat_fs_error_ratelimit() is called -- which honours the configured errors= mount option (panic / remount-ro / continue) -- and the operation returns -EIO so we don't write fresh entries into an already-corrupt directory. [1] https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc [2] https://lore.kernel.org/lkml/20181207013410.7050-1-mcroce@redhat.com/ [3] https://lore.kernel.org/lkml/20181216231510.26854-1-mcroce@redhat.com/ [4] https://lore.kernel.org/lkml/20190201001408.7453-1-mcroce@redhat.com/ Reported-by: Timothy Redaelli <tredaelli@redhat.com> Suggested-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Matteo Croce <teknoraver@meta.com> Link: https://patch.msgid.link/20260616163346.32603-1-technoboy85@gmail.com Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org> Cc: Nicolai Buchwitz <nb@tipi-net.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 7d6fd507464821220a40a0e55f53cda862cc15bb) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit c200892 ] Currently, when in-kernel module decompression (CONFIG_MODULE_DECOMPRESS) is enabled, IMA has no way to verify the appended module signature as it can't decompress the module. Define a new kernel_read_file_id enumerate READING_MODULE_COMPRESSED so IMA can calculate the compressed kernel module data hash on READING_MODULE_COMPRESSED and defer appraising/measuring it until on READING_MODULE when the module has been decompressed. Before enabling in-kernel module decompression, a kernel module in initramfs can still be loaded with ima_policy=secure_boot. So adjust the kernel module rule in secure_boot policy to allow either an IMA signature OR an appended signature i.e. to use "appraise func=MODULE_CHECK appraise_type=imasig|modsig". Reported-by: Karel Srot <ksrot@redhat.com> Suggested-by: Mimi Zohar <zohar@linux.ibm.com> Suggested-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Coiby Xu <coxu@redhat.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Stable-dep-of: 377cae9 ("ima: Fix stack-out-of-bounds in is_bprm_creds_for_exec()") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 265ca3f6524be05039099582818521fb218c5917) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 377cae9 ] KASAN reported a stack-out-of-bounds access in ima_appraise_measurement from is_bprm_creds_for_exec: BUG: KASAN: stack-out-of-bounds in ima_appraise_measurement+0x12dc/0x16a0 Read of size 1 at addr ffffc9000160f940 by task sudo/550 The buggy address belongs to stack of task sudo/550 and is located at offset 24 in frame: ima_appraise_measurement+0x0/0x16a0 This frame has 2 objects: [48, 56) 'file' [80, 148) 'hash' This is caused by using container_of on the *file pointer. This offset calculation is what triggers the stack-out-of-bounds error. In order to fix this, pass in a bprm_is_check boolean which can be set depending on how process_measurement is called. If the caller has a linux_binprm pointer and the function is BPRM_CHECK we can determine is_check and set it then. Otherwise set it to false. Fixes: 95b3cda ("ima: instantiate the bprm_creds_for_exec() hook") Signed-off-by: Chris J Arges <carges@cloudflare.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 0f39d936a34933ebfbdc13a04f0aba814d3b9709) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit ce4e789 ] Factor out wrapper xfs_attr3_node_entry_remove function, which exported for external use. Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Long Li <leo.lilong@huawei.com> Signed-off-by: Carlos Maiolino <cem@kernel.org> Stable-dep-of: b854e1c ("xfs: close crash window in attr dabtree inactivation") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 50144efd23ad9f939aed83ecbc83d4a12c8b9a79) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit e65bb55 ] Factor out wrapper xfs_attr3_leaf_init function, which exported for external use. Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Long Li <leo.lilong@huawei.com> Signed-off-by: Carlos Maiolino <cem@kernel.org> Stable-dep-of: b854e1c ("xfs: close crash window in attr dabtree inactivation") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 4b963fddf470fc55838349bdca5e86e816e68df0) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit b854e1c ] When inactivating an inode with node-format extended attributes, xfs_attr3_node_inactive() invalidates all child leaf/node blocks via xfs_trans_binval(), but intentionally does not remove the corresponding entries from their parent node blocks. The implicit assumption is that xfs_attr_inactive() will truncate the entire attr fork to zero extents afterwards, so log recovery will never reach the root node and follow those stale pointers. However, if a log shutdown occurs after the leaf/node block cancellations commit but before the attr bmap truncation commits, this assumption breaks. Recovery replays the attr bmap intact (the inode still has attr fork extents), but suppresses replay of all cancelled leaf/node blocks, maybe leaving them as stale data on disk. On the next mount, xlog_recover_process_iunlinks() retries inactivation and attempts to read the root node via the attr bmap. If the root node was not replayed, reading the unreplayed root block triggers a metadata verification failure immediately; if it was replayed, following its child pointers to unreplayed child blocks triggers the same failure: XFS (pmem0): Metadata corruption detected at xfs_da3_node_read_verify+0x53/0x220, xfs_da3_node block 0x78 XFS (pmem0): Unmount and run xfs_repair XFS (pmem0): First 128 bytes of corrupted metadata buffer: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ XFS (pmem0): metadata I/O error in "xfs_da_read_buf+0x104/0x190" at daddr 0x78 len 8 error 117 Fix this in two places: In xfs_attr3_node_inactive(), after calling xfs_trans_binval() on a child block, immediately remove the entry that references it from the parent node in the same transaction. This eliminates the window where the parent holds a pointer to a cancelled block. Once all children are removed, the now-empty root node is converted to a leaf block within the same transaction. This node-to-leaf conversion is necessary for crash safety. If the system shutdown after the empty node is written to the log but before the second-phase bmap truncation commits, log recovery will attempt to verify the root block on disk. xfs_da3_node_verify() does not permit a node block with count == 0; such a block will fail verification and trigger a metadata corruption shutdown. on the other hand, leaf blocks are allowed to have this transient state. In xfs_attr_inactive(), split the attr fork truncation into two explicit phases. First, truncate all extents beyond the root block (the child extents whose parent references have already been removed above). Second, invalidate the root block and truncate the attr bmap to zero in a single transaction. The two operations in the second phase must be atomic: as long as the attr bmap has any non-zero length, recovery can follow it to the root block, so the root block invalidation must commit together with the bmap-to-zero truncation. Fixes: 1da177e ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Signed-off-by: Long Li <leo.lilong@huawei.com> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Carlos Maiolino <cem@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 7ea3850b9ce005e70f502b308edb2d99ca074ed3) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 69714a7 ] damos_walk() request is canceled after damon_ctx->kdamond is reset. This can make weird situations where damon_is_running() returns false but the DAMON context has the damos_walk() request linked. There was a similar situation for damon_call() requests handling [1], which _was_ able to cause a racy use-after-free bug. Unlike the case of damon_call(), because damos_walk() is always synchronously handled and allows only single request at time, there is no such problematic race cases. But, keeping it as is could stem another subtle race condition bug in future. Avoid that by cancelling the requests before the ->kdamond reset. Note that this change also makes all damon_ctx dependent resource cleanups consistently done before the damon_ctx->kdamond reset. Link: https://lkml.kernel.org/r/20260117175256.82826-4-sj@kernel.org Link: https://lore.kernel.org/20251230014532.47563-1-sj@kernel.org [1] Signed-off-by: SeongJae Park <sj@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Stable-dep-of: 33c3f6c ("mm/damon/core: fix damos_walk() vs kdamond_fn() exit race") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 7e54ed8a780c8151350c073f3a91ca1da52c11b0) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 33c3f6c ] When kdamond_fn() main loop is finished, the function cancels remaining damos_walk() request and unset the damon_ctx->kdamond so that API callers and API functions themselves can show the context is terminated. damos_walk() adds the caller's request to the queue first. After that, it shows if the kdamond of the damon_ctx is still running (damon_ctx->kdamond is set). Only if the kdamond is running, damos_walk() starts waiting for the kdamond's handling of the newly added request. The damos_walk() requests registration and damon_ctx->kdamond unset are protected by different mutexes, though. Hence, damos_walk() could race with damon_ctx->kdamond unset, and result in deadlocks. For example, let's suppose kdamond successfully finished the damow_walk() request cancelling. Right after that, damos_walk() is called for the context. It registers the new request, and shows the context is still running, because damon_ctx->kdamond unset is not yet done. Hence the damos_walk() caller starts waiting for the handling of the request. However, the kdamond is already on the termination steps, so it never handles the new request. As a result, the damos_walk() caller thread infinitely waits. Fix this by introducing another damon_ctx field, namely walk_control_obsolete. It is protected by the damon_ctx->walk_control_lock, which protects damos_walk() request registration. Initialize (unset) it in kdamond_fn() before letting damon_start() returns and set it just before the cancelling of the remaining damos_walk() request is executed. damos_walk() reads the obsolete field under the lock and avoids adding a new request. After this change, only requests that are guaranteed to be handled or cancelled are registered. Hence the after-registration DAMON context termination check is no longer needed. Remove it together. The issue is found by sashiko [1]. Link: https://lore.kernel.org/20260327233319.3528-3-sj@kernel.org Link: https://lore.kernel.org/20260325141956.87144-1-sj@kernel.org [1] Fixes: bf0eaba ("mm/damon/core: implement damos_walk()") Signed-off-by: SeongJae Park <sj@kernel.org> Cc: <stable@vger.kernel.org> # 6.14.x Signed-off-by: Andrew Morton <akpm@linux-foundation.org> and API functions themselves can show the context is terminated. damos_walk() adds the caller's request to the queue first. After that, it shows if the kdamond of the damon_ctx is still running (damon_ctx->kdamond is set). Only if the kdamond is running, damos_walk() starts waiting for the kdamond's handling of the newly added request. The damos_walk() requests registration and damon_ctx->kdamond unset are protected by different mutexes, though. Hence, damos_walk() could race with damon_ctx->kdamond unset, and result in deadlocks. For example, let's suppose kdamond successfully finished the damow_walk() request cancelling. Right after that, damos_walk() is called for the context. It registers the new request, and shows the context is still running, because damon_ctx->kdamond unset is not yet done. Hence the damos_walk() caller starts waiting for the handling of the request. Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 93a7f297362deac614ce3dbbba73ff2ba31aaca3) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit a02cd68 ] Currently there can only be a single open of /sys/fs/selinux/policy at any time. This allows any process to block any other process from reading the kernel policy. The original motivation seems to have been a mix of preventing an inconsistent view of the policy size and preventing userspace from allocating kernel memory without bound, but this is arguably equally bad. Eliminate the policy_opened flag and shrink the critical section that the policy mutex is held. While we are making changes here, drop a couple of extraneous BUG_ONs. Cc: stable@vger.kernel.org Link: https://lore.kernel.org/selinux/20100726193414.19538.64028.stgit@paris.rdu.redhat.com/ Signed-off-by: Stephen Smalley <stephen.smalley.work@gmail.com> Signed-off-by: Paul Moore <paul@paul-moore.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit c24d2e190b955baf3a95e05d34b192f61bd201b3) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 56dd290 ] The driver saves the minor number it gets upon registration in its descriptor for debugging purposes. However, there is inevitably a window between registration and saving the correct minor in a descriptor. During this window the debugging output will be wrong. As wrong debug output is worse than no debug output, just remove it. Signed-off-by: Oliver Neukum <oneukum@suse.com> Link: https://patch.msgid.link/20260312094619.1590556-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Stable-dep-of: c602254 ("USB: iowarrior: fix use-after-free on disconnect race") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit e8ed9a1dfc74fc85b3a203ab6317110d537981c8) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit c602254 ] mutex_unlock() may access the mutex structure after releasing the lock and therefore cannot be used to manage lifetime of objects directly (unlike spinlocks and refcounts). [1][2] Use a kref to release the driver data to avoid use-after-free in mutex_unlock() when release() races with disconnect(). [1] a51749a ("locking/mutex: Document that mutex_unlock() is non-atomic") [2] 2b9d9e0 ("locking/mutex: Clarify that mutex_unlock(), and most other sleeping locks, can still use the lock object after it's unlocked") Fixes: 946b960 ("USB: add driver for iowarrior devices.") Cc: stable <stable@kernel.org> Reported-by: Yue Sun <samsun1006219@gmail.com> Link: https://lore.kernel.org/r/20260618080204.38322-1-samsun1006219@gmail.com Signed-off-by: Johan Hovold <johan@kernel.org> Link: https://patch.msgid.link/20260622152612.116422-2-johan@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 30ec3025b771511625375fb3fb959aea3b45fb0d) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 6b0223a4795f5db52dee038a7a29e9906122b0f7 upstream.
rose_rx_call_request() creates the socket for an incoming call and
queues the call's skb on the listening socket with skb->sk pointing at
it, without taking a reference. If the caller clears the call before
it is accepted, rose_disconnect() leaves that socket in STATE_0 with
SOCK_DEAD set, and since commit "rose: release netdev ref and destroy
orphaned incoming sockets" rose_heartbeat_expiry() reaps such orphaned
sockets and frees them. The skb stays on the listener's queue, so:
- closing the listener makes rose_destroy_socket() walk its queue and
set flags and restart the heartbeat on the freed socket;
- accept() can hand the freed socket to user space.
On a live node running a KASAN kernel, stopping the FPAC daemons shortly
after a local (loopback) call had been set up and dropped gave:
BUG: KASAN: slab-use-after-free in rose_destroy_socket+0x24a/0x570 [rose]
Write of size 8 ... by task fpacwpd
rose_destroy_socket
rose_release
Allocated by task 0: ... rose_rx_call_request <- rose_loopback_timer
Freed by task ...: ... sk_free <- rose_heartbeat_expiry
refcount_t: addition on 0; use-after-free.
rose_start_heartbeat <- rose_destroy_socket <- rose_release
followed a few seconds later by a page fault in the re-armed heartbeat
and a kernel panic.
Make the listener's queue own a reference on each pending socket,
taken when the call is queued and dropped by rose_accept() or by the
listener's rose_destroy_socket() once the skb is off the queue. Have
the heartbeat set SOCK_DESTROY under the socket lock before reaping a
dead socket, as the other reaping paths already do, and make both
consumers check it under the child's lock: rose_accept() skips a
reaped socket and waits for the next call, and rose_destroy_socket()
no longer re-arms the heartbeat of a socket that is gone.
Fixes: df12be096302 ("rose: release netdev ref and destroy orphaned incoming sockets")
Signed-off-by: Bernard Pidoux <bernard.f6bvp@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 314b72d5e82736d8ef5427db857363b4f2e33c87)
Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit b59cabf upstream. Commit 8078486 ("io_uring: use region api for SQ") and commit 81a4058 ("io_uring: use region api for CQ") made io_uring_setup() allocate the rings with io_create_region(). However, io_create_region() charges the memory to RLIMIT_MEMLOCK, and the rings had been exempt from that limit since commit 26bfa89 ("io_uring: place ring SQ/CQ arrays under memcg memory limits"). As of now, a user without CAP_IPC_LOCK gets ENOMEM from io_uring_setup() when their rings exceed the limit, which is 8 MiB by default. PostgreSQL developers have already hit this in their io_uring tests [1]. The issue can be reproduced with a simple liburing program, run as an unprivileged user: #include <liburing.h> #include <stdio.h> int main(void) { static struct io_uring ring[64]; int i; for (i = 0; i < 64; i++) if (io_uring_queue_init(4096, &ring[i], 0) < 0) break; printf("%d rings\n", i); return 0; } Before those commits (v6.13), it prints "64 rings". After those commits (v6.14), it prints "21 rings". This patch makes io_create_region() take the user to charge, and passes no user for the SQ/CQ rings. Link: https://www.postgresql.org/message-id/flat/667f7dcf-404b-4898-a426-57ca6e0617f6@gmail.com [1] Fixes: 8078486 ("io_uring: use region api for SQ") Fixes: 81a4058 ("io_uring: use region api for CQ") Cc: stable@vger.kernel.org Signed-off-by: Hengyu Liang <hengyul@cs.unc.edu> Link: https://lore.kernel.org/io-uring/20261006125732.3425762-1-hengyul@cs.unc.edu/ [axboe: 6.18 still has the ctx based region API. Convert io_create_region() and io_free_region() to take the user_struct, and add a user argument to io_create_region_mmap_safe()] Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit e46794d1936caadd3316ccfca194165af615191a) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit cde56da upstream. Just like with the SQ and CQ rings, the provided buffer rings were also not charged against the memlock limit prior to the below mentioned commit. Restore that behavior. Fixes: ef62de3 ("io_uring/kbuf: use region api for pbuf rings") Reported-by: Hengyu Liang <hengyul@cs.unc.edu> Cc: stable@vger.kernel.org Tested-by: Hengyu Liang <hengyul@cs.unc.edu> [axboe: 6.18 uses io_create_region_mmap_safe() for the pbuf ring] Signed-off-by: Jens Axboe <axboe@kernel.dk> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit a6d84b420a84843d837f729c298d98d8b070d314) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit b155151 ] Before commit fa759cd ("kho: allocate metadata directly from the buddy allocator"), the chunks were allocated from the slab allocator using kzalloc(). Those were rightly freed using kfree(). When the commit switched to using the buddy allocator directly, it missed updating kho_mem_ser_free() to use free_page() instead of kfree(). Link: https://lkml.kernel.org/r/20251118182218.63044-1-pratyush@kernel.org Fixes: fa759cd ("kho: allocate metadata directly from the buddy allocator") Signed-off-by: Pratyush Yadav <pratyush@kernel.org> Reviewed-by: Pasha Tatashin <pasha.tatashin@soleen.com> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Cc: Alexander Graf <graf@amazon.com> Cc: David Matlack <dmatlack@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Federico Parola <fparola@amazon.de> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 8b7748e9904f80fb597f4a00aa1d2322889e6f5a) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
… program [ Upstream commit 04af4ef ] tcp_bpf_ioctl() answers SIOCINQ from psock->msg_tot_len, which only counts bytes in ingress_msg. Without a stream/skb verdict program nothing is diverted there: data stays in sk_receive_queue, so FIONREAD returns 0 even though read() returns data. Add tcp_inq() to the reported value when the psock has no verdict program. The two queues are disjoint, so bytes redirected into ingress_msg from other sockets stay correctly accounted through msg_tot_len. Remove unused sk_psock_msg_inq(). Fixes: 929e30f ("bpf, sockmap: Fix FIONREAD for sockmap") Signed-off-by: Mattia Meleleo <mattia.meleleo@coralogix.com> Reviewed-by: Jiayuan Chen <jiayuan.chen@linux.dev> Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com> Reviewed-by: John Fastabend <john.fastabend@gmail.com> Link: https://lore.kernel.org/bpf/20260708-fionread-no-verdict-v3-1-b4ee31b3af53@coralogix.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 5c0940abe76c99484ed6d70a809fc653f59f0991) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
[ Upstream commit 9020135 ] This reverts commit 93ce8ea. Mehmet reported that the offending commit breaks his AR9271 USB adapter which uses zero-length replies to commands that don't return a value. Revert the whole thing to restore the functionality. Cc: stable@vger.kernel.org # the offending commit is in 6.12.113 Reported-by: Mehmet Fide <mehmet.fide@gmail.com> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 88c7c3aa8d0ffcb33ef81e4e9e0b40b594a49f9a) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit 23a0be6 upstream. In krb5_authenticate(), out_len is calculated to determine available headroom in response_buf for the incoming Kerberos AP-REP token. However, when SMB2_SESSION_SETUP is processed as a non-first element of a compounded SMB2 request, the calculation omits work->next_smb2_rsp_hdr_off. This causes out_len to overstate remaining buffer headroom by the cumulative size of prior responses in the compound chain. Consequently, the length check in ksmbd_krb5_authenticate() (*out_len <= resp->spnego_blob_len) passes erroneously, allowing memcpy() to write the AP-REP blob past the end of response_buf into adjacent kernel heap memory. Fix this by subtracting work->next_smb2_rsp_hdr_off when computing out_len, ensuring it accurately reflects physical remaining buffer space. Signed-off-by: Ilan Dudnik <ilan.dudnik@safebreach.com> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 517404e157395d0f8da125ca956c566895dfcd06) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
commit b3e6212 upstream. KVM tags the per-vCPU MMIO cache with a memslot generation so that a memslot update invalidates cached MMIO information. Both the fill and validation paths use kvm_memslots(), which unconditionally selects address space 0, even when the vCPU is running in SMM and using address space 1. Commit 56f17dd ("kvm: x86: fix stale mmio cache bug") added the memslot generation to the cache key so that a memslot update could not leave a stale entry valid. When commit 699023e ("KVM: x86: add SMM to the MMU role, support SMRAM address space") added the SMM address space, these helpers were not converted to use the active memslots. Consequently, an update to the SMM memslots can leave an entry from the old SMM address space apparently valid after the vCPU returns to the normal address space. A guest can then cause an access to valid RAM at the same GFN to be returned to userspace as KVM_EXIT_MMIO. Completing that exit through the VMM's RAM address space writes the backing page without going through KVM's write-tracking path. If the page backs a nested EPT table, KVM can continue using shadow translations derived from the old contents. The WARN_ON_ONCE() in kvm_mmu_write_protect_fault() catches this invalid cache and memslot combination. Use the vCPU's active memslots when caching and validating the entry. Memslot generations are unique across address spaces, so the generation also distinguishes the normal and SMM views. This matches the MMIO SPTE cache, which already uses kvm_vcpu_memslots(). On an unpatched current-mainline kernel, a regression test that fills the cache in SMM and updates only the SMM memslots fails the intended RAM write and triggers the kvm_mmu_write_protect_fault() warning. With this change, the same test completes the RAM write without a warning. The x86/smm_test, set_memory_region_test, and memslot_modification_stress_test selftests also pass. Fixes: 699023e ("KVM: x86: add SMM to the MMU role, support SMRAM address space") Cc: stable@vger.kernel.org Signed-off-by: Jinu Kim <kimjw04271234@gmail.com> Link: https://patch.msgid.link/20260807112818.958190-1-kimjw04271234@gmail.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 2566780c684c9c21241d409d790087c73070f312) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Link: https://lore.kernel.org/r/20261017155104.830766652@linuxfoundation.org Tested-by: Brett A C Sheffield <bacs@librecast.net> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Wentao Guan <guanwentao@uniontech.com> Tested-by: Miguel Ojeda <ojeda@kernel.org> Tested-by: SJ Park <sj@kernel.org> Tested-by: Sean Lyon <sean@seanlyon.dev> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Barry K. Nathan <barryn@pobox.com> Tested-by: Pavel Machek (CIP) <pavel@nabladev.com> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 2926d88bb7fc4608fd942453d929c39e4e5ec006) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Reviewer's GuideUpdates the kernel base to 6.18.58 by changing the sublevel and importing a wide upstream stable-kernel fix set, with notable changes to device power management, driver teardown and concurrency, filesystem integrity and recovery, io_uring accounting, VMA handling, protocol lifetimes, scheduler hotplug behavior, and security measurement and policy paths. Sequence diagram for synchronous iavf MAC address changessequenceDiagram
participant User
participant iavf_set_mac
participant PF
participant AdminQueue
User->>iavf_set_mac: iavf_set_mac
iavf_set_mac->>iavf_set_mac: iavf_set_mac_sync
iavf_set_mac_sync->>PF: iavf_add_ether_addrs
PF-->>AdminQueue: ADD_ETH_ADDR response
iavf_set_mac_sync->>AdminQueue: iavf_poll_virtchnl_response
AdminQueue->>iavf_set_mac_sync: iavf_virtchnl_completion
alt response received
iavf_set_mac_sync-->>User: success
else timeout
iavf_set_mac_sync-->>User: -EAGAIN
end
Sequence diagram for compressed kernel module integrity checkssequenceDiagram
participant Loader as init_module_from_file
participant Reader as kernel_read_file
participant Decompressor as module_decompress
participant IMA as security_kernel_post_read_file
participant SELinux as selinux_kernel_read_file
Loader->>Reader: kernel_read_file READING_MODULE_COMPRESSED
Reader-->>Loader: compressed module data
Loader->>Decompressor: module_decompress
Decompressor-->>Loader: decompressed module
Loader->>IMA: security_kernel_post_read_file READING_MODULE
IMA->>SELinux: selinux_kernel_read_file
SELinux-->>IMA: policy decision
IMA-->>Loader: integrity result
Flow diagram for dm-integrity superblock validation on resumeflowchart TD
Resume[dm_integrity_resume]
Read[sync_rw_sb]
Compare[superblock_changed]
Restore[Restore ic->sb from ic->sb_copy]
Error[dm_integrity_io_error]
Writes[Update flags and write superblock]
Resume --> Read
Read --> Compare
Compare -->|changed| Restore
Restore --> Error
Compare -->|unchanged| Writes
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Hey - I've found 2 issues
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path="security/selinux/selinuxfs.c" line_range="354-363" />
<code_context>
- BUG_ON(filp->private_data);
-
- mutex_lock(&selinux_state.policy_mutex);
-
rc = avc_has_perm(current_sid(), SECINITSID_SECURITY,
SECCLASS_SECURITY, SECURITY__READ_POLICY, NULL);
if (rc)
- goto err;
-
- rc = -EBUSY;
- if (fsi->policy_opened)
- goto err;
+ return rc;
- rc = -ENOMEM;
plm = kzalloc(sizeof(*plm), GFP_KERNEL);
if (!plm)
- goto err;
+ return -ENOMEM;
+ mutex_lock(&selinux_state.policy_mutex);
rc = security_read_policy(&plm->data, &plm->len);
if (rc)
goto err;
-
if ((size_t)i_size_read(inode) != plm->len) {
inode_lock(inode);
i_size_write(inode, plm->len);
inode_unlock(inode);
}
-
- fsi->policy_opened = 1;
+ mutex_unlock(&selinux_state.policy_mutex);
filp->private_data = plm;
</code_context>
<issue_to_address>
**Repeated policy opens exhaust kernel memory**
When a process granted SELinux policy-read permission repeatedly opens the policy file and keeps the descriptors open, `sel_open_policy()` calls `security_read_policy()` for each open, which allocates a separate `vmalloc_user()` policy image; `sel_release_policy()` keeps that image until the fd closes. Repeated opens can therefore exhaust kernel memory and destabilize the host.
Bound the number of active policy snapshots or otherwise account and cap their aggregate memory.
</issue_to_address>
### Comment 2
<location path="drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_0_ppt.c" line_range="1698" />
<code_context>
+ /* Create device link: USB (consumer) depends on GPU (supplier) */
+ link = device_link_add(&usb_pdev->dev, &gpu_pdev->dev,
+ DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME);
+ if (link) {
+ smu->usb_power_link = link;
+ drm_info(adev_to_drm(adev), "USB controller %s D0 power state depends on %s\n",
</code_context>
<issue_to_address>
**USB resume dependency is missing**
When device-link creation fails for a matching xHCI controller, `device_link_add()` returns `NULL`, but the helper reports success without recording that the dependency is missing, so initialization proceeds and USB can resume before the GPU.
Propagate device-link creation failure so initialization does not proceed without the USB-to-GPU dependency.
</issue_to_address>| mutex_lock(&selinux_state.policy_mutex); | ||
| rc = security_read_policy(&plm->data, &plm->len); | ||
| if (rc) | ||
| goto err; | ||
|
|
||
| if ((size_t)i_size_read(inode) != plm->len) { | ||
| inode_lock(inode); | ||
| i_size_write(inode, plm->len); | ||
| inode_unlock(inode); | ||
| } | ||
|
|
||
| fsi->policy_opened = 1; | ||
| mutex_unlock(&selinux_state.policy_mutex); |
There was a problem hiding this comment.
🟡 Medium · Repeated policy opens exhaust kernel memory
When a process granted SELinux policy-read permission repeatedly opens the policy file and keeps the descriptors open, sel_open_policy() calls security_read_policy() for each open, which allocates a separate vmalloc_user() policy image; sel_release_policy() keeps that image until the fd closes. Repeated opens can therefore exhaust kernel memory and destabilize the host.
Bound the number of active policy snapshots or otherwise account and cap their aggregate memory.
Prompt for AI agents
In `security/selinux/selinuxfs.c` at lines 354-363:
**Repeated policy opens exhaust kernel memory**
When a process granted SELinux policy-read permission repeatedly opens the policy file and keeps the descriptors open, `sel_open_policy()` calls `security_read_policy()` for each open, which allocates a separate `vmalloc_user()` policy image; `sel_release_policy()` keeps that image until the fd closes. Repeated opens can therefore exhaust kernel memory and destabilize the host.
Bound the number of active policy snapshots or otherwise account and cap their aggregate memory.| /* Create device link: USB (consumer) depends on GPU (supplier) */ | ||
| link = device_link_add(&usb_pdev->dev, &gpu_pdev->dev, | ||
| DL_FLAG_STATELESS | DL_FLAG_PM_RUNTIME); | ||
| if (link) { |
There was a problem hiding this comment.
🟡 Medium · USB resume dependency is missing
When device-link creation fails for a matching xHCI controller, device_link_add() returns NULL, but the helper reports success without recording that the dependency is missing, so initialization proceeds and USB can resume before the GPU.
Propagate device-link creation failure so initialization does not proceed without the USB-to-GPU dependency.
Prompt for AI agents
In `drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_0_ppt.c` at line 1698:
**USB resume dependency is missing**
When device-link creation fails for a matching xHCI controller, `device_link_add()` returns `NULL`, but the helper reports success without recording that the dependency is missing, so initialization proceeds and USB can resume before the GPU.
Propagate device-link creation failure so initialization does not proceed without the USB-to-GPU dependency.There was a problem hiding this comment.
🟡 Changes recommended
Unresolved critical issues allow truncated WMI replies to copy uninitialized data, GPU teardown to use a freed device link, and module appraisal to approve bytes using a replacement file’s cached digest.
8 open issues
Avoid deleting a stale USB power device link · New Validate USB WMI response length before copying payload · New Prevent inode writes during module decompression and appraisal · New Require a non-NULL shared PCIe root port · New Wait for the requested MAC operation to complete · New Rollback only this call's MAC filter changes · New Refresh the readdir-size timestamp after successful truncate · New Preserve LoadPin exclusion for compressed modules · New
What changed in this PR
Updates Deepin’s kernel base from 6.18.57 to 6.18.58, integrating upstream maintenance across core kernel subsystems and drivers.
Changes:
- Updates compressed-module integrity handling and security hooks.
- Addresses resource lifetimes, concurrency, memory accounting, and filesystem consistency.
- Revises supporting interfaces and adapts VMA tests.
| File | Description |
|---|---|
| tools/testing/vma/vma.c | Adapts tests to the extended VMA-copy interface. |
| security/selinux/selinuxfs.c | Allows concurrent policy opens with per-file snapshots. |
| security/selinux/hooks.c | Handles compressed-module reads. |
| security/ipe/hooks.c | Applies module policy to compressed modules. |
| security/integrity/ima/ima.h | Extends the appraisal interface with execution-check context. |
| security/integrity/ima/ima_policy.c | Enables module signatures and blacklist checks in secure-boot rules. |
| security/integrity/ima/ima_main.c | Supports deferred module appraisal and execution-check context. |
| security/integrity/ima/ima_appraise.c | Uses explicit execution-check context for audit messages. |
| net/rose/rose_timer.c | Marks pending sockets before destruction. |
| net/rose/af_rose.c | Adds pending-socket references and teardown synchronization. |
| net/ipv6/ip6_gre.c | Removes the ERSPAN destination-MTU update. |
| net/ipv4/tcp_bpf.c | Includes ordinary TCP data in receive-queue accounting. |
| net/bluetooth/rfcomm/core.c | Moves connection setup outside the RFCOMM mutex. |
| mm/vma.h | Updates VMA-copy and split declarations. |
| mm/vma.c | Prevents source self-merges when retaining mappings. |
| mm/mremap.c | Prepares locked mappings for remapping without unmapping. |
| mm/damon/core.c | Coordinates walk requests with monitoring shutdown. |
| Makefile | Sets the kernel sublevel to 58. |
| kernel/sched/sched.h | Documents another scheduler locking exception. |
| kernel/sched/ext.c | Keeps tasks runnable during CPU offlining. |
| kernel/module/main.c | Adds post-decompression security appraisal. |
| kernel/kexec_handover.c | Matches page allocation with page-based freeing. |
| io_uring/zcrx.c | Passes explicit users for memory accounting. |
| io_uring/register.c | Separates ring allocation from charged memory regions. |
| io_uring/memmap.h | Updates memory-region accounting interfaces. |
| io_uring/memmap.c | Makes user memory accounting explicit. |
| io_uring/kbuf.c | Exempts provided-buffer rings from memlock accounting. |
| io_uring/io_uring.c | Exempts submission and completion rings from memlock accounting. |
| include/net/mana/mana.h | Makes XDP MTU limits account for device headroom. |
| include/net/bluetooth/rfcomm.h | Defines a flag for closure during connection setup. |
| include/linux/skmsg.h | Removes the superseded receive-length helper. |
| include/linux/kernel_read_file.h | Adds a compressed-module read identifier. |
| include/linux/damon.h | Adds walk-request shutdown state. |
| fs/xfs/xfs_attr_inactive.c | Revises attribute-tree teardown for crash consistency. |
| fs/xfs/libxfs/xfs_da_btree.h | Declares the attribute-node entry-removal helper. |
| fs/xfs/libxfs/xfs_da_btree.c | Shares node-entry removal with attribute teardown. |
| fs/xfs/libxfs/xfs_attr_leaf.h | Declares the leaf-reinitialization helper. |
| fs/xfs/libxfs/xfs_attr_leaf.c | Adds empty-leaf reinitialization. |
| fs/smb/server/smb2pdu.c | Accounts for compound-response offsets in authentication buffers. |
| fs/smb/client/inode.c | Moves truncate timestamps before server requests. |
| fs/nfsd/nfs4proc.c | Preserves callback state identifiers for asynchronous copies. |
| fs/fat/dir.c | Honors end-of-directory markers during traversal. |
| drivers/usb/misc/iowarrior.c | Reference-counts device state across open and disconnect. |
| drivers/usb/gadget/function/f_hid.c | Reports character-device allocation failure correctly. |
| drivers/ufs/core/ufshcd.c | Drains completion queues before forced command completion. |
| drivers/ufs/core/ufs-mcq.c | Processes completions without accessing disabled-controller registers. |
| drivers/spi/spi-mpc52xx.c | Corrects interrupt-allocation failure cleanup. |
| drivers/scsi/ch.c | Releases temporary SCSI device references. |
| drivers/pci/controller/dwc/pcie-designware.c | Distinguishes PCIe link-startup failure states. |
| drivers/net/wireless/ath/ath9k/wmi.h | Removes response-status storage. |
| drivers/net/wireless/ath/ath9k/wmi.c | Removes short-response validation and error propagation. |
| drivers/net/ethernet/xilinx/xilinx_axienet.h | Adds receive-submission locking state and documentation. |
| drivers/net/ethernet/xilinx/xilinx_axienet_main.c | Synchronizes DMA teardown and reclaims remaining buffers. |
| drivers/net/ethernet/microsoft/mana/mana_en.c | Includes network-device headroom in receive-buffer sizing. |
| drivers/net/ethernet/microsoft/mana/mana_bpf.c | Uses configured receive headroom for XDP. |
| drivers/net/ethernet/intel/iavf/iavf.h | Declares synchronous response-polling interfaces. |
| drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | Adds response polling and filter-send error handling. |
| drivers/net/ethernet/intel/iavf/iavf_main.c | Polls synchronously for MAC-address changes. |
| drivers/md/dm-integrity.c | Validates superblock geometry on resume. |
| drivers/infiniband/hw/erdma/erdma_verbs.c | Uses interrupt-safe XArray operations. |
| drivers/infiniband/hw/erdma/erdma_main.c | Configures interrupt-safe XArray locking. |
| drivers/gpu/drm/xe/xe_i2c.c | Stops notifications and work before client teardown. |
| drivers/gpu/drm/amd/pm/swsmu/smu14/smu_v14_0_0_ppt.c | Creates an xHCI-to-GPU power dependency. |
| drivers/gpu/drm/amd/pm/swsmu/inc/amdgpu_smu.h | Adds power-dependency state and callbacks. |
| drivers/gpu/drm/amd/pm/swsmu/amdgpu_smu.c | Integrates power-dependency setup and teardown. |
| arch/x86/kvm/x86.h | Uses vCPU-specific memory-slot generations for MMIO caching. |
| arch/riscv/kernel/patch.c | Revises physical-address mapping for executable-memory patching. |
Review effort: Balanced
| if (smu->usb_power_link) { | ||
| device_link_del(smu->usb_power_link); | ||
| smu->usb_power_link = NULL; |
| if (wmi->cmd_rsp_buf != NULL && wmi->cmd_rsp_len != 0) | ||
| memcpy(wmi->cmd_rsp_buf, skb->data, wmi->cmd_rsp_len); |
| err = security_kernel_post_read_file(f, (char *)info.hdr, info.len, | ||
| READING_MODULE); |
| return 0; | ||
| } | ||
|
|
||
| root_port = pcie_find_root_port(gpu_pdev); |
| { | ||
| const u8 *addr = data; | ||
|
|
||
| return iavf_is_mac_set_handled(adapter->netdev, addr); |
| if (ret != -EAGAIN) { | ||
| iavf_mac_add_reject(adapter); | ||
| ether_addr_copy(adapter->hw.mac.addr, netdev->dev_addr); |
| if (rc == 0) | ||
| cifs_resize_file_locked(inode, size); |
| id(KEXEC_INITRAMFS, kexec-initramfs) \ | ||
| id(POLICY, security-policy) \ | ||
| id(X509_CERTIFICATE, x509-certificate) \ | ||
| id(MODULE_COMPRESSED, kernel-module-compressed) \ |


Update kernel base to 6.18.58.
Summary by Sourcery
Update the kernel base to 6.18.58 and incorporate the associated upstream stability, correctness, and security fixes.
Bug Fixes:
Enhancements:
Tests: