arc: validate DT CPU map strings before parsing them
arc_get_cpu_map() fetches the possible-cpus or present-cpus property
from the flat DT and immediately passes the raw pointer to
cpulist_parse(). That parser expects a NUL-terminated text buffer, but
this path does not prove that the DT property is terminated within its
declared bounds.
Reject unterminated CPU-map properties before handing them to
cpulist_parse().
Changes since v1:
- fold the NUL-termination check into the initial lookup test, as
suggested by Vineet Gupta
tracing/remotes: Fix leak in trace_remote_alloc_buffer() error path
If page allocation fails in trace_remote_alloc_buffer(), desc->nr_cpus
is not yet incremented for the current CPU. As a consequence, on error,
half-allocated rb_desc will not be freed in trace_remote_free_buffer().
Increment desc->nr_cpus as soon as the first allocation for the current
CPU has succeeded.
Link: https://patch.msgid.link/20260709160017.1729517-2-vdonnefort@google.com Fixes: 96e43537af54 ("tracing: Introduce trace remotes") Reported-by: Sashiko <sashiko-bot@kernel.org> Signed-off-by: Vincent Donnefort <vdonnefort@google.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
platform/x86: asus-wmi: temporarily revert to setting a charge limit
A userspace regression has been observed leaving the battery charging
threshold unconfigured, so while the fix is being shipped revert
the change keeping the infrastructure in place to return to the
preferred behaviour as soon as it's appropriate to do.
platform/x86/intel/vsec: free ACPI discovery data on early errors
intel_vsec_add_dev() may attach an ACPI discovery table copy to the
intel_vsec_device before passing ownership to intel_vsec_add_aux(). The
normal auxiliary-device release path frees that copy, but the earliest
intel_vsec_add_aux() failures free only the outer structure directly.
Route those direct frees through a common helper so acpi_disc is
released consistently on the parent, xarray, and ID allocation failure
paths.
Fixes: 22fa2ebc11a1 ("platform/x86/intel/vsec: Plumb ACPI PMT discovery tables through vsec") Signed-off-by: Yousef Alhouseen <alhouseenyousef@gmail.com> Reviewed-by: David E. Box <david.e.box@linux.intel.com> Link: https://patch.msgid.link/CAMuQ4bUtJtYNTguKoiXngROJw0QQQcrvW3=3_B0-hpMQOFqvCQ@mail.gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux
Pull arm64 fixes from Will Deacon:
- Fix crash when using SMT hotplug on ACPI systems in conjunction with
maxcpus=
- Fix 30% kswapd performance regression introduced by C1-Pro SME
erratum workaround
- Fix TLB over-invalidation regression during memory hotplug
- Fix incorrect encoding of FEAT_BWE2 value in ID_AA64DFR2_EL1.BWE
- Typo fixes in the arm64 selftests
* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
selftests/arm64: fix spelling errors in comments
arm64/sysreg: Fix BWE field encoding in ID_AA64DFR2_EL1
arm64/mm: Optimize TLB flush in unmap_hotplug_[pmd|pud]_range()
arm64: Avoid eager DVMSync reclaim batches with C1-Pro SME erratum
cpu/hotplug: Fix NULL kobject warning in cpuhp_smt_enable()
arm64: smp: Fix hot-unplug tearing by forcing unregistration
Merge tag 'platform-drivers-x86-v7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86
Pull x86 platform driver fixes from Ilpo Järvinen:
- amd/pmc:
- Use correct IP block table for AMD 1Ah M80H SoC
- Avoid logging "(null)" for missing DMI values
- asus-armoury: update power limits for G614PR
- bitland-mifs-wmi: Fix NULL pointer dereference during suspend/resume
* tag 'platform-drivers-x86-v7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86:
platform/x86: amd-pmc: Use correct IP block table for AMD 1Ah M80H SoC
platform/x86: asus-armoury: update power limits for G614PR
platform/x86: bitland-mifs-wmi: Fix NULL pointer dereference during suspend/resume
platform/x86/amd/pmc: Avoid logging "(null)" for DMI values
Notably, ops.set_weight() is called _after_ ops.disable().
This violates the expected semantics of the callbacks, the expectation
being that ops.disable() can only be followed by ops.exit_task() or
ops.enable().
Skipping the weight adjustment for disabled tasks should be harmless
since the weight will be recalculated in scx_enable_task() if the task
ever rejoins SCX.
Fixes: 637b0682821b ("sched: Fold sched_class::switch{ing,ed}_{to,from}() into the change pattern") Cc: stable@vger.kernel.org # v6.19+ Signed-off-by: Kuba Piecuch <jpiecuch@google.com> Signed-off-by: Tejun Heo <tj@kernel.org>
dm-bufio: fix wrong count calculation in dm_bufio_issue_discard
block_to_sector converts a block number to a sector number and adds
c->start to the result. It is inappropriate to use this function for
converting the number of blocks to a number to sectors because c->start
would be incorrectly added to the result.
Luckily, the only target that uses dm_bufio_issue_discard is dm-ebs,
which sets c->start to 0, so this bug is latent.
Merge tag 'gpio-fixes-for-v7.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux
Pull gpio fixes from Bartosz Golaszewski:
- provide the missing .get_direction() callback in gpio-palmas
- fix interrupt handling in gpio-dwapb
- add a GPIO self-test program binary to .gitignore
- fix a resource leak in gpio-mvebu
- make the GPIO sharing heuristic more adaptable
* tag 'gpio-fixes-for-v7.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/brgl/linux:
gpio: mvebu: free generic chips on unbind
selftests: gpio: add gpio-cdev-uaf to .gitignore
gpio: dwapb: Mask interrupts at hardware initialization
gpio: dwapb: Defer clock gating until noirq
gpio: shared: make the voting mechanism adaptable
gpios: palmas: add .get_direction() op
bug: fix warning suppressions with kunit built as module
CONFIG_KUNIT is a tristate symbol but the warning suppression code in
lib/bug.c is only built if it's built-in due to it using a plain #ifdef,
rendering warning suppressions broken for kunit build as loadable module.
kunit_is_suppressed_warning() already has a stub for when kunit is
disabled so drop that guard entirely.
Link: https://lore.kernel.org/r/20260708095459.12111-1-bartosz.golaszewski@oss.qualcomm.com Suggested-by: Albert Esteve <aesteve@redhat.com> Cc: stable@vger.kernel.org Fixes: 85347718ab0d ("bug/kunit: Core support for suppressing warning backtraces") Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Reviewed-by: Albert Esteve <aesteve@redhat.com> Reviewed-by: David Gow <david@davidgow.net> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Merge tag 'ata-7.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux
Pull ata fixes from Damien Le Moal:
- Fix handling of security locked drive revalidation. This prevents
such drives from being dropped when locked on resume (Terrence)
* tag 'ata-7.2-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux:
ata: libata-core: Allow capacity transition to zero for locked drives
ata: libata-core: Skip HPA resize for locked drives
Steven Rostedt [Wed, 8 Jul 2026 20:34:36 +0000 (16:34 -0400)]
selftests/tracing: Have trigger-hist-poll.tc use sched_process_exit
Currently trigger-hist-poll.tc uses sched_process_free to test the polling
of the histogram file. The way it does that is to run sleep, then execute
the poll.c code that polls on the sched_process_free for up to 4 seconds
to test that when sleep triggers the sched_process_free trace event, it
will update the histogram and wake the poll.c code up.
The issue is that sched_process_free trace event is called by
delayed_put_task_struct() which is called after a RCU grace period has
ended. If CONFIG_RCU_LAZY is enabled, RCU callbacks are batched together
and do not execute right away. This causes the delayed_put_task_struct()
to be called after the poll.c function finishes and it will report an
error that it did not wake up on the event. That's because the event
didn't trigger during its wait time.
Use sched_process_exit instead, which is called when a process exits and
doesn't depend on RCU callbacks that may be delayed.
Steven Rostedt [Wed, 8 Jul 2026 19:32:39 +0000 (15:32 -0400)]
selftests/ftrace: Fix reading enabled_functions in add_remove_fprobe_module test
The add_remove_fprobe_module test checks the number of functions added to
the enabled_functions file to make sure that the functions added or
removed is as expected. The issue is that it expects this file to be empty
on start up.
Now that systemd uses BPF that attaches to functions via ftrace, this file
is not empty in several systems:
# cat /sys/kernel/tracing/enabled_functions
bpf_lsm_file_open (1) R D M tramp: ftrace_regs_caller+0x0/0x61 (call_direct_funcs+0x0/0x50)
direct(jmp)-->bpf_trampoline_6442529439+0x0/0xe9
Change the test to read the number of lines in enabled_functions at the
start of the test and subtract that from the value of the count for the
checks within the test.
KVM: TDX: Reject concurrent change to CPUID entry count
Reject KVM_TDX_INIT_VM if userspace changes cpuid.nent between the
initial read and the subsequent copy of the initialization data.
tdx_td_init() first reads user_data->cpuid.nent to size the flexible
kvm_tdx_init_vm copy. The copied structure also contains cpuid.nent,
and that field can differ from the value used to size the allocation if
userspace modifies the input concurrently. setup_tdparams_cpuids() later
passes init_vm->cpuid.nent to kvm_find_cpuid_entry2(), which uses it as
the array bound for the copied entries.
Require the copied count to match the value used to size the allocation
so that CPUID parsing cannot access beyond the entries actually copied.
Fixes: 0bd0a4a1428b ("KVM: TDX: Replace kmalloc + copy_from_user with memdup_user in tdx_td_init()") Reported-by: Sashiko:gemini-3.1-pro-preview Cc: <stable@vger.kernel.org> Signed-off-by: Binbin Wu <binbin.wu@linux.intel.com> Reviewed-by: Xiaoyao Li <xiaoyao.li@intel.com> Reviewed-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260710035324.3170534-1-binbin.wu@linux.intel.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Atish Patra [Tue, 2 Jun 2026 22:36:33 +0000 (15:36 -0700)]
KVM: selftests: Verify SNP VMs are rejected from migration and mirroring
Migration and mirroring of SEV-SNP VMs are not supported yet.
Add two selftests that verify KVM rejects intra-host migration and
mirroring when the source VM is an SNP VM, so the restriction stays enforced
until proper SNP state transfer is implemented.
Atish Patra [Tue, 2 Jun 2026 22:36:32 +0000 (15:36 -0700)]
KVM: SEV: Do not allow intra-host migration/mirroring of SNP VMs
The intra-host migration/mirroring feature is not fully implemented for
SEV-SNP VMs. The proper migration requires additional SNP-specific
state such as guest_req_mutex, guest_req_buf, and guest_resp_buf to be
transferred or initialized on the destination.
The SNP VM mirroring requires vmsa features to be copied as well otherwise
ASID would be bound to SNP range while VM is detected as a SEV VM.
Reject SNP source VMs in migration/mirroring until proper SNP state
transfer is implemented.
Fixes: 1dfe571c12cf ("KVM: SEV: Add initial SEV-SNP support") Reported-by: Chris Mason <clm@meta.com> Reported-by: Sashiko <sashiko-bot@kernel.org> Assisted-by: Claude:claude-opus-4-6 Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by: Atish Patra <atishp@meta.com> Link: https://patch.msgid.link/20260602-sev_snp_fixes-v3-1-24bfd3ae047c@meta.com Cc: stable@vger.kernel.org
[sean: let lines poke past 80 chars, tag for stable] Signed-off-by: Sean Christopherson <seanjc@google.com>
Merge tag 'drm-fixes-2026-07-10' of https://gitlab.freedesktop.org/drm/kernel
Pull drm fixes from Dave Airlie:
"Weekly fixes pull for drm, amdgpu, amdxdna, xe leading the way, some
small core fixes and a nouveau stability fix along with some minor
changes in other drivers.
Seems to be a bit quiter than last week at least.
fb-helper:
- Sync on first active crtc in fb_dirty, rather than first crtc
drm_exec:
- Use direct label in drm_exec
buddy:
- Rework try_harder in the buddy allocator
i915:
- fix underrun on panthor lake
- LT PHY SSC programming fix
- fix some NULL derefs and leaks
nouveau:
- fix a vmm large/small page table update race
xe:
- Fix PTE index in xe_vm_populate_pgtable for chunked binds
- Wait on external BO kernel fences in exec IOCTL
- Remove duplicate include
- Free madvise VMA array on L2 flush failure
- Stub notifier_lock helpers when DRM_GPUSVM=n
amdxdna:
- Fix uaf in mmap failure path
- A lot of deadlocks, access races and return value fixes
analogix_dp:
- Fix analogix_dp bitshifts during link training
v3d:
- Fix absent indirect bo handling
imagination:
- Make function static to solve compiler warning
- Fix error checking"
* tag 'drm-fixes-2026-07-10' of https://gitlab.freedesktop.org/drm/kernel: (44 commits)
nouveau/vmm: fix another SPT/LPT race
drm/imagination: fix error checking of pvr_vm_context_lookup()
drm/imagination: make pvr_fw_trace_init_mask_ops static
gpu/buddy: bail out of try_harder when alignment cannot be honoured
drm/xe/userptr: Stub notifier_lock helpers when DRM_GPUSVM=n
drm/xe: free madvise VMA array on L2 flush failure
drm/xe: remove duplicate <kunit/test-bug.h> include
drm/xe: Wait on external BO kernel fences in exec IOCTL
drm/xe: Fix PTE index in xe_vm_populate_pgtable() for chunked binds
drm/fb-helper: Only consider active CRTCs for vblank sync
drm/amdkfd: Check bounds on CRIU restore queue type and mqd size
drm/amd/pm: fix smu14 power limit range calculation
drm/amdkfd: Check bounds in allocate_event_notification_slot
amdkfd: properly free secondary context id
drm/amdkfd: Don't acquire buffers during CRIU queue restore
drm/amdkfd: Check bounds on CRIU restore event id
drm/gfx10: Program DB_RING_CONTROL
drm/amdgpu: fix lifetime issue of amdgpu_vm_get_task_info_pasid()
drm/amdgpu: trigger GPU recovery when userq destroy fails to unmap a hung queue
drm/amd/amdgpu: disable ASPM on VI if pcie dpm is disabled
...
Wang Yan [Fri, 10 Jul 2026 08:34:37 +0000 (16:34 +0800)]
selftests/riscv: ptrace: Fix memory leak of regset_data in vector tests
The regset_data buffer allocated with calloc() in the parent process
of several vector ptrace tests is never freed before returning,
causing memory leaks in:
block: remove redundant GD_NEED_PART_SCAN in add_disk_final()
add_disk_final() sets GD_NEED_PART_SCAN before calling bdev_add(),
then calls disk_scan_partitions() which sets the flag itself. The
early set is redundant and introduces a race.
Between bdev_add() and disk_scan_partitions(), concurrent openers
(multipathd, blkid, LVM) see the flag in blkdev_get_whole() and
trigger bdev_disk_changed(). When disk_scan_partitions() then runs,
it calls bdev_disk_changed() again, dropping the partitions the
concurrent opener already created before re-adding them, which can
result in transient partition disappearances.
The race is observable by inserting an msleep() between bdev_add()
and disk_scan_partitions() while running concurrent open() calls
during device bind. Without artificial delay, it manifests under
scheduling pressure during boot on systems with aggressive device
scanners (multipathd, systemd-udevd).
Therefore, do not set GD_NEED_PART_SCAN in add_disk_final(). Other
GD_NEED_PART_SCAN consumers (blkdev_get_whole(),
sd_need_revalidate()) should not be affected as the flag
is set internally by disk_scan_partitions().
The retry-on-next-open intention from commit e5cfefa97bcc
("block: fix scan partition for exclusively open device again")
should also not be affected as the early return paths in
disk_scan_partitions() should be unreachable at device registration
time (bd_holder is NULL and open_partitions is zero).
Fixes: e5cfefa97bcc ("block: fix scan partition for exclusively open device again") Cc: stable@vger.kernel.org Signed-off-by: Connor Williamson <connordw@amazon.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Link: https://patch.msgid.link/20260615130715.53693-1-connordw@amazon.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
Weiming Shi [Sat, 4 Jul 2026 03:35:46 +0000 (20:35 -0700)]
sctp: validate STALE_COOKIE cause length before reading staleness
When an ERROR chunk with a STALE_COOKIE cause is received in the
COOKIE_ECHOED state, sctp_sf_do_5_2_6_stale() reads the 4-byte Measure
of Staleness that follows the cause header:
err is the first cause in the chunk, not the STALE_COOKIE cause that
caused the dispatch, and nothing guarantees the staleness field is
present. sctp_walk_errors() only requires a cause to be as long as the
4-byte header, so for a STALE_COOKIE cause of length 4 the read runs
past the cause, and for a minimal ERROR chunk past skb->tail. The value
is echoed to the peer in the Cookie Preservative of the reply INIT,
leaking uninitialized memory.
sctp_sf_cookie_echoed_err() already walks to the STALE_COOKIE cause, so
check its length there and pass it to sctp_sf_do_5_2_6_stale(), which
reads that cause instead of the first one. A STALE_COOKIE cause too
short to hold the staleness field is discarded.
The read is reachable by any peer that can drive an association into
COOKIE_ECHOED, including an unprivileged process using a raw SCTP socket
in a user and network namespace.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Xiang Mei <xmei5@asu.edu> Assisted-by: Claude:claude-opus-4-8 Cc: stable@vger.kernel.org Signed-off-by: Weiming Shi <bestswngs@gmail.com> Acked-by: Xin Long <lucien.xin@gmail.com> Link: https://patch.msgid.link/20260704033545.2438373-2-bestswngs@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
... and must not be subjected to the 'nul terminated' constraint.
If the interface name is 15 characters long, the mask is 16-bytes
'0xff' (to cover for \0) and the valid device name is rejected.
ipvs: fix more places with wrong ipv6 transport offsets
Sashiko reports for more incorrect IPv6 transport offsets.
The app code for TCP was assuming IPv4 network header
even after the ipvsh argument was provided. This can
cause problems with apps over IPv6. As for the only
official app in the kernel tree (FTP) this problem is
harmless because we use Netfilter to mangle the FTP
ports and we do not adjust the TCP seq numbers.
Also, provide correct offset of the ICMPV6 header in
ip_vs_out_icmp_v6() for correct checksum checks when
the IPv6 packet has extension headers.
Fixes: d12e12299a69 ("ipvs: add ipv6 support to ftp") Fixes: 2a3b791e6e11 ("IPVS: Add/adjust Netfilter hook functions and helpers for v6") Cc: stable@vger.kernel.org Link: https://sashiko.dev/#/patchset/20260706101624.69471-1-zhaoyz24%40mails.tsinghua.edu.cn Signed-off-by: Julian Anastasov <ja@ssi.bg> Signed-off-by: Florian Westphal <fw@strlen.de>
netfilter: flowtable: use correct direction to set up tunnel route
The layer 2 encapsulation and layer 3 tunnel information in the xmit
path is taken from the other tuple, because the tunnel information that
is included in the tuple for hashtable lookups is also used to perform
the egress encapsulation in the transmit path.
This patch uses the correct direction when setting up the tunnel, the
original proposed patch to address this fix uses the reversed direction.
While at it, remove the redundant check to call dst_release() to drop
the reference on the dst that was obtained from the forward path, which
is not useful in the direct xmit path unless tunneling is performed.
Fixes: fa7395c02d95 ("netfilter: flowtable: support IPIP tunnel with direct xmit") Cc: stable@vger.kernel.org Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: Florian Westphal <fw@strlen.de>
Add a nft_flowtable.sh regression test for the bridge direct-xmit plus
IPIP/IP6IP6 underlay configuration that reproduces the reachable
DIRECT+tunnel tuple combination exercised by the flowtable fix.
The test reuses the existing bridge and tunnel topology, installs flow
rules for the tunnel egress and bridge reply path, verifies IPv4 and
IPv6 forwarding, and checks the flowtable counters after the transfer.
netfilter: nf_conncount: fix zone comparison in tuple dedup
The "already exists" dedup logic in __nf_conncount_add() decides
whether a connection has already been counted and can be skipped instead
of incrementing the connlimit count. It compares the conntrack zone of a
list entry with the zone of the connection being added using
nf_ct_zone_id() and nf_ct_zone_equal(), passing conn->zone.dir or
zone->dir as the direction argument.
Those helpers take enum ip_conntrack_dir values: IP_CT_DIR_ORIGINAL is 0
and IP_CT_DIR_REPLY is 1. However, zone->dir is a u8 bitmask:
NF_CT_ZONE_DIR_ORIG is 1, NF_CT_ZONE_DIR_REPL is 2 and
NF_CT_DEFAULT_ZONE_DIR is 3. Passing that bitmask as the enum direction
shifts the meaning of every non-zero value. An ORIG-only zone passes 1
and is tested as REPLY, while REPL-only and default zones pass 2 or 3 and
test bits beyond the valid direction range. In those cases
nf_ct_zone_id() can fall back to NF_CT_DEFAULT_ZONE_ID instead of using
the real zone id, so different zones can be treated as equal and dedup
collapses to tuple equality alone.
nf_conncount stores and compares the original-direction tuple for a
connection. If an skb already has an attached conntrack entry,
get_ct_or_tuple_from_skb() explicitly copies
ct->tuplehash[IP_CT_DIR_ORIGINAL].tuple, regardless of the packet's
ctinfo. Therefore the zone comparison in the tuple dedup path must use
IP_CT_DIR_ORIGINAL as well; the zone direction bitmask describes where a
zone id applies, not which direction this conncount tuple represents.
Fix the two dedup comparisons by passing IP_CT_DIR_ORIGINAL directly.
Do not special-case NF_CT_DEFAULT_ZONE_DIR and do not compare raw zone
ids: using the existing helpers with IP_CT_DIR_ORIGINAL preserves the
direction-aware NF_CT_DEFAULT_ZONE_ID fallback. A default bidirectional
zone contains the ORIG bit, so it naturally returns the real zone id;
reply-only zones continue to fall back for original-direction tuple
comparisons.
Fixes: 21ba8847f857 ("netfilter: nf_conncount: Fix garbage collection with zones") Fixes: b36e4523d4d5 ("netfilter: nf_conncount: fix garbage collection confirm race") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn> Reported-by: Ao Wang <wangao@seu.edu.cn> Reported-by: Xuewei Feng <fengxw06@126.com> Reported-by: Qi Li <qli01@tsinghua.edu.cn> Reported-by: Ke Xu <xuke@tsinghua.edu.cn> Assisted-by: Claude-Code:GLM-5.2 Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Signed-off-by: Florian Westphal <fw@strlen.de>
netfilter: bridge: fix stale prevhdr pointer in br_ip6_fragment()
br_ip6_fragment() gets prevhdr, a pointer into the skb head, from
ip6_find_1stfragopt(), then calls skb_checksum_help(). For a cloned skb
skb_checksum_help() reallocates the head via pskb_expand_head(), leaving
prevhdr dangling. It is later dereferenced in ip6_frag_next(), causing a
use-after-free write.
Save prevhdr's offset before skb_checksum_help() and recompute it after,
like commit ef0efcd3bd3f ("ipv6: Fix dangling pointer when ipv6
fragment").
BUG: KASAN: slab-use-after-free in ip6_frag_next (net/ipv6/ip6_output.c:857)
Write of size 1 at addr ffff888013ff5016 by task exploit/141
Call Trace:
...
kasan_report (mm/kasan/report.c:595)
ip6_frag_next (net/ipv6/ip6_output.c:857)
br_ip6_fragment (net/ipv6/netfilter.c:212)
nf_ct_bridge_post (net/bridge/netfilter/nf_conntrack_bridge.c:407)
nf_hook_slow (net/netfilter/core.c:619)
br_forward_finish (net/bridge/br_forward.c:66)
__br_forward (net/bridge/br_forward.c:115)
maybe_deliver (net/bridge/br_forward.c:191)
br_flood (net/bridge/br_forward.c:245)
br_handle_frame_finish (net/bridge/br_input.c:229)
br_handle_frame (net/bridge/br_input.c:442)
...
packet_sendmsg (net/packet/af_packet.c:3114)
...
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)
Kernel panic - not syncing: Fatal exception in interrupt
Fixes: 764dd163ac92 ("netfilter: nf_conntrack_bridge: add support for IPv6") Cc: stable@vger.kernel.org Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Xiang Mei (Microsoft) <xmei5@asu.edu> Signed-off-by: Florian Westphal <fw@strlen.de>
ecache_work_evict_list() redelivers DESTROY events for conntracks that
were moved to the per-netns dying_list after event delivery failed. It
sets a 10ms deadline:
stop = jiffies + ECACHE_MAX_JIFFIES
but then tests:
time_after(stop, jiffies)
This condition is true while the deadline is still in the future, so the
worker returns STATE_RESTART after the first successful redelivery in the
usual case. ecache_work() maps STATE_RESTART to delay 0, which turns the
redelivery path into one dying conntrack per workqueue dispatch and makes
the sent > 16 batching/cond_resched() path effectively unreachable.
A conntrack netlink listener whose receive queue is congested can make
DESTROY event delivery fail with -ENOBUFS. With sustained conntrack
churn, entries then accumulate on the dying_list and are only drained at
the degraded one-entry-per-dispatch rate once delivery succeeds again,
wasting CPU on back-to-back workqueue reschedules and prolonging
conntrack memory/resource pressure.
In a KASAN QEMU test with CONFIG_NF_CONNTRACK_EVENTS=y and
nf_conntrack.enable_hooks=1, a congested DESTROY listener caused 8192
nf_ct_delete() calls to return false and move entries to the dying_list.
After closing the listener, the unfixed kernel needed 7670 ecache_work()
entries to destroy 7669 conntracks. With this change, the same 8192
entries were destroyed by 2 ecache_work() entries.
Swap the comparison so the worker restarts only after the deadline has
expired.
Fixes: 2ed3bf188b33 ("netfilter: ecache: use dedicated list for event redelivery") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn> Reported-by: Ao Wang <wangao@seu.edu.cn> Reported-by: Xuewei Feng <fengxw06@126.com> Reported-by: Qi Li <qli01@tsinghua.edu.cn> Reported-by: Ke Xu <xuke@tsinghua.edu.cn> Assisted-by: Claude-Code:GLM-5.2 Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Signed-off-by: Florian Westphal <fw@strlen.de>
xt_nat SNAT and DNAT target handlers assume IP-family conntrack state
is present and can dereference a NULL pointer when instantiated from an
unsupported family through nft_compat. A bridge-family compat rule can
therefore trigger a NULL-dereference in nf_nat_setup_info().
Reject non-IP families in xt_nat_checkentry() so unsupported targets
cannot be installed. Keep NFPROTO_INET allowed for valid inet NAT
compat users and leave the runtime fast path unchanged.
[ The crash was fixed via 9dbba7e694ec ("netfilter: nft_compat: ebtables emulation must reject non-bridge targets"),
so this patch is no longer critical.
Nevertheless, NAT is only relevant for ipv4/ipv6, so this extra
family check is a good idea in any case. ]
Paolo Abeni [Fri, 10 Jul 2026 14:27:44 +0000 (16:27 +0200)]
Merge tag 'wireless-2026-07-09' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless
Johannes Berg says:
====================
Too many robustness fixes to list. Mostly for
- slight out-of-bounds reads of SKBs,
- leaks on error conditions, and
- malformed netlink input rejection.
* tag 'wireless-2026-07-09' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: (46 commits)
wifi: cfg80211: bound element ID read when checking non-inheritance
wifi: brcmfmac: cyw: fix heap overflow on a short auth frame
wifi: brcmfmac: initialize SDIO data work before cleanup
wifi: cfg80211: validate assoc response length before status and IE access
wifi: cfg80211: validate rx/tx MLME callback frame lengths before access
wifi: mac80211: ibss: wait for in-flight TX on disconnect
wifi: mac80211: recalculate rx_nss on IBSS peer capability update
wifi: cfg80211: use wiphy work for socket owner autodisconnect
wifi: mac80211: fix memory leak in ieee80211_register_hw()
wifi: mac80211: free AP_VLAN bc_buf SKBs outside IRQ lock
wifi: mac80211: validate deauth frame length before reason access
wifi: mac80211: avoid non-S1G AID fallback for S1G assoc
wifi: cfg80211: reject empty PMSR peer lists
wifi: cfg80211: reject unsupported PMSR FTM location requests
wifi: cfg80211: validate PMSR FTM preamble range
wifi: cfg80211: validate PMSR measurement type data
wifi: nl80211: constrain MBSSID TX link ID range
wifi: nl80211: validate nested MBSSID IE blobs
wifi: ieee80211: validate MLE common info length
wifi: cfg80211: derive S1G beacon TSF from S1G fields
...
====================
net/iucv: take a reference on the socket found in afiucv_hs_rcv()
afiucv_hs_rcv() looks up the destination socket under iucv_sk_list.lock,
drops the lock, and then passes the socket to the afiucv_hs_callback_*()
handlers without holding a reference. AF_IUCV sockets are not
RCU-protected and are freed synchronously by iucv_sock_kill() ->
sock_put(), so a concurrent close can free the socket in the window
between read_unlock() and the handler, which then dereferences freed
memory (for example sk->sk_data_ready() in afiucv_hs_callback_syn()).
Take a reference with sock_hold() while the socket is still on the list
and release it with sock_put() once the handler has run.
Weiming Shi [Sat, 4 Jul 2026 17:14:21 +0000 (10:14 -0700)]
ipv4: fib: free fib_alias with kfree_rcu() on insert error path
fib_table_insert() publishes new_fa into the leaf's fa_list with
fib_insert_alias() before calling the fib entry notifiers. When a
notifier fails, the error path removes new_fa with fib_remove_alias()
(hlist_del_rcu) and frees it right away with kmem_cache_free().
fib_table_lookup() walks that list under rcu_read_lock() only, so a
concurrent lookup that already reached new_fa keeps reading it after the
free:
BUG: KASAN: slab-use-after-free in fib_table_lookup (net/ipv4/fib_trie.c:1601)
Read of size 1 at addr ffff88810676d4eb by task exploit/297
Call Trace:
fib_table_lookup (net/ipv4/fib_trie.c:1601)
ip_route_output_key_hash_rcu (net/ipv4/route.c:2814)
ip_route_output_key_hash (net/ipv4/route.c:2705)
__ip4_datagram_connect (net/ipv4/datagram.c:49)
udp_connect (net/ipv4/udp.c:2144)
__sys_connect (net/socket.c:2167)
__x64_sys_connect (net/socket.c:2173)
do_syscall_64
entry_SYSCALL_64_after_hwframe
which belongs to the cache ip_fib_alias of size 56
Triggering the error path needs CAP_NET_ADMIN and a registered fib
notifier that can reject a route; a netdevsim device whose IPv4 FIB
resource is exhausted is enough.
Free new_fa with alias_free_mem_rcu(), as fib_table_delete() already
does for a fib_alias removed from the trie.
Fixes: a6c76c17df02 ("ipv4: Notify route after insertion to the routing table") Reported-by: Xiang Mei <xmei5@asu.edu> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi <bestswngs@gmail.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260704171421.1786806-1-bestswngs@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Sandipan Das [Fri, 10 Jul 2026 10:45:27 +0000 (16:15 +0530)]
perf/x86/amd/lbr: Fix kernel address leakage
A user-only branch stack can contain branches that originate from
the kernel. As a result, kernel addresses are exposed to user space
even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors
supporting X86_FEATURE_AMD_LBR_V2, perf can still report SYSRET/ERET
entries for which the branch-from addresses are in the kernel.
The reason is that the hardware filter only considers the privilege
level applicable to the branch target. Extend software filtering to
also validate the branch-from addresses against br_sel, so that any
branch record whose branch-from address is in the kernel is dropped
when PERF_SAMPLE_BRANCH_USER is requested.
Fixes: f4f925dae741 ("perf/x86/amd/lbr: Add LbrExtV2 hardware branch filter support") Reported-by: Ian Rogers <irogers@google.com> Signed-off-by: Sandipan Das <sandipan.das@amd.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: stable@vger.kernel.org Cc: Peter Zijlstra <peterz@infradead.org> Link: https://patch.msgid.link/a898a29725f6b2f30518354cdc2e432db66c43cf.1783680119.git.sandipan.das@amd.com
drbd: reject data replies with an out-of-range payload size
recv_dless_read() receives a P_DATA_REPLY from a peer into the bio of an
outstanding read request. The peer-supplied payload length reaches it as
the signed int data_size, and two peer-controlled inputs can make it
negative. With a negotiated data-integrity-alg the digest length is
subtracted first, so a reply whose payload is smaller than the digest
underflows data_size. With no integrity algorithm (the default) data_size
is assigned from the unsigned h95/h100 wire length and drbdd() never
bounds it for a payload-carrying command, so a length above INT_MAX casts
it negative; this path needs no non-default feature. The bio receive loop
then computes expect = min_t(int, data_size, bv_len), which is negative,
and drbd_recv_all_warn(mapped, expect) receives with a size_t of SIZE_MAX
into the first mapped page.
The sibling receive path read_in_block() is not affected: it uses an
unsigned size and rejects it against DRBD_MAX_BIO_SIZE before receiving.
Reject a data reply whose size is negative after the optional digest
subtraction, covering both triggers.
Impact: a malicious or man-in-the-middle DRBD peer copies attacker-chosen
bytes past a bio page in the receiver, corrupting kernel memory. A node
that reads from its peer (a diskless node, or read-balancing to the peer)
is exposed in the default configuration; data-integrity-alg is not
required.
Fixes: b411b3637fa7 ("The DRBD driver") Cc: stable@vger.kernel.org Assisted-by: Codex:gpt-5-5-xhigh Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Reviewed-by: Christoph Böhmwalder <christoph.boehmwalder@linbit.com> Link: https://patch.msgid.link/20260710022837.3738461-1-michael.bommarito@gmail.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
John Ogness [Tue, 7 Jul 2026 14:10:04 +0000 (16:16 +0206)]
serial: 8250: Ignore flow control on suspend/resume with no_console_suspend
If no_console_suspend is specified, on suspend the 8250 console driver
uses a scratch register (UART_SCR) to store a special canary value. This
is used during the resume path to identify a printk() call before the
driver's own ->resume() callback. In this case,
serial8250_console_restore() is called to quickly re-init the 8250 for
console printing.
See commit 4516d50aabed ("serial: 8250: Use canary to restart console after
suspend") for the original motivation.
Unfortunately, this canary workaround does not work in all cases (such as
suspend to mem) because the scratch register will not reset. This has not
been a real issue until now because it could simply lead to some garbage
characters upon resume. However, with the introduction of console flow
control it becomes a real problem because a failed suspend/resume detection
when flow control is enabled leads to all characters hitting the flow
control timeout.
Workaround this issue by temporarily ignoring console flow control when
the debug canary suspend/resume detection is active.
Matthias Feser [Tue, 26 May 2026 07:35:09 +0000 (07:35 +0000)]
serial: 8250_omap: clear rx_running on zero-length DMA completes
On AM33xx RX DMA only triggers when the FIFO reaches the
configured threshold (typically 48 bytes). For smaller bursts
no DMA request is issued and the FIFO is drained by RX timeout.
In this case __dma_rx_do_complete() can legitimately see count == 0.
The current code exits early in this case and does not clear
dma->rx_running, leaving the DMA state inconsistent. This can
prevent RX DMA from restarting and may cause
omap_8250_rx_dma_flush() to fail, marking DMA as broken.
Fix this by clearing dma->rx_running once the DMA transfer has
completed or been terminated, even if no data was transferred.
Fixes: a5fd8945a478 ("serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA termination is done") Cc: stable <stable@kernel.org> Signed-off-by: Matthias Feser <mfe@KBSgmbhfr.onmicrosoft.com> Reviewed-by: Moteen Shah <m-shah@ti.com> Link: https://patch.msgid.link/BE3P281MB55155F2F5795E411F5A65282EE0B2@BE3P281MB5515.DEUP281.PROD.OUTLOOK.COM Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolas Pitre [Fri, 26 Jun 2026 02:48:33 +0000 (22:48 -0400)]
vt: fix spurious modifier in CSI/cursor key sequences
csi_modifier_param() builds the xterm modifier parameter from
shift_state, counting KG_SHIFTL/KG_SHIFTR as Shift, KG_ALTGR as Alt
and KG_CTRLL/KG_CTRLR as Ctrl in addition to the canonical KG_SHIFT,
KG_ALT and KG_CTRL.
That is wrong when those weights are not plain modifiers. Keymaps
derived from XKB layouts (by kbd's xkbsupport, and by the
console-setup used in Debian, Ubuntu and others) encode the active
layout group using KG_SHIFTL/KG_SHIFTR:
group 1: -
group 2: shiftl
group 3: shiftr
group 4: shiftl | shiftr
So while a non-default layout group is selected, KG_SHIFTL and/or
KG_SHIFTR are set in shift_state with no Shift key held.
csi_modifier_param() then adds a spurious Shift to every cursor and
CSI key: pressing Up while group 2 is active emits ESC[1;2A (Shift+Up)
instead of ESC[A. KG_ALTGR has the same problem since it is the
standard third-level selector.
Normal keymaps bind the physical Shift/Ctrl/Alt keys to KG_SHIFT,
KG_CTRL and KG_ALT, leaving the left/right and AltGr weights free for
layout and level selection. Count only those canonical weights, so
genuine modifiers are still encoded while layout/level selectors are
not.
Fixes: 4af70f151671 ("vt: add modifier support to cursor keys") Reported-by: Alexey Gladkov <legion@kernel.org> Closes: https://lore.kernel.org/kbd/aj2gR0Y7sM6i9s2G@example.org/ Cc: stable <stable@kernel.org> Signed-off-by: Nicolas Pitre <npitre@baylibre.com> Link: https://patch.msgid.link/20260626024833.3419086-1-nico@fluxnic.net Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
USE_OF is already selected by ARM (unless ARCH_FOOTBRIDGE || ARCH_RPC ||
ARCH_SA1100; these all conflict with ARCH_MULTI_V5). So there is no need
for an explicit select and it can be dropped.
Merge tag 'tegra-for-7.2-arm64-dt-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes
arm64: tegra: Device tree fixes for v7.2
These changes fix an invalid compatible string combination for GPC DMA
on Tegra264, change the compatible string for the CPU found on Tegra234
and update the unit-address of CPU#1 on Tegra264 so it matches the value
in the "reg" property.
* tag 'tegra-for-7.2-arm64-dt-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
arm64: tegra: Fix CPU1 node unit-address on Tegra264
arm64: tegra: Fix CPU compatible string to cortex-a78ae on Tegra234
arm64: tegra: Remove fallback compatible for GPCDMA
The error counter "v->corrupted_errs" was not atomic, thus it could be
subject to race conditions. The call to
dm_audit_log_target("max-corrupted-errors") may be skipped due to the
races.
The prefix "DM_VERITY_ERR_BLOCK_NR" is 22 chars. Add '=', one digit for
type, ',', up to 20 digits for a u64 block number, and a NUL terminator:
that's 46 bytes. The buffer is 42 bytes. For block numbers >= 16 decimal
digits (devices larger than ~16 EB with 4K blocks), snprintf silently
truncates the uevent environment variable.
Merge tag 'tegra-for-7.2-soc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes
soc/tegra: Fixes for v7.2
Fix a spurious WARN() that was checking for an outdated condition.
* tag 'tegra-for-7.2-soc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
soc/tegra: fuse: Fix spurious straps warning on SMCCC platforms
dm-verity: avoid double increment of &use_bh_wq_enabled
verity_parse_opt_args is called twice, first with the only_modifier_opts,
first with only_modifier_opts == true and then with only_modifier_opts ==
false. Thus, the static branch &use_bh_wq_enabled was incremented twice
and the destructor verity_dtr would only decrement it once.
Fix tihs bug by only incrementing it on the first call, on the second
call, when v->use_bh_wq is true, do nothing.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Assisted-by: Claude:claude-opus-4-6 Cc: stable@vger.kernel.org Fixes: df326e7a0699 ("dm verity: allow optional args to alter primary args handling")
Merge tag 'tegra-for-7.2-pmc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/fixes
soc/tegra: pmc: Fixes for v7.2
This contains two fixes, one for a bad error unwinding path and another
for an #ifdef block that wasn't covering all the combinations correctly.
* tag 'tegra-for-7.2-pmc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
soc/tegra: pmc: fix #ifdef block in header
drm/tegra: Fix a strange error handling path
dm-ioctl: fix a possible overflow in list_version_get_info
sizeof(tt->version) is 12 bytes, but the code writes 16 bytes into the
output buffer - info->vers->version[0], info->vers->version[1],
info->vers->version[2] and info->vers->next. This can cause buffer
overflow.
Fix this buffer overflow by replacing "sizeof(tt->version)" with
"sizeof(struct dm_target_versions)".
dm_early_create: fix freeing used table on dm_resume failure
If dm_resume fails, the kernel attempts to free table with
dm_table_destroy, but the table was already instantiated with
dm_swap_table. This commit skips the call to dm_table_destroy in this
case.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Assisted-by: Claude:claude-opus-4.6 Fixes: 6bbc923dfcf5 ("dm: add support to directly boot to a mapped device") Cc: stable@vger.kernel.org
dm-integrity: fix a bug if the bio is out of limits
If dm_integrity_check_limits fails, the code would exit with
DM_MAPIO_KILL. However, the range would be already locked at this point,
and it wouldn't be unlocked, resulting in a deadlock. Let's move the
limit check up, so that when it exits, no resources are leaked.
If hash size is less than device's tuple size, dm-integrity is supposed
to zero the remaining space. There was a bug in the code that zeroing
didn't work. This commit fixes it.
When the "fix_hmac" argument is used, dm-integrity is supposed to check
the superblock with the journal_mac. However, there was a logic bug in
the code - the code only checked the superblock mac if the bit
SB_FLAG_FIXED_HMAC was set in the superblock. So, the attacker could
clear this bit and bypass the checking trivially.
This commit changes dm-integrity so that when the user specified the
"fix_hmac" flag and the superblock doesn't have the bit
SB_FLAG_FIXED_HMAC set, the activation is aborted with an error.
Unfortunatelly, there's a bug in the integritysetup tool that when using
the 'open' command it passes the "fix_hmac" argument to the kernel even
if the user specified --integrity-legacy-hmac. The bug will be fixed in
the upcoming 2.8.7 release.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Reported-by: Shukai Ni <shukai.ni@kuleuven.be>
Merge tag 'reset-fixes-for-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/pza/linux into arm/fixes
Reset controller fixes for v7.2
* Fix the SpacemiT K3 USB2 AHB reset bit location.
* Add missing COMBOPHY_RESET definition for Altera Agilex5.
* Fix the reset-sunxi initialization error path to release the
requested memory region.
* Correct polarity of MIPI CSI resets on NXP i.MX8MQ. The corresponding
fix in the CSI2 driver, 6d79bb8fd2aa, is already contained in v7.2-rc1.
* tag 'reset-fixes-for-v7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/pza/linux:
reset: imx7: Correct polarity of MIPI CSI resets on i.MX8MQ
reset: sunxi: fix memory region leak on ioremap failure
dt-bindings: reset: altr: add COMBOPHY_RESET for Agilex5
reset: spacemit: k3: fix USB2 ahb reset
It runs under rcu_read_lock() holding only an l2tp_session reference and
takes NO reference on the internal PPP channel (struct channel,
chan->ppp) that ppp_input() dereferences.
The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel
are RCU-safe. But the internal struct channel is a separate allocation
that ppp_release_channel() frees with a plain kfree():
For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit
(no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips
both ppp_disconnect_channel()'s synchronize_net() and
ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace
period. rcu_read_lock() in pppol2tp_recv() does not protect against a
plain kfree(), so an in-flight ppp_input() on one CPU can dereference
the channel just freed by close() on another CPU.
The bug is reachable by an unprivileged user.
Defer the channel free to an RCU callback via call_rcu() so the grace
period fences any in-flight ppp_input(). The disconnect and unbridge
teardown paths already fence with synchronize_net()/synchronize_rcu();
call_rcu() does the same here without stalling the close() path.
Fixes: ee40fb2e1eb5 ("l2tp: protect sock pointer of struct pppol2tp_session with RCU") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Norbert Szetei <norbert@doyensec.com> Reviewed-by: Qingfang Deng <qingfang.deng@linux.dev> Link: https://patch.msgid.link/E793FCF2-58DE-4387-A983-C7B4BC3158BD@doyensec.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Thomas Huth [Fri, 10 Jul 2026 08:16:42 +0000 (10:16 +0200)]
selftests/landlock: Skip scoped_signal subtest with MSG_OOB if not available
MSG_OOB might be disabled in the kernel for unix sockets (by not
selecting CONFIG_AF_UNIX_OOB), and in this case the related tests
of the scoped_signal_test are currently failing. Add a runtime
probe using socketpair() to detect MSG_OOB support and skip the
test gracefully if it is unavailable.
Signed-off-by: Thomas Huth <thuth@redhat.com> Link: https://patch.msgid.link/20260710081642.405916-1-thuth@redhat.com Cc: stable@vger.kernel.org Fixes: f34e9ce5f479 ("selftests/landlock: Test signal created by out-of-bound message") Signed-off-by: Mickaël Salaün <mic@digikod.net>
Thomas Huth [Thu, 9 Jul 2026 16:43:40 +0000 (18:43 +0200)]
selftests/landlock: Fix screwed up pointers in the scoped_signal_test
The scoped_signal_test uses pthread_join(..., (void **)&ret)) in
a couple of places, i.e. the return value of the thread is stored
in the shape of a "void *" into the memory location of &ret.
Pointers are 64-bit on modern computers, but the ret variable is
declared as a simple "enum thread_return" which is only 32 bits.
So the pthread_join() will overflow the ret variable by 4 byte.
The problem is very visible on big endian systems like s390x
where the test is failing: The least significant byte that carries
the return code of the thread is not written into the ret variable
here, but somewhere else in the stack frame, so the comparison
for the right return code is failing here.
Fix it by getting rid of the enum and defining the THREAD_* constants
and "ret" variables as proper "void *" pointers. This way we can
also get rid of some ugly (void *) castings in a couple of spots.
Signed-off-by: Thomas Huth <thuth@redhat.com> Link: https://patch.msgid.link/20260709164340.339656-1-thuth@redhat.com Cc: stable@vger.kernel.org Fixes: c8994965013e ("selftests/landlock: Test signal scoping for threads")
[mic: Add clang-format markups] Signed-off-by: Mickaël Salaün <mic@digikod.net>
Following commit 99df2a8eba34 ("clang-format: fix formatting of guard()
and scoped_guard() statements"), update scoped_guard() formatting.
Also, see the related fix [1].
landlock: Fix kernel-doc for the nested quiet layer flag
kernel-doc emits "Excess struct member 'quiet' description in
'landlock_layer'" because "quiet" is a bitfield inside the named nested
struct "flags", but its inline comment used the bare member name
"@quiet:", which kernel-doc attributes to the enclosing landlock_layer.
Use the canonical dotted notation "@flags.quiet:" so kernel-doc resolves
the nested member, and include it in the generated documentation.
Cc: Justin Suess <utilityemal77@gmail.com> Cc: Tingmao Wang <m@maowtm.org> Fixes: a260c0055665 ("landlock: Add a place for flags to layer rules") Link: https://patch.msgid.link/20260703141711.2016964-1-mic@digikod.net Signed-off-by: Mickaël Salaün <mic@digikod.net>
Enforce that TCP Fast Open is controlled by
LANDLOCK_ACCESS_NET_CONNECT_TCP. Semantics of connect() and
sendmsg(MSG_FASTOPEN) should be identical from Landlock's perspective.
Also enforce error code consistency, since UDP sockets ignore the
MSG_FASTOPEN flag while Unix sockets reject it.
The documentation of the socket_connect() LSM hook states that it
controls connecting a socket to a remote address. It has not been the
case since the addition of TCP Fast Open (RFC 7413) support, which
allows opening a TCP connection (thus, setting a socket's destination
address) via the MSG_FASTOPEN flag passed to
sendto()/sendmsg()/sendmmsg(). The problem then got duplicated into
MPTCP.
Landlock did not take it into account when its TCP support was added,
leaving a bypass of TCP connect policy.
Ideally a call to the LSM hook would be added in the fastopen code path,
in order to fix this generically. But connect() hooks are designed to
run with the socket locked, unlike sendmsg() hooks.
Closes: https://github.com/landlock-lsm/linux/issues/41 Fixes: fff69fb03dde ("landlock: Support network rules with TCP bind and connect") Signed-off-by: Matthieu Buffet <matthieu@buffet.re> Link: https://patch.msgid.link/20260701214628.33319-1-matthieu@buffet.re Cc: stable@vger.kernel.org
[mic: Wrap commit message] Signed-off-by: Mickaël Salaün <mic@digikod.net>
Lee Jia Jie [Thu, 9 Jul 2026 13:56:19 +0000 (21:56 +0800)]
perf/aux: Fix page UAF in map_range()
map_range() reads rb->aux_pages[], rb->aux_nr_pages and rb->aux_pgoff via
perf_mmap_to_page() while holding only event->mmap_mutex. Those fields are
serialized by rb->aux_mutex, and mmap_mutex is per event.
Thus, two events sharing one rb via PERF_EVENT_IOC_SET_OUTPUT can race
rb_alloc_aux() with map_range(), leading to a page-UAF scenario as follows:
CPU 0 CPU 1
===== =====
rb_alloc_aux() map_range()
[1]: allocate rb->aux_pages[0]
[2]: rb->aux_nr_pages++
[3]: perf_mmap_to_page()
returns rb->aux_pages[0]
[4]: map it as VM_PFNMAP
[5]: rb->aux_pgoff = 1
munmap the page
[6]: free rb->aux_pages[0]
Pages mapped as VM_PFNMAP have no refcount protection, so CPU 1 holds a
mapping to a freed physical frame.
Fix this by taking rb->aux_mutex across the page walk in map_range().
Fixes: b709eb872e19 ("perf: map pages in advance") Signed-off-by: Lee Jia Jie <jiajie.lee@starlabs.sg> Signed-off-by: Ingo Molnar <mingo@kernel.org> Cc: stable@vger.kernel.org Cc: Peter Zijlstra <peterz@infradead.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Namhyung Kim <namhyung@kernel.org>
Dave Airlie [Mon, 15 Jun 2026 04:47:37 +0000 (14:47 +1000)]
nouveau/vmm: fix another SPT/LPT race
We've had an unknown Turing issue for a while with page faults since
large pages and compression.
I've got a patch series that syncs all our L2 handling with ogkm and it
made this fault happen more.
After writing a bunch of debugging patches, I spotted an invalid LPT
entry where there should have been a valid one.
A 64K MAP succeeds on a range, but a subsequent SPT put drops SPT refs
across multiple ranges,
We shouldn't assume all ranges where SPTEs go away will have the same
sparse/invalid/valid state, just iterate over each instead and do the
right thing.
Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com> Fixes: d19512f5abb1 ("nouveau/vmm: start tracking if the LPT PTE is valid. (v6)") Link: https://patch.msgid.link/20260615044737.3419585-1-airlied@gmail.com
[ Properly format commit message. - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
(cherry picked from commit d008141ed4ce924167a03d46fbce9ad1fe4efa29) Signed-off-by: Dave Airlie <airlied@redhat.com>
Dave Airlie [Fri, 10 Jul 2026 03:03:14 +0000 (13:03 +1000)]
Merge tag 'drm-misc-fixes-2026-07-09' of https://gitlab.freedesktop.org/drm/misc/kernel into drm-fixes
drm-misc-fixes for v7.2-rc3:
- Fix uaf in amdxdna mmap failure path.
- A lot of deadlocks, access races and return value fixes in amdxdna.
- Fix analogix_dp bitshifts during link training.
- Use direct label in drm_exec.
- Fix absent indirect bo handling in v3d.
- Sync on first active crtc in fb_dirty, rather than first crtc.
- Rework try_harder in the buddy allocator.
- Make imagination function static to solve compiler warning.
- Fix imagination error checking.
Dave Airlie [Fri, 10 Jul 2026 02:27:02 +0000 (12:27 +1000)]
Merge tag 'drm-intel-fixes-2026-07-09' of https://gitlab.freedesktop.org/drm/i915/kernel into drm-fixes
Fix underrun regressions on Panther Lake by reverting the recent
SCL=0 enablement for always-on VRR timing. It also includes a fix
display LT PHY SSC programming and a small set of i915 fixes
addressing NULL pointer dereferences, memory leaks and bound checks.
Merge tag 'v7.2-rc2-smb3-server-fixes' of git://git.samba.org/ksmbd
Pull smb server fixes from Steve French:
"This contains a set of SMB server fixes mostly around session setup,
multichannel/session binding, and protocol-compatible error reporting:
- Fix SID-to-id mapping so only SIDs with a valid local Unix
representation are translated, while preserving other Windows
SIDs in NT ACL xattrs
- Fix SMB3 multichannel binding across multi-round authentication,
keep the derived channel key separate from the established session
key, and enforce the 32-channel session limit
- Match Windows-compatible close timestamp behavior by coalescing
automatic write time updates smaller than 15ms
- Return STATUS_DISK_FULL for SET_INFO allocation failures caused
by ENOSPC or EFBIG
- Fix several signed SESSION_SETUP error paths so clients see the
intended server status instead of replacing it with
STATUS_ACCESS_DENIED
- Fix reauthentication on bound channels and reject different-user
channel binding with STATUS_ACCESS_DENIED
- Use the referenced session dialect/signing algorithm when
validating and signing rejected cross-dialect binding requests"
* tag 'v7.2-rc2-smb3-server-fixes' of git://git.samba.org/ksmbd:
ksmbd: use the session dialect for rejected binding signatures
ksmbd: mark rejected cross-dialect bindings as signed
ksmbd: sign rejected SMB2.1 session binding responses
ksmbd: handle channel binding with a different user
ksmbd: find bound sessions during reauthentication
ksmbd: mark invalid session responses as signed
smb/server: map SET_INFO ENOSPC to disk full
ksmbd: coalesce sub-15ms write time updates on close
ksmbd: fix multichannel binding and enforce channel limit
ksmbd: validate SID namespace before mapping IDs
cifs: Remove CIFSSMBSetPathInfoFB() fallback function
This fallback function CIFSSMBSetPathInfoFB() is called only from
CIFSSMBSetPathInfo() function. CIFSSMBSetPathInfo() is used in
smb_set_file_info() which contains all required fallback code, including
fallback via filehandle, since commit f122121796f9 ("cifs: Fix changing
times and read-only attr over SMB1 smb_set_file_info() function") and
commit 92210ccd877b ("cifs: Add fallback code path for cifs_mkdir_setinfo()").
So the CIFSSMBSetPathInfoFB() is just code duplication, which is not needed
anymore. Therefore remove it.
Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
cifs: Fix and improve cifs_is_path_accessible() function
Do not call SMBQueryInformation() command for path with SMB wildcard
characters on non-UNICODE connection because server expands wildcards.
Function cifs_is_path_accessible() needs to check if the real path exists
and must not expand wildcard characters.
Do not dynamically allocate memory for small FILE_ALL_INFO structure and
instead allocate it on the stack. This structure is allocated on stack by
all other functions.
When CAP_NT_SMBS was not negotiated then do not issue CIFSSMBQPathInfo()
command. This command returns failure by non-NT Win9x SMB servers, so there
is no need try it. The purpose of cifs_is_path_accessible() function is
just to check if the path is accessible, so SMBQueryInformation() for old
servers is enough.
Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
Xie Yuanbin [Fri, 5 Jun 2026 08:12:13 +0000 (16:12 +0800)]
mm/memory-failure: trace: change memory_failure_event to ras subsystem
Commit 97f0b1345219 ("tracing: add trace event for memory-failure")
introduced memory_failure_event in ras subsystem. commit 31807483d395
("mm/memory-failure: remove the selection of RAS") changed
memory_failure_event to memory_failure subsystem. This breaks the
backward compatibility, some user programs rely on it.
Change memory_failure_event to ras subsystem to keep backward
compatibility.
Link: https://lore.kernel.org/20260605081213.154660-1-xieyuanbin1@huawei.com Fixes: 31807483d395 ("mm/memory-failure: remove the selection of RAS") Signed-off-by: Xie Yuanbin <xieyuanbin1@huawei.com> Reported-by: Yi Lai <yi1.lai@intel.com> Reported-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Closes: https://lore.kernel.org/linux-mm/CY8PR11MB7134346A3E4BB28ECA28D6E989132@CY8PR11MB7134.namprd11.prod.outlook.com Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Reviewed-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Miaohe Lin <linmiaohe@huawei.com> Tested-by: Qiuxu Zhuo <qiuxu.zhuo@intel.com> Reviewed-by: Lance Yang <lance.yang@linux.dev> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Borislav Petkov <bp@alien8.de> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm: page_reporting: allow driver to set batch capacity
At the moment, if a virtio balloon device has a page reporting vq but its
size is < PAGE_REPORTING_CAPACITY (32), the balloon driver fails probe.
But, there's no way for host to know this value, so it can easily create a
smaller vq and suddenly adding the reporting capability to the device
makes all of the driver fail. Not pretty.
Add a capacity field to page_reporting_dev_info so drivers can control the
maximum number of pages per report batch.
In virtio-balloon, set the capacity to the reporting virtqueue size,
letting page_reporting adapt to whatever the device provides.
Capacity need not be a power of two. Code previously called out division
by PAGE_REPORTING_CAPACITY as cheap since it was a power of 2, but no
performance difference was observed with non-power-of-2 values.
If capacity is 0 or exceeds PAGE_REPORTING_CAPACITY, it defaults to
PAGE_REPORTING_CAPACITY. The 0 check and the clamping is done in
page_reporting_register(), before the reporting work is scheduled, so we
never get division by 0.
Link: https://lore.kernel.org/444c24cf39f3f3620fc90ef4695bd6b0979f4c4b.1783232420.git.mst@redhat.com Fixes: b0c504f15471 ("virtio-balloon: add support for providing free page reports to host") Signed-off-by: Michael S. Tsirkin <mst@redhat.com> Assisted-by: Claude:claude-opus-4-6 Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Gregory Price <gourry@gourry.net> Acked-by: Zi Yan <ziy@nvidia.com> Reviewed-by: Pankaj Gupta <pankaj.gupta@amd.com> Cc: Alexander Duyck <alexander.h.duyck@linux.intel.com> Cc: Brendan Jackman <jackmanb@google.com> Cc: Eugenio Pérez <eperezma@redhat.com> Cc: Jason Wang <jasowang@redhat.com> Cc: Johannes Weiner <hannes@cmpxchg.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Cc: Xuan Zhuo <xuanzhuo@linux.alibaba.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm/kmemleak: fix checksum computation for per-cpu objects
The per-cpu object checksum folds each CPU's CRC together with XOR and
seeds every CRC with 0. Both choices make update_checksum() miss content
changes:
- XOR is self-cancelling, so equal contents on two CPUs cancel out and
simultaneous identical changes leave the checksum unchanged.
- crc32(0, ...) over all-zero content is 0, so a freshly allocated,
zeroed per-cpu area checksums to 0, matching the initial value, and
the object is never seen to change.
See discussions at [0].
When update_checksum() wrongly reports an actively modified object as
unchanged, kmemleak stops greying it for an extra scan and can report a
live per-cpu object as a leak.
Fold the per-cpu CRC as a single rolling checksum across all CPUs and
initialise the object checksum to ~0 so the first computed value always
registers as a change, even for content that hashes to 0.
reset_checksum() is seeded the same way.
SJ Park [Fri, 3 Jul 2026 16:56:08 +0000 (09:56 -0700)]
mm/damon/core: disallow overlapping input ranges for damon_set_regions()
damon_set_regions() assumes the input ranges are sorted by the address and
don't overlap each other. Hence the assumption was initially to be
explicitly validated. But commit 97d482f4592f ("mm/damon/sysfs: reuse
damon_set_regions() for regions setting") has mistakenly removed the
validation.
This can make DAMON behave in unexpected ways. At the best, the
monitoring results snapshot will just look weird since there will be
overlapping regions. DAMOS will also work weirdly, applying the same
action multiple times for overlapping regions, and make DAMOS quota weird.
More seriously, depending on the setup and regions updates sequence,
negative size regions can be made. It will trigger WARN_ONCE() if the
kernel is built with CONFIG_DAMON_DEBUG_SANITY=y. Depending on the
monitoring results, the negative size region can further trigger division
by zero in damon_merge_two_regions().
Note that some of the consequences including the WARN_ONCE() and the
divide by zero depend on commits that were introduced after the root cause
commit 97d482f4592f ("mm/damon/sysfs: reuse damon_set_regions() for
regions setting").
Fix the problems by checking the assumption and returning an error if
the input ranges don't meet the assumption.
Lance Yang [Thu, 2 Jul 2026 14:02:57 +0000 (22:02 +0800)]
MAINTAINERS: add Usama as a THP reviewer
Usama has been active around THP, really enjoys working on THPs, and tries
to review all the patches that come in.
Let's invite him to the THP party as a reviewer to help with the ongoing
THP review load.
Link: https://lore.kernel.org/20260702140257.44780-1-lance.yang@linux.dev Signed-off-by: Lance Yang <lance.yang@linux.dev> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Acked-by: Lorenzo Stoakes <ljs@kernel.org> Acked-by: Zi Yan <ziy@nvidia.com> Acked-by: Barry Song <baohua@kernel.org> Acked-by: SJ Park <sj@kernel.org> Acked-by: Baolin Wang <baolin.wang@linux.alibaba.com> Cc: Dev Jain <dev.jain@arm.com> Cc: Liam R. Howlett <liam@infradead.org> Cc: Nico Pache <npache@redhat.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Zi Yan <ziy@nvidia.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Arnd Bergmann [Fri, 15 May 2026 20:44:46 +0000 (22:44 +0200)]
fat: avoid stack overflow warning
Building the fat kunit tests on with -fsanitize=alignment reveals some
rather excessive stack usage:
fs/fat/fat_test.c: In function 'fat_clus_to_blknr_test':
fs/fat/fat_test.c:33:1: error: the frame size of 4736 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
33 | }
| ^
fs/fat/fat_test.c: In function 'fat_get_blknr_offset_test':
fs/fat/fat_test.c:52:1: error: the frame size of 4800 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]
The problem is clearly related to the on-stack copy of a local
msdos_sb_info structure. Avoid this by making that copy 'static const'
and changing the called functions to accept a constant input.
Link: https://lore.kernel.org/20260515204456.2692208-1-arnd@kernel.org Fixes: 410002f8139c ("kunit: fat: test cluster and directory i_pos layout helpers") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Acked-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp> Cc: Christian Brauner <brauner@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: Adi Nata <adinata.softwareengineer@gmail.com> Cc: David Laight <david.laight.linux@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
SJ Park [Tue, 30 Jun 2026 03:52:19 +0000 (20:52 -0700)]
mm/damon/core: validate ranges in damon_set_regions()
DAMON core logic assumes zero length regions don't exist. However, a few
DAMON API callers including DAMON_SYSFS, DAMON_RECLAIM and DAMON_LRU_SORT
allow users to set empty monitoring target regions. This could result in
WARN_ONCE() on CONFIG_DAMON_DEBUG_SANITY enabled kernel, and
divide-by-zero from damon_merge_two_regions().
For example, the WANR_ONCE() can be triggered like below.
Thomas Weißschuh [Mon, 25 May 2026 08:33:52 +0000 (10:33 +0200)]
m68k: avoid -Wunused-but-set-parameter in clear_user_page()
The loop in clear_user_pages() iterates over all pages and calls
clear_user_page() for each of them. During the loop "vaddr" is modified.
However on m68k clear_user() is a macro which does not use "vaddr". The
compiler sees a variable which is modified but never used and emits a
warning for that:
include/linux/highmem.h: In function 'clear_user_pages':
include/linux/highmem.h:234:63: warning: parameter 'vaddr' set but not used [-Wunused-but-set-parameter=]
static inline void clear_user_pages(void *addr, unsigned long vaddr,
Other architectures use an inline function for clear_user_page() which
avoids the warning. This is not possible on m68k, as dlush_dcache_page()
is another macro which is not yet defined where clear_user_page() is
defined. Including cacheflush_mm.h will trigger recursive and lots of
other issues.
So hide the warning with a cast to (void) instead.
While we are here, do the same for copy_user_page().
Link: https://lore.kernel.org/20260525-m68k-clear_user_page-v2-1-0c8981c6eca1@weissschuh.net Fixes: 62a9f5a85b98 ("mm: introduce clear_pages() and clear_user_pages()") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Andreas Schwab <schwab@linux-m68k.org> Cc: Ankur Arora <ankur.a.arora@oracle.com> Cc: David Hildenbrand <david@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm/huge_memory: set PG_has_hwpoisoned only after new folio head is established
__split_folio_to_order() copies the hwpoison state onto each new sub-folio
while splitting a folio to a non-zero order. It does so via
if (handle_hwpoison && page_range_has_hwpoisoned(new_head, new_nr_pages))
folio_set_has_hwpoisoned(new_folio);
*before* clear_compound_head(new_head)/prep_compound_page(new_head, ...)
turns @new_head from a tail page into a proper folio head.
PG_has_hwpoisoned is a FOLIO_SECOND_PAGE flag, so
folio_set_has_hwpoisoned() resolves to folio_flags(folio, 1). With the
new compound_info-based page-flags layout, folio_flags() asserts the page
is not a tail:
Reproduced by syzkaller: hwpoison-inject a few subpages of a large shmem
folio, then MADV_REMOVE (fallocate punch hole) on the same range, which
splits the partial folio to a non-zero order.
memory_failure() tries to split the poisoned folio to order 0 first, but
that split is best-effort; when it fails the folio is left large with
PG_has_hwpoisoned set, the case fa5a06170036 added this hwpoison copying
for.
Move the folio_set_has_hwpoisoned() call to after
clear_compound_head()/prep_compound_page(), where @new_folio is a real
order-new_order head folio (handle_hwpoison implies new_order != 0, so a
second page always exists). The flag still lands on the same struct page
(page[1] of the new folio); only the ordering relative to compound-head
setup changes, satisfying the FOLIO_SECOND_PAGE precondition.
Link: https://lore.kernel.org/20260701174235.3173401-1-riel@surriel.com Fixes: fa5a06170036 ("mm/huge_memory: preserve PG_has_hwpoisoned if a folio is split to >0 order") Signed-off-by: Rik van Riel <riel@surriel.com> Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Zi Yan <ziy@nvidia.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Tested-by: Lance Yang <lance.yang@linux.dev> Reviewed-by: Lorenzo Stoakes <ljs@kernel.org> Reviewed-by: 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: Nico Pache <npache@redhat.com> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Yang Shi <yang@os.amperecomputing.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Commit 65edfda6f3f2 ("mm/rmap: extend rmap and migration support
device-private entries") introduced the concept of device-private PMD
entries, but did not correctly update the rmap walk code to account for
them.
As a result, when page_vma_mapped_walk() encounters device-private PMD
entries, it takes no action other than to acquire the PMD lock and exit.
However this is highly problematic for two reasons - firstly, device
private entries possess a PFN so check_pmd() needs to be called to ensure
an overlapping PFN range.
Secondly, and more importantly, if PVMW_MIGRATION is set the caller
assumes the returned entry is a migration entry, resulting in memory
corruption when the caller tries to interpret the device private entry as
such.
In addition, commit 146287290023 ("mm/huge_memory: implement
device-private THP splitting") allowed device private PMDs to be split
like THP mappings, but again did not update this code path.
As a result, we might race a PMD split prior to acquiring the PMD lock.
This patch addresses all of these issues by invoking check_pmd(), ensuring
PMVW_MIGRATION is not set and checks whether a split raced us we do for
PMD THP and migration entries.
Instead of checking for a subset of the cases after taking the pmd_lock(),
put device-private along with pmd_trans_huge() and
pmd_is_migration_entry(). Also remove thp_migration_supported() as it is
already guarded by pmd_is_migration_entry().
[akpm@linux-foundation.org: fix Raspberry Pi 1 build, per David] Link: https://lore.kernel.org/20260630021540.17297-1-richard.weiyang@gmail.com Fixes: 65edfda6f3f2 ("mm/rmap: extend rmap and migration support device-private entries") Signed-off-by: Wei Yang <richard.weiyang@gmail.com> Suggested-by: David Hildenbrand <david@kernel.org> Reviewed-by: Lance Yang <lance.yang@linux.dev> Acked-by: Balbir Singh <balbirs@nvidia.com> Tested-by: Klara Modin <klarasmodin@gmail.com> Cc: SeongJae Park <sj@kernel.org> Cc: Zi Yan <ziy@nvidia.com> Cc: Lorenzo Stoakes <ljs@kernel.org> Cc: <stable@vger.kernel.org>q Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
SJ Park [Tue, 30 Jun 2026 01:38:18 +0000 (18:38 -0700)]
MAINTAINERS: s/SeongJae/SJ/
My legal and preferred first names are SeongJae and SJ, respectively. I
was using the legal name for commits and tags, while using the preferred
name for conversations. It sometimes confuses people including myself.
Consistently use the preferred name.
Together remove copyright notes on files. Those are only confusing for
people who are not familiar with the law. Meanwhile, we can infer the
information in a better way from git logs and public information.
Link: https://lore.kernel.org/20260630013820.143366-1-sj@kernel.org Signed-off-by: SJ Park <sj@kernel.org> Acked-by: Lorenzo Stoakes <ljs@kernel.org> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Cc: Liam R. Howlett <liam@infradead.org> Cc: Michal Hocko <mhocko@suse.com> Cc: Mike Rapoport <rppt@kernel.org> Cc: Suren Baghdasaryan <surenb@google.com> Cc: Vlastimil Babka <vbabka@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
userfaultfd allows registration on shadow stack VMAs. With userfaultfd
access, you can register on the shadow stack, discard a page ... and
inject a page with chosen return addresses via UFFDIO_COPY.
Update vma_can_userfault() to reject VM_SHADOW_STACK.
While on it, also reject VM_SPECIAL so that if a driver would implement
vm_uffd_ops, it wouldn't be possible to register special VMAs with
userfaultfd.
Since VM_SPECIAL includes VM_DONTEXPAND which is set but hugetlb, exclude
hugetlb VMAs from the check for VM_SPECIAL.
Link: https://lore.kernel.org/20260618095017.2553004-1-rppt@kernel.org Fixes: 54007f818206 ("mm: Introduce VM_SHADOW_STACK for shadow stack memory") Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Reported-by: vova tokarev <vladimirelitokarev@gmail.com> Acked-by: David Hildenbrand (Arm) <david@kernel.org> Reviewed-by: Lorenzo Stoakes <ljs@kernel.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christian Brauner <brauner@kernel.org> Cc: Jan Kara <jack@suse.cz> Cc: Linus Torvalds <torvalds@linuxfoundation.org> Cc: Mike Rapoport <rppt@kernel.org> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Peter Xu <peterx@redhat.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
xen-blkfront: fix double completion of split requests on resume
When a block request is too large for a single ring entry and the
backend does not support indirect descriptors, blkfront splits it across
two ring requests. This only happens when the frontend runs on a
64K-page kernel (e.g. arm64): there, even a single-page request may not
fit in one ring slot and must be split. blkif_ring_get_request() is
called twice and both shadow slots (shadow[id] and shadow[extra_id])
point at the *same* struct request, linked through associated_id.
blkif_completion() collapses the pair on the normal completion path,
recycling the second slot and completing the request once. The
suspend/resume walk in blkfront_resume() does not: it visits every
shadow slot with ->request set and calls blk_mq_end_request() or
re-queues ->request. For an in-flight split request it therefore
processes the shared struct request twice on resume/migration -- a
double completion.
Skip the secondary slot of a split request in the resume walk so each
logical request is processed exactly once. The secondary slot is the
linked one (associated_id != NO_ASSOCIATED_ID) that carries no
scatter-gather list (num_sg == 0); the first slot always keeps the sg
list. The bug is only reachable on suspend/resume or live migration of
such a guest, so it has no local reproducer.
Fixes: 6cc568339047 ("xen/blkfront: Handle non-indirect grant with 64KB pages") Assisted-by: 0sec:claude-opus-4-8 Signed-off-by: Doruk Tan Ozturk <doruk@0sec.ai> Acked-by: Roger Pau Monné <roger.pau@citrix.com> Link: https://patch.msgid.link/20260709100853.7489-1-doruk@0sec.ai Signed-off-by: Jens Axboe <axboe@kernel.dk>
Starting with rustc 1.88, the `clippy::unwrap_or_default` lint triggers
on `rust/kernel/soc.rs` if `CONFIG_CC_OPTIMIZE_FOR_SIZE=y`:
warning: use of `unwrap_or` to construct default value
--> ../rust/kernel/soc.rs:66:10
|
66 | .unwrap_or(core::ptr::null())
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: try: `unwrap_or_default()`
This is a clippy bug [1]: the lint decides whether an expression is
equivalent to `Default::default()` by inspecting the optimized MIR of
`<*const T as Default>::default` exported by `core`, so its outcome
depends on the optimization level `core` was built with. Moreover, its
suggestion ignores our MSRV of 1.85 (`Default` for `*const T` is only
stable since Rust 1.88), so we could not apply it anyway.
Disable the lint globally rather than working around this single
occurrence; it can be re-enabled conditionally using `rustc-min-version`
once clippy is fixed.
tools/sched_ext: scx - Fix cmask_subset(), cmask_equal() and cmask_weight()
cmask_equal(), cmask_weight() and cmask_subset() bounded their word walks
with CMASK_NR_WORDS(nr_cids), which pads by one word and can't tell the last
word in use without @base. The walks could thus cover a slack word past the
active range, which cmask_reframe() leaves non-zero: a stale bit there gave
cmask_equal() a spurious mismatch, cmask_weight() an inflated count, and
cmask_subset() a spurious violation. cmask_subset() could also read
@b->bits[] one word past its allocation (within the arena's fault-recovered
range, so harmless), and deviated from the kernel scx_cmask_subset() by
failing any @a range that doesn't nest inside @b's even when the overhanging
bits are all clear.
Bound the cmask_equal() and cmask_weight() walks by the words the range
actually spans, with early returns for empty ranges. Rewrite cmask_subset()
to match the kernel semantics: scan @a's overhangs for set bits with
cmask_next_set() and walk the words of the range intersection.
cmask_subset() moves below cmask_next_set(), which it now uses. Padding bits
don't need masking as every cmask helper keeps them clear.
Fixes: a58e6b79b432 ("sched_ext: Add cmask, a base-windowed bitmap over cid space") Signed-off-by: Tejun Heo <tj@kernel.org> Reviewed-by: Andrea Righi <arighi@nvidia.com>
sched_ext: Fix premature ops->priv publication in scx_alloc_and_add_sched()
scx_alloc_and_add_sched() publishes @sch through ops->priv before allocating
the cgroup path. If that allocation fails, the unwind path clears ops->priv
and frees @sch immediately. scx_prog_sched() callers can dereference
ops->priv from RCU context the moment it is set, so freeing without a grace
period can use-after-free a concurrent kfunc caller.
Move the publication below the cgroup path allocation so that every failure
path after publication frees @sch through kobject_put(), whose release path
defers the freeing by a grace period.
sched_ext: Record an error on errno-only sub-enable failure
scx_sub_enable_workfn() has several failure paths that only return an errno
(e.g. -ENOMEM from an allocation) and jump to err_disable without calling
scx_error(). scx_flush_disable_work() runs the disable, and thus ops.exit(),
only when an error has been recorded, so an errno-only failure leaves the
half-initialized sub-scheduler linked.
Record an error at the err_disable sink so every errno-only failure runs the
disable path.
cpufreq: Make cpufreq_update_pressure() fall back to cpuinfo.max_freq
If arch_scale_freq_ref() is not defined for a given arch (like x86, for
example), cpufreq_update_pressure() will always set cpufreq_pressure to
zero for all CPUs in the system, which is generally problematic on
systems with asymmetric capacity [1].
However, in the absence of arch_scale_freq_ref(), it is reasonable
to assume that cpuinfo.max_freq is the maximum sustainable frequency
for the given cpufreq policy. Moreover, there are cases in which
arch_scale_freq_ref() would need to be defined to return essentially
the cpuinfo.max_freq value anyway (for example, intel_pstate on
hybrid platforms).
For the above reasons, update cpufreq_update_pressure() to fall back to
using cpuinfo.max_freq as the reference frequency if zero is returned by
arch_scale_freq_ref().
cpufreq: intel_pstate: Set non-turbo capacity to HWP_GUARANTEED_PERF()
Setting cpu->capacity_perf to cpu->pstate.max_pstate_physical in the
"no turbo" case is inconsistent with what happens elsewhere in the
driver and causes arch_scale_cpu_capacity() to be incorrect. It also
skews arch_scale_freq_capacity() which ends up differing from 1024 for
the guaranteed P-state.
Address that by setting capacity_perf to HWP_GUARANTEED_PERF() in the
"no turbo" case.
Fixes: 929ebc93ccaa ("cpufreq: intel_pstate: Set asymmetric CPU capacity on hybrid systems") Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com> Cc: All applicable <stable@vger.kernel.org> Link: https://patch.msgid.link/12928972.O9o76ZdvQC@rafael.j.wysocki
648790e09527 ("io_uring: restore RCU read section in io_req_local_work_add()")
io_ctx_mark_taskrun() is only ever called with the RCU read lock
already held, like previously. Hence's there's no need for this commit
anymore, which grabbed the RCU read lock inside io_ctx_mark_taskrun().
projects / thirdparty / linux.git / log
