__ptr_ring_check_produce() has no users left after reverting
commit 1d6e569b7d0c ("tun/tap & vhost-net: avoid ptr_ring tail-drop
when a qdisc is present").
The commit stops the netdev queue when the ptr_ring is full instead of
dropping the packet. My own tests showed no relevant regression, but on
Brett Sheffield's librecast testbed an IPv6 multicast testcase got
slower. With 8 iperf3 TCP threads sending, the throughput dropped from
13.5 Gbit/s to 9.13 Gbit/s.
Reported-by: Brett Sheffield <brett@librecast.net> Closes: https://lore.kernel.org/netdev/akVnoOYQOrt8k-Gu@karahi.librecast.net/ Signed-off-by: Simon Schippers <simon.schippers@tu-dortmund.de> Acked-by: Michael S. Tsirkin <mst@redhat.com> Link: https://patch.msgid.link/20260728092240.250257-2-simon.schippers@tu-dortmund.de Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jakub Kicinski [Thu, 30 Jul 2026 00:07:49 +0000 (17:07 -0700)]
Merge tag 'wireless-2026-07-29' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless
Johannes Berg says:
====================
Much quieter, thankfully:
- a set of ath12k fixes, including a recent
MLO regression for WCN7850/QCC2072
- iwlegacy gets rid of a BUG_ON that triggered
- a couple more robustness/security fixes
* tag 'wireless-2026-07-29' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless:
wifi: iwlegacy: replace BUG_ON() with WARN_ON() on num_stations check
wifi: mac80211: validate individual TWT params before driver setup
wifi: cfg80211: publish PMSR request before starting the driver
wifi: mwifiex: use the subframe length when parsing A-MSDU TDLS frames
wifi: cfg80211: validate IEs in cfg80211_wext_siwgenie()
wifi: mac80211: fix tid_tx use-after-free on BA session stop
wifi: ath12k: resolve PENDING ML peer ID from MLO_PEER_MAP HTT event
wifi: ath12k: defer dp_peer registration when firmware allocates MLD peer ID
wifi: ath12k: do not advertise MLD peer ID for firmware-allocate devices
wifi: ath12k: introduce host_alloc_ml_id hardware parameter
wifi: ath12k: add support for HTT_T2H_MSG_TYPE_MLO_RX_PEER_MAP
wifi: ath12k: keep ATH12K_PEER_ML_ID_VALID set in ath12k_sta::ml_peer_id
wifi: ath12k: factor out peer assoc send-and-wait into a helper
wifi: ath12k: fix out-of-bounds clear_bit in ath12k_mac_dp_peer_cleanup()
====================
Merge tag 'probes-fixes-v7.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull probes fixes from Masami Hiramatsu:
- Reject $arg0 during meta-argument expansion to prevent negative index
calculation and out-of-bounds reading of traceprobe parameters
- Roll back on enable_trace_fprobe() failure
Add a rollback cleanup path when __register_trace_fprobe() fails
partway through to unregister registered probes and clear flags or
file links
- Fix module reference count leak on error in register_fprobe()
Ensure the module_put() cleanup loop still runs even when
get_ips_from_filter() returns an error, preventing module
reference count leaks
* tag 'probes-fixes-v7.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
fprobe: Fix module reference count leak on error in register_fprobe()
tracing/fprobe: Roll back on enable_trace_fprobe() failure
tracing/probes: Reject $arg0 in meta argument expansion
The Adaptation Layer Indication parameter contains a fixed 32-bit
Adaptation Code Point after its parameter header. However,
sctp_verify_param() accepts a header-only parameter because the generic
parameter walker only requires the header to be present.
sctp_process_param() then reads adaptation_ind beyond the declared
parameter. When the malformed parameter is last in an INIT, the read
starts at the receive skb tail, and the value is copied into the state
cookie returned in the INIT ACK. This may disclose four receive-buffer
tail bytes.
Require the declared parameter length to match the fixed structure size
and abort the association through the existing invalid parameter length
path otherwise.
MAINTAINERS: make Luiz a maintainer and myself reviewer for Realtek DSA
I have changed jobs and therefore no longer have access to hardware
using Realtek Ethernet switches. Luiz has kindly agreed to take up the
role of maintainer, while I will stick around as a reviewer.
Also update .mailmap so that mails to my old company email stop
bouncing. Use my new work email for Analog Devices Inc. instead.
Shuangpeng Bai [Mon, 27 Jul 2026 18:53:39 +0000 (14:53 -0400)]
ipv6: release fib6_null_entry on subtree failure
When adding a source-specific route creates a new subtree, fib6_add()
installs fib6_null_entry as the temporary leaf of the new subtree root
and takes a fib6_info reference for that holder.
If adding the first source leaf fails, the code frees the just allocated
subtree root but leaves that hold behind. fib6_null_entry is a per-netns
sentinel and is freed directly at netns teardown, so this does not keep
the object alive. However, it leaves its visible refcount permanently
elevated and can eventually saturate the refcount on repeated failures.
Drop the null-entry reference before freeing the unlinked subtree root.
Fixes: 5ea715289af6 ("ipv6: broadly use fib6_info_hold() helper") Signed-off-by: Shuangpeng Bai <shuangpeng.kernel@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Link: https://patch.msgid.link/20260727185339.1545169-1-shuangpeng.kernel@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Kiran Kella [Mon, 27 Jul 2026 10:16:28 +0000 (03:16 -0700)]
psp: fix NULL genl_sock deref race with concurrent netns teardown
The race occurs between network namespace removal and PSP device
unregistration. When a netns is deleted while a PSP device associated
with that netns is concurrently being removed, psp_dev_unregister()
triggers psp_nl_notify_dev() to send a device change notification.
Concurrently, cleanup_net() running in the netns workqueue calls
genl_pernet_exit(), which sets net->genl_sock to NULL. If
genl_pernet_exit() wins the race, two sites in psp_nl_multicast_per_ns()
then dereference the NULL socket and crash:
Fix by replacing the bare dev_net() calls with maybe_get_net().
maybe_get_net() returns NULL if the namespace is already dying.
Holding the reference ensures genl_sock remains valid across both the
build_ntf() and genlmsg_multicast_netns() calls.
Fixes: 00c94ca2b99e ("psp: base PSP device support") Fixes: 06c2dce2d0f6 ("psp: add new netlink cmd for dev-assoc and dev-disassoc") Reviewed-by: Ajit Khaparde <ajit.khaparde@broadcom.com> Reviewed-by: Vikas Gupta <vikas.gupta@broadcom.com> Reviewed-by: Bhargava Marreddy <bhargava.marreddy@broadcom.com> Reviewed-by: Akhilesh Samineni <akhilesh.samineni@broadcom.com> Signed-off-by: Kiran Kella <kiran.kella@broadcom.com> Link: https://patch.msgid.link/20260727101628.502042-1-kiran.kella@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
dibs: fix use-after-free of dmb_node in loopback attach/detach/unregister
dibs_lo_attach_dmb(), dibs_lo_detach_dmb() and dibs_lo_unregister_dmb()
look up the dmb_node under dmb_ht_lock, drop the lock and only then
operate on the node's refcount. Nothing keeps the node alive across
that window: __dibs_lo_unregister_dmb() removes the node from the hash
table under the write lock and immediately frees it.
A concurrent final put can therefore free the node between the lookup
and the refcount operation:
The same window exists for the refcount_dec_and_test() calls in the
detach and unregister paths.
Close the race structurally by making hash table membership and the
refcount transitions atomic with respect to each other:
- Perform the final refcount_dec_and_test() and hash_del() in a single
dmb_ht_lock write-side critical section, in both the unregister and
the detach path. Freeing the node still happens after the lock is
dropped, which is safe because a node whose refcount reached zero has
left the hash table and can no longer be found.
- This establishes the invariant that any node found in the hash table
holds at least one reference, and that the final reference can only
be dropped under the write lock. dibs_lo_attach_dmb() can thus take
its reference with a plain refcount_inc() while still holding the
read lock; refcount_inc_not_zero() is no longer needed.
__dibs_lo_unregister_dmb() no longer touches the hash table and is
renamed to dibs_lo_free_dmb() accordingly.
Note: commit cc21191b584c ("dibs: Move data path to dibs layer") moved
the code to its current location; the race was introduced earlier by
commit c3a910f2380f ("net/smc: implement DMB-merged operations of
loopback-ism").
Tested SMC-D via ISM and dibs loopback.
Cc: stable@vger.kernel.org Fixes: c3a910f2380f ("net/smc: implement DMB-merged operations of loopback-ism") Reported-by: Rahul Chandelkar <rc@rexion.ai> Signed-off-by: Hidayath Khan <hidayath@linux.ibm.com> Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Link: https://patch.msgid.link/20260727093530.968834-1-hidayath@linux.ibm.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
ring-buffer: Fix reader page read offset for remote buffers
A page swapped in by __rb_get_reader_page_from_remote() retains its
stale read offset, causing subsequent reads to skip events or read
past valid data. Fix it.
Link: https://patch.msgid.link/20260729133609.4022734-1-vdonnefort@google.com Fixes: fbd1743ecba1 ("ring-buffer: Add non-consuming read for ring-buffer remotes") Signed-off-by: Vincent Donnefort <vdonnefort@google.com> Reviewed-by: Keir Fraser <keirf@google.com> Tested-by: Keir Fraser <keirf@google.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Karl Mehltretter [Wed, 29 Jul 2026 01:21:32 +0000 (03:21 +0200)]
riscv: mm: Fix out-of-bounds page-table walk during memory hot-remove
remove_pud_mapping() and remove_p4d_mapping() obtain a child table base
with pud_offset(p4dp, 0) and p4d_offset(pgd, 0), then add the index for
addr.
RISC-V folds page-table levels at runtime. When a level is folded, its
offset helper returns the parent entry itself, but the index can still be
nonzero. Adding it walks past the parent table. Sv48 folds P4D, while Sv39
folds both P4D and PUD, so memory hot-remove can descend into unrelated
memory and pass an invalid page to __free_pages(). This can trigger:
kernel BUG at include/linux/mm.h:1810!
VM_BUG_ON_PAGE(page_ref_count(page) == 0)
arch_remove_memory+0x1e/0x5c
try_remove_memory+0x15e/0x200
remove_memory+0x24/0x3c
Only add the index when the corresponding page-table level is enabled,
matching p4d_offset() and pud_offset().
Fixes: c75a74f4ba19 ("riscv: mm: Add memory hotplugging support") Assisted-by: Claude:claude-fable-5 Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com> Link: https://patch.msgid.link/20260729012132.24882-1-kmehltretter@gmail.com Signed-off-by: Paul Walmsley <pjw@kernel.org>
kbuild: rpm-pkg: Preserve BTF sections in kernel modules during debuginfo stripping
After switching to the kernel's default package scripts for our local
kernel RPM builds, we noticed that module BTF entries were missing:
$ ls /sys/kernel/btf/
vmlinux <<<< only vmlinux, no module BTF
Root cause: find-debuginfo.sh (from the debugedit package) prefers
eu-strip over strip when elfutils is installed, which is the common
case on RHEL 9. eu-strip removes non-allocated ELF sections, including
the .BTF section that contains BPF Type Format information for kernel
modules. Without .BTF, BPF tools (bpftool, bcc, bpftrace) cannot resolve
kernel types at runtime, and /sys/kernel/btf/<module> entries are not
created when modules are loaded.
Additionally, since commit 8646db238997 ("libbpf,bpf: Share BTF
relocate-related code with kernel"), modules contain a .BTF.base section
that maps distilled type IDs to vmlinux types. If .BTF.base is stripped,
btf_parse_module() falls back to vmlinux BTF directly, causing type ID
mismatches and rejecting the module's BTF entirely.
Fix by passing --keep-section .BTF and --keep-section .BTF.base via
_find_debuginfo_opts, which adds -K .BTF and -K .BTF.base to the
eu-strip/strip command, preserving both sections while allowing normal
debuginfo extraction to proceed.
After this change, all module BTF files are properly generated:
Leo Li [Tue, 28 Jul 2026 17:02:47 +0000 (13:02 -0400)]
drm/amd/display: Exit idle optimizations before programming
[Why]
We need to exit PSR/IPS before programming. Before calling DC for
programming in amdgpu_dm_commit_planes(), there's a
vblank_control_workqueue flush. This waits for IPS and PSR exit. (See
drm_vblank_on/off() > amdgpu_dm_crtc_set_vblank() --queue_work()->
amdgpu_dm_crtc_vblank_control_worker())
Prior to the tagged "Fixes:" change, drm_vblank_get() was called before
the workqueue flush. This ordering ensures that PSR exit occurred before
programming. After the "Fixes:" change, drm_vblank_get() is called after
the workqueue flush, leading to programming while idle optimizations are
still active. This can lead to incorrect flip_pending detection used by
vblank event delivery.
[How]
Split the vblank_get() component of `dm_arm_vblank_event()` into
`dm_arm_vblank_event_pre_programming()`, which is called before
programming. Call it before the vblank_control_workqueue flush.
Includes a drive-by cleanup of prepare_flip_isr(): the only caller is
dm_arm_vblank_event() and it's simple enough to roll-in.
v2: Fix checkpatch formatting warning on
drm_arm_vblank_event_pre_programming() arg alignment.
Yang Wang [Wed, 29 Jul 2026 07:56:46 +0000 (15:56 +0800)]
drm/amd/pm: hide pp_table sysfs on APUs
APUs use firmware-owned DPM tables and do not support replacement through
pp_table. Generic callbacks can nevertheless expose the sysfs file and
accept an upload before resetting the power management stack.
Treat pp_table as unsupported on APUs. Use the same platform check in the
get and set paths to hide the file and reject uploads.
Fixes: 289921b03fe5 ("drm/amd/powerplay: implement sysfs of pp_table for smu11 (v2)") Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
(cherry picked from commit 74f28db2db69777cd2f059d50fe34e365ddd5add) Cc: stable@vger.kernel.org
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull kvm fixes from Paolo Bonzini:
"arm64:
- Fix a tiny buglet when propagating the deactivation of an interrupt
from a nested guest, which happened to trigger a gold plated CPU
bug on a particular implementation
- Fix a race between LPI unmapping and mapping, resulting in leaked
LPIs
- Make LPI mapping more robust on memory allocation failure
- Fix the handling of the EL2 tracing clock being disabled
- A couple of Sashiko-driven fixes for corner cases in the EL2
tracing code
- Add missing sysreg tracepoint for the EL2 code
- Tidy-up the mutual exclusion of guest-memfd and MTE
- Update Fuad's email address to point to @linux.dev
s390:
- several fixes for PCI passthru in s390 kvm
- fix a 7.2-rc regression in the adapter interrupt mapping code
x86:
- Add memory clobber to asm for VMX instructions; without one, the
compiler could reorder them in troublesome ways because "asm
volatile" and "asm goto" only protect against removal of the asm.
- Cancel delayed I/O APIC EOI handling before destroying vCPUs
- Check all address spaces (normal and SMM) for write tracking and large
pages, not just the current one.
- Always update x2APIC MSR intercepts for L1 when AVIC is deactivated,
even if not running L1. If the deactivation is VM-wide rather than being
caused by something in L2's vCPU state, after a nested vmexit L1 will
be able to access the host's APIC state"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (21 commits)
KVM: SVM: Update x2APIC MSR intercepts if AVIC is inhibited while L2 is active
KVM: x86/mmu: Check all address spaces before skipping unsync
KVM: x86/mmu: Check write tracking in all address spaces
KVM: x86: Cancel delayed I/O APIC EOI handling before destroying vCPUs
KVM: VMX: add memory clobber to asm for VMX instructions
KVM: s390: Fall back to short-term pinning in MAP ioctl
KVM: s390: pci: Validate AIBV and AISB before pinning guest pages
KVM: s390: pci: Fix resource leak on IRQ registration failure
KVM: s390: pci: Fix NULL dereference on AIBV allocation failure
KVM: s390: pci: Fix missing error codes and memory unaccounting
KVM: s390: pci: Fix memory accounting for pinned/unpinned pages
KVM: s390: pci: Reject adapter interrupt forwarding if already enabled
KVM: arm64: Reject guest_memfd memslots when the VM has MTE
KVM: arm64: Add missing hyp_enter when trapping sysreg
KVM: arm64: Fix hyp_trace_desc allocation size in hyp_trace_load()
KVM: arm64: Fix potential leak in hyp_trace_buffer_alloc_bpages_backing
KVM: arm64: Fix hyp_trace clock disabling
KVM: arm64: vgic: Mitigate potential LPI registration failure
KVM: arm64: vgic: Fix race between LPI release and re-registration
KVM: arm64: Update Fuad Tabba's email address
...
KVM: SVM: Update x2APIC MSR intercepts if AVIC is inhibited while L2 is active
Always update x2APIC MSR intercepts for L1 when AVIC is deactivated, even
if L2 is active and KVM is using a separate MSR bitmap to run L2. If AVIC
is fully enabled prior to running L2, and is then inhibited while L2 is
active (for a VM-scoped inhibit), then KVM will run L1 with AVIC disabled,
but with x2APIC MSR intercepts disabled, i.e. will allow L1 to read most of
the host's APIC state, send arbitrary interrupts, change task priority, and
ultimately trivially DoS the host.
E.g. sending a self-IPI in L1 on HYPERV_REENLIGHTENMENT_VECTOR, 0xee, with
CONFIG_HYPERV=n in the host kernel as a "safe" PoC, yields:
Spurious interrupt (vector 0xee) on CPU#425. Acked
And hacking KVM to abuse kvm_set_posted_intr_wakeup_handler() to register a
handler and WARN on POSTED_INTR_WAKEUP_VECTOR yields:
------------[ cut here ]------------
WARNING: arch/x86/kvm/svm/svm.c:5594 at pi_wakeup_handler+0x9/0x10 [kvm_amd], CPU#156: nested_x2apic_t/316940
CPU: 156 UID: 0 PID: 316940 Comm: nested_x2apic_t Tainted: G S U
Tainted: [S]=CPU_OUT_OF_SPEC, [U]=USER
Hardware name: Google Astoria-Turin/astoria, BIOS 0.20260209.0-0 02/09/2026
RIP: 0010:pi_wakeup_handler+0x9/0x10 [kvm_amd]
Call Trace:
<IRQ>
sysvec_kvm_posted_intr_wakeup_ipi+0x64/0x80
</IRQ>
<TASK>
asm_sysvec_kvm_posted_intr_wakeup_ipi+0x1a/0x20
RIP: 0010:vcpu_run+0x1430/0x1e40 [kvm]
kvm_arch_vcpu_ioctl_run+0x2c1/0x600 [kvm]
kvm_vcpu_ioctl+0x580/0x6b0 [kvm]
__se_sys_ioctl+0x6d/0xb0
do_syscall_64+0x10a/0x480
entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x46ff4b
</TASK>
---[ end trace 0000000000000000 ]---
Fixes: 091abbf578f9 ("KVM: x86: nSVM: optimize svm_set_x2apic_msr_interception") Cc: stable@vger.kernel.org Cc: Yosry Ahmed <yosry@kernel.org> Signed-off-by: Sean Christopherson <seanjc@google.com> Link: https://patch.msgid.link/20260729213558.639074-1-pbonzini@redhat.com/ Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Muhammad Bilal [Wed, 17 Jun 2026 21:25:20 +0000 (02:25 +0500)]
accel/qaic: use sizeof(*trans_hdr) for transaction length check
In encode_message() the per-transaction lower-bound check compares
trans_hdr->len against sizeof(trans_hdr), i.e. the size of the pointer,
instead of sizeof(*trans_hdr), the size of struct qaic_manage_trans_hdr.
Every other length check in this file (encode_message() at the loop
guard, decode_message(), etc.) correctly uses sizeof(*trans_hdr), so
this is an inconsistency. On 64-bit builds the pointer and the struct
are both 8 bytes, so the check is correct by coincidence and there is
no behavioural change. On 32-bit builds the pointer is 4 bytes, which
weakens the minimum-length check below the 8-byte header size.
Use sizeof(*trans_hdr) so the check validates against the actual
transaction header size on all builds.
Fixes: ea33cb6fc278 ("accel/qaic: tighten bounds checking in encode_message()") Signed-off-by: Muhammad Bilal <meatuni001@gmail.com> Reviewed-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Signed-off-by: Jeff Hugo <jeff.hugo@oss.qualcomm.com> Link: https://patch.msgid.link/20260617212520.59801-1-meatuni001@gmail.com
audit: fix potential use-after-free in audit_del_rule()
`audit_del_rule()` destroys `e->rule.exe` via `audit_remove_mark_rule()`
before unlinking the rule from RCU-visible filter lists and waiting for a
grace period. Concurrent readers in `audit_filter()` and
`audit_filter_rules()` still dereference `e->rule.exe`, while the fsnotify
mark can be freed on an independent lifetime path. This creates a
use-after-free window during rule deletion.
Fix this by unlinking the rule from the RCU-visible lists and invoking
`synchronize_rcu()` before calling `audit_remove_mark_rule()` (and other
rule removal helpers). This ensures that all existing RCU readers have
exited the critical section before any underlying resources are destroyed.
Cc: stable@vger.kernel.org Fixes: 34d99af52ad4 ("audit: implement audit by executable") Reported-by: Vega <vega@nebusec.ai> Assisted-by: Codex:gpt-5.4 Signed-off-by: Luxiao Xu <rakukuip@gmail.com> Signed-off-by: Ren Wei <enjou1224z@gmail.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
audit: fix potential integer overflow in audit_log_n_string()
audit_log_n_string() computes new_len as "slen + 3" (enclosing quotes
plus the NUL terminator) and stores it into an int, while slen is a
size_t. For a sufficiently large slen the addition can overflow and/or
the result be truncated when assigned to the int new_len, so the
"new_len > avail" check can be bypassed and the subsequent
memcpy(ptr, string, slen) can write past the skb tail.
This is the same class of bug that was fixed for the hex sibling in
commit 65dfde57d1e2 ("audit: fix potential integer overflow in
audit_log_n_hex()"); both helpers are reached through
audit_log_n_untrustedstring() with the same length source.
Make new_len a size_t and use check_add_overflow() to catch the
overflow, mirroring the audit_log_n_hex() fix. No functional change for
the in-tree callers, which all pass bounded lengths.
Cc: stable@vger.kernel.org Fixes: 168b7173959f ("AUDIT: Clean up logging of untrusted strings") Signed-off-by: Zhan Xusheng <zhanxusheng@xiaomi.com> Signed-off-by: Paul Moore <paul@paul-moore.com>
riscv: drop __init from vec_check_unaligned_access_speed_all_cpus
This function runs within a kthread and need not necessarily finish
before system finishes boot and free_initmem() unmaps the .init.text
section. This function makes calls to SBI for probing unaligned access
speed, and if this is slow for some reason (say some debug prints were
added to SBI), the kthread can still be running at this point and result
in an instruction page fault when trying to fetch from the freed region.
tracing/filters: Fix false positive match in regex_match_full()
regex_match_full() calls strncmp(str, r->pattern, len) where len is the
target field buffer size. When len is smaller than r->len (the filter
pattern length), strncmp() checks only len bytes of r->pattern against
str. If those len bytes match, strncmp() returns 0, resulting in a
false-positive match where a shorter string in a fixed-size field
matches a longer filter pattern.
For example, a 4-byte static string field containing "abcd" matched the
filter pattern "abcdefgh" because strncmp("abcd", "abcdefgh", 4)
returned 0. In this case, @len does NOT include '\0' because it is
fixed-size array.
Fix this by returning 0 (no match) early when len < r->len.
tracing: Check return value of __register_event() in trace_module_add_events()
trace_module_add_events() ignores the return value of __register_event()
and unconditionally calls __add_event_to_tracers() for each event.
If __register_event() fails (for example, if event_init() fails), the
trace_event_call is not added to ftrace_events list, but
__add_event_to_tracers() still creates a trace_event_file pointing to it.
If module loading subsequently fails and module memory is freed, tracing
state retains a stale trace_event_call pointer in trace_event_file,
leading to a use-after-free when tracefs or tracing subsystem operations
are later executed.
Fix this by checking the return value of __register_event() and only
calling __add_event_to_tracers() if event registration succeeded.
Fixes: ae63b31e4d0e ("tracing: Separate out trace events from global variables") Cc: stable@vger.kernel.org Link: https://patch.msgid.link/178528487878.124250.14170824576025743236.stgit@devnote2 Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
tracing/mmiotrace: Add NULL check for mmio_trace_array in logging functions
mmio_trace_rw() and mmio_trace_mapping() retrieve mmio_trace_array into
tr and pass it to __trace_mmiotrace_rw() and __trace_mmiotrace_map().
If these functions are invoked while mmio_trace_array is NULL (e.g. before
initialization or after disabled), accessing tr->array_buffer.buffer will
result in a NULL pointer dereference crash.
Fix this by adding an explicit NULL check for tr at the beginning of
__trace_mmiotrace_rw() and __trace_mmiotrace_map().
tracing/mmiotrace: Reset dropped_count in mmio_reset_data()
mmio_reset_data() is called during tracer initialization, reset, and
start. While it resets overrun_detected and prev_overruns, it neglects
to reset dropped_count. Consequently, dropped event counts from prior
tracing sessions persist in dropped_count and corrupt overrun reports
in subsequent runs.
Fix this by explicitly calling atomic_set(&dropped_count, 0) in
mmio_reset_data().
Link: https://patch.msgid.link/178524299122.56416.16277704230639425172.stgit@devnote2 Fixes: 173ed24ee2d6 ("mmiotrace: count events lost due to not recording") Assisted-by: Antigravity:gemini-3.6-flash Signed-off-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
riscv: mm: fix SWIOTLB initialization for systems with DRAM above 4GB
On RISC-V platforms where the entire physical memory (DRAM) resides
above the 32-bit address space (i.e., above dma32_phys_limit), the
current SWIOTLB initialization logic fails.
This patch addresses two interconnected issues on such platforms:
1. Incorrect 32-bit DMA bounce assumption:
The existing condition `max_pfn > PFN_DOWN(dma32_phys_limit)` assumes
that a 32-bit DMA bounce buffer is required simply because the maximum
PFN exceeds the 32-bit limit. However, if all DRAM starts above 4GB,
no memory exists below the limit to satisfy this allocation. Fix
this by adding a check to ensure `memblock_start_of_DRAM()` is actually
below the 32-bit limit before enforcing 32-bit SWIOTLB.
2. kmalloc() bounce buffer allocation failure on non-coherent systems:
For non-coherent DMA, kmalloc() buffers whose sizes are not
cache-line-aligned still require bouncing, even if 32-bit DMA bouncing
is skipped. Without the `SWIOTLB_ANY` flag, swiotlb_init() defaults to
allocating from low memory, which fails completely when DRAM only exists
in high memory. By appending `SWIOTLB_ANY` to swiotlb_flags, the allocator
is permitted to allocate this bounce buffer from high memory.
With this patch, systems with non-coherent DMA and DRAM entirely above
4GB can successfully map the software IO TLB in high memory and boot
normally.
Yong-Xuan Wang [Wed, 29 Jul 2026 17:43:28 +0000 (11:43 -0600)]
riscv/sifive: remove warning in errata
The alternative patching of sifive vendor extensions also calls the
sifive_errata_patch_func(), but the patch_id of the vendor extension
(ext + RISCV_VENDOR_EXT_ALTERNATIVES_BASE) is always larger than
ERRATA_SIFIVE_NUMBER. Remove this unnecessary warning.
Nam Cao [Wed, 29 Jul 2026 17:43:28 +0000 (11:43 -0600)]
riscv: time: Add missing __iomem in get_cycles() and get_cycles_hi()
__iomem is missing while calling readl_relaxed() in get_cycles() and
get_cycles_hi() and sparse complains.
Add __iomem to silence the sparse warnings.
Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202607160619.14G8GHp5-lkp@intel.com/ Signed-off-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260716053319.2178937-1-namcao@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
hwmon: (npcm750-pwm-fan): stop fan timer on device detach
When a fan tach channel is present, npcm7xx_pwm_fan_probe() starts
fan_timer. The timer callback polls tach state and rearms the timer, but
the driver has no remove callback or devm cleanup action to stop it. On
device detach, the devm-managed driver data and I/O mappings can be
released while the timer is still pending or running.
Register a devm cleanup action before starting the timer and shut the
timer down synchronously from that action.
iface_fw_to_cpu_addr() only checks that the firmware-provided MCU virtual
address points inside the shared section. The returned pointer is later
used as a full firmware interface structure, so accepting an address near
the end of the shared section can still lead to out-of-bounds accesses.
Pass the expected object size to iface_fw_to_cpu_addr() and reject ranges
that do not fit entirely in the shared section.
Fixes: 2718d91816ee ("drm/panthor: Add the FW logical block") Cc: stable@vger.kernel.org Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patch.msgid.link/20260720114918.15973-1-osama.abdelkader@gmail.com
fprobe: Fix module reference count leak on error in register_fprobe()
In register_fprobe(), get_ips_from_filter() resolves target function
addresses and increments module reference counts via try_module_get() for
symbols in kernel modules. If get_ips_from_filter() fails on the second
pass and returns an error, register_fprobe() returned directly without
releasing module references acquired up to that point.
Fix this by ensuring the cleanup loop executing module_put() runs even when
get_ips_from_filter() returns a negative error.
drm/xe/pt: check no-DMA huge-pte cases before DMA segment test
On a non-range clear, curs.size is never set, so the segment test
(next - va_curs_start > curs->size) returns false for every level > 0
before the clear_pt short-circuit is reached. The clear then descends to
level 0 instead of forming a huge zero-leaf, wasting page tables and
risking -ENOMEM on unbind.
Move the null-VMA, purged-BO and clear_pt short-circuits above the
curs->size test. The bind path always sets curs.size, so it is unaffected.
v2
- Also set curs.size on the clear path so the cursor stays meaningful
during the walk. clear_pt is only reached with range == NULL, so assert
that invariant. (Matthew Brost)
Cc: Matthew Brost <matthew.brost@intel.com> Fixes: 5b658b7e89c3 ("drm/xe: Clear scratch page on vm_bind") Reported-by: Sashiko <sashiko-bot@kernel.org> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260728055916.593707-2-himal.prasad.ghimiray@intel.com Signed-off-by: Himal Prasad Ghimiray <himal.prasad.ghimiray@intel.com>
(cherry picked from commit 04eeeb45cb61b8a3e9d785003457e550c920ba49) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
drm/imagination: Update the trace point pvr_job_submit_fw()
Trace point pvr_job_submit_fw() is used to trace job submission to
the FW. Currently it is recorded when a command is written to the Client
circular buffer.
Move trace recording after writing command to the Kernel circular buffer to
better represent command submission to the FW.
Fixes: c1079aebb4de ("drm/imagination: Add support for trace points") Signed-off-by: Brajesh Gupta <brajesh.gupta@imgtec.com> Reviewed-by: Alessio Belle <alessio.belle@imgtec.com> Link: https://patch.msgid.link/20260724-b4-tracepoint-fix-v3-1-8f8e5e8179d3@imgtec.com Signed-off-by: Alessio Belle <alessio.belle@imgtec.com>
Alexander Kaplan [Sat, 18 Jul 2026 10:52:07 +0000 (12:52 +0200)]
drm/i915/dp: Ignore the sink's DSC max FRL rate without a PCON DSC encoder
intel_dp_hdmi_sink_max_frl() limits the sink's max FRL rate by its
DSC max FRL rate whenever the sink supports DSC 1.2.
However, the DSC max FRL rate (HF-VSDB DSC_Max_FRL_Rate) only applies
to compressed video transport, which requires a DSC 1.2 encoder in
the PCON (configured via intel_dp_pcon_dsc_configure()).
Without such an encoder the HDMI link always carries uncompressed
video, for which the regular Max_FRL_Rate is the correct limit.
Applying the DSC limit unconditionally trains the FRL link at a lower
rate than both the PCON and the sink support.
E.g. an LG OLED G4 (Max_FRL_Rate 48 Gbps, DSC_Max_FRL_Rate 24 Gbps)
behind a Synaptics VMM7100 PCON (PCON max FRL bw 48 Gbps, no DSC
encoder):
Sink max rate from EDID = 24 Gbps
FRL trained with : 24 Gbps
while Windows/macOS train the same hardware at 40/48 Gbps.
The too low FRL rate needlessly constrains the formats available to
the sink.
Only apply the sink's DSC max FRL rate if the PCON has a DSC 1.2
encoder, matching the gate in intel_dp_pcon_dsc_configure().
PCONs with a DSC encoder keep the current conservative behavior,
since the link is trained once and compressed transport may be used
for any subsequent mode.
With this the setup above trains at 48 Gbps.
Tested on PTL (xe) with the above PCON/sink combo.
Fixes: 10fec80b48c5 ("drm/i915/display: Configure PCON for DSC1.1 to DSC1.2 encoding") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260718105207.5565-3-alexander.kaplan@sms-medipool.de
(cherry picked from commit 71b57dd92f94569dca4bdf883fbd8ca5d4ed4bae) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
The OVL adaptor registers both an aggregate driver for its child devices
and a component for the main DRM aggregate. Probe currently ignores an
error from registering the child aggregate and leaves that aggregate
registered if registering the DRM component fails. The remove callback
also leaves the DRM component registered.
These imbalances can leave component framework entries referring to a
device whose probe failed or whose driver has been detached. The aggregate
unbind callback also fails to undo component_bind_all(), leaving its child
components marked as bound when the aggregate is removed.
Check the aggregate registration result, unwind it when the component
registration fails, and unregister the component before the aggregate on
remove. Keep runtime PM enabled until both framework registrations have
been removed, and unbind all child components from the aggregate unbind
callback.
Fixes: 453c3364632a ("drm/mediatek: Add ovl_adaptor support for MT8195") Cc: stable@vger.kernel.org # 6.4+ Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20260721152242.47138-1-mhun512@gmail.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
drm/mediatek: mtk_dsi: Enable HS clock only at pre-enable
Commit 76255024cadb ("drm/mediatek: mtk_dsi: enable hs clock
during pre-enable") rightfully moves the HS clock enablement to
before atomic_enable(), but it's moving it to mtk_dsi_poweron(),
which is not only called in the .atomic_pre_enable() callback
for the DRM bridge, but also in the MediaTek DRM's .ddp_start()
callback, which happens way before the bridge ones.
The HS clock enablement should be done at just the right time,
otherwise some bridge chips (or some Display Driver ICs) may
not work correctly: this is seen at least with a Parade DSI to
eDP bridge (PS8640) on the MT8173 Elm Chromebook.
This resolves a regression that was seen on the aforementioned
machine, which was happening only after a suspend-resume cycle.
Alexander Kaplan [Wed, 10 Jun 2026 19:38:25 +0000 (21:38 +0200)]
drm/dp: Read the PCON max FRL bandwidth only for HDMI DFPs
The PCON max FRL bandwidth field lives in byte 2 of the DFP Detailed
Capability Info (DPCD 0x82 for the first DFP).
The DP standard defines the meaning of descriptor bytes 1-3 strictly
per DFP type, and for a DisplayPort type DFP all of them are
reserved, with "read all 0s" semantics (DP v2.0, section 2.12.3,
Table 2-183).
The FRL bandwidth field is an HDMI DFP extension added by the VESA
DP-to-HDMI PCON specification.
drm_dp_get_pcon_max_frl_bw() however parses the byte without checking
the DFP type, the branch presence or DETAILED_CAP_INFO_AVAILABLE.
Without the latter the port descriptors are one byte wide and
port_cap[2] is not even the right register.
All neighbouring helpers parsing the same descriptor are scoped by
the DFP type already, see for instance drm_dp_downstream_max_bpc()
reading the same byte and returning 0 for a DP type DFP.
amdgpu's DC parses the field only for HDMI(/DP++) detailed types as
well.
This is not theoretical.
A Synaptics VMM7100 based USB-C to HDMI adapter with a macOS targeted
firmware advertises a DisplayPort type DFP with the type byte
replicated across the whole descriptor (08 08 08 08).
i915 decodes that as "PCON limited to 18 Gbps FRL" and prunes every
mode above ~750 MHz dotclock, including all the 4k@100/120 modes the
sink EDID offers, while macOS drives 4k@120 through the same adapter
just fine via DP DSC (and amdgpu's type-scoped parser would ignore
the bogus field as well).
Only parse the field for an HDMI DFP behind a DPCD 1.1+ branch
device that reports detailed cap info, matching the type-scoped
field layout of the spec and the rest of the helpers.
Fixes: ce32a6239de6 ("drm/dp_helper: Add Helpers for FRL Link Training support for DP-HDMI2.1 PCON") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> (v2) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.12+ Signed-off-by: Alexander Kaplan <alexander.kaplan@sms-medipool.de> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patch.msgid.link/20260610193825.2933-1-alexander.kaplan@sms-medipool.de
Chao Shi [Mon, 27 Jul 2026 20:12:57 +0000 (16:12 -0400)]
block: stop the timeout timer when releasing a never added disk
disk_release() undoes blk_mq_init_allocated_queue() for a disk whose
probe failed before add_disk(), but it only calls blk_mq_exit_queue().
Nothing there stops q->timeout, and that timer rolls forward: it stays
pending until it next expires, not until the last request completes.
So if the driver issued any I/O before adding the disk, the
request_queue is freed while still linked into a timer wheel bucket.
Commit 6f8191fdf41d ("block: simplify disk shutdown") dropped the
blk_cleanup_queue() call that used to stop it. __del_gendisk() and
blk_mq_destroy_queue() still do; only the probe failure path lost it.
nvme gets there because nvme_update_ns_info() submits Report Zones or
FDP io-mgmt-recv on ns->queue before the disk is added, so a later
failure - a concurrent reset setting NVME_CTRL_FROZEN, or
device_add_disk() failing - lands in put_disk() with the timer armed:
BUG: KASAN: slab-use-after-free in detach_if_pending+0x30c/0x340
Write of size 8 at addr ffff888004d71310 by task kworker/u8:2/37
__timer_delete_sync+0x156/0x240 kernel/time/timer.c:1621
blk_sync_queue+0x22/0x40 block/blk-core.c:222
nvme_sync_queues+0x100/0x150 drivers/nvme/host/core.c:5362
nvme_reset_work+0x138/0x930 drivers/nvme/host/pci.c:3264
Allocated by task 34:
__blk_mq_alloc_disk+0x33/0x100 block/blk-mq.c:4462
nvme_alloc_ns+0x290/0x3870 drivers/nvme/host/core.c:4146
Freed by task 0:
blk_free_queue_rcu+0x3a/0x50 block/blk-core.c:254
rcu_core+0xc10/0x1730 kernel/rcu/tree.c:2857
The queue being synced there is ctrl->admin_q, only a victim sharing a
timer wheel bucket with the freed queue's dangling entry; other runs
tripped in enqueue_timer(), __run_timers() or blk_mq_timeout_work().
Failing nvme_alloc_ns() with a debug patch makes it deterministic: one
leaked timer trips KASAN within seconds, while 1987 patched releases
produced no splat.
Stop the timer and the queue work items before blk_mq_exit_queue(), like
blk_mq_destroy_queue() does.
Found by FuzzNvme.
Fixes: 6f8191fdf41d ("block: simplify disk shutdown") Acked-by: Weidong Zhu <weizhu@fiu.edu> Signed-off-by: Chao Shi <coshi036@gmail.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260727201257.211635-1-coshi036@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
ems_usb_read_bulk_callback() walks CPC messages packed in one USB
receive buffer.
Check that each declared message fits in the URB payload. Also require the
type-specific payload to cover the fields used by the CAN, state, error and
overrun handlers.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260706092752.79600-1-pengpeng@iscas.ac.cn Fixes: 702171adeed3 ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface") Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
es58x_read_bulk_callback() resubmits the RX URB after processing a received
packet. If the resubmit succeeds, the URB remains anchored and will be
handled by the normal RX path or by teardown.
However, if usb_submit_urb() fails, the callback unanchors the URB and then
returns directly. This skips the existing free_urb path, so the coherent
transfer buffer allocated with usb_alloc_coherent() is not released.
Reuse the existing free_urb path after a resubmit failure so that the RX
coherent buffer is freed before leaving the callback.
Fixes: 5eaad4f76826 ("can: usb: etas_es58x: correctly anchor the urb in the read bulk callback") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/20260706014601.415445-1-lgs201920130244@gmail.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: gs_usb: gs_usb_receive_bulk_callback(): resubmit URB on skb allocation failure
If the allocation of the SKB in gs_usb_receive_bulk_callback() fails, the
driver returns from the callback without resubmitting the URB in order to
receive further USB in URBs.
This results in a silent performance degradation which, if it occurs
repeatedly, results in starvation of USB in traffic.
Instead of returning immediately, try to resend the URB. If this also
fails, this is logged as an info message.
can: c_can: c_can_chip_config(): keep controller in init mode until bittiming is configured
c_can_chip_config() was programming C_CAN_CTRL_REG without CONTROL_INIT,
which may allow the controller to become active before
c_can_set_bittiming() finishes.
That creates a short timing window where the peripheral can interact with
the bus using a different/default bitrate, potentially generating bus
errors and corrupting traffic.
Set CONTROL_INIT together with the control-mode writes in
c_can_chip_config() (normal, loopback and listen-only paths), so the
controller stays halted until bit timing is fully programmed.
This prevents transient bus disturbance during startup when the configured
bitrate differs from the active bus bitrate.
Signed-off-by: Lucas Martins Alves <lucas.alves@lumal21.com.br> Link: https://patch.msgid.link/20260714164839.771123-1-lucas.alves@lumal21.com.br Fixes: 881ff67ad450 ("can: c_can: Added support for Bosch C_CAN controller") Cc: stable@kernel.org
[mkl: remove space before close parenthesis] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: softing: fw_parse(): validate firmware record spans
fw_parse() reads a fixed record header, a firmware-provided payload,
and a trailing checksum without knowing the end of the firmware blob. A
truncated record can therefore make those reads exceed the blob.
The same record also supplies addresses and lengths for writes into
DPRAM. The generic loader uses wrap-prone mixed signed arithmetic for its
bounds check, while the application loader does not bound the staging
copy at all.
Pass the firmware end to the parser and validate the full source record.
Use a signed wide offset for generic DPRAM records and validate the
application staging span against the mapped DPRAM before copying.
Tu Nguyen [Thu, 25 Jun 2026 13:51:51 +0000 (14:51 +0100)]
can: rcar_canfd: change the initializing flow for clocks and resets
Testing CANFD on RZ/G3E shows that many registers do not reset to their
initial values with the current flow of deasserting resets first and then
enabling clocks.
Based on the HW manual, clocks should be supplied first and the
resets deasserted afterward.
section 7.4.3 Procedure for Activating Modules: RZ/G2L
section 4.4.9.3 Procedure for Starting up Units: RZ/G3E
So, update the order of the initializing flow for resets and clocks
to match the hardware manual, resetting all CANFD registers to their
initial values. Also update rcar_canfd_global_deinit() to assert
resets before disabling clocks, so the teardown path mirrors the new
init ordering.
Fixes: 76e9353a80e9 ("can: rcar_canfd: Add support for RZ/G2L family") Signed-off-by: Tu Nguyen <tu.nguyen.xg@renesas.com> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com> Tested-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/20260625135216.130450-1-biju.das.jz@bp.renesas.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: kvaser_usb_leaf: kvaser_usb_leaf_wait_cmd(): validate received command extents
The wait and bulk receive paths walk variable-length commands from a
USB buffer. A nonzero command shorter than CMD_HEADER_LEN can still be
dispatched, and the wait path copies a matching command into a fixed
caller-owned struct kvaser_cmd using the device-provided length.
Reject nonzero commands that do not contain the fixed header or that
extend beyond the current USB buffer item. In the wait path, also reject
a matching command that exceeds the destination before copying it.
Fixes: 080f40a6fa28 ("can: kvaser_usb: Add support for Kvaser CAN/USB devices") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260722042221.44066-1-pengpeng@iscas.ac.cn Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: kvaser_usb: kvaser_usb_hydra_get_busparams(): fix memory leak in kvaser_usb_hydra_get_busparams()
The memory allocated for cmd is not freed after the call to
kvaser_usb_send_cmd() in both the normal and error paths.
Fix that by adding a kfree() immediately after the call.
Fixes: 39d3df6b0ea8 ("can: kvaser_usb: Compare requested bittiming parameters with actual parameters in do_set_{,data}_bittiming") Cc: stable@vger.kernel.org Signed-off-by: Abdun Nihaal <nihaal@cse.iitm.ac.in> Link: https://patch.msgid.link/20260722103906.108571-1-nihaal@cse.iitm.ac.in Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
can: peak_usb: validate uCAN receive record lengths
pcan_usb_fd_decode_buf() walks uCAN records packed in one USB
receive buffer.
Require each record to contain the fixed header for its type, and verify
CAN payload bytes before copying them into the skb.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://patch.msgid.link/20260706092836.79754-1-pengpeng@iscas.ac.cn Fixes: 0a25e1f4f185 ("can: peak_usb: add support for PEAK new CANFD USB adapters") Cc: stable@vger.kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Maoyi Xie [Tue, 16 Jun 2026 18:15:31 +0000 (02:15 +0800)]
can: peak_usb: peak_usb_start(): fix double free of transfer buffer on URB submit error
In peak_usb_start(), each RX URB transfer buffer is allocated with kmalloc()
and the URB is flagged URB_FREE_BUFFER so that the final usb_free_urb() also
frees the transfer buffer.
If usb_submit_urb() fails, the error path frees the buffer explicitly with
kfree(buf) and then calls usb_free_urb(urb). Because URB_FREE_BUFFER is set,
usb_free_urb() -> urb_destroy() frees the same buffer a second time, a double
free of the transfer buffer.
BUG: KASAN: double-free in usb_free_urb.part.0+0x91/0xb0
Free of addr ffff8881069ccb80 by task trigger.sh/285
Drop the redundant kfree(buf); usb_free_urb() already releases the transfer
buffer. This mirrors commit 03819abbeb11 ("net: usb: lan78xx: Fix double free
issue with interrupt buffer allocation").
Fixes: bb4785551f64 ("can: usb: PEAK-System Technik USB adapters driver core") Closes: https://lore.kernel.org/linux-can/178159320216.2154888.16953451793788581739@maoyixie.com/T/#u Cc: stable@vger.kernel.org Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com> Reviewed-by: Vincent Mailhol <mailhol@kernel.org> Link: https://patch.msgid.link/178163373110.2507866.216458825145756798@maoyixie.com Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
James Gao [Wed, 20 May 2026 05:40:03 +0000 (13:40 +0800)]
can: peak_usb: add bounds check for USB channel index
The channel control index ctrl_idx is derived from rx->len which comes
directly from a device USB payload. The mask 0x0f allows values 0-15, but
the array size of usb_if->dev[] is only 2. Values 2-15 cause heap
out-of-bounds read, eventually causing kernel panic in the IRQ context.
Add bounds checking for ctrl_idx before the array access in both
pcan_usb_pro_handle_canmsg() and pcan_usb_pro_handle_error().
The driver has a match table for the pci bus wired into its driver
structure, but the table is not exported with MODULE_DEVICE_TABLE().
Add the missing MODULE_DEVICE_TABLE() entry so module alias information
is generated for automatic module loading.
This is a source-level fix. It does not claim dynamic hardware
reproduction; the evidence is the driver-owned match table, its use by
the driver registration structure, and the missing module alias
publication.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Acked-by: Pavel Pisa <pisa@fel.cvut.cz> Link: https://patch.msgid.link/20260704151957.48194-1-pengpeng@iscas.ac.cn Fixes: 792a5b678e81 ("can: ctucanfd: CTU CAN FD open-source IP core - PCI bus support.") Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Avi Weiss [Wed, 22 Jul 2026 19:27:26 +0000 (22:27 +0300)]
can: ctucanfd: use self-test mode for PRESUME_ACK
Use self-test mode for CAN_CTRLMODE_PRESUME_ACK so transmitted
frames can complete without receiving an ACK.
ACK forbidden mode prevents the controller from acknowledging
received frames and does not implement the presume-ack behavior.
Fixes: 2dcb8e8782d8 ("can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.") Signed-off-by: Avi Weiss <thnkslprpt@gmail.com> Acked-by: Pavel Pisa <pisa@fel.cvut.cz> Link: https://patch.msgid.link/20260722192726.230729-1-thnkslprpt@gmail.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Avi Weiss [Thu, 23 Jul 2026 07:44:03 +0000 (10:44 +0300)]
can: ctucanfd: handle bus error interrupts
Include REG_INT_STAT_BEI in the top-level error interrupt condition.
BEI is enabled when CAN_CTRLMODE_BERR_REPORTING is requested and
ctucan_err_interrupt() already handles it. Without checking and
clearing BEI in the top-level handler, bus error interrupts are not
handled or acknowledged.
Fixes: 2dcb8e8782d8 ("can: ctucanfd: add support for CTU CAN FD open-source IP core - bus independent part.") Signed-off-by: Avi Weiss <thnkslprpt@gmail.com> Acked-by: Pavel Pisa <pisa@fel.cvut.cz> Link: https://patch.msgid.link/20260723074403.131575-1-thnkslprpt@gmail.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Avi Weiss [Thu, 23 Jul 2026 09:59:34 +0000 (12:59 +0300)]
can: ctucanfd: unmap BAR0 using base address
BAR0 is mapped into bar0_base, while cra_addr points to an offset
within that mapping and is used for other purposes.
Pass bar0_base to pci_iounmap(), instead of cra_addr, on the probe error
path so the address returned by pci_iomap() is used for unmapping.
Fixes: 792a5b678e81 ("can: ctucanfd: CTU CAN FD open-source IP core - PCI bus support.") Signed-off-by: Avi Weiss <thnkslprpt@gmail.com> Acked-by: Pavel Pisa <pisa@fel.cvut.cz> Link: https://patch.msgid.link/20260723095934.181042-1-thnkslprpt@gmail.com Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Minhong He [Wed, 29 Jul 2026 08:56:56 +0000 (16:56 +0800)]
can: isotp: check register_netdevice_notifier() error in module init
Register the netdevice notifier before can_proto_register() and check the
return value. If protocol registration fails, unregister the notifier
before returning the error.
Align isotp_module_init() with the reordering already done for raw.c
(commit c28b3bffe49e ("can: raw: process optimization in raw_init()")) and
bcm.c (commit edd1a7e42f1d ("can: bcm: registration process optimization
in bcm_module_init()")).
net: sxgbe: check descriptor ring allocation failures
sxgbe_open() ignores the return value of init_dma_desc_rings() and
continues to program DMA with invalid ring addresses when allocation
fails. Check the return value and disconnect the PHY on failure.
Fixes: 1edb9ca69e8a ("net: sxgbe: add basic framework for Samsung 10Gb ethernet driver") Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: David S. Miller <davem@davemloft.net>
net: sxgbe: free TX rings on RX allocation failure
When RX descriptor ring allocation fails, init_dma_desc_rings() only
frees the partially allocated RX rings and returns. The TX rings that
were allocated earlier in the same function are leaked.
Rearrange error labels to clean up TX rings upon RX failures.
Fixes: 1edb9ca69e8a ("net: sxgbe: add basic framework for Samsung 10Gb ethernet driver") Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Signed-off-by: David S. Miller <davem@davemloft.net>
This patch is a follow-up to commit cf070fe33bfb ("can: isotp: serialize
TX state transitions under so->rx_lock") which addresses following
sashiko-bot findings:
- isotp_sendmsg(): drain so->txfrtimer first so a stale callback can't
re-arm echotimer after the claim
- isotp_release(): wake so->wait after forcing ISOTP_SHUTDOWN so a
sleeping sendmsg() claim isn't stranded
- isotp_sendmsg(): have both wait_event_interruptible() calls in
isotp_sendmsg() also wake on ISOTP_SHUTDOWN and do not return claim to
IDLE to avoid corrupting a concurrent isotp_release() process.
- isotp_sendmsg(): handle potential claim of a new transfer when
the wait_event_interruptible() call returns in CAN_ISOTP_WAIT_TX_DONE
mode. Don't touch timers and states of the new transfer if a new thread
incremented so->tx_gen before getting the lock at err_event_drop.
- isotp_sendmsg(): handle a stuck can_send() and omit timer and state
changes if a new transfer was claimed. wait_tx_done() returns the error
recorded in so->tx_result[], tagged with the caller's own generation.
- isotp_tx_timeout(): on a claimed timeout, record the ECOMM error for
the timed-out transfer's own generation in so->tx_result[]; sk->sk_err
is raised unconditionally, same as every other error path here.
- isotp_tx_gen_done()/isotp_tx_timeout(): always read tx.state (acquire)
before tx_gen - the reverse order let a weakly ordered CPU pair a fresh
tx.state with a stale tx_gen/tx_result slot.
- isotp_sendmsg(): wait_tx_done: drain sk_err via sock_error() once we
have read the result from so->tx_result[], so an already-reported error
doesn't stay latched for a later poll()/SO_ERROR.
Also align the remaining lock-free so->tx.state/rx.state/cfecho accesses
and use skb->hash as unique loopback echo frame indicator.
Fixes: cf070fe33bfb ("can: isotp: serialize TX state transitions under so->rx_lock") Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net> Link: https://patch.msgid.link/20260724181525.43556-1-socketcan@hartkopp.net Cc: stable@kernel.org Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Merge patch series "can: j1939: resend lost patches for buffer init and netdevice tracking"
Oleksij Rempel <o.rempel@pengutronix.de> says:
This series collects and resends two j1939 patches that were previously
lost on their way upstream. They address different, unconnected issues in
the stack:
- Patch 1 prevents residual data leaks by zeroing the allocated receive
buffer in j1939_session_fresh_new().
- Patch 2 implements netdevice_tracker for j1939_{priv,session,ecu}
management to help investigate a dev_hold()/dev_put() refcount
leak (unregister_netdevice() waiting for vcan0) reported by syzbot.
Zero the allocated buffer in j1939_session_fresh_new() to ensure it
contains no residual data.
While there is a potential performance impact if users allocate maximum
sized ETP buffers, most real-world use cases are not noticeably affected
since the maximum known buffer size is typically around 65K.
Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") Reported-by: Ji'an Zhou <eilaimemedsnaimel@gmail.com>
Message-ID: <CAPAUci5dykCLjoijqkUtFqJFesgncrD7+S6y_V=gjbFkY2Tifg@mail.gmail.com> Signed-off-by: Oleksij Rempel <o.rempel@pengutronix.de> Link: https://patch.msgid.link/20260728055835.1151785-3-o.rempel@pengutronix.de Cc: stable@kernel.org
[mkl: add Message-ID] Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
This refcount leak in j1939_priv might be caused by a refcount leak in
j1939_{session,ecu} because j1939_{session,ecu} holds a ref on j1939_priv.
For further investigation using upstream kernels, enable netdevice_tracker
in j1939_{priv,session,ecu} management.
André Pragosa [Tue, 28 Jul 2026 22:11:25 +0000 (23:11 +0100)]
ALSA: hda/realtek: Add mute LED quirk for HP Victus 16-e0xxx (MB 88ED)
Add subsystem ID 103c:88ed to the existing HP Victus 16-e0xxx
mute LED quirk list.
The HP Victus 16-e0xxx with subsystem ID 103c:88ed uses the same
mute LED coefficient configuration as the already supported
103c:88eb variant.
The mute LED was verified by manually toggling coefficient index
0x0b (bit 3) using hda-verb. After adding the quirk, the LED is
registered as hda::mute and follows the audio mute state.
ALSA: usb-audio: Add GET_SAMPLE_RATE quirk for C-Media CM6206
The C-Media CM6206 (0d8c:0102) truncates the three-byte sample rate it
returns for UAC_GET_CUR to its two low bytes. After the rate has been
set to 96000 (0x017700) the device reports back 30464 (0x007700).
At probe time the driver initializes every altsetting to its maximum
rate, so altsetting 5 is set to 96000 and the warning appears on each
plug-in, before anything has opened the device:
usb 3-1.3: 1:5 Set sample rate 96000, clock 0
usb 3-1.3: current rate 30464 is different from the runtime rate 96000
That altsetting is the one parse_audio_format_rates_v1() already fixes
up for this chip, so this affects every CM6206.
Only the read-back is broken, the rate itself is applied: a 1 kHz sine
rendered at 96 kHz is recovered at 1000.2 Hz, and a silent fallback to
48000 would have been reported as 0x00bb80 rather than as the low half
of the requested rate.
Add a QUIRK_FLAG_GET_SAMPLE_RATE entry for the device so the read-back
is skipped. Setting the same flag through the quirk_flags module
parameter makes the warning disappear while the 96000 init still
happens.
ALSA: usb-audio: Clamp frame size in implicit-feedback mode
snd_usb_handle_sync_urb() scales received sync packet sizes by the sender's
stride and stores the result directly in out_packet->packet_size[i]. If a
connected USB device sends an oversized sync packet, this frame count can
exceed ep->maxframesize.
The un-clamped frame count then propagates to the playback endpoint queue,
potentially driving packet transfers beyond the endpoint's hardware frame
limits.
Cap the calculated frame count against ep->maxframesize in
snd_usb_handle_sync_urb() to prevent oversized packets from entering the
playback queue.
ALSA: usb-audio: Fix DMA buffer out-of-bounds write when fill_max is set
When a USB audio endpoint requests full packet transfers via the fill_max
descriptor flag, data_ep_set_params() promotes ep->curpacksize to
ep->maxpacksize. However, maxsize is left at the original sample-rate
derived value.
Since u->buffer_size is allocated as maxsize * packets, the resulting
DMA buffer is far too small for the requested transfer length. When the
USB host controller streams up to curpacksize bytes per packet, it writes
past the end of the buffer via DMA, corrupting kernel heap memory.
Update maxsize to curpacksize when fill_max is set so that the allocated
DMA buffer size matches the actual transfer request size.
[ changed to reassign maxsize only when ep->fill_max is set -- tiwai ]
Ao Sun [Thu, 23 Jul 2026 03:45:30 +0000 (03:45 +0000)]
scsi: ufs: core: Initialize hba->rpmbs list in ufshcd
Initialize the hba->rpmbs list in ufshcd_alloc_host() to prevent NULL
pointer dereference in the device teardown path if ufs_rpmb_probe()
fails.
Fixes: b06b8c421485 ("scsi: ufs: core: Add OP-TEE based RPMB driver for UFS devices") Co-developed-by: Jiazi Li <jiazi.li@transsion.com> Signed-off-by: Jiazi Li <jiazi.li@transsion.com> Signed-off-by: Ao Sun <ao.sun@transsion.com> Reviewed-by: Bean Huo <beanhuo@micron.com> Link: https://patch.msgid.link/20260723034440.217-1-ao.sun@transsion.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
scsi: mpi3mr: Fix potential deadlock in mpi3mr_fault_uevent_emit
mpi3mr_fault_uevent_emit() runs from the fault watchdog and reset paths
where host I/O may already be blocked. GFP_KERNEL allocations here, both
the local kzalloc_obj() and the ones inside kobject_uevent_env() itself,
can trigger reclaim that waits on that blocked I/O and deadlock.
Use memalloc_noio_save()/restore() to cover the whole call instead of
just the local allocation.
Fixes: ec54b348f274 ("scsi: mpi3mr: Record and report controller firmware faults") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Closes: https://sashiko.dev/#/patchset/20260724164630.924288-1-chandrakanth.patil%40broadcom.com Signed-off-by: Chandrakanth Patil <chandrakanth.patil@broadcom.com> Link: https://patch.msgid.link/20260724175231.935192-1-chandrakanth.patil@broadcom.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
octeontx2-af: Block VFs from clobbering special CGX PKIND state
PF and VF NIX LFs that share a CGX LMAC reuse the same hardware PKIND
programming. When HiGig2 or EDSA parsing is enabled, a VF NIX LF alloc must
not reset the LMAC RX PKIND or default TX parse config over the PF setup.
Add cgx_get_pkind() and rvu_cgx_is_pkind_config_permitted() so VFs skip
cgx_set_pkind(), rvu_npc_set_pkind(), and NIX_AF_LFX_TX_PARSE_CFG updates
when the LMAC is using NPC_RX_HIGIG_PKIND or NPC_RX_EDSA_PKIND.
Leon Romanovsky [Wed, 22 Jul 2026 06:30:10 +0000 (09:30 +0300)]
scsi: target: Clear cmd_cnt when initial counter enrollment fails
When target_get_sess_cmd() fails during session shutdown because
percpu_ref_tryget_live() returns false, the command keeps the
se_cmd->cmd_cnt pointer that __target_init_cmd() assigned earlier
without owning a reference. Final release through
target_release_cmd_kref() then issues an unmatched percpu_ref_put().
Commit 8e288be8606a ("scsi: target: Pass in cmd counter to use during
cmd setup") moved the cmd_cnt assignment ahead of the reference
acquisition. Clear se_cmd->cmd_cnt whenever the initial
target_get_sess_cmd() fails in target_init_cmd() and
target_submit_tmr(), so release performs exactly one matching put per
acquired reference.
scsi: ufs: core: Revert "Delegate the interrupt service routine to a threaded IRQ handler"
There have been multiple reports of performance regressions caused by
commit 3c7ac40d7322 ("scsi: ufs: core: Delegate the interrupt service
routine to a threaded IRQ handler"). Hence this revert.
This patch reverts most of the following commits:
* 3c7ac40d7322 ("scsi: ufs: core: Delegate the interrupt service
routine to a threaded IRQ handler")
* 6475cfb81fc4 ("scsi: ufs: core: Avoid IRQ thread wakeup during active
UIC command")
* eabcac808ca3 ("scsi: ufs: core: Fix IRQ lock inversion for the SCSI
host lock")
Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: 孙魁 (Kui Sun) <kui.sun@unisoc.com> Cc: André Draszik <andre.draszik@linaro.org> Cc: Gregory CLEMENT <gregory.clement@bootlin.com> Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Fixes: 3c7ac40d7322 ("scsi: ufs: core: Delegate the interrupt service routine to a threaded IRQ handler") Signed-off-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Tested-by: André Draszik <andre.draszik@linaro.org> # on Pixel 6 Reviewed-by: André Draszik <andre.draszik@linaro.org> Link: https://patch.msgid.link/b70eb60a01f971bed68c42c5b555929db5f835df.1784135511.git.bvanassche@acm.org Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Guangshuo Li [Tue, 14 Jul 2026 17:27:26 +0000 (01:27 +0800)]
scsi: ufs: core: Cancel RTC work in active-active suspend
UFS RTC support schedules ufs_rtc_update_work to periodically update the
device RTC. The work can issue query commands and access the UFS host
controller.
A previous change moved the RTC work cancellation before the PRE_CHANGE
vendor suspend callback to close a race in the common suspend path.
However, the active-active path jumps directly to vops_suspend after
flushing exception handling work and therefore bypasses the
cancellation.
If the RTC work runs while the vendor suspend callback is gating or
otherwise changing hardware state, it can access the controller during
suspend and trigger an SError.
Cancel the RTC work before entering the vendor suspend callback in the
active-active path. Since this path now cancels the work, move the RTC
work scheduling outside the device and link state restoration block in
the resume path. This restarts RTC updates after an active-active
suspend and resume cycle.
Fixes: b0bd84c39289 ("scsi: ufs: core: Fix SError in ufshcd_rtc_work() during UFS suspend") Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Reviewed-by: Peter Wang <peter.wang@mediatek.com> Reviewed-by: Bean Huo <beanhuo@micron.com> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20260714172726.1736967-1-lgs201920130244@gmail.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Ibrahim Hashimov [Sun, 12 Jul 2026 18:37:39 +0000 (20:37 +0200)]
scsi: scsi_debug: Fix REPORT ZONES alloc_len underflow OOB write
resp_report_zones() sizes the reply buffer from the CDB allocation
length. The v3 fix rounds alloc_len up with ALIGN() before deriving the
descriptor count:
For alloc_len in 0xFFFFFFC1..0xFFFFFFFF, ALIGN() rounds up to
0x100000000, so arr_len is 4 GB. On 32-bit, kzalloc()'s size_t is 32-bit
and truncates 0x100000000 to 0; kzalloc(0) returns ZERO_SIZE_PTR, which
passes the !arr check, and desc = arr + 64 is then dereferenced in the
loop -> out-of-bounds write / panic.
Clamp rep_max_zones to devip->nr_zones. The loop already stops at
sdebug_capacity (after nr_zones zones), so a report can never hold more
than nr_zones descriptors; the clamp does not change the report, it only
bounds arr_len to (nr_zones + 1) * RZONES_DESC_HD, a real device
property that can never reach 0x100000000.
Fixes: 7db0e0c8190a ("scsi: scsi_debug: Fix buffer size of REPORT ZONES command") Suggested-by: Damien Le Moal <dlemoal@kernel.org> Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov <security@auditcode.ai> Assisted-by: AuditCode-AI:2026.07 Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20260712183739.83915-1-security@auditcode.ai Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
In the iblock_execute_pr_out() function, PRO_PREEMPT,
PRO_PREEMPT_AND_ABORT, and PRO_RELEASE all perform callback capability
checks through ops->pr_clear. The error check allows unimplemented hooks
to pass through the gate, resulting dereferencing a NULL function
pointer.
Check whether the hooks that need to be called are supported.
Fixes: 394f81184882 ("scsi: target: Add block PR support to iblock") Signed-off-by: TanZheng <tanzheng@kylinos.cn> Reviewed-by: Mike Christie <michael.christie@oracle.com> Link: https://patch.msgid.link/20260724075850.280699-1-kensanya@163.com Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Damien Le Moal [Thu, 9 Jul 2026 07:02:23 +0000 (16:02 +0900)]
scsi: libsas: terminate deferred commands on time out
If a command times out while we have deferred non-NCQ commands waiting to
be issued, the SCSI EH task is not immediately woken up as the waiting
deferred commands are never issued nor completed, thus leaving the SCSI
host in a busy state (shost->host_failed != scsi_host_busy(shost)) which
prevents the SCSI EH task from being woken up. Eventually, when the
deferred commands also time out, the SCSI EH task is woken up and the
timeout processing occurs.
Avoid this unnecessary additional SCSI EH wake up time with the same
method as implemented in libata-scsi, using the eh_timed_out SCSI host
template operation. The function sas_eh_timed_out() implements this
operation and executes the function ata_scsi_retry_deferred_qc()
for SATA devices.
Co-developed-by: Igor Pylypiv <ipylypiv@google.com> Signed-off-by: Igor Pylypiv <ipylypiv@google.com> Fixes: 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: John Garry <john.g.garry@oracle.com> Reviewed-by: Hannes Reinecke <hare@kernel.org> Tested-by: Igor Pylypiv <ipylypiv@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
Damien Le Moal [Wed, 22 Jul 2026 22:42:26 +0000 (07:42 +0900)]
ata: libata-scsi: schedule deferred atapi command
Modify atapi_qc_complete() to call ata_scsi_schedule_deferred_qc() to
ensure that any deferred queued command can execute. This is similar to
ata_scsi_qc_complete() function for regular ATA devices.
Fixes: 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal <dlemoal@kernel.org>
Damien Le Moal [Thu, 9 Jul 2026 01:01:33 +0000 (10:01 +0900)]
ata: libata-scsi: terminate deferred commands on time out
If a command times out while we have deferred non-NCQ commands waiting to
be issued, the SCSI EH task is not immediately woken up as the waiting
deferred commands are never issued nor completed, thus leaving the SCSI
host in a busy state (shost->host_failed != scsi_host_busy(shost)) which
prevents the SCSI EH task from being woken up. Eventually, when the
deferred commands also time out, the SCSI EH task is woken up and the
timeout processing occurs.
Avoid this unnecessary SCSI EH task wake-up additional time by scheduling
a retry of all waiting deferred QCs, using the eh_timed_out SCSI host
template operation. The function ata_scsi_eh_timed_out() is introduced to
implement this operation.
However, terminating deferred commands with DID_REQUEUE to force a retry
by calling the function ata_scsi_requeue_deferred_qc() may still keep the
SCSI host in a busy state because the block layer may immediately re-issue
these commands. The solution to this is to schedule libata EH for the
port which suffered the command timeout to prevent accepting any new
command. ata_scsi_requeue_deferred_qc() is modified to add a call to
ata_port_schedule_eh() for this purpose.
In addition to this change, ata_scsi_requeue_deferred_qc() is also
modified to take a new timedout_scmd scsi command argument which indicates
the SCSI command that timed out. With this additional argument,
ata_scsi_requeue_deferred_qc() can now also terminate with DID_TIME_OUT
any timed out deferred qc, which simplifies ata_scsi_cmd_error_handler().
In this case, ata_scsi_requeue_deferred_qc() returns SCSI_EH_DONE, with
this return value propagated back to the ata_scsi_eh_timed_out() operation
to indicate to scsi_timeout() that the timed out command was handled and
no further processing is needed.
For non-timed out deferred qc that need to be retried,
ata_scsi_requeue_deferred_qc() returns SCSI_EH_NOT_HANDLED, thus
indicating to scsi_timeout() that the timed out command needs to go
through the SCSI EH (and libata EH) processing by adding it to the EH work
queue with scsi_eh_scmd_add().
One side effect of these changes is that the function atapi_qc_complete()
needs to be modified to ensure that a deferred ATAPI command that needs
to be retried is completed with DID_REQUEUE instead of the default
SAM_STAT_GOOD status, and a command that timed out is completed with
DID_TIME_OUT instead of SAM_STAT_CHECK_CONDITION.
Fixes: 0ea84089dbf6 ("ata: libata-scsi: avoid Non-NCQ command starvation") Cc: stable@vger.kernel.org Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Igor Pylypiv <ipylypiv@google.com> Tested-by: Igor Pylypiv <ipylypiv@google.com> Reviewed-by: Niklas Cassel <cassel@kernel.org> Reviewed-by: Martin K. Petersen <martin.petersen@oracle.com>
net: phylink: put link_gpio if phylink_create fails
In phylink_create() if phylink_register_sfp() returns an error, link_gpio
obtained by phylink_parse_fixedlink() is never released. While this is a
very unlikely scenario, it's worth to fix/handle this.
This was present from the very first implementation of phylink but got
relevant only with the introduction of ce0aa27ff3f6 ("sfp: add sfp-bus to
bridge between network devices and sfp cages") where additional function
were added after phylink_parse_fixedlink() making the release of link_gpio
needed if such additional function errored out.
While at it, restructure the exit condition of phylink_create() with the
goto pattern to reduce code duplication on handling error conditions.
Fixes: ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages") Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Link: https://patch.msgid.link/20260726150806.2437-1-ansuelsmth@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Chris Gellermann [Wed, 22 Jul 2026 13:02:46 +0000 (15:02 +0200)]
selftests/mm: fix potential wild pointer access of getline due to missing init
This is another occurrence of using getline where the code assumes that
getline allocates memory to store the line, but the pointer passed to it
is uninitialized and potentially a non-null pointer. This violates the
Open Group Spec[1] and caused a segfault in a similar situation in
selftest/clone3/clone3_set_tid. Fix it by initializing the line pointer
to NULL.
The issue has been found by simply grepping through the selftest code
after running into the issue in clone3_set_tid. Whether it segfaults in
its current state is unknown to me. But it's good to be addressed due to
defensive reasons.
Link: https://lore.kernel.org/20260722130246.2135563-3-christian.gellermann@codasip.com Link: https://pubs.opengroup.org/onlinepubs/9799919799/functions/getline.html Fixes: 26b4224d9961 ("selftests: expanding more mlock selftest") Signed-off-by: Chris Gellermann <christian.gellermann@codasip.com> Acked-by: David Hildenbrand (arm) <david@kernel.org> Reviewed-by: Lorenzo Stoakes <ljs@kernel.org> Cc: Christian Brauner <brauner@kernel.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Shuah Khan <shuah@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Chris Gellermann [Wed, 22 Jul 2026 13:02:45 +0000 (15:02 +0200)]
selftests/clone3: fix wild pointer access of getline due to missing init
Patch series "selftests: Add missing initalization of pointer passed to
getline", v2.
This patch (of 2):
Clone3_set_tid uses getline(&line, ...) in a loop to read the child's
process status. The code expects that getline allocates the buffer for
the line on the first loop iteration. According to the Open Group
Spec[1], char *line has to be null pointer for this:
> ssize_t getline(char **restrict lineptr, ...);
> If *lineptr is a null pointer or if the object pointed to by *lineptr
> is of insufficient size, an object shall be allocated as if by
malloc()
> or the object shall be reallocated as if by realloc()[...].
However, char *line is only declared, leading to an undefined value that
is potentially non-null. In an example run with Musl v1.2.6, the realloc
call[2] of getdelim, which implements getline, triggers a segfault:
./run_kselftest.sh --test clone3:clone3_set_tid
[ 1366.165898] kselftest: Running tests in clone3
...
[ 1367.799244] clone3_set_tid[811]: unhandled signal 11 code 0x1 at
0x0000000000000000 in libc.so[68184,3fbf69f000+4c000]
[ 1367.802808] CPU: 0 UID: 0 PID: 811 Comm: clone3_set_tid Not tainted
..
[ 1367.804188] epc: 0x0000003fbf6b0184
[ 1367.804188] ra : 0x0000003fbf6d4664
[ 1367.804188] sp : 0x0000003fce5f2e40
[ 1367.805314] gp : 0x0000002aaab0dfb8
[ 1367.805314] tp : 0x0000003fbf6f14a8
[ 1367.805314] t0 : 0x0000003fbf63d000
...
Looking at the realloc implementation, Musl mallocs for a null pointer
memory. But for a non-null pointer, it assumes it's passed a valid
pointer to the heap and tries to access its meta-data. This leads to the
segfault we see:
void *realloc(void *p, size_t n)
{
if (!p) return malloc(n);
if (size_overflows(n)) return 0;
struct meta *g = get_meta(p);
...
}
Fix this by properly initializing the line pointer to NULL.
Link Lin [Tue, 21 Jul 2026 00:55:33 +0000 (00:55 +0000)]
mm/page_reporting: use system_freezable_wq to fix UAF during suspend
During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like
virtio_balloon reset their underlying virtio devices and delete their
virtqueues via vdev->config->del_vqs().
However, page reporting work (page_reporting_process) was scheduled on the
global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM
freezer skips it, leaving page_reporting_process active during suspend.
If pages are freed into the buddy allocator while suspending (for example,
when core MM invokes the balloon shrinker during S4 hibernation image
saving), page reporting triggers virtballoon_free_page_report() on deleted
virtqueues, resulting in a Use-After-Free / General Protection Fault:
Fix this by switching page reporting work to system_freezable_wq. This
ensures that the PM freezer pauses page_reporting_process before device
drivers destroy their reporting virtqueues. Because the reporting worker
is frozen, memory reclamation/freeing (e.g. via shrinker execution) can
safely return pages to MM during freeze without triggering unfrozen
reporting work on deleted virtqueues.
This aligns with the driver's existing design. The comment in
virtballoon_freeze() states:
/*
* The workqueue is already frozen by the PM core before this
* function is called.
*/
Testing:
I have verified these fixes using Google’s virtualization infrastructure
by running continuous suspend/resume iterations (40+ cycles) while
churning memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60%
--timeout 1`) to constantly create free pages for the buddy allocator. We
also set the `page_reporting_order` parameter to 0 to make the page
reporting worker highly sensitive, forcing it to pick up any 4K free
pages. This confirmed that the UAF crashes are no longer reproducible.
Link: https://lore.kernel.org/20260721005603.1710551-1-linkl@google.com Fixes: 36e66c554b5c ("mm: introduce Reported pages") Signed-off-by: Link Lin <linkl@google.com> Suggested-by: David Hildenbrand (Arm) <david@kernel.org> Suggested-by: Michael S. Tsirkin <mst@redhat.com> Acked-by: David Rientjes <rientjes@google.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Acked-by: Michael S. Tsirkin <mst@redhat.com> Cc: Alexander Duyck <alexander.duyck@gmail.com> Cc: Greg Thelen <gthelen@google.com> Cc: James Houghton <jthoughton@google.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Jiaqi Yan <jiaqiyan@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Richard Chang [Mon, 20 Jul 2026 04:41:03 +0000 (04:41 +0000)]
mm: vmscan: abort proactive reclaim early when freezing for suspend
Proactive reclaim (triggered via memory.reclaim or node sysfs) checks for
pending signals in its outer loop in user_proactive_reclaim(). However,
the inner reclaim loops—specifically scanning cgroups in shrink_many()
and evicting/aging folios in try_to_shrink_lruvec()—can run for a long
time before returning to the outer loop, especially on systems with many
cgroups or large memory sizes.
During system suspend, the PM freezer attempts to freeze all tasks by
sending fake signals (setting TIF_SIGPENDING). Because the inner loops do
not check for pending signals, the proactive reclaim task can remain stuck
in kernel space for seconds, failing to enter the refrigerator in a timely
manner. This leads to suspend failures due to freeze timeouts, a behavior
observed on Android devices.
This latency issue is specific to proactive reclaim because of its large,
user-defined reclaim targets (could be gigabytes). Since commit 287d5fedb377 ("mm: memcg: use larger batches for proactive reclaim"),
proactive reclaim uses larger decaying batch sizes (starting at 1/4 of the
remaining target) to maintain throughput. This keeps the task in the
inner reclaim loop for extended periods. In contrast, reactive reclaim
(global/memcg) uses small targets (SWAP_CLUSTER_MAX, typically 32 pages),
allowing it to return to the outer loop and check signals frequently.
To fix this, add a signal_pending() check to should_abort_scan() for
proactive reclaim paths. Since should_abort_scan() is called within the
inner scanning and eviction loops, this allows proactive reclaim to abort
early and return to the outer loop in user_proactive_reclaim().
Additionally, return -ERESTARTSYS instead of -EINTR in
user_proactive_reclaim(). When interrupted by system suspend, returning
-ERESTARTSYS allows the task to enter the refrigerator and automatically
restart the syscall upon resume, making the freezer transparent to
userspace. For real signals, the signal layer will either restart the
syscall (if SA_RESTART is set) or return -EINTR to userspace.
This fix specifically targets Multi-Gen LRU (MGLRU). Classic LRU's scan
targets per iteration are strictly bounded by get_scan_count(), which
ensures it returns to the outer loop more frequently.
The check in should_abort_scan() is limited to proactive reclaim
(sc->proactive) to avoid inadvertently affecting reactive reclaim paths,
and is wrapped in unlikely() as it is a slow path.
Link: https://lore.kernel.org/20260720044103.905191-1-richardycc@google.com Fixes: 287d5fedb377 ("mm: memcg: use larger batches for proactive reclaim") Fixes: 94968384dde1 ("memcg: introduce per-memcg reclaim interface") Suggested-by: Michal Hocko <mhocko@suse.com> Suggested-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Richard Chang <richardycc@google.com> Acked-by: Michal Hocko <mhocko@suse.com> Cc: Axel Rasmussen <axelrasmussen@google.com> Cc: Barry Song <baohua@kernel.org> Cc: David Hildenbrand <david@kernel.org> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Kairui Song <kasong@tencent.com> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Martin Liu <liumartin@google.com> Cc: Minchan Kim <minchan@kernel.org> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: Suren Baghdasaryan <surenb@google.com> Cc: T.J. Mercier <tjmercier@google.com> Cc: Wei Xu <weixugc@google.com> Cc: Yuanchu Xie <yuanchu@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
arm64, mailmap: update email address for Peter Collingbourne
I am no longer at Google.
Link: https://lore.kernel.org/20260718172923.8297-1-peter@pcc.me.uk Signed-off-by: Peter Collingbourne <peter@pcc.me.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Ian Rogers <irogers@google.com> Cc: Jakub Kacinski <kuba@kernel.org> Cc: Martin Kepplinger <martink@posteo.de> Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Will Deacon <will@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios
__folio_split() keeps dereferencing the mapping after the split:
shmem_uncharge(mapping->host) and remap_page() while the folios are still
frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the
after-split folios have been unlocked and freed.
Nothing holds an inode reference across that. The split relies on @folio
-- which the beyond-EOF drop loop never removes, as it starts at
folio_next(folio) -- staying locked and in the page cache to hold off
eviction. But the unlock loop unlocks @folio before i_mmap_unlock_read()
runs. If the caller's @lock_at is a tail beyond EOF, as memory_failure()
passes when splitting a poisoned tail of a shmem THP that reaches past
i_size during truncation, it too is gone from the page cache; so once
@folio is unlocked no locked, in-cache folio pins the inode, and a
concurrent final iput() can evict and RCU-free it before
i_mmap_unlock_read() touches i_mmap_rwsem:
Freed by task 4601:
shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177
evict+0x57f/0xac0 fs/inode.c:870
Do every mapping dereference while @folio still pins the inode: drop
i_mmap_rwsem right after remap_page(), before the loop that unlocks and
frees the after-split folios, and clear @mapping so the exit path does not
unlock it again. shmem_uncharge() and remap_page() already run before
that point, so after this nothing past the unlock loop touches the inode
or the mapping.
This is now a rule the split depends on, alongside keeping @folio frozen
until the page cache is updated: no inode or mapping dereference once the
after-split folios start being unlocked.
Link: https://lore.kernel.org/20260716095424.471052-1-kirill@shutemov.name Fixes: baa355fd3314 ("thp: file pages support for split_huge_page()") Signed-off-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Reported-by: Hao Zhang <zhanghao1@kylinos.cn> Closes: https://lore.kernel.org/linux-mm/20260710071344.GA106129@zh-pc Co-developed-by: Hao Zhang <zhanghao1@kylinos.cn> Signed-off-by: Hao Zhang <zhanghao1@kylinos.cn> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Reviewed-by: Miaohe Lin <linmiaohe@huawei.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Barry Song <baohua@kernel.org> Cc: Dev Jain <dev.jain@arm.com> Cc: Lance Yang <lance.yang@linux.dev> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Naoya Horiguchi <nao.horiguchi@gmail.com> Cc: Nico Pache <npache@redhat.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
riscv/mm: use physical alignment for vmemmap_start_pfn
RISC-V computes vmemmap_start_pfn by rounding phys_ram_base down to
VMEMMAP_ADDR_ALIGN. That alignment must therefore be expressed in the
physical-address domain.
Commit 476849b0fba4 ("riscv/mm: align vmemmap to maximal folio size")
attempted to account for the maximal folio alignment by feeding
MAX_FOLIO_VMEMMAP_ALIGN directly into VMEMMAP_ADDR_ALIGN. However,
MAX_FOLIO_VMEMMAP_ALIGN is measured in bytes of struct page storage,
whereas VMEMMAP_ADDR_ALIGN is used to align a physical address.
The mask-based compound_info encoding requires pfn_to_page(0) to be
naturally aligned to MAX_FOLIO_VMEMMAP_ALIGN. Commit 9f94db4c7eaa
("mm/sparse: check memmap alignment for compound_info_has_mask()") added a
check for that requirement and exposed the unit mismatch on systems such
as QEMU virt, where the DRAM base is not aligned to MAX_FOLIO_NR_PAGES *
PAGE_SIZE.
Convert MAX_FOLIO_VMEMMAP_ALIGN to the equivalent physical alignment
before using it in VMEMMAP_ADDR_ALIGN. This keeps the existing
round_down() logic while making the resulting vmemmap base satisfy the
mask-alignment requirement.
Link: https://lore.kernel.org/20260716115326.3466926-1-xujiakai2025@iscas.ac.cn Fixes: 476849b0fba4 ("riscv/mm: align vmemmap to maximal folio size") Signed-off-by: Jiakai Xu <xujiakai2025@iscas.ac.cn> Reviewed-by: Kiryl Shutsemau (Meta) <kas@kernel.org> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: David Hildenbrand <david@kernel.org> Cc: Guo Ren <guoren@kernel.org> Cc: Mike Rapoport <rppt@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Nam Cao <namcao@linutronix.de> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Vishal Moola (Oracle) <vishal.moola@gmail.com> Assisted-by: YuanSheng:DeepSeek-V4-Flash Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm/migrate: exclude hugetlb folios from MTHP_STAT_NR_ANON accounting
__folio_migrate_mapping() increments MTHP_STAT_NR_ANON for the destination
folio when `folio_test_anon(folio) && folio_test_large(folio)` is true.
However, hugetlb folios satisfy both conditions despite having a
completely separate accounting system — they use hugetlb_add_anon_rmap()
which does not touch mTHP stats, and their free path also bypasses the
mTHP decrement in __free_pages_prepare().
This causes MTHP_STAT_NR_ANON to be incremented on each hugetlb migration
without a corresponding decrement, permanently inflating the nr_anon
counter.
Add a !folio_test_hugetlb() check to __folio_migrate_mapping() so that
only actual mTHP folios are counted.
Link: https://lore.kernel.org/20260717064502.1980173-3-npache@redhat.com Fixes: 5d65c8d758f2 ("mm: count the number of anonymous THPs per size") Co-developed-by: David Hildenbrand <david@kernel.org> Signed-off-by: David Hildenbrand <david@kernel.org> Signed-off-by: Nico Pache <npache@redhat.com> Reviewed-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: Barry Song <baohua@kernel.org> Cc: Byungchul Park <byungchul@sk.com> Cc: Gregory Price <gourry@gourry.net> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: Rakie Kim <rakie.kim@sk.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm: decrement MTHP_STAT_NR_ANON in free_zone_device_folio()
Patch series "mm: fix PMD level mTHP accounting bugs", v2.
While running selftests I noticed the PMD level per-mTHP stats (nr_anon)
remained elevated after each run. After further investigation I noticed
this accounting error occurs for both the migration.private_anon_htlb_test
and the HMM tests.
In the HMM case this is due to folio_add_new_anon_rmap() incrementing the
mTHP stats, but never containing a corresponding decrement in
free_zone_device_folio(). We solve this by making sure to decrement the
counter when freeing device memory.
In the migration case, we are incrementing this counter without first
checking whether this folio is a hugetlb folio, which relies on a separate
accounting system. We solve this by adding the proper hugetlb check
before incrementing this counter.
With these changes in place, the two tests no longer cause elevated PMD
level accounting issues.
This patch (of 2):
When a zone device folio is mapped as anonymous, folio_add_new_anon_rmap()
increments MTHP_STAT_NR_ANON. The corresponding decrement lives in
__free_pages_prepare() in page_alloc.c, but zone device folios are freed
via free_zone_device_folio() which never calls __free_pages_prepare().
This causes nr_anon to remain permanently elevated after zone device
folios are freed.
Add the missing mod_mthp_stat() decrement to free_zone_device_folio() so
that the counter is properly balanced.
Link: https://lore.kernel.org/20260717064502.1980173-1-npache@redhat.com Link: https://lore.kernel.org/20260717064502.1980173-2-npache@redhat.com Fixes: 5d65c8d758f2 ("mm: count the number of anonymous THPs per size") Co-developed-by: David Hildenbrand <david@kernel.org> Signed-off-by: David Hildenbrand <david@kernel.org> Signed-off-by: Nico Pache <npache@redhat.com> Reviewed-by: Zi Yan <ziy@nvidia.com> Cc: Alistair Popple <apopple@nvidia.com> Cc: Barry Song <baohua@kernel.org> Cc: Byungchul Park <byungchul@sk.com> Cc: Gregory Price <gourry@gourry.net> Cc: "Huang, Ying" <ying.huang@linux.alibaba.com> Cc: Joshua Hahn <joshua.hahnjy@gmail.com> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Matthew Brost <matthew.brost@intel.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Cc: Oscar Salvador <osalvador@suse.de> Cc: Rakie Kim <rakie.kim@sk.com> Cc: Baolin Wang <baolin.wang@linux.alibaba.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm: memcg: initialize *locked in memcg1_oom_prepare() stub
mem_cgroup_oom() passes an uninitialized "locked" to memcg1_oom_prepare()
and reads it back in memcg1_oom_finish():
bool locked, ret;
...
if (!memcg1_oom_prepare(memcg, &locked))
return false;
ret = mem_cgroup_out_of_memory(memcg, mask, order);
memcg1_oom_finish(memcg, locked);
This relies on memcg1_oom_prepare() setting *locked whenever it returns
true. The CONFIG_MEMCG_V1=y version does, but the stub used when
CONFIG_MEMCG_V1=n returns true without touching *locked, so
memcg1_oom_finish() consumes an uninitialized value. On a memcg OOM this
is reported by UBSAN:
UBSAN: invalid-load in mm/memcontrol.c:1932:27
load of value 0 is not a valid value for type 'bool' (aka '_Bool')
Initialize *locked to false in the stub; with cgroup v1 compiled out there
is no OOM lock to take.
Link: https://lore.kernel.org/20260716-memcg-oom-uninit-locked-v2-1-63631d878eb4@debian.org Fixes: e93d4166b40a ("mm: memcg: put cgroup v1-specific code under a config option") Signed-off-by: Breno Leitao <leitao@debian.org> Reviewed-by: Joshua Hahn <joshua.hahnjy@gmail.com> Acked-by: Johannes Weiner <hannes@cmpxchg.org> Reviewed-by: SeongJae Park <sj@kernel.org> Acked-by: Shakeel Butt <shakeel.butt@linux.dev> Cc: Michal Hocko <mhocko@kernel.org> Cc: Muchun Song <muchun.song@linux.dev> Cc: Roman Gushchin <roman.gushchin@linux.dev> Cc: Shakeel Butt <shakeel.butt@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Jakub Kicinski [Wed, 29 Jul 2026 00:30:21 +0000 (17:30 -0700)]
Merge tag 'for-net-2026-07-28' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth
Luiz Augusto von Dentz says:
====================
bluetooth pull request for net:
- hci_sync: Fix advertising data UAFs
- hci_conn: hold conn reference fixes
- L2CAP: fix UAF in l2cap_le_connect_rsp
- RFCOMM: validate skb length in rfcomm_recv_frame
- ISO: Locking fixes
- SCO: give the socket its own sco_conn reference
- MGMT: fix UAF in pair command cancellation
- MGMT: fix pending command UAF in EIR updates
- HIDP: reject frames without a transaction header
- HIDP: validate numbered report payloads
- btmtk: Fix short read errors in btmtk_usb_uhw_reg_read()
- btmtk: Fix short read errors in btmtk_usb_reg_read()
- btusb: Fix short read errors in btusb_qca_send_vendor_req()
- btintel: Validate length before parsing diagnostics TLV
* tag 'for-net-2026-07-28' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: (31 commits)
Bluetooth: SCO: give the socket its own sco_conn reference
Bluetooth: btusb: Fix short read errors in btusb_qca_send_vendor_req()
Bluetooth: btmtk: Fix short read errors in btmtk_usb_reg_read()
Bluetooth: btmtk: Fix short read errors in btmtk_usb_uhw_reg_read()
Bluetooth: hci_sync: remove unnecessary hci_conn_get in create_conn_sync
Bluetooth: hci_sync: fix hci_conn_del() use in hci_le_create_conn_sync
Bluetooth: hci_sync: hold conn in hci_past_sync() callback
Bluetooth: hci_sync: hold conn in hci_connect_pa_sync() callback
Bluetooth: hci_sync: hold conn in hci_connect_big_sync() callback
Bluetooth: hci_sync: hold conn in hci_connect_acl/le_sync() callbacks
Bluetooth: hci_conn: hold conn reference in abort_conn_sync()
Bluetooth: btintel: Validate length before parsing diagnostics TLV
Bluetooth: ISO: fix race of kfree vs kref_get_unless_zero
Bluetooth: ISO: fix refcounting of iso_conn
Bluetooth: ISO: ensure no dangling hcon references in iso_conn
Bluetooth: ISO: avoid deadlocks in iso_sock_timeout
Bluetooth: ISO: fix leaking sk after socket release
Bluetooth: ISO: hold sk properly in iso_conn_ready
Bluetooth: ISO: validate sockaddr_iso first in iso_sock_rebind_bis()
Bluetooth: ISO: fix timeout vs sync_timeout typo in check_bcast_qos
...
====================