When a VMA is mremap()'d with MREMAP_DONTUNMAP set, that results in the
VMA being copied, but the source VMA not being unmapped.
If the VMA is mlock()'d this is a legal operation, though the source VMA
has its VMA_LOCKED_BIT cleared.
However this is done in dontunmap_complete(), after mm->locked_vm was
incremented via vrm_stat_account(), resulting in double-counting.
Worse, this is not even corrected when source VMA is unmapped, due to the
VMA_LOCKED_BIT flag having been cleared.
This all works fine in the usual mremap() case (without MREMAP_DONTUNMAP),
as the source VMA is unmapped with VMA_LOCKED_BIT intact, at which time
mm->locked_vm is decremented accordingly.
Resolve the issue by invoking vrm_stat_account() only after
dontunmap_complete() has run.
Note that MREMAP_DONTUNMAP requires old_len == new_len, so no need to
account for a delta in size in this case.
The bug was introduced by commit b714ccb02a ("mm/mremap: complete
refactor of move_vma()") which incorrectly reordered the accounting and
the clearing of the VMA_LOCKED_BIT flag.
Link: https://lore.kernel.org/20260828-mremap-fix-locked-vm-v1-1-c80be7505d1e@kernel.org
Fixes: b714ccb02a ("mm/mremap: complete refactor of move_vma()")
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Reported-by: sashiko-bot <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260825-fix-mremap-dontunmap-pgoff-v1-1-39a40b2c98b3@kernel.org
Reported-by: Kunwu Chan <kunwu.chan@gmail.com>
Closes: https://lore.kernel.org/all/20260828094823.594279-1-kunwu.chan@linux.dev/
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Tested-by: Kunwu Chan <kunwu.chan@gmail.com>
Reviewed-by: Kunwu Chan <kunwu.chan@gmail.com>
Cc: Jann Horn <jannh@google.com>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Pedro Falcato <pfalcato@suse.de>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
The sysfs THP tuneables at /sys/kernel/mm/transparent_huge_pages/ rather
confusingly only control the behaviour of THP in some instances.
They are not applicable to MADV_COLLAPSE operations, nor to DAX mappings.
Long-term, THP is predicated upon compaction being able to obtain large
folios to populate THP ranges.
However, vm_normal_folio() returns NULL for PFN map mappings, thus their
reference count is maintained by the driver, not core mm.
As a consequence, the folios are not subject to reclaim nor compaction, so
are not truly part of the THP mechanism at all.
However, since commit 5dd40721f1 ("mm: allow THP orders for PFNMAPs")
introduced the ability to establish huge PFN maps, they have been subject
to THP tuneables.
This is incorrect - if a huge PFN map is available (defined by
vma->vm_ops->huge_fault being non-NULL for a VMA_PFNMAP_BIT VMA), then it
should be mapped huge upon fault-in.
Correct this by explicitly checking for this while ensuring that smaps
continues to accurately report THPeligible statistics.
While here, abstract the entire file-backed THP check in
vma_can_map_huge_file(), with sensible separation of logic into helper
functions.
Note that drm_gem_shmem_mmap() and panthor_gem_mmap() establish huge PFN
maps of shmem folios, however they are marked unevictable in
drm_gem_get_pages(), and in any case would fail the reference check in
__remove_mapping() even if they weren't.
Failing to map huge PFN maps has resulted in significant real-world
performance degradation, see links for details.
[ziy@nvidia.com: rename some functions]
Link: https://lore.kernel.org/DL1HIHWYJ7TB.1CY76SJS0V03L@nvidia.com
Link: https://lore.kernel.org/20260827-hugepfn-allowable-orders-v1-1-94819c8807c8@kernel.org
Fixes: 5dd40721f1 ("mm: allow THP orders for PFNMAPs")
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Zi Yan <ziy@nvidia.com>
Reported-by: Cedric Le Goater <clg@redhat.com>
Closes: https://lore.kernel.org/linux-mm/20260805055544.1568534-1-clg@redhat.com/
Reported-by: Saravanan D <saravanand@crusoe.ai>
Closes: https://lore.kernel.org/linux-mm/20260821070520.25759-1-saravanand@crusoe.ai/
Reviewed-by: Zi Yan <ziy@nvidia.com>
Tested-by: Saravanan D <saravanand@crusoe.ai>
Tested-by: Lance Yang <lance.yang@linux.dev>
Reviewed-by: SJ Park <sj@kernel.org>
Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Barry Song <baohua@kernel.org>
Cc: David Hildenbrand <david@kernel.org>
Cc: Dev Jain <dev.jain@arm.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Peter Xu <peterx@redhat.com>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Chia-Yu Chang says:
====================
Explicit TSO segment count
This series replaces the existing min_tso_segs() congestion control
callback with a new tso_segs() callback that allows congestion control
algorithms to provide an explicit TSO segment count for each data burst.
To support BPF congestion controls, the series also exposes
tcp_tso_autosize() as a BPF kfunc, allowing BPF implementations to
reuse the kernel TSO autosizing logic while implementing custom
tso_segs() callbacks.
====================
Link: https://patch.msgid.link/20260831165230.2696893-1-chia-yu.chang@nokia-bell-labs.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Expose tcp_tso_autosize() as a BPF kfunc and register it in the TCP
congestion-control kfunc set. This allows BPF congestion controls to
reuse the kernel TSO autosizing logic while applying their own
minimum TSO segment policy.
To make the kfunc robust against BPF-provided inputs, min_tso_segs is
sanitized to at least 1 and mss_now == 0 returns the sanitized minimum
value instead of performing autosizing.
Signed-off-by: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
This patch replaces the existing min_tso_segs() callback with a new
tso_segs() callback, allowing congestion control algorithms to provide
an explicit TSO segment count for each data burst and bypass
tcp_tso_autosize(). The resulting tso_segs value is clamped to
[1, sk->sk_gso_max_segs], preventing congestion-control implementations
from returning an invalid zero-segment value.
This change has the following impacts on BPF struct_ops users:
- The callback is renamed from min_tso_segs() to tso_segs()
- The signature gains an extra u32 mss_now argument
- The return value semantics is changed from "floor value passed into
tcp_tso_autosize()" to "final tso_segs value", bypassing autosizing
As a result, existing BPF programs must be updated, because returning a
small constant will now directly limit the final tso_segs value instead
of specifying the minimum value passed to tcp_tso_autosize().
Signed-off-by: Chia-Yu Chang <chia-yu.chang@nokia-bell-labs.com>
Signed-off-by: Ilpo Järvinen <ij@kernel.org>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
-----BEGIN PGP SIGNATURE-----
iQJKBAABCAA0FiEEzOlt8mkP+tbeiYy5AoYrw/LiJnoFAmqb6gQWHGNoZW5odWFj
YWlAa2VybmVsLm9yZwAKCRAChivD8uImeuBkD/9SNpBtFcumYkl1S3FUSTC8Up5k
8exUSd6bJr/lc5+cPJcY4VZLOus8ueKjJuKXQE0C3Id6Cd8g1MGZUQVGXIWYz2Sx
69z2rhYkE4b386ivNutwCzA7Bjlb/rMZEeDGfEuRe2eVOH2o8ADiLG+ANNUHbpWt
zTbLUiBOFD2sfWL2fSShcBJthYF7QTBh54jlL56HBleWMdq6y4ii7rh1X+6RFgNg
xRi7s/4+FLxh+F+1GOVrPvIuNrqQaTgWVASsmmRE56n66WOFeVgsG4NVi0/i0f9Z
MLHp/QeSx5/OtIhjjt9BkV+0E2tXAUMEOalj0HpaDBxsfAjAFLDt7TRra9BhV+aI
FrEnbIwG809BYAjRO2scf4khtrLofZpIv+STt+vbKjFYEv2Z03x/2JS6Tg9gGmtN
wP1GfzfPgk8FgdbQ4pgT354COYr1Ey+OU1tjNTmmYMYN7WmXmGG9Yx7LfrtvsNU9
ohFeHyTygAcw/bE1/IdWqFK7DP6V5LuOoeOtfuEnRC/SFHdGbr2fvu3dfZSK06kE
CWY9QSF7J8MfLNhgRi4/Q0QxRtdekDyANZezS2uwNv1Hn6Pwt9rXMScMiyWkNSg7
6oltWiIrXx5lMBCHDciNWyAR+mQe3/G8YUPnrpPWsfMcOelvfMN/RWtYWMalevZ5
YY9ufXSCGMQQDBPFDQ==
=SgJ4
-----END PGP SIGNATURE-----
Merge tag 'loongarch-fixes-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson
Pull LoongArch fixes from Huacai Chen:
- Fix build errors when RUST and KASAN enabled
- fix a typo in comment of vmlinux.lds.S
- fix several bugs in Kprobes, BPF JIT and KVM support
* tag 'loongarch-fixes-7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/chenhuacai/linux-loongson:
perf build: Add clang and rust target flags for LoongArch
LoongArch: KVM: Fix TOCTOU race on pv_features
LoongArch: KVM: Validate MSI data before routing it to EIOINTC
LoongArch: KVM: Preserve memslot arch flags on KVM_MR_FLAGS_ONLY
LoongArch: KVM: Remove unused function kvm_arch_flush_remote_tlbs_memslot()
LoongArch: KVM: Fix resource leak in kvm_loongarch_env_init() error path
LoongArch: KVM: Add unregister helpers for the KVM interrupt devices
LoongArch: KVM: Free init resources if kvm_init() fails
LoongArch: BPF: Fix off-by-one error for insn_is_cast_user()
LoongArch: Avoid preempt count underflow without probe
LoongArch: Do not save/restore percpu base register in rethook trampoline
LoongArch: Remove unused setup_profiling_timer() function
LoongArch: Fix typo "avaliable" in comment of vmlinux.lds.S
LoongArch: Do not select HAVE_RUST when KASAN is enabled
put_chars() runs from the hvc console write path with preemption
disabled, so it asks alloc_buf() for GFP_ATOMIC. Only the data buffer
gets it: the struct port_buffer itself keeps the GFP_KERNEL default, so
the allocation can enter direct reclaim and sleep. A write to /dev/kmsg
on a CONFIG_DEBUG_ATOMIC_SLEEP kernel splats:
BUG: sleeping function called from invalid context at ./include/linux/sched/mm.h:320
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: virtme-ng-init
preempt_count: 1, expected: 0
Preemption disabled at:
[<ffffffff813fd90d>] vprintk_emit+0x17d/0x510
Call Trace:
<TASK>
dump_stack_lvl+0x69/0xa0
__might_resched+0x37a/0x4d0
__kmalloc_cache_noprof+0x94/0x5f0
put_chars+0x209/0x3e0
hvc_console_print+0x234/0x640
console_flush_all+0x4fc/0x950
console_unlock+0xbf/0x1b0
vprintk_emit+0x312/0x510
devkmsg_emit+0xba/0x110
devkmsg_write+0x21b/0x2e0
vfs_write+0x4dc/0x9d0
ksys_write+0x108/0x1e0
do_syscall_64+0xfa/0x460
</TASK>
Pass gfp on to that allocation too.
Fixes: fc220d6be3 ("virtio_console: refactor __send_to_port() buffer ownership")
Signed-off-by: Breno Leitao <leitao@debian.org>
Acked-by: Sungho Bae <baver.bae@lge.com>
Tested-by: Florian Westphal <fw@strlen.de>
Link: https://patch.msgid.link/20260810-serial-v1-1-abbe51602c13@debian.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-----BEGIN PGP SIGNATURE-----
iQJPBAABCgA5FiEE8rQSAMVO+zA4DBdWxWXV+ddtWDsFAmqcOFUbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyAAoJEMVl1fnXbVg7DwAP/i5lmUS85n22uWD7wkmU
5ocMbdl9cKprtcpi8axR9kbtBIC5bq0j3sUwmiFgR6KI774v7FnxJ3AIrey3GwtF
okiaWLffKOYROCDvmLg36ciSbFGEqjS8lwOPl1geBX7tZhhnGgcV+XRXcMv4ehj8
HiOtjN8a+8kXrYTMB73JhBkzku7Hojb/vA9ZHXeCLjP4nfzlXneqltSQw/+3uVvf
jrLfOX3a1lgLkz0Q7AlfAO7ppXv5msrZYu7E1aILYtLA5K6J6Gh1jyK+Y8OZlvdg
hukhU3mAw2pCV5dg6rAurYWzVhE/tNmKmlg2s1LiW3K1Q2NNSPGvR0ArmAnd9bPY
6ZwoK47m98xuZgIAO7v+ej9LYI3XANGwdupTmrKhQ7shLYtzvSsob7kWRYfjCMWu
UaTGshMsrfMXZNznXm2Ydy1Gmr3TBI2J1HpUFiibRL4XgsQ7u9hLUFwiFUiMEi9V
g9oqTN/1VUMsImADlnrdAf30pLtOe8PHV1naFLdmdl+iCPc9o0cX9X5m2fHWtkpt
Cjz/au8Z0zMVJMIDUZuBgCX4mWNSx7pWYKQYvlGOLQEehXNLRVcY5SnIqRman8WF
gnUPaaTb6KDS+SJjRDPkRH9ihGlNEd2c/tzrxek4/42CF842PGeMvGK06PtPyzxW
LWtmCtBWRArSHUq09NZbboim
=z6qW
-----END PGP SIGNATURE-----
Merge tag 'for-7.3-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux
Pull btrfs fixes from David Sterba:
- preserve inode compression level when changing attributes
- fix lost wakeup when waiting for a zstd workspace
- fix bio context leaks after ordered extent processing errors
- in send, handle unexpected extents for non-regular inodes
- handle edge case in creation of reloc tree with enabled quotas
- in scrub report the exact failing offset, not the stripe base
- error handling fixes
- error code propagation in send, zoned mode and raid-stripe-tree
- restore active device pointer after seeding device addition error
- transaction abort fixups
- update Chris' email address
* tag 'for-7.3-rc1-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux:
MAINTAINERS: update Chris Mason's email address
btrfs: tests: do not touch page cache if root/inode allocation failed
btrfs: zstd: fix lost wakeup when waiting for a workspace
btrfs: do not force reloc root creation during qgroup_account_snapshot()
btrfs: send: fix lost error return value in will_overwrite_ref()
btrfs: abort transaction before releasing tree_log_mutex on commit failure
btrfs: zoned: propagate do_zone_finish() error in btrfs_zone_finish_endio()
btrfs: zoned: finish active block group cleanup if call_zone_finish() fails
btrfs: send: reject extents for non-regular inodes
btrfs: return proper negative error code for update_raid_extent_item()
btrfs: fix the possible bioc_list memory leak during error
btrfs: fix transaction use-after-free in raid stripe insertion
btrfs: scrub: report the failing sector's address, not the stripe base
btrfs: preserve the compression property when other inode flags change
btrfs: restore active device pointers after failed sprout
btrfs: detach failed sprout device from transaction update list
btrfs: clean up target device if block group marking fails
When cifs_close() defers a close, it hands the cifsFileInfo reference
of the closing struct file to the queued work. Each execution of
smb2_deferred_work_close() drops one such reference.
deferred_close_scheduled can be false while the work is pending: the
workqueue clears PENDING when the callback starts to run, before the
callback clears the flag under deferred_lock. A close in that
interval requeues the running work, and the callback then clears the
flag, leaving the requeued work pending with the flag down. A later
cifs_open() can reuse the handle and its cifs_close() reaches the
same branch: queue_delayed_work() fails because the work is still
pending, but cifs_close() returns without dropping the closing file's
reference. The cifsFileInfo count stays pinned and its tlink, dentry
and server handle are leaked.
Check the return value and hand off the reference only when work was
actually queued. Otherwise, use the shared _cifsFileInfo_put(), like
the mod_delayed_work() branch above: the pending execution already
owns its reference.
This issue was found by an in-house static analysis tool.
Fixes: c3f207ab29 ("cifs: Deferred close for files")
Cc: stable@vger.kernel.org
Assisted-by: Codex:gpt-5.6
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>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
cifs_oplock_break() takes over the reference that
cifs_queue_oplock_break() acquired when it queued the work, and drops it
with _cifsFileInfo_put() once the break has been processed.
Only in setups with "-o multiuser", cifs_sb_tlink() may fail, at which
point cifs_oplock_break() returns without putting the file reference,
mirroring the reference leak we already fixed in the companion patch to
cifs_queue_oplock_break().
This would trigger a crash due to busy inodes on the next unmount:
BUG: Dentry ... still in use (1) [unmount of cifs cifs]
VFS: Busy inodes after unmount of cifs (cifs)
Drop the reference on that path as well. Doing so before the out label
mirrors the normal path, which also puts the reference before
cifs_done_oplock_break().
Found by Sashiko code review. The failure path was not exercised at
runtime.
Fixes: e8f5f849ff ("cifs: fix potential oops in cifs_oplock_break")
Cc: stable@vger.kernel.org
Assisted-by: Kiro:claude-opus-5
Signed-off-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
cifs_queue_oplock_break() unconditionally takes a reference on the
target file before queueing cifs_oplock_break(). Only that work item
decreases the reference counter again.
If another oplock break arrives while that work is still queued,
queue_work() will return false and not queue this second work item. As a
result, we will never reach the point to drop the file reference again
and are leaking this reference. This can be triggered when interacting
with a slow-responding server.
As a result, later unmount operations for this file system will fail with
BUG: Dentry ... still in use (1) [unmount of cifs cifs]
VFS: Busy inodes after unmount of cifs (cifs)
kernel BUG at fs/super.c:777!
Fix this by only incrementing the reference count if the work has been
queued successfully. Taking it after queue_work() is safe because all
three callers hold tcon->open_file_lock across the call and
_cifsFileInfo_put() decrements under that same lock, so a worker that
starts the handler in the window cannot drop the reference before it has
been taken.
Fixes: b98749cac4 ("CIFS: keep FileInfo handle live during oplock break")
Cc: stable@vger.kernel.org
Assisted-by: Kiro:claude-opus-5
Signed-off-by: Bjoern Doebel <doebel@amazon.de>
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
2 enhancements to add support and MCQ for additional Intel 4.0
controller types. The rest are all driver fixes, the largest of which is
the mpi3mr target use after free fix, follwed by a similar TOCTOU fix
for io_uring passthrough in bsg.
Signed-off-by: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
-----BEGIN PGP SIGNATURE-----
iLgEABMIAGAWIQTnYEDbdso9F2cI+arnQslM7pishQUCapw/mRsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwyLDImHGphbWVzLmJvdHRvbWxleUBoYW5zZW5wYXJ0bmVy
c2hpcC5jb20ACgkQ50LJTO6YrIXurAD7BFNaHlTRLIlurYSeMYOV0ZVQQXR9GsW8
1KQhJW1W6GABAIr7L81Gm1jTUa+CuXixW2N9tv8PBsXx627eWyRZ7tyb
=9pG9
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Two enhancements to add support and MCQ for additional Intel 4.0
controller types.
The rest are all driver fixes, the largest of which is the mpi3mr
target use after free fix, follwed by a similar TOCTOU fix for
io_uring passthrough in bsg"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: megaraid_sas: Limit NVMe request size to the PRP chain frame
scsi: bsg: Fix TOCTOU in io_uring passthrough command setup
scsi: bsg: Cap io_uring sense copy to max_response_len
scsi: mpt3sas: Avoid out-of-bounds cpumask_of_node() call in _base_assign_reply_queues()
scsi: mpi3mr: Fix use-after-free on tgt_dev->starget during target device refresh/update
scsi: target: iscsi: Reserve a terminator byte for the login payload
scsi: target: iscsi: Fix hang for aborted WRITE_PENDING commands
scsi: ufs: ufs-pci: Add MCQ support for Intel UFS 4.0 controllers
scsi: ufs: ufs-pci: Add support for Intel UFS 4.0 HS-Gear5
scsi: sg: Report request-table problems when any status is set
scsi: mpi3mr: Fix target device refcount leak in mpi3mr_sas_port_add()
scsi: mpi3mr: Fix NULL pointer dereference in mpi3mr_sas_port_add()
scsi: ufs: ufs-qcom: Fix sequential read variance
scsi: ufs: ufs-qcom: Restore HS/LS link startup mode for Qualcomm UFS controller v6.2+
scsi: ibmvfc: Document protocol parameter of ibmvfc_alloc_target()
scsi: ibmvfc: Fix kernel-doc name for ibmvfc_scsi_relogin()
scsi: pm8001: Use rollback index when freeing MSI-X vectors
scsi: fnic: Initialize the NVMe local port info before registering
-----BEGIN PGP SIGNATURE-----
iQJEBAABCAAuFiEEwPw5LcreJtl1+l5K99NY+ylx4KYFAmqb+cYQHGF4Ym9lQGtl
cm5lbC5kawAKCRD301j7KXHgpjBkEACTFzHAVopJbtKT6+Rg9esQNPUDfeJkJy/L
3v8Vi4R7tozAB0IKc58RxV2YFMvga5teWJkAnd33983/MbwCzj9B0oRjSmnHf8K5
pq4gu1f5pdyfRXGGAnI6ZMom1MNsfuWWiZmD8vQuQ+q4qNVSnQBg0UjrDggDlcW6
o6EtyjgqAwaaGs+sWgxgy0sYWV7TMiCx4+AZR0TDm8cN3LXyOkOp2abgR35/tnDB
fs3kUPTkBC4rCZK2uVUhgF6Wctcd2qIF6AEP+bBbWifSCI/jmqAYHk/0IM1xpn8e
XXPO43X5Iad5iiMWMHlku9G7ZjTo/K2bLc1n9F4IlNZgVPAcF9qtYok5Uc3ghldg
/qOsclI8D2feQ5j6u060FdnN99+TSHcS3h4roa8jIPNojmh5orw2xRiDCvSVG3au
+UfEUWnf0JjsmJfX9HCQyV6oTB/7IeiSI+4akHXobCnsG4n9BL8kZ1HR8qwPWsYj
HPeLHraPljX2slDj+X9EFA8AyxgU33HC9JbjvLlN4L2amX+7Jtwb3A7MlKrGEuUP
gzybtHk5g17/mcYVj9N2k4tHECR1aZChTQcfNdCctMVB3vXk3KKkFsZstJapCVmT
fSKx7pdrrNwo3WoKzn8xp/+2gcrRRo4AhSCg9oVfloc5nSFkyfPpq0vPspsUj3ib
4ze4Sy2TiQ==
=4ZE+
-----END PGP SIGNATURE-----
Merge tag 'block-7.3-20260905' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux
Pull block fixes from Jens Axboe:
- NVMe fixes via Keith:
- nvme-tcp fixes for an out-of-bounds write on an over-long PDU
- nvmet-tcp, nvmet-rdma and nvme-rdma leak and cleanup-ordering
fixes
- FDP placement id array racy access fix
- nvme-fc double free of fabrics options on nvme_add_ctrl()
failure, and a secret leak failure
- Fault injection opcode filtering
- stale namespace removal during scan
- Various other smaller fixes and cleanups
- Flag zoned disks with GENHD_FL_NO_PART
- Save the page offset gaps in a cloned bio
- Fix dma_alignment for large or unreported limits in loop and zloop
- Clear VM_MAYWRITE on a read-only ublk char device mmap
* tag 'block-7.3-20260905' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: (25 commits)
nvme-tcp.h: drop kernel-doc comments, fix a few descriptions
nvme-fc: fix double free of fabrics options when nvme_add_ctrl() fails
nvmet: reject namespace enable without device path
nvmet-auth: Synchronize timeout work during SQ teardown
MAINTAINERS: update nvme entry
nvmet-tcp: reject unsolicited H2CData PDUs
nvme-tcp: defer TLS inline send to io_work
nvmet-tcp: fix out-of-bounds write when receiving an over-long PDU
nvme-tcp: return -EPROTO for a C2HData on a write
nvmet: print namespace IDs as unsigned 32bit value
nvme: print namespace IDs as unsigned 32bit value
nvme: remove stale namespaces by NSID range during scan
nvme: add missing SRCU grace period in error path
nvme-fabrics: fix DHCHAP secret leak on parse failure
ublk: clear VM_MAYWRITE on read-only ublk char device mmap
loop, zloop: fix dma_alignment for large or unreported limits
block: save page offset gaps in cloned bio
block: flag zoned disks with GENHD_FL_NO_PART
nvmet-rdma: fix queue leak when connect backlog is exceeded
nvme: add opcode filtering for fault injection
...
When __replay_soft_interrupts() replays a pending interrupt (e.g.
PACA_IRQ_DEC -> timer_interrupt), it calls the handler directly with a
synthetic pt_regs. The DEFINE_INTERRUPT_HANDLER_ASYNC wrapper around
each handler calls arch_interrupt_async_exit_prepare() on the way out,
which calls arch_interrupt_exit_prepare() -> local_irq_disable() ->
arch_local_irq_disable(), which does:
irq_soft_mask_set(IRQS_DISABLED) /* 0x1 */
This unconditionally overwrites irq_soft_mask with IRQS_DISABLED (0x1),
stripping the IRQS_PMI_DISABLED (0x2) bit. The result is that
irq_soft_mask is 0x1 instead of IRQS_ALL_DISABLED (0x3) when the
handler returns to __replay_soft_interrupts().
For a normally-taken interrupt this is harmless: the next interrupt
always enters through arch_interrupt_enter_prepare() which
unconditionally sets irq_soft_mask to IRQS_ALL_DISABLED. But during
replay, next_interrupt() is called directly between replayed handlers
without going back through arch_interrupt_enter_prepare(), so the
stripped bit is never restored. next_interrupt() then fires a WARNING:
WARNING: arch/powerpc/kernel/irq_64.c:75
WARN_ON(irq_soft_mask_return() != IRQS_ALL_DISABLED)
The warning was observed early in boot on a POWER10 pseries guest
during kmem_cache_init_late(), where a spinlock release triggers
interrupt replay that processes a pending timer interrupt.
Debugger state confirming the bug:
Before timer_interrupt(®s):
irq_soft_mask = 0x3 (IRQS_ALL_DISABLED) correct
irq_happened = 0x41 (HARD_DIS|REPLAYING) correct
After timer_interrupt(®s) returns:
irq_soft_mask = 0x1 (IRQS_DISABLED) WRONG - PMI bit stripped
irq_happened = 0x41 unchanged
The fix is to replace local_irq_disable() with hard_irq_disable().
hard_irq_disable() is the right primitive here for two reasons:
1. On PPC64 (hw_irq.h:301) it calls irq_soft_mask_set_return(IRQS_ALL_DISABLED),
setting the soft mask to 0x3 (both IRQS_DISABLED and IRQS_PMI_DISABLED),
which preserves the PMI bit and fixes the WARNING. The additional
work it does (__hard_irq_disable(), PACA_IRQ_HARD_DIS |=) is
redundant but safe since both are already set at this point in the
exit path; the trace_hardirqs_off() inside is guarded by
if (!arch_irqs_disabled_flags(flags)) so it will not double-fire.
2. On PPC32 (hw_irq.h:467) hard_irq_disable() maps to
arch_local_irq_disable() -> __hard_irq_disable(), which clears
MSR[EE] in hardware. This is exactly correct: PPC32 has no soft-mask
PACA mechanism, so the hardware disable is the right way to satisfy
irqentry_exit()'s requirement. This also fixes a build error on PPC32
where irq_soft_mask_set() is only defined under CONFIG_PPC64:
arch/powerpc/include/asm/entry-common.h:273: error: implicit
declaration of function 'irq_soft_mask_set'
Using hard_irq_disable() requires no #ifdef and is consistent with
how the rest of the entry code (e.g. entry-common.h:463) handles the
same PPC32/PPC64 split.
Fixes: 334f3f6d7a ("powerpc/entry: Disable interrupts before irqentry_exit")
Reported-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Closes: https://lore.kernel.org/all/6f9bfb0f-b14c-468e-bb9f-c157d120d0dc@linux.ibm.com/
Tested-by: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Reviewed-by: Shrikanth Hegde <sshegde@linux.ibm.com>
Signed-off-by: Mukesh Kumar Chaurasiya (IBM) <mkchauras@gmail.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260904090858.128563-1-mkchauras@gmail.com
mctp_i3c_probe() drops busdevs_lock after finding the matching bus. A
concurrent I3C_NOTIFY_BUS_REMOVE can then unregister and free the bus
netdev before probe passes its private data to mctp_i3c_add_device().
The latter consequently adds a list node through a freed mbus pointer.
Keep busdevs_lock held until the device has been added. This also
satisfies the __must_hold annotation on mctp_i3c_add_device().
Fixes: c8755b29b5 ("mctp i3c: MCTP I3C driver")
Signed-off-by: XingWang Xiang <v3rdant.xiang@gmail.com>
Acked-by: Matt Johnston <matt@codeconstruct.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
When the number of requested VFs exceeds MAX_VFS_FOR_MAP_PE, the
message prints that limit but labels it "Configurable VFs". Report
the configurable VF limit and the PE mapping limit with separate
error messages.
Suggested-by: Christophe Leroy <chleroy@kernel.org>
Signed-off-by: Jiangshan Yi <yijiangshan@kylinos.cn>
Reviewed-by: Christophe Leroy <chleroy@kernel.org>
[Maddy: Fixed Christophe's reviewed by tag]
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260813063731.399598-1-yijiangshan@kylinos.cn
arch_check_excluded_range() checks if a kexec segment overlaps an
excluded memory range.
Both ranges use inclusive end addresses, but the overlap check uses
exclusive comparisons. This skips ranges with start == ->ranges[i].end
or end == ->ranges[i].start. Use inclusive comparisons instead.
Fixes: 6e5250eaa6 ("powerpc/crash: use generic APIs to locate memory hole for kdump")
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260810145827.157972-3-thorsten.blum@linux.dev
Return the size directly and drop the extra_sz variable to simplify
kdump_extra_elfcorehdr_size(). The two warning paths now fall through
to the existing return 0 at the end of the function.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260730131940.597739-2-thorsten.blum@linux.dev
add_usable_mem() adds usable memory ranges for the kdump kernel.
The ranges are inclusive, but the partial overlap check uses exclusive
comparisons. This skips ranges with base == loc_end or end == loc_base.
Use inclusive comparisons instead.
Fixes: 7c64e21a1c ("powerpc/kexec_file: Restrict memory usage of kdump kernel")
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev>
Reviewed-by: Sourabh Jain <sourabhjain@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/20260809162403.18142-2-thorsten.blum@linux.dev
The eeh_driver disables and offlines the PE permanently when it
exceeds the freeze count beyond eeh_max_freeze within the last hour.
The PE is only offline, so the device tree entries, eeh device
references are all intact till the real unplug of the device from
the guest/host takes place.
On pSeries, with a new hotplug of any PCI device, the drmgr initiates
a system-wide PCI rescan, which finds devices offlined by the eeh_driver
and there will be attempts to bring them online. This leads to
recurring EEHs either at the config read time itself or a bit
later depending on the type of the problem.
For PowerNV, the commit d2b0f6f77e ("powerpc/eeh: No hotplug on
permanently removed dev") introduced the EEH_DEV_REMOVED flag to
prevent such inadvertent rescans on hierarchical toplogies relavent in
Baremetal setups. For pSeries, such topologies don't really make sense
as the devices are either part of the same PE OR exposed as independent
devices on multiple virtual PHBs. However, the inadvertent rescans are
still a possibility with either hotplug of a new device or otherwise
with manual system-wide pci bus rescan attempts.
So the patch checks for EEH_DEV_REMOVED before allowing config space
access just like PowerNV, making the PCI core omit the PE, and thus
preventing subsequent EEH recurances. The patch is tested on PowerVM
and KVM machines with single and multi-function devices, and on the
devices behind a switch. The unplug of the affected devices post EEH
removal is also working fine as expected.
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Reported-by: Tasmiya Nalatwad <tasmiya@linux.ibm.com>
Tested-by: Tasmiya Nalatwad <tasmiya@linux.ibm.com>
Reviewed-by: Harsh Prateek Bora <harshpb@linux.ibm.com>
References: d2b0f6f77e ("powerpc/eeh: No hotplug on permanently removed dev")
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/178246517230.1267.12206176311111155505.stgit@linux.ibm.com
The commit 1010b4c012 ("powerpc/eeh: Make EEH driver device hotplug
safe") refactored the EEH code such that the pci_rescan_remove_lock is
held at the beginning of eeh_handle_normal_event() and the
eeh_reset_device() is called with that lock being held. Looks like the
commit missed to remove the existing lock/unlock inside eeh_rmv_device()
which is no longer necessary. This is causing the eehd to hang on the
lock which it actually holds when that code path is taken.
[<0>] 0xc00000011c78f870
[<0>] __switch_to+0xfc/0x1a0
[<0>] pci_lock_rescan_remove+0x30/0x44
[<0>] eeh_rmv_device+0x290/0x2e0
[<0>] eeh_pe_dev_traverse+0x80/0x130
[<0>] eeh_reset_device+0xcc/0x23c
[<0>] eeh_handle_normal_event+0x830/0xa80
[<0>] eeh_event_handler+0xf8/0x190
[<0>] kthread+0x194/0x1b0
[<0>] start_kernel_thread+0x14/0x18
The issue is seen for cases where the errors are detected on the PHB
directly AND|OR for devices where the driver error_detected() returns
PCI_ERS_RESULT_NEED_RESET, and driver being not EEH sensitive(i.e no
error handlers like slot_reset(), resume() etc defined).
Fixes: 1010b4c012 ("powerpc/eeh: Make EEH driver device hotplug safe")
Cc: stable <stable@kernel.org>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Reviewed-by: Amit Machhiwal <amachhiw@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/178404937381.913.2759874335293830160.stgit@linux.ibm.com
The commit f0ac60e6e3 ("powerpc/powernv/pci: Switch to use
msi_create_parent_irq_domain()") removed the legacy MSI irq chip
pnv_pci_msi_irq_chip but left behind the static definition of it and
its reference in is_pnv_opal_msi().
The KVM IRQ bypass for vfio devices is broken because the
comparision in is_pnv_opal_msi() fails on the comparision with
stale unused variable showing the below errors in dmesg.
kvmppc_set_passthru_irq_hv: Could not assign IRQ map for (X,Y)
kvmppc_set_passthru_irq (irq X, gsi Y) fails: -2
vfio-pci A:B:C.D irq bypass producer (eventfd Z) registration fails: -2
The patch removes the stale variable definition and fixes the
is_pnv_opal_msi() by comparing against the chip name prefix.
Fixes: f0ac60e6e3 ("powerpc/powernv/pci: Switch to use msi_create_parent_irq_domain()")
Cc: stable@kernel.org
Signed-off-by: Shivaprasad G Bhat <sbhat@linux.ibm.com>
Tested-by: Gautam Menghani <gautam@linux.ibm.com>
Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com>
Link: https://patch.msgid.link/178716225364.1437.6201568081502251835.stgit@linux.ibm.com
This is another run of the Coccinelle script for converting kmalloc()
family of allocations to kmalloc_obj() via the existing rules in
scripts/coccinelle/api/kmalloc_objs.cocci
This catches both the set of kmalloc() uses added since the first
kmalloc_obj() conversions in v7.0 and adds a large group missed in the
first pass due to Coccinelle not interacting well with the cleanup.h
scoped_...() family of macros[1]. I worked around this with spatch's
"--macro-file" argument to a file with all the scoped_...() macros mapped
to Coccinelle's YACFE_ITERATOR[2] as that was the closest viable control
flow indicator I could find.
Build tested allmodconfig on x86, arm64, arm, loongarch, mips, powerpc,
riscv, and s390 with no new warnings.
Link: https://lore.kernel.org/lkml/202609021314.8A9C0B8@keescook/ [1]
Link: https://github.com/coccinelle/coccinelle/blob/master/standard.h [2]
Signed-off-by: Kees Cook <kees+treewide@kernel.org>
-----BEGIN PGP SIGNATURE-----
iIoEABYKADIWIQQdXVVFGN5XqKr1Hj7LwZzRsCrn5QUCapsP/BQcem9oYXJAbGlu
dXguaWJtLmNvbQAKCRDLwZzRsCrn5b2gAQC3ms2HRoZolscMWqnUNoi5SmPpwcV2
v/ojwDc1TnS9HAEA/604QYihEvRQzKQwEyF6W6b83w22tyWKhDW1a0d7KQ4=
=/Hd6
-----END PGP SIGNATURE-----
Merge tag 'integrity-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity
Pull IMA fixes from Mimi Zohar:
- Instantiating the ima_file_truncate and ima_path_truncate LSM hooks
resulted in configfs locking issues.
configfs files should not be measured, appraised, or audited in the
first place, so the builtin policies are updated to exclude them.
- IMA audit messages include the filename, which could result in a page
fault when the filename doesn't exist
- Un-hide the IMA_MEASURE_PCR_IDX Kconfig prompt
* tag 'integrity-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/zohar/linux-integrity:
ima: allow users to specify the pcr index with IMA_MEASURE_PCR_IDX
ima: Check for ERR_PTR from dentry_path() in validate_hash_algo()
ima: don't measure/appraise files on configfs
configfs: move CONFIGFS_MAGIC definition to magic.h
netvsc_run_xdp() in drivers/net/hyperv/netvsc_bpf.c has handled
XDP_REDIRECT since commit 1cb9d3b618 ("hv_netvsc: Add support for
XDP_REDIRECT"), and netvsc_drv.c advertises NETDEV_XDP_ACT_REDIRECT
in xdp_features. Remove the stale note.
Link: https://patch.msgid.link/20260831200357.45390-1-chrismelnu@gmail.com
Signed-off-by: Christian Melendez <chrismelnu@gmail.com>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tony Nguyen says:
====================
Intel Wired LAN Driver Updates 2026-09-01 (i40e)
Kohei Enju adds support for XDP metadata of Rx hash and VLAN tag.
Chris Packham reduces messaging when Rx filters are exhausted, and
promiscuous mode is enabled, to occur once when the mode is enabled
rather than repeated messaging for each filter.
* '40GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue:
i40e: Avoid repeating RX filter warning
i40e: add support for bpf_xdp_metadata_rx_vlan_tag()
i40e: add support for bpf_xdp_metadata_rx_hash()
i40e: prepare for XDP metadata ops support
====================
Link: https://patch.msgid.link/20260901211752.1922993-1-anthony.l.nguyen@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
bind_wildcard picks an ephemeral port by binding fd[0] with port 0, reads
it back with getsockname(), and then reuses that exact port number for the
other addresses/families in fd[1..7]. This all happens in the default
network namespace, so unrelated processes on the same host are drawing from
the very same ephemeral port range (net.ipv4.ip_local_port_range) at the
same time.
Such a process can independently get assigned that exact port number on a
different, non-conflicting address in the short window between fd[0]'s
bind() and fd[1]'s, making fd[1]'s bind() fail with EADDRINUSE for reasons
that have nothing to do with the wildcard-bind behavior under test, e.g.:
# bind_wildcard.c:775:plain:Expected ret (-1) == 0 (0)
# plain: Test terminated by assertion
not ok N bind_wildcard.v6_local_v4_local.plain
Fix it the same way so_incoming_cpu.c, tcp_port_share.c and
reuseport_dualstack.c already do: unshare into a fresh network namespace
and bring lo up, so there is nobody else to race with for the port.
Signed-off-by: Ricardo B. Marlière (SUSE) <ricardo@marliere.net>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The RX completion queue is sized to hold exactly one CQE per posted RX WQE.
MANA_FENCE_RQ makes hardware post an additional CQE_RX_OBJECT_FENCE after
the packet CQEs. The current sizing reserves no extra slot for it and in
rare cases, CQ has no guaranteed slot for the fence CQE when it is full of
packet CQEs. This can lead to dropping the fence completion while the
driver waits holding RTNL lock throughout the timeout duration.
Reserve one extra CQE slot for CQE_RX_OBJECT_FENCE. mana_gd_alloc_memory()
requires queue_size to be a power-of-two and at least MANA_PAGE_SIZE;
the reservation pushes cq_size past a power-of-two, so round up the CQ size
in mana_create_rxq().
Cc: stable@vger.kernel.org
Fixes: 6cc74443a7 ("net: mana: Add RX fencing")
Signed-off-by: Sahil Chandna <sahilchandna@linux.microsoft.com>
Reviewed-by: Haiyang Zhang <haiyangz@microsoft.com>
Link: https://patch.msgid.link/20260901121837.3503240-1-sahilchandna@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Stop verification if mark_chain_precision() fails when called from
loop_flag_is_zero(). No functional change intended for the paths where
backtracking succeeds.
Fixes: 1ade237119 ("bpf: Inline calls to bpf_loop when callback is known")
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-9-0f5a360ff15d@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
btf_check_func_arg_match() accepts a NULL register for an
ARG_PTR_TO_BTF_ID argument tagged __arg_nullable and skips
check_reg_type() and check_func_arg_reg_off() without marking the
register precise. Hence a checkpoint created on such a path would
prune against arbitrary scalar value.
Fixes: e2b3c4ff5d ("bpf: add __arg_trusted global func arg tag")
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-7-0f5a360ff15d@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
check_kfunc_arg() allows bpf_register_is_null() for nullable arguments
w/o marking the underlying scalar register precise. Hence a checkpoint
created on such a path would prune against arbitrary scalar value.
Fixes: 3bda08b636 ("bpf: Allow NULL buffers in bpf_dynptr_slice(_rw)")
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-5-0f5a360ff15d@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Check that mark_chain_precision() is called for a NULL pointer passed
as a nullable pointer argument of a global subprogram.
(Pointer arguments of the global subprograms are nullable by default).
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-4-0f5a360ff15d@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
check_mem_reg() allows bpf_register_is_null() for nullable arguments
w/o marking the underlying scalar register precise. Hence a checkpoint
created on such a path would prune against arbitrary scalar value.
The argument may live on the stack rather than in a register when a
call has more than MAX_BPF_FUNC_REG_ARGS arguments, hence the new
mark_arg_precision() helper.
Fixes: e5069b9c23 ("bpf: Support pointers in global func args")
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-3-0f5a360ff15d@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
check_func_arg() allows bpf_register_is_null() for nullable arguments
w/o marking the underlying scalar register precise. Hence a checkpoint
created on such a path would prune against arbitrary scalar value.
check_helper_call() enforces second parameter of the
bpf_get_local_storage() to be zero, w/o marking the underlying scalar
register precise. Hence a checkpoint created on such a path would
prune against arbitrary scalar value.
Grouping these two into one patch, as they share the same fixes tag.
Fixes: b5dc0163d8 ("bpf: precise scalar_value tracking")
Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
Link: https://lore.kernel.org/r/20260904-register-is-null-precise-fixes-v1-1-0f5a360ff15d@gmail.com
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Nikhil P. Rao says:
====================
pds_core: fixes for the PCI reset path [part]
Patch 1 is the v2 patch with the pdsc_core_init() and
pdsc_identify_ver() checks removed. Those checks are dead code. commit
cd09971dcc ("pds_core: keep the health thread stopped during reset")
disables health_work across the reset, so the health thread can no
longer reach pdsc_setup() with the BARs unmapped. The only other callers
are probe and pdsc_reset_done(), and both map the BARs earlier in the
same call, so cmd_regs cannot be NULL by the time they get there.
The pdsc_core_init() check is also worse than what it replaces. Its
bail-out jumps to err_out_uninit, which ends up in pdsc_intr_free() and
writes to pdsc->intr_ctrl, also NULL at that point.
On v2 I said I would convert pdsc_identify() and pdsc_core_init() to
pdsc_devcmd_with_data() once the PLDM series landed. Dropping that: the
helper has no read-back path and both callers need one, and giving them
an -ENXIO return means hardening pdsc_intr_free() against a NULL
intr_ctrl on the err_out_uninit path. That is a lot of churn to
deduplicate two call sites.
Patch 2 is the VF pci_release_regions() fix, older than the cmd_regs
race, so it carries its own Fixes tag.
The v2 changelog claim that pdsc_unmap_bars() clears db_pages was wrong.
It clears info_regs, cmd_regs, intr_status and intr_ctrl; db_pages is
never mapped.
v2: https://lore.kernel.org/20260804235946.177762-1-nikhil.rao@amd.com
v1: https://lore.kernel.org/20260729055258.1416225-1-nikhil.rao@amd.com
====================
Link: https://patch.msgid.link/20260901044219.1361466-1-nikhil.rao@amd.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
pdsc_reset_prepare() and pdsc_reset_done()'s pdsc_map_bars() error path
clear/iounmap cmd_regs without devcmd_lock, and
pdsc_legacy_firmware_update()'s download loop derefs cmd_regs after
dropping and retaking the lock without re-checking. An FLR concurrent
with a devlink flash can unmap cmd_regs under an in-flight devcmd,
causing a NULL deref or a write to unmapped MMIO.
Take devcmd_lock across the BAR unmap/remap, and re-check cmd_regs in
the download loop. Only the PF maps cmd_regs and runs devcmd, so skip
the unmap on a VF, as pdsc_remove() and pdsc_reset_done() already do.
A reset that completes entirely within the unlocked window is not a
correctness problem for the image: the device clears its update session,
so a resumed download is rejected, and it verifies the staged image
before writing a flash slot, reporting PDS_RC_BAD_FW rather than
activating it.
pdsc_unmap_bars() also clears info_regs, intr_status and intr_ctrl. The
interrupt and start/stop readers of those are quiesced before the unmap
by pdsc_fw_down(), which frees the interrupts and tears down the queues.
The debugfs readers are not, since those files outlive a reset; that is
pre-existing and out of scope here.
Fixes: e96094c1d1 ("pds_core: Clear BARs on reset")
Reported-by: sashiko-bot <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/patchset/20260708212222.296202-1-nikhil.rao%40amd.com?part=3
Signed-off-by: Nikhil P. Rao <nikhil.rao@amd.com>
Link: https://patch.msgid.link/20260901044219.1361466-2-nikhil.rao@amd.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Show the number of packets dropped by DMAC filters in the CGX/RPM
debugfs mac_filter entry.
CGX uses RX_STAT4 for this counter, while RPM/RPM2 use RX_STAT2.
Signed-off-by: Hariprasad Kelam <hkelam@marvell.com>
Signed-off-by: Nitin Shetty J <nshettyj@marvell.com>
Link: https://patch.msgid.link/20260901042503.1182121-1-nshettyj@marvell.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jamal Hadi Salim says:
====================
net: cap tx_queue_len at S16_MAX to prevent oversized ring allocations
An unprivileged user (via unshare -Urn) can set a huge tx_queue_len
and exhaust global memory through ring allocations sized from it
(pfifo_fast skb_arrays, tun/tap ptr_rings).
The reproducer from vega@nebusec.ai set the following params for
illustration: txqlen of 500000 -> ~32 GiB/ring attempts, 1.6 GB tun,
~960 MB tap. Gets worse when you consider qdiscs like mq.
What we fix: every path an unprivileged user can use to install
an oversized tx_queue_len is rejected with -ERANGE before any ring is
allocated; per-ring memory is bounded at 256 KiB.
This is for you sashikos: What we deliberately _do not fix_
bound the NUMBER of rings. With the cap in place the worst case moves
from "one knob" to the aggregate of ring x queues x devices, example:
ip link add v0 numtxqueues 4096 txqueuelen 32767 type veth
tc qdisc add dev v0 root mq
-> 4096 * 3 * 32767 * 8 = ~3.0 GiB (one command)
50 tun devices x 256 queues x 32767 x 8 = ~3.1 GiB
Unfortunately tx_queue_len is a bit ambigious in meaning:
In some cases it means a ring size (which is pre-allocated, ex:
tun, tap, and pfifo_fast); a cap of 4096 seems reasonable here.
but in other cases it is used to indicate a queue limit ex:
the qdisc consumers that allocate nothing (pfifo/bfifo/gred/plug/sfb,
htb direct_qlen, qfq, teql). 32767 is a legitimate high-BDP queue
length, so we are going to keep that value.
Getting back to you sashikos, after this is merged and shows up
in net-next we will send followup patches as follows:
this series is not misread as "closes the OOM class"):
a) Per-site ring limits at six identified locations
- pfifo_fast init/resize,
- tun attach/resize,
- tap minor/resize)
if you can spot more in your review we will take care of those as well.
b) memcg accounting (GFP_KERNEL_ACCOUNT) for those ring
allocations: contains a memcg-limited container's ring memory.
Not GFP_KERNEL_ACCOUNT has no effect on the unshare attacker
but will protect against containers (memory.max in its cgroup)
====================
Link: https://patch.msgid.link/QDISC-2899.v2.20260901233641@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Add nine test cases for the S16_MAX tx_queue_len cap to the
pfifo_fast suite. Netlink cases exercise the ifla_policy bound
(2/3); the two new sysfs cases exercise the netif_change_tx_queue_len()
choke point that 1/3 owns (SIOCSIFTXQLEN shares it; the ioctl is not
portably reachable from tdc):
- dbe3: set txqueuelen 32767 (S16_MAX) - accepted, pins the exact
boundary value.
- b50e: set txqueuelen 32768 - rejected with -ERANGE.
- 40f8: write 32768 to /sys/class/net/*/tx_queue_len - rejected
(covers patch 1/3 directly; netlink cannot reach this path).
- 4b6e: write 32767 via sysfs - accepted, boundary positive control
for the patch-1 path.
- b90d: create a dummy with txqueuelen 32767 - accepted.
- 57ab: create a dummy with txqueuelen 32768 - rejected at netlink
parse time.
- e777: create a dummy with txqueuelen 500000 - rejected (the v1
bypass path flagged by review).
- 31ac: create a veth with an oversized txqueuelen on the peer nest -
rejected (the peer nest is parsed against ifla_policy too).
- b567: create a veth with txqueuelen on both ends within the cap -
accepted (positive control for the peer nest).
The three negative-creation verifies assert device absence
("ip -o link show" must not contain the device), not merely absence
of a qlen pattern - the device does not exist when creation fails, so
the exit code carries the signal and the verify adds content.
The v1 04b5 "resize rollback" case is dropped: with the cap checked
first, netif_change_tx_queue_len() returns -ERANGE before the write,
the notifier or any qdisc resize, so the case exercised no resize and
no rollback. It was also nondeterministic: pre-patch, the resize
issues three ~11 MB kvmallocs for qlen 500000 which normally succeed,
so the case passed on an unfixed kernel only under memory pressure -
its outcome depended on the test host's free memory.
Test commands run inside the netns, but nsPlugin creates the veth
peer in the root namespace, so the teardown deletes the in-ns end
only; deleting the peer via the pair is implicit.
Note: iproute2 treats "txqueuelen" appearing after "type X" as a
link-type attribute and silently drops it, so the creation cases
place it before "type" to actually reach the kernel.
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/QDISC-2899.v2.20260901233641@mojatatu.com.3
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
rtnl_create_link() assigns IFLA_TXQLEN directly to dev->tx_queue_len
without going through netif_change_tx_queue_len(), so a device created
with "ip link add ... txqueuelen 500000" bypasses the S16_MAX cap and
still triggers the oversized ring allocations in pfifo_fast, tun and
tap. The veth peer nest (rtnl_nla_parse_ifinfomsg()) and the
RTM_NEWLINK-on-existing-device path reach the same sinks.
Enforce the cap in ifla_policy instead: IFLA_TXQLEN becomes
NLA_POLICY_FULL_RANGE(NLA_U32, &txqlen_range) with
txqlen_range = { .min = 0, .max = S16_MAX }. All netlink consumers
parse against this policy - rtnl_setlink(), rtnl_newlink() (create
and change), and the veth peer nest - so every netlink path is capped
at parse time and rejects the attribute with -ERANGE plus a proper
"integer out of range" extack message before any device state is
modified (the RTM_SETLINK half-application wart is gone with it).
Document the bound in the rt-link.yaml netlink spec.
Conditions to recreate the bug:
- CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y.
- Unprivileged user in a fresh user+net namespace (unshare -Urn):
ip link add v0 txqueuelen 500000 type veth peer name v1
-> on the fixed kernel this is rejected with -ERANGE ("integer out
of range" extack) instead of installing an oversized tx_queue_len
that later inflates pfifo_fast/tun/tap ring allocations.
- ip link set v0 txqueuelen 500000 is likewise rejected at parse time.
Fixes: 38f7b870d4 ("[RTNETLINK]: Link creation API")
Reported-by: Vega <vega@nebusec.ai>
Tested-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/QDISC-2899.v2.20260901233641@mojatatu.com.2
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Several subsystems allocate ring buffers sized by dev->tx_queue_len
with no upper bound. An unprivileged user (via unshare -Urn) can set a
huge tx_queue_len and exhaust global memory with ring allocations:
- pfifo_fast: pfifo_fast_init() and pfifo_fast_change_tx_queue_len()
allocate 3 skb_array rings of tx_queue_len entries each.
- tun: tun_queue_resize() and the queue-attach path resize ptr_rings
to tx_queue_len on the NETDEV_CHANGE_TX_QUEUE_LEN notifier.
- tap (macvtap/ipvtap): tap_queue_resize() and tap_init() resize/init
ptr_rings to tx_queue_len on the same notifier.
netif_change_tx_queue_len() is the single entry point for IFLA_TXQLEN,
sysfs, and the SIOCSIFTXQLEN ioctl. Cap new_len at S16_MAX (32767)
there so the oversized value is rejected at set time. This takes
effect whether the device is up or down, before dev->tx_queue_len is
written, before any notifier fires, and before any ring is allocated.
The "> S16_MAX" check also subsumes the previous unsigned-long
truncation test, and a negative ifr_qlen from the ioctl lands far
above the cap after conversion, so both old failure modes are covered
by the one comparison.
tx_queue_len is ambigious: both a per-ring sizing multiplier and a
default queue-length/limit knob for consumers that allocate
nothing at set time (pfifo/bfifo/gred/plug/sfb limits, htb
direct_qlen, qfq max_classes, teql). 32767 is chosen as the largest
value NLA_POLICY_FULL_RANGE can express for the u32 IFLA_TXQLEN
policy in patch 2/3 while staying a legitimate queue length on
high-BDP paths; the ring-memory trade-off of a shared knob is
disclosed below.
Conditions to recreate the bug:
- CONFIG_NET_SCHED=y, CONFIG_VETH=y, CONFIG_USER_NS=y, CONFIG_NET_NS=y.
- Unprivileged user in a fresh user+net namespace (unshare -Urn).
- pfifo_fast: create veth pairs, set tx_queue_len to 500000, attach
mq+pfifo_fast. ~28 iterations OOMs a 2GB guest.
- tun: create 50 tun devices with IFF_MULTI_QUEUE, set tx_queue_len to
500000, open 8 queues each. ~1.6GB of ptr_ring allocations OOMs a
512MB guest.
- tap: same as tun with IFF_TAP. ~960MB OOMs a 512MB guest.
- On the fixed kernel the oversized tx_queue_len is rejected with
-ERANGE at set time (all four paths: RTM_SETLINK, RTM_NEWLINK
create, sysfs, ioctl - the latter two via this check, the former
two via this check and the 2/3 parse policy respectively).
Fixes: 6a643ddb56 ("net: introduce helper dev_change_tx_queue_len()")
Reported-by: Vega <vega@nebusec.ai>
Closes: https://lore.kernel.org/netdev/20260828121902.66837-1-jhs@mojatatu.com/
Tested-by: Victor Nogueira <victor@mojatatu.com>
Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Link: https://patch.msgid.link/QDISC-2899.v2.20260901233641@mojatatu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The commit cited in the Fixes tag allowed VXLAN FDB entries to point to
FDB nexthops so that overlay traffic could be load balanced across
multiple VTEPs. Such entries can only be configured from user space,
cannot be learned and cannot roam. They only make sense with a user space
control plane such as E-VPN where data plane learning is disabled.
Despite that, the VXLAN driver does not currently prevent such entries
from being configured with the "dynamic" flag. The per-nexthop FDB list
is only protected by the per-device hash lock, which is not sufficient
when two VXLAN devices point to the same FDB nexthop and therefore share
the list. Aging runs in softirq context without RTNL, so an entry deleted
by one device can race with an addition or deletion from the other,
leading to list corruption:
list_del corruption. next->prev should be ffff8881069d9548, but was
dead000000000122. (next=ffff8881069d9448)
WARNING: CPU: 0 PID: 90 at lib/list_debug.c:65
__list_del_entry_valid_or_report+0x1aa/0x210
...
vxlan_fdb_destroy+0x5b8/0xad0
vxlan_cleanup+0x328/0x450
call_timer_fn+0x2a/0x1c0
run_timer_softirq+0x18c/0x210
BUG: KASAN: slab-use-after-free in vxlan_fdb_destroy
Fix this by rejecting the bogus configuration of dynamic FDB entries that
point to FDB nexthops, both when created and when an existing entry is
updated. As such, the per-nexthop FDB list is only ever mutated under the
RTNL lock. Add test cases to make sure that this does not regress in the
future.
Fixes: 1274e1cc42 ("vxlan: ecmp support for mac fdb entries")
Suggested-by: Ido Schimmel <idosch@nvidia.com>
Signed-off-by: Seungwon Bae <qotmddnjs@ajou.ac.kr>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260902155956.296699-1-qotmddnjs@ajou.ac.kr
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
dmb->cpu_addr was allocated via folio_alloc(). Use folio_put() instead of
kfree() in the error exit of ism_alloc_dmb() to avoid slab allocator
corruption.
While at it, reset dmb->cpu_addr after folio_put to avoid unintentional UAF
by future callers.
Fixes: 83781384a9 ("s390/ism: Properly fix receive message buffer allocation")
Signed-off-by: Alexandra Winter <wintera@linux.ibm.com>
Reviewed-by: Gerd Bayer <gbayer@linux.ibm.com>
Link: https://patch.msgid.link/20260902143733.433574-1-wintera@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
