The linux-next integration testing tree https://git.landau.one/pub/scm/linux/kernel/git/next/linux-next.git/atom?h=master 2026-09-11T12:20:26+00:00 2026-09-11T12:20:26+00:00 Mark Brown broonie@kernel.org 2026-09-11T12:20:26+00:00 urn:sha1:55bdb828b1d8490efa4ee9006451b64c30995e78 2026-09-11T12:20:24+00:00 Mark Brown broonie@kernel.org 2026-09-11T12:20:24+00:00 urn:sha1:5bc2d23ff5760f308797ee60b1f1421588e12255 2026-09-11T12:03:59+00:00 Mark Brown broonie@kernel.org 2026-09-11T12:03:59+00:00 urn:sha1:dc1acf6441bc4ac755ebd10a07a4f75590bbbf2b 2026-09-11T11:48:42+00:00 Mark Brown broonie@kernel.org 2026-09-11T11:48:42+00:00 urn:sha1:85aa63bd8cc0a9f239dc11cde1938b4762ff4fb1 2026-09-11T03:22:01+00:00 Michael Liang mliang@purestorage.com 2026-08-21T18:15:27+00:00 urn:sha1:5c8e102762f3003286534b3c656b46cc120d2df6 fault_create_debugfs_attr() has always taken an extra dentry reference on the created directory (attr->dname = dget(dir)) so that fail_dump() could print the name via %pd from any context. Nothing anywhere in the tree ever calls dput() on attr->dname. For callers with a matching teardown, that unmatched reference causes one dentry plus its attached inode to leak per fault_create_debugfs_attr / debugfs_remove_recursive cycle. simple_recursive_removal() drops debugfs's own +1 ref on the child dentry, but the dget()'d ref keeps its refcount at 1: the dentry ends up unhashed but pinned, and its inode is never freed. Boot-once callers (mm/failslab, block/blk-core, etc.) leak exactly once at init and never destroy the tree, so the impact there is bounded. But per-lifecycle callers (drivers/nvme, drivers/infiniband/hw/hfi1, drivers/mmc, drivers/iommu/iommufd, drivers/media, drivers/misc, drivers/gpu/drm/msm, drivers/crypto, net/sunrpc) leak on every create/destroy cycle. We observed this in production: an NVMe/RDMA host repeatedly reconnecting to a target that rejected the CRTO Property Get went through ~50 nvme controller create/destroy cycles per second, and dentry and inode_cache grew by ~13k pinned objects per 240 s -- unrecoverable through drop_caches. Byte math matched a per-cycle 1-dentry / 1-inode leak from the "fault_inject" directory dentry. Fix this by not holding any external reference in fault_attr. Embed the directory name as a fixed-size char array (FAULT_ATTR_DNAME_LEN, 64 bytes) inside struct fault_attr, copied by strscpy() at fault_create_debugfs_attr() time. fail_dump() prints it via %s. Advantages of an embedded array over kstrdup() + kfree() paired with a new destroy API: - Zero API footprint. No new export and no caller changes required: callers already own their fault_attr's memory and free it when they are done, and now that suffices. - No allocation on the create path. - fault_create_debugfs_attr() cannot fail from the name-copy step. - No lifetime coupling between attr->dname and debugfs; the string is valid for exactly as long as the containing struct. The 64-byte length accommodates every in-tree caller with generous headroom (the longest current name is "fail_dma_array_full", 19 chars). The user-visible fail_dump() format changes from "name %pd" to "name %s", but the printed content is identical -- %pd on the created directory renders the same string that was passed in as @name. drivers/infiniband/hw/hfi1/fault.c drops a now-invalid "attr.dname = NULL" statement; the surrounding kzalloc() already zero-initialises the array. Link: https://lore.kernel.org/20260821181527.3271414-1-mliang@purestorage.com Fixes: 6adc4a22f20b ("fault-inject: add ratelimit option") Signed-off-by: Michael Liang <mliang@purestorage.com> Reviewed-by: Andrew Morton <akpm@linux-foundation.org> Cc: Akinbou Mita <akinobu.mita@gmail.com> Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com> Cc: Jason Gunthorpe <jgg@ziepe.ca> Cc: Leon Romanovsky <leon@kernel.org> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> 2026-09-10T22:14:05+00:00 Jakub Kicinski kuba@kernel.org 2026-08-06T18:51:42+00:00 urn:sha1:99d76b4da88f21edd14b169f65de33e8df1b7804 Cross-merge networking fixes after downstream PR (net-7.3-rc3). Conflicts: drivers/net/dsa/mt7530.c 3c18e3c9a54e ("net: dsa: mt7530: populate lpi_interfaces to fix EEE support") 10d9d8328e8a ("net: dsa: mt7530: replace mt7530_read with regmap_read") Adjacent changes: drivers/net/bonding/bond_alb.c 1746ef2e2df2 ("bonding: use skb_cow_head() in bond_do_alb_xmit() and rlb_arp_xmit()") 4cef95f72bbd ("bonding: fix u32 overflow in compute_gap()") Signed-off-by: Jakub Kicinski <kuba@kernel.org> 2026-09-10T13:35:13+00:00 Leon Romanovsky leonro@nvidia.com 2026-09-10T13:35:13+00:00 urn:sha1:e22a3627b7151754f07f90ea3d1ab6e85f5d93f4 The completion IRQ handler accesses the EQ state and DMA buffer. Its IRQ was registered before that state was initialized, while teardown released the buffer before free_irq() synchronized the handler. Initialize the EQ without arming it, register the IRQ, and then arm it. Reverse the resource order during teardown by freeing the IRQ before destroying the EQ. Fixes: 2a152512a155 ("RDMA/efa: CQ notifications") Link: https://patch.msgid.link/20260907-use-after-free-of-admin-queue-struct-v1-2-dd9d9267fbf4@nvidia.com Reviewed-by: Michael Margolin <mrgolin@amazon.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> 2026-09-10T13:35:13+00:00 Leon Romanovsky leonro@nvidia.com 2026-09-10T13:35:13+00:00 urn:sha1:e08aca85c02ff290f785f07acae758f0daf5f49e The management IRQ handler accesses both the admin completion queue and the async event queue. The driver registered the IRQ before constructing these queues and destroyed them before freeing the IRQ, so the handler's lifetime was not contained by the resources it accesses. Initialize the queues with interrupts masked, request the IRQ, and then switch to interrupt mode. On removal, reset the device and free the IRQ before destroying the queues. Also reset the device before destroying the queues if IRQ registration fails, because the device already has their DMA addresses. Fixes: b7f5e880f377 ("RDMA/efa: Add the efa module") Link: https://patch.msgid.link/20260907-use-after-free-of-admin-queue-struct-v1-1-dd9d9267fbf4@nvidia.com Reviewed-by: Michael Margolin <mrgolin@amazon.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> 2026-09-06T09:14:38+00:00 Jeffin Philip jeffinphilip14@gmail.com 2026-09-04T13:14:37+00:00 urn:sha1:33fb59da49c4c3f5c2ec9f9d4447a56857a02c02 iwpm_get_nlmsg_request() initializes refcount _after_ list_add_tail() making it accessible to global list where another CPU can kref_get() on nlmsg_request causing a refcount "addition on 0" bug. Fix this by initializing kref _before_ list_add_tail() so refcount for nlmsg_request can be incremented/decremented normally. In addition, also initialize every field before list_add_tail(). Reported-by: syzbot+bd317784d628820741b5@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=bd317784d628820741b5 Fixes: 30dc5e63d6a5 ("RDMA/core: Add support for iWARP Port Mapper user space service") Cc: stable@vger.kernel.org Signed-off-by: Jeffin Philip <jeffinphilip14@gmail.com> Link: https://patch.msgid.link/20260904131437.12917-1-jeffinphilip14@gmail.com Signed-off-by: Leon Romanovsky <leon@kernel.org> 2026-09-06T07:52:38+00:00 Leon Romanovsky leonro@nvidia.com 2026-09-06T07:52:38+00:00 urn:sha1:4a93466061d38f159b857aad63a9cc3cd3affadb The only callers of irdma_sc_qp_flush_wqes() and irdma_sc_mr_fast_register() always request their respective send queues to be posted, so their post_sq false branches are unreachable. Remove both arguments and post the queues unconditionally. Drop the redundant QP flush request assignments as well. Link: https://patch.msgid.link/20260903-64-bit-iova-is-silently-truncated-to-v1-2-96e878ea6873@nvidia.com Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Reviewed-by: Jacob Moroni <jmoroni@google.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>