David Windsor [Fri, 5 Jun 2026 14:57:07 +0000 (10:57 -0400)]
bpf: Reject sleepable BPF_LSM_CGROUP programs at load time
The cgroup shim runs under rcu_read_lock_dont_migrate(), so we should
not attach any sleepable BPF programs there. Add support to the verifier
to explicitly reject attempts to load sleepable BPF programs destined
for LSM cgroup attachment.
Without this, we get the following splat from a BPF_LSM_CGROUP
program marked BPF_F_SLEEPABLE attached to file_open when it calls
bpf_get_dentry_xattr():
libbpf provides a .s named section variant for every sleepable
program type except lsm_cgroup, reflecting that per-cgroup LSM programs
are intended to only run in a non-sleepable context.
The above splat was obtained by bypassing libbpf by using bpf(2)
directly.
Fixes: 69fd337a975c ("bpf: per-cgroup lsm flavor") Signed-off-by: David Windsor <dwindsor@gmail.com> Acked-by: Yonghong Song <yonghong.song@linux.dev> Acked-by: Song Liu <song@kernel.org> Link: https://lore.kernel.org/bpf/20260605145707.608579-1-dwindsor@gmail.com Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com>
riscv: alternative: Pass vDSO start as parameter to apply_vdso_alternatives()
The dedicated vDSO with CFI should also be patched in the same way.
To prepare for that move the currently hardcoded vDSO start symbol
into a parameter.
Make the declarations of vdso_start and its related symbols always
visible. With that their users don't have to use ifdeffery but can
use the better IS_ENABLED() compile-time checks.
Kyle Zeng [Sun, 7 Jun 2026 00:41:29 +0000 (17:41 -0700)]
ALSA: seq: Clear variable event pointer on read
snd_seq_read() copies a queued variable-length event header to userspace
before expanding the payload. Queued variable-length events use
SNDRV_SEQ_EXT_CHAINED internally, and data.ext.ptr points at the first
extension cell.
The read side strips SNDRV_SEQ_EXT_* bits from data.ext.len before the
copy, but it leaves data.ext.ptr untouched. A userspace sequencer client
can therefore write a direct variable event to itself and read back the
extension-cell kernel address from the returned header.
Clear the temporary header pointer before copy_to_user(). The original
queued event remains unchanged and is still passed to
snd_seq_expand_var_event(), so payload expansion keeps using the
internal chain.
Takashi Iwai [Sat, 6 Jun 2026 16:11:41 +0000 (18:11 +0200)]
ALSA: timer: Fix UAF at snd_timer_user_params()
At releasing a timer object, e.g. when a userspace timer
(CONFIG_SND_UTIMER) gets closed and snd_timer_free() is called, it
tries to detach the timer instances and release the resources.
However, it's still possible that other in-flight tasks are holding
the timer instance where the to-be-deleted timer object is associated,
and this may lead to racy accesses.
Fortunately, most of ioctls dealing with the timer instance list
already have the protection with register_mutex, and this also avoids
such races. But, SNDRV_TIMER_IOCTL_PARAMS isn't protected, hence the
concurrent ioctl may lead to use-after-free.
This patch just adds the guard with register_mutex to protect
snd_timer_user_params() for covering the code path as a quick
workaround. It's no hot-path but rather a rarely issued ioctl, so the
performance penalty doesn't matter.
Takashi Iwai [Sat, 6 Jun 2026 16:11:40 +0000 (18:11 +0200)]
ALSA: timer: Forcibly close timer instances at closing
When snd_timer object is freed via snd_timer_free() and still pending
snd_timer_instance objects are assigned to the timer object, it tries
to unlink all instances and just set NULL to each ti->timer, then
releases the resources immediately. The problem is, however, when
there are slave timer instances that are associated with a master
instance linked to this timer: namely, those slave instances still
point to the freed timer object although the master instance is
unlinked, which may lead to user-after-free. The bug can be easily
triggered particularly when a new userspace-driven timers
(CONFIG_SND_UTIMER) is involved, since it can create and delete the
timer object via a simple file open/close, while the other
applications may keep accessing to that timer.
This patch is an attempt to paper over the problem above: now instead
of just unlinking, call snd_timer_close[_locked]() forcibly for each
pending timer instance, so that all assigned slave timer instances are
properly detached, too. Since snd_timer_close() might be called later
by the driver that created that instance, the check of
SNDRV_TIMER_IFLG_DEAD is added at the beginning, too.
Wu Fei [Thu, 4 Jun 2026 23:03:15 +0000 (07:03 +0800)]
RISC-V: KVM: Fix skip of valid pages in kvm_riscv_gstage_unmap_range
Same as kvm_riscv_gstage_wp_range, the possible valid pages should not
be skipped if !found_leaf. Different from wp case, which can
write-protect more than asked, unmap can't do that, no splitting is
added right now but a warning is logged instead.
Wu Fei [Thu, 4 Jun 2026 23:03:14 +0000 (07:03 +0800)]
RISC-V: KVM: Fix skip of valid pages in kvm_riscv_gstage_wp_range
The current gstage range walker unconditionally advances by 'page_size'
when a leaf PTE is not found, e.g. when the range to wp is
[0xfffff01fc000, 0xfffff023c000) and page_size is 2MB, if found_leaf of
0xfffff01fc000 returns false, it skip the whole range, but it's possible
to have valid entries in [0xfffff0200000, 0xfffff023c000).
Vivian Wang [Tue, 3 Mar 2026 05:29:49 +0000 (13:29 +0800)]
riscv: mm: Unconditionally sfence.vma for spurious fault
Svvptc does not guarantee that it's safe to just return here. Since we
have already cleared our bit, if, theoretically, the bounded timeframe
for the accessed page to become valid still hasn't happened after sret,
we could fault again and actually crash.
Hopefully, these spurious faults should be rare enough that this is an
acceptable slowdown.
Vivian Wang [Tue, 3 Mar 2026 05:29:48 +0000 (13:29 +0800)]
riscv: mm: Use the bitmap API for new_valid_map_cpus
The bitmap was defined with incorrect size. Fix it by using the proper
bitmap API in C code. The corresponding assembly code is still okay and
remains unchanged.
Vivian Wang [Tue, 3 Mar 2026 05:29:47 +0000 (13:29 +0800)]
riscv: mm: Rename new_vmalloc into new_valid_map_cpus
Since this mechanism is now used for the kfence pool, which comes from
the linear mapping and not vmalloc, rename new_vmalloc into
new_valid_map_cpus to avoid misleading readers.
Vivian Wang [Tue, 3 Mar 2026 05:29:46 +0000 (13:29 +0800)]
riscv: kfence: Call mark_new_valid_map() for kfence_unprotect()
In kfence_protect_page(), which kfence_unprotect() calls, we cannot send
IPIs to other CPUs to ask them to flush TLB. This may lead to those CPUs
spuriously faulting on a recently allocated kfence object despite it
being valid, leading to false positive use-after-free reports.
Fix this by calling mark_new_valid_map() so that the page fault handling
code path notices the spurious fault and flushes TLB then retries the
access.
Update the comment in handle_exception to indicate that
new_valid_map_cpus_check also handles kfence_unprotect() spurious
faults.
Note that kfence_protect() has the same stale TLB entries problem, but
that leads to false negatives, which is fine with kfence.
Rui Qi [Sun, 7 Jun 2026 02:17:59 +0000 (20:17 -0600)]
riscv: stacktrace: Remove bogus -0x4 offset in non-FP walk_stackframe
In the non-frame-pointer version of walk_stackframe, each value read
from the stack is treated as a potential return address and has 0x4
subtracted before being used as the program counter. This was intended
to convert the return address (the instruction after a call) back to
the call site, but it is incorrect:
1. RISC-V has variable-length instructions due to the RVC (compressed
instruction) extension. A call instruction can be either 4 bytes
(regular) or 2 bytes (compressed, e.g. c.jal). Subtracting a fixed
0x4 assumes all call instructions are 4 bytes, which is wrong for
compressed instructions.
2. Stack traces conventionally report return addresses, not call sites.
Other architectures (ARM64, x86, ARM) do not subtract instruction
size from return addresses in their stack unwinding code.
3. The frame-pointer version of walk_stackframe already dropped the
-0x4 offset. Commit b785ec129bd9 ("riscv/ftrace: Add
HAVE_FUNCTION_GRAPH_RET_ADDR_PTR support") replaced "pc =
frame->ra - 0x4" with ftrace_graph_ret_addr(), and the commit
message explicitly noted that "the original calculation, pc =
frame->ra - 4, is buggy when the instruction at the return address
happened to be a compressed inst." The non-FP version was simply
overlooked.
Remove the bogus -0x4 offset to match the FP version and the
conventions used by other architectures.
Zishun Yi [Sun, 7 Jun 2026 02:17:58 +0000 (20:17 -0600)]
riscv: cacheinfo: Fix node reference leak in populate_cache_leaves
Currently, the while loop drops the reference to prev in each iteration.
If the loop terminates early due to a break, the final of_node_put(np)
correctly drops the reference to the current node.
However, if the loop terminates naturally because np == NULL, calling
of_node_put(np) is a no-op. This leaves the last valid node stored in
prev without its reference dropped, resulting in a node reference leak.
Fix this by changing the final `of_node_put(np)` to `of_node_put(prev)`.
Fixes: 94f9bf118f1e ("RISC-V: Fix of_node_* refcount") Cc: stable@vger.kernel.org Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Zishun Yi <vulab@iscas.ac.cn> Link: https://patch.msgid.link/20260509074040.1747800-1-vulab@iscas.ac.cn Signed-off-by: Paul Walmsley <pjw@kernel.org>
Han Gao [Sun, 7 Jun 2026 02:17:58 +0000 (20:17 -0600)]
riscv: kexec_file: Constrain segment placement to direct map
When kexec_file_load places segments with buf_max=ULONG_MAX and
top_down=true, they land at the highest available physical addresses.
On RISC-V the size of the linear mapping is determined by the active
VM mode: SV39 caps the direct map at roughly 128GB, while SV48/SV57
extend the range substantially further. When the installed physical
memory exceeds the direct map size of the active mode, top-down
placement puts DTB/initrd at physical addresses outside the linearly
mapped region. The kexec'd kernel cannot reach them during early
boot, triggering a page fault at memcmp in start_kernel.
Fix by constraining buf_max to PFN_PHYS(max_low_pfn), which reflects
the runtime direct map boundary for the active VM mode (SV39/SV48/
SV57). This keeps all kexec segments within the linearly mapped
region while preserving the upstream top_down allocation strategy.
Vivian Wang [Sun, 7 Jun 2026 02:17:54 +0000 (20:17 -0600)]
riscv: mm: Define DIRECT_MAP_PHYSMEM_END
On RISC-V, the actual mappable range of physical address space is
dependent on the current MMU mode i.e. satp_mode (See
Documentation/arch/riscv/vm-layout.rst).
Define the DIRECT_MAP_PHYSMEM_END macro based on the existing virtual
address space layout macros to expose this information to
get_free_mem_region(). Otherwise, it returns a region that couldn't be
mapped, which breaks ZONE_DEVICE.
Hui Wang [Sun, 7 Jun 2026 02:17:54 +0000 (20:17 -0600)]
riscv: cpu_ops_sbi: No need to be bothered to check ret.error
If the ret.error equals to 0, the sbi_err_map_linux_errno() can also
handle it, i.e. if ret.error is SBI_SUCCESS, it will return 0
immediately, so no need to be bothered to check ret.error here.
Hui Wang [Sun, 7 Jun 2026 02:17:54 +0000 (20:17 -0600)]
riscv: cpu_ops: Change return value type of cpu_is_stopped() to bool
In the original sbi_cpu_is_stopped(), if rc doesn't equal to the
SBI_HSM_STATE_STOPPED, it will return rc to the caller directly. But
there is a hidden problem, the rc could be SBI_HSM_STATE_STARTED, if
so, this function will report cpu stopped while the cpu isn't really
stopped.
Furthermore, from the name of cpu_is_stopped(), it gives a sense the
return value is a bool type, true means the cpu is stopped, conversely
false means the cpu is not stopped.
Here change the return value type to bool and change the callers
accordingly. This could fix the above two issues.
Fixes: f1e58583b9c7c ("RISC-V: Support cpu hotplug") Signed-off-by: Hui Wang <hui.wang@canonical.com> Link: https://patch.msgid.link/20260413123515.48423-1-hui.wang@canonical.com
[pjw@kernel.org: cleaned up some of the pr_warn() messages] Signed-off-by: Paul Walmsley <pjw@kernel.org>
Hui Wang [Sun, 7 Jun 2026 02:17:53 +0000 (20:17 -0600)]
riscv: kexec_elf: Remove unused pr_fmt definition
Remove the pr_fmt macro as no pr_*() calls exist in this file. The
prefix string "kexec_image: " is also not appropriate for kexec_elf.c,
if pr_fmt is needed in the future, referring to kexec_image.c, a more
appropriate prefix like "kexec_file(elf): " can be added at that time.
Chen Pei [Sun, 7 Jun 2026 02:17:53 +0000 (20:17 -0600)]
riscv: ftrace: select HAVE_BUILDTIME_MCOUNT_SORT
RISC-V already satisfies all prerequisites for build-time mcount sorting:
the sorttable host tool handles EM_RISCV in its machine-type dispatch, and
the __mcount_loc section entries are stored as direct virtual addresses in
the final vmlinux binary, so no relocation processing is required during
the sort step.
Select HAVE_BUILDTIME_MCOUNT_SORT so that BUILDTIME_MCOUNT_SORT is
automatically enabled when DYNAMIC_FTRACE is configured. This allows
sorttable to sort the __mcount_loc section at link time, making the
run-time ftrace initialisation path skip the software sort and reducing
kernel startup overhead.
Verified with CONFIG_FTRACE_SORT_STARTUP_TEST=y, which confirms that
the section produced by the build is already in ascending order:
Julian Braha [Sun, 7 Jun 2026 02:17:53 +0000 (20:17 -0600)]
riscv: dead code cleanup in kconfig for RISCV_PROBE_VECTOR_UNALIGNED_ACCESS
The same Kconfig statement 'depends on RISCV_ISA_V' appears twice for
RISCV_PROBE_VECTOR_UNALIGNED_ACCESS. The first instance is in its choice
menu, "Vector unaligned Accesses Support", making the second instance in
its specific Kconfig definition dead code. I propose removing this second
instance.
This dead code was found by kconfirm, a static analysis tool for Kconfig.
Julian Braha [Sun, 3 May 2026 04:03:31 +0000 (05:03 +0100)]
riscv: replace select with dependency for visible RELOCATABLE
RANDOMIZE_BASE currently selects RELOCATABLE even though RELOCATABLE
is visible to users. Some other architectures, like x86, use 'depends on'
for RELOCATABLE in their definition of RANDOMIZE_BASE, so let's do the same
here.
This select-visible Kconfig misusage was detected by Kconfirm, a static
analysis tool for Kconfig.
Jinyu Tang [Thu, 4 Jun 2026 14:26:02 +0000 (22:26 +0800)]
KVM: selftests: Add a hugetlb memslot alignment test mode
kvm_page_table_test can already exercise hugetlb-backed guest memory,
but it always creates the test memslot with GPA alignment matching the
hugetlb backing size. That misses the case where a valid hugetlb
memslot is later moved so that the memslot GPA and HVA no longer have
the same offset within the backing huge page.
Add a -u option that moves the test memslot GPA by one guest page after
creating the hugetlb memslot. The memslot is created through the normal
helper first, so the backing allocation remains valid and hugetlb aligned.
Moving the memslot then creates a deliberate HVA/GPA offset mismatch
before the guest mapping is installed.
This mode is useful for checking that architecture MMUs do not install
a block mapping when the block would map the wrong host pages or cover
memory outside the memslot. The option is restricted to hugetlb-backed
test memory because it's specifically about hugetlb block mapping
eligibility.
docs: memfd_preservation: fix rendering of ABI documentation
The "memfd Live Update ABI" section in include/linux/kho/abi/memfd.h
currently does not render in the exported documentation. This is because
it should not include the "DOC:" in its reference. Drop it to ensure
correct rendering. Tested by running make htmldocs.
Fixes: 15fc11bb2cb6 ("docs: add documentation for memfd preservation via LUO") Signed-off-by: Pratyush Yadav (Google) <pratyush@kernel.org> Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20260605160645.3650271-1-pratyush@kernel.org Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Jinyu Tang [Thu, 4 Jun 2026 14:26:01 +0000 (22:26 +0800)]
KVM: riscv: Check hugetlb block mappings against memslot bounds
RISC-V KVM has used the hugetlb VMA size directly as the G-stage
mapping size since stage-2 page table support was added. That is safe
only if the block covered by the fault is fully contained in the
memslot and the userspace address has the same offset as the GPA
within that block.
The THP path already checks those constraints before installing a PMD
block mapping. The hugetlb path did not, so an unaligned memslot could
make KVM install a PMD or PUD sized G-stage block that covers memory
outside the slot or maps the wrong host pages.
Pass the target mapping size into fault_supports_gstage_huge_mapping().
The same helper can be used for both THP PMD mappings and hugetlb
PMD/PUD mappings.
Select hugetlb mapping sizes through the same memslot-boundary check,
falling back from PUD to PMD to PAGE_SIZE. When a smaller hugetlb
mapping size is selected, fault the GFN aligned to that selected size
instead of the original VMA size.
Also keep hugetlb mappings out of transparent_hugepage_adjust(). Once
the hugetlb path has chosen PAGE_SIZE, promoting it again through the
THP helper would miss the hugetlb fallback decision.
Dmitry Torokhov [Sat, 23 May 2026 04:42:39 +0000 (21:42 -0700)]
Input: ims-pcu - fix potential infinite loop in CDC union descriptor parsing
The driver parses CDC union descriptors in ims_pcu_get_cdc_union_desc()
by iterating through the extra descriptor data. However, it does not
verify that the bLength of each descriptor is at least 2. A malicious
device could provide a descriptor with bLength = 0, leading to an
infinite loop in the driver.
Add a check to ensure bLength is at least 2 before proceeding with
parsing.
Fixes: 628329d52474 (Input: add IMS Passenger Control Unit driver) Cc: stable@vger.kernel.org Assisted-by: Gemini:gemini-3.1-pro Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Dmitry Torokhov [Fri, 22 May 2026 17:40:54 +0000 (10:40 -0700)]
Input: ims-pcu - add response length checks
The driver processes response data from device buffers without verifying
that the device actually sent enough data. This can lead to
out-of-bounds reads or processing stale data.
Add checks for the expected response length before accessing the
buffers.
Dmitry Torokhov [Fri, 22 May 2026 17:30:44 +0000 (10:30 -0700)]
Input: ims-pcu - fix DMA mapping violation in line setup
In ims_pcu_line_setup(), the driver uses pcu->cmd_buf as a transfer
buffer for usb_control_msg(). However, pcu->cmd_buf is embedded in the
struct ims_pcu allocation, which violates DMA mapping rules regarding
cacheline alignment.
Use a heap-allocated buffer for the line coding data instead.
Dmitry Torokhov [Fri, 22 May 2026 17:30:21 +0000 (10:30 -0700)]
Input: ims-pcu - fix out-of-bounds read in ims_pcu_irq() debug logging
The debug logging in ims_pcu_irq() unconditionally prints data from
pcu->urb_in_buf. However, if the interrupt fired for pcu->urb_ctrl, the
actual data resides in pcu->urb_ctrl_buf. If urb->actual_length for the
control URB exceeds pcu->max_in_size, this leads to an out-of-bounds
read.
Fix this by printing from the correct buffer associated with the URB.
Dmitry Torokhov [Fri, 22 May 2026 17:29:26 +0000 (10:29 -0700)]
Input: ims-pcu - validate control endpoint type
The driver currently assumes that the first endpoint of the control
interface is an interrupt IN endpoint without verifying it. A malicious
device could provide a different endpoint type, which would then be
passed to usb_fill_int_urb(), potentially leading to kernel warnings
or undefined behavior.
Verify that the control endpoint is an interrupt IN endpoint.
Dmitry Torokhov [Fri, 22 May 2026 17:29:04 +0000 (10:29 -0700)]
Input: ims-pcu - fix race condition in reset_device sysfs callback
The ims_pcu_reset_device() sysfs callback calls ims_pcu_execute_command()
without acquiring pcu->cmd_mutex. This can lead to data races and
corruption of the shared command buffer if triggered concurrently with
other commands.
Acquire pcu->cmd_mutex before calling ims_pcu_execute_command().
Dmitry Torokhov [Fri, 22 May 2026 17:25:11 +0000 (10:25 -0700)]
Input: ims-pcu - fix type confusion in CDC union descriptor parsing
The driver currently trusts the bMasterInterface0 from the CDC union
descriptor without verifying that it matches the interface being
probed. This could lead to the driver overwriting the private data of
another interface.
Validate that the control interface found in the descriptor is indeed
the one we are probing.
Dmitry Torokhov [Fri, 22 May 2026 17:24:47 +0000 (10:24 -0700)]
Input: ims-pcu - fix use-after-free and double-free in disconnect
ims_pcu_disconnect() only intended to perform cleanup when the primary
(control) interface is unbound. However, it currently relies on the
interface class to distinguish between control and data interfaces.
A malicious device could present a data interface with the same class
as the control interface, leading to premature cleanup and potential
use-after-free or double-free.
Switch to verifying that the interface being disconnected is indeed
the control interface.
Dmitry Torokhov [Fri, 22 May 2026 17:29:41 +0000 (10:29 -0700)]
Input: ims-pcu - fix logic error in packet reset
ims_pcu_reset_packet() incorrectly sets have_stx to true, which implies
that the start-of-packet delimiter has already been received. This
causes the protocol parser to skip waiting for the next STX byte and
potentially process garbage data.
Correctly set have_stx to false when resetting the packet state.
Dmitry Torokhov [Mon, 1 Jun 2026 04:42:35 +0000 (21:42 -0700)]
Input: ims-pcu - only expose sysfs attributes on control interface
When the driver was converted to use the driver core to instantiate device
attributes (via .dev_groups in the usb_driver structure), the attributes
started appearing on all interfaces bound to the driver. Since the ims-pcu
driver manually claims the secondary data interface during probe, the
driver core automatically creates the sysfs attributes for that interface
as well.
However, the driver only supports these attributes on the primary control
interface. Data interfaces lack the necessary descriptors and internal
state to handle these requests, and accessing them can lead to unexpected
behavior or crashes.
Fix this by updating the is_visible() callbacks for both the main and OFN
attribute groups to verify that the interface being accessed is indeed the
control interface.
In particular, the address of a label is only expected to be used with a
computed goto.
While the generic version more or less works today, it is known to be
brittle and may break with current and future optimizations. For
example, Clang -O2 always returns 1 when this function is inlined:
Fix it by overriding _THIS_IP_ in <asm/linkage.h> (which is included by
<linux/instruction_pointer.h>) using an architecture-specific inline asm
version. Additionally, avoiding taking the address of a label prevents
compilers from emitting spurious indirect branch targets (e.g. ENDBR or
BTI) under control-flow integrity schemes.
Florian Schmaus [Sun, 7 Jun 2026 02:17:53 +0000 (20:17 -0600)]
riscv: module: Use generic cmp_int() instead of custom cmp_3way()
The module-sections.c file defines a custom cmp_3way() macro to perform
3-way comparisons during relocation sorting.
Instead of maintaining our own implementation, use the generic
cmp_int() macro provided by the already included <linux/sort.h>. This
removes redundant code and relies on standard kernel interfaces.
Rui Qi [Sun, 7 Jun 2026 02:17:53 +0000 (20:17 -0600)]
riscv: Fix ftrace_graph_ret_addr() to use the correct task pointer
The walk_stackframe() function is used to unwind the stack of a given
task. When function graph tracing is enabled, ftrace_graph_ret_addr()
is called to resolve the original return address if it was modified by
the tracer.
The current code incorrectly passes 'current' instead of 'task' to
ftrace_graph_ret_addr(). This causes incorrect return address resolution
when unwinding a stack of a different task (e.g., when the task is
blocked in __switch_to).
Fix this by passing 'task' instead of 'current' to match the behavior
of other architectures (arm64, loongarch, powerpc, s390, x86).
Zong Li [Sun, 7 Jun 2026 02:17:52 +0000 (20:17 -0600)]
selftests/riscv: fix compiler output flag spacing in all Makefiles
Standardize the compiler output flag format across all RISC-V
selftests by adding a space between '-o' and '$@'.
Although '-o$@' is perfectly valid for GCC/Clang to parse,
changing it to '-o $@' with a space aligns with the GNU
official documentation conventions, improves readability by
visually separating the flag from the target variable, and
ensures consistency with other architectures.
Currently, RISC-V selftests use '-o$@' (without space) in 13
instances across 6 Makefiles, while all other architectures
consistently use '-o $@' (with space). This inconsistency makes
RISC-V an outlier in the kernel's selftest infrastructure.
Thorsten Blum [Sun, 7 Jun 2026 02:17:52 +0000 (20:17 -0600)]
riscv: propagate insert_resource result from add_resource
Currently, add_resource() returns 1 on success, even though its callers
only check for negative values. Instead, propagate the insert_resource()
result from add_resource() to align with standard kernel return-value
conventions (0 on success, negative errno on failure).
Use %pR to print the full resource range while at it.
Thorsten Blum [Sun, 7 Jun 2026 02:17:52 +0000 (20:17 -0600)]
riscv: use sysfs_emit in cpu_show_ghostwrite
Replace sprintf() with sysfs_emit() in cpu_show_ghostwrite(), which is
preferred for formatting sysfs output because it provides safer bounds
checking.
While the current code only emits fixed strings that fit easily within
PAGE_SIZE, use sysfs_emit() to follow secure coding best practices.
Thorsten Blum [Sun, 7 Jun 2026 02:17:52 +0000 (20:17 -0600)]
riscv: pi: replace strlcat with strscpy in get_early_cmdline
Use the return value of strscpy() instead of calling strlen(fdt_cmdline)
again and return early on string truncation. Drop the explicit size
argument since early_cmdline has a fixed length, which strscpy()
determines using sizeof() when the argument is omitted.
Replace strlcat() with strscpy() to append CONFIG_CMDLINE.
Also remove the unnecessary fdt_cmdline NULL initialization.
Thorsten Blum [Sun, 7 Jun 2026 02:17:51 +0000 (20:17 -0600)]
riscv/purgatory: return bool from verify_sha256_digest
Change the function's return type from int to bool and return the result
of memcmp() directly to simplify the code. While at it, cast ->start to
'const u8 *' to better match the expected type.
Richard Patel [Mon, 18 May 2026 18:39:18 +0000 (18:39 +0000)]
riscv: cfi: reject unknown flags in PR_SET_CFI
prctl(PR_SET_CFI,PR_CFI_BRANCH_LANDING_PADS) silently ignored
unknown control values. Only PR_CFI_{ENABLE,DISABLE,LOCK} should
be permitted.
This changes the behavior of the uABI (fails previously accepted bits
with EINVAL).
Fixes: 08ee1559052b ("prctl: cfi: change the branch landing pad prctl()s to be more descriptive") Signed-off-by: Richard Patel <ripatel@wii.dev> Link: https://patch.msgid.link/20260518183918.322545-1-ripatel@wii.dev
[pjw@kernel.org: change the patch description to note that although this is a uABI change, it does not break the uABI] Signed-off-by: Paul Walmsley <pjw@kernel.org>
Nam Cao [Tue, 7 Apr 2026 12:06:39 +0000 (14:06 +0200)]
riscv: Fix fast_unaligned_access_speed_key not getting initialized
The static key fast_unaligned_access_speed_key is supposed to be
initialized after check_unaligned_access_all_cpus() has been completed.
However, check_unaligned_access_all_cpus() has been moved to late_initcall
while setting fast_unaligned_access_speed_key still happens at
arch_initcall_sync, thus the static key does not get properly initialized.
fast_unaligned_access_speed_key can still be initialized in CPU hotplug
events, but that cannot be relied on.
Move fast_unaligned_access_speed_key's initialization into
check_unaligned_access_all_cpus() to fix this issue. This also prevent
someone from moving one initcall while forgetting the other in the future.
Fixes: 6455c6c11827 ("riscv: Clean up & optimize unaligned scalar access probe") Reported-by: Michael Neuling <mikey@neuling.org> Closes: https://lore.kernel.org/linux-riscv/CAEjGV6y0=bSLp_wrS0uHFj1S2TCRtz4GKzaU5O-L1VV-EL7Nnw@mail.gmail.com/ Signed-off-by: Nam Cao <namcao@linutronix.de> Link: https://patch.msgid.link/20260407120639.4006031-1-namcao@linutronix.de Signed-off-by: Paul Walmsley <pjw@kernel.org>
Andreas Schwab [Thu, 21 May 2026 22:34:30 +0000 (00:34 +0200)]
riscv/ptrace: Use USER_REGSET_NOTE_TYPE for REGSET_CFI
Fixes a warning while dumping core:
[54983.546369][ C7] WARNING: [!note_name] fs/binfmt_elf.c:1771 at elf_core_dump+0x910/0xf68, CPU#7: abort01/31982
Fixes: 2af7c9cf021c ("riscv/ptrace: expose riscv CFI status and state via ptrace and in core files") Signed-off-by: Andreas Schwab <schwab@suse.de> Link: https://patch.msgid.link/87y0hcxuh5.fsf@igel.home Signed-off-by: Paul Walmsley <pjw@kernel.org>
Luca Weiss [Fri, 1 May 2026 09:18:31 +0000 (11:18 +0200)]
clk: qcom: gdsc: Support enabling interconnect path for power domain
On newer SoCs like Milos the CAMSS_TOP_GDSC power domains requires the
enablement of the multimedia NoC, otherwise the GDSC will be stuck on
'off'.
Add support for getting an interconnect path as specified in the SoC
clock driver, and enabling/disabling that interconnect path when the
GDSC is being enabled/disabled.
Jagadeesh Kona [Thu, 7 May 2026 05:38:30 +0000 (11:08 +0530)]
clk: qcom: camcc-x1p42100: Add support for camera clock controller
Add support for the camera clock controller for camera clients to
be able to request for camcc clocks on X1P42100 platform. Although
X1P42100 is derived from X1E80100, the camera clock controller driver
differs significantly. Few PLLs, clocks and GDSC's are removed, there
is delta in frequency tables for most RCG's and parent data structures
also changed for few RCG's. Hence introduce a separate camcc driver
for X1P42100 platform.
Jagadeesh Kona [Thu, 7 May 2026 05:38:29 +0000 (11:08 +0530)]
clk: qcom: camcc-x1e80100: Add support for camera QDSS debug clocks
Add support for camera QDSS debug clocks on X1E80100 platform which
are required to be voted for camera icp and cpas usecases. This change
aligns the camcc driver to the new ABI exposed from X1E80100 camcc
bindings that supports these camcc QDSS debug clocks.
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com> Fixes: 76126a5129b5 ("clk: qcom: Add camcc clock driver for x1e80100") Link: https://lore.kernel.org/r/20260507-purwa-videocc-camcc-v5-4-fc3af4130282@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Jagadeesh Kona [Thu, 7 May 2026 05:38:28 +0000 (11:08 +0530)]
clk: qcom: videocc-x1p42100: Add support for video clock controller
Add support for the video clock controller for video clients to be
able to request for videocc clocks on X1P42100 platform. Although
X1P42100 is derived from X1E80100, the video clock controller differs
significantly. The BSE clocks are newly added, several cdiv clocks have
been removed, and most RCG frequency tables have been updated. Initial
PLL configurations also require changes, hence introduce a separate
videocc driver for X1P42100 platform.
Jagadeesh Kona [Thu, 7 May 2026 05:38:27 +0000 (11:08 +0530)]
dt-bindings: clock: qcom: Add X1P42100 camera clock controller
Add X1P42100 camera clock controller support and clock bindings
for camera QDSS debug clocks which are applicable for both X1E80100
and X1P42100 platforms.
A constant offset added to a PTR_TO_FLOW_KEYS register lands in
reg->var_off, but check_flow_keys_access() bounds-checks only insn->off
and never folds reg->var_off.value. A BPF_PROG_TYPE_FLOW_DISSECTOR
program can therefore do "flow_keys += 0x1000; *(flow_keys + 0)" and have
it accepted, then read/write kernel stack past struct bpf_flow_keys at
runtime. Patch 1 folds reg->var_off.value into the offset (and rejects
non-constant offsets), mirroring check_ctx_access(); patch 2 adds verifier
selftests.
This is a regression introduced in the 7.1 development cycle by commit 022ac0750883 ("bpf: use reg->var_off instead of reg->off for pointers"),
which moved the constant offset from reg->off (folded generically before 022ac0750883) into reg->var_off without updating the flow_keys path. No
released kernel is affected: v7.0.x rejects the program above, and the bug
reproduces only on v7.1-rc1..rc5, so no stable backport is needed.
It was first reported privately to security@kernel.org; per their guidance
it is handled in the open as a normal regression fix. Found by manual
verifier audit and confirmed dynamically in a disposable QEMU/KVM guest:
the load above is accepted, a runtime read leaked a kernel-stack pointer
0x1000 past bpf_flow_keys, and a runtime write of a marker faulted the
guest in net_rx_action.
An alternative -- forbidding pointer arithmetic on PTR_TO_FLOW_KEYS
outright by dropping "if (known) break;" in adjust_ptr_min_max_vals() --
was rejected because v7.0.x accepted (and correctly bounds-checked)
constant arithmetic on the keys pointer; restoring the fold preserves that
behaviour while closing the divergence.
Signed-off-by: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
---
v2 -> v3:
- Pass existing reg/argno context into check_flow_keys_access(), avoiding
a stale regno reference in check_mem_access().
- Add a variable-offset selftest using bpf_get_prandom_u32().
v1 -> v2:
- Target bpf-next instead of bpf (per reviewer feedback).
- Base-commit updated to bpf-next/master.
Nuoqi Gui [Sat, 6 Jun 2026 10:50:38 +0000 (18:50 +0800)]
selftests/bpf: add tests for PTR_TO_FLOW_KEYS offset bounds
Add verifier tests covering pointer arithmetic on a PTR_TO_FLOW_KEYS
register. This covers the bpf-next regression where an out-of-bounds
constant offset introduced as flow_keys += K and then dereferenced at
insn->off 0 was accepted, while the equivalent flow_keys + K direct offset
was rejected.
The tests check that in-bounds constant arithmetic on the keys pointer is
still accepted, out-of-bounds constant arithmetic is rejected for both read
and write, and a truly varying offset from bpf_get_prandom_u32() remains
rejected by the existing PTR_TO_FLOW_KEYS pointer arithmetic rules.
Nuoqi Gui [Sat, 6 Jun 2026 10:50:37 +0000 (18:50 +0800)]
bpf: Fold reg->var_off into PTR_TO_FLOW_KEYS bounds check
Constant pointer arithmetic on a PTR_TO_FLOW_KEYS register lands the
constant in reg->var_off (e.g. flow_keys(imm=4096)), but the
PTR_TO_FLOW_KEYS path in check_mem_access() passes only insn->off to
check_flow_keys_access() and never folds reg->var_off.value. The
verifier therefore accepts an access that, at runtime, dereferences past
struct bpf_flow_keys -- a verifier/runtime divergence that yields an
out-of-bounds read and write of kernel stack memory.
Commit 022ac0750883 ("bpf: use reg->var_off instead of reg->off for
pointers") removed the generic "off += reg->off" that check_mem_access()
applied before the per-type dispatch and replaced it with per-path
folding of reg->var_off.value (for example the ctx path now folds the
register offset via check_ctx_access()). The PTR_TO_FLOW_KEYS path was
not given the equivalent fold, so a constant offset that used to be
folded and rejected is now silently accepted:
before 022ac0750883: the offset stays in reg->off and is folded
generically, so the access is checked with off=4096 and rejected.
after 022ac0750883: the offset lands in reg->var_off, the flow_keys
path checks off=0 and accepts; at runtime the access dereferences
base + 0x1000.
For a BPF_PROG_TYPE_FLOW_DISSECTOR program the following is accepted:
has the same effective offset but is correctly rejected with
"invalid access to flow keys off=4096 size=8", which isolates the defect
to the missing var_off fold. Once attached as a flow dissector, the
accepted program reads kernel stack past struct bpf_flow_keys (a
kernel-stack / KASLR information leak) and can likewise write past it,
corrupting kernel memory.
Fix it by folding reg->var_off.value into the offset before the bounds
check and rejecting non-constant offsets, mirroring the other pointer
types (e.g. check_ctx_access()).
After commit 0652a3daa787 ("tracing: Fix CFI violation in probestub
being called by tprobes"), there are many build errors when building
ARCH=arm multi_v7_defconfig + CONFIG_CFI=y like:
In file included from drivers/base/devres.c:17:
In file included from drivers/base/trace.h:16:
In file included from include/linux/tracepoint.h:23:
include/linux/cfi.h:44:6: error: call to undeclared function 'get_kernel_nofault'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
44 | if (get_kernel_nofault(hash, func - cfi_get_offset()))
| ^
1 error generated.
get_kernel_nofault() is called in the generic version of
cfi_get_func_hash() but nothing ensures uaccess.h is always included for
a proper expansion and prototype. Include uaccess.h in cfi.h to clear
up the errors.
Cc: stable@vger.kernel.org Fixes: 0652a3daa787 ("tracing: Fix CFI violation in probestub being called by tprobes") Signed-off-by: Nathan Chancellor <nathan@kernel.org> Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dmitry Torokhov [Sat, 30 May 2026 05:52:39 +0000 (22:52 -0700)]
Input: atlas_btns - modernize the driver
Rework the driver to use modern style:
- Remove global state by introducing a per-device structure
- Use devm for resource management (input device allocation)
- Use dev_err_probe() for error reporting in the probe path
- Clean up unused definitions and headers.
Rosen Penev [Wed, 3 Jun 2026 19:24:15 +0000 (12:24 -0700)]
Input: apbps2 - simplify resource mapping and IRQ retrieval
Simplify resource mapping by using devm_platform_ioremap_resource()
instead of the longer devm_platform_get_and_ioremap_resource() helper
as the last argument is NULL.
Additionally, use platform_get_irq() to retrieve the interrupt
instead of irq_of_parse_and_map() and propagate its error code on
failure. irq_of_parse_and_map() requires irq_dispose_mapping, which is
missing.
Rosen Penev [Wed, 3 Jun 2026 05:42:17 +0000 (22:42 -0700)]
Input: xilinx_ps2 - remove driver
Remove the Xilinx XPS PS/2 controller driver. This driver supports an
old Xilinx EDK IP core that is no longer in active use. The hardware
is not available on modern platforms, and the driver has no users here.
Input: atkbd - skip deactivate for HONOR BCC-N's internal keyboard
After commit 9cf6e24c9fbf17e52de9fff07f12be7565ea6d61 ("Input: atkbd -
do not skip atkbd_deactivate() when skipping ATKBD_CMD_GETID"), HONOR
BCC-N, aka HONOR MagicBook 14 2026's internal keyboard stops
working. Adding the atkbd_deactivate_fixup quirk fixes it.
libperf: Document struct perf_cpu int16_t ABI limitation
struct perf_cpu.cpu is int16_t, limiting perf to 32767 CPUs. This is
part of the libperf ABI (returned by value from perf_cpu_map__cpu() and
friends), so widening it requires an ABI bump.
Add a comment on the struct definition noting this, and create a TODO
file to collect future ABI changes so they can be batched into a single
version bump.
Cc: Ian Rogers <irogers@google.com> Cc: Namhyung Kim <namhyung@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
perf sched: Free callchain nodes in idle thread cleanup
free_idle_threads() relies on the thread priv destructor (free()) to
clean up idle_thread_runtime structs. But free() doesn't walk the
callchain_cursor linked list or the callchain_root tree allocated
by callchain_cursor__copy() and callchain_append() during --idle-hist
processing. Every idle thread with callchain data leaks these nodes.
Introduce callchain_cursor_cleanup() to free the cursor's linked list
of callchain_cursor_node entries, and call it together with
free_callchain() in free_idle_threads() before thread__put().
Fixes: 225b24f569980ac9 ("perf sched timehist: Save callchain when entering idle") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
perf tools: Fix int16_t truncation of max_cpu_num in set_max_cpu_num()
set_max_cpu_num() assigns the sysfs "possible" CPU count to
max_cpu_num.cpu which is int16_t (struct perf_cpu). On systems
with >32767 possible CPUs the value silently truncates, potentially
wrapping negative. This causes cpunode_map to be underallocated
and subsequent cpu__get_node() calls to read out of bounds.
The matching check for max_present_cpu_num was added by commit c760174401f6 ("perf cpumap: Reduce cpu size from int to int16_t")
but max_cpu_num was missed. Add the same INT16_MAX guard.
Fixes: c760174401f605cf ("perf cpumap: Reduce cpu size from int to int16_t") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Cc: Ian Rogers <irogers@google.com> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
perf timechart: Fix cpu2y() OOB read on untrusted CPU index
cpu2y() indexes topology_map[cpu] without bounds checking. The array
is allocated with nr_cpus entries (from env->nr_cpus_online), but
callers pass sample CPU values from perf.data which can exceed that
size with cross-machine recordings.
Track the topology_map allocation size and bounds-check the CPU
argument in cpu2y() before indexing. Out-of-bounds CPUs fall back
to the identity mapping (cpu2slot(cpu)), which is the same behavior
as when no topology is available.
Fixes: c507999790438cde ("perf timechart: Add support for topology") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Cc: Stanislav Fomichev <stfomichev@yandex-team.ru> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Linus Torvalds [Sat, 6 Jun 2026 16:49:16 +0000 (09:49 -0700)]
Merge tag 'sound-7.1-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"It's getting calmer, but we still came up with a handful of small
fixes, including two core fixes. All look sane and safe.
Core:
- Fix wait queue list corruption in snd_pcm_drain() on linked streams
- Fix UMP event stack overread in seq dummy driver
USB-audio:
- Add quirk for AB13X USB Audio
- Fix the regression with sticky mixer volumes in 7.1-rc
ASoC:
- Fix 32-slot TDM breakage on Freescale SAI
- Varioud DMI quirks for AMD ACP"
* tag 'sound-7.1-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: seq: dummy: fix UMP event stack overread
ALSA: usb-audio: Add iface reset and delay quirk for AB13X USB Audio
ALSA: PCM: Fix wait queue list corruption in snd_pcm_drain() on linked streams
ASoC: amd: acp70: add standalone RT721 SoundWire machine
ASoC: amd: yc: Add MSI Raider A18 HX A9WJG to quirk table
ASoC: fsl_sai: Fix 32 slots TDM broken by integer shift UB in xMR write
ASoC: amd: yc: Enable internal mic on MSI Bravo 17 C7VF
ASoC: amd: acp: Add DMI quirk for Lenovo Yoga Pro 7 15ASH11
ALSA: usb-audio: Set the value of potential sticky mixers to maximum
perf c2c: Fix use-after-free in he__get_c2c_hists() error path
he__get_c2c_hists() assigns c2c_he->hists before calling
c2c_hists__init(). If init fails, the error path calls free(hists)
but leaves c2c_he->hists pointing to freed memory. On teardown,
c2c_he_free() finds the non-NULL pointer and calls
hists__delete_entries() on it, causing a use-after-free.
Set c2c_he->hists to NULL before freeing so teardown skips the
already-freed allocation.
Fixes: b2252ae67b687d2b ("perf c2c report: Decode c2c_stats for hist entries") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Cc: Jiri Olsa <jolsa@kernel.org> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
perf stat: Introduce perf_env__get_cpu_topology() to guard NULL env->cpu
process_cpu_topology() in header.c frees env->cpu on old-format
perf.data files that predate topology information, but leaves
nr_cpus_avail set. The six perf_env__get_*_aggr_by_cpu() functions
in builtin-stat.c pass the bounds check but dereference a NULL
env->cpu pointer, crashing on old recordings.
Introduce perf_env__get_cpu_topology() as a safe accessor that
validates env->cpu, cpu.cpu >= 0, and cpu.cpu < nr_cpus_avail in
one place, returning a struct cpu_topology_map pointer or NULL.
Convert all six topology aggregation callbacks to use it.
Fixes: 88031a0de7d68d13 ("perf stat: Switch to cpu version of cpu_map__get()") Reported-by: sashiko-bot <sashiko-bot@kernel.org> Cc: Ian Rogers <irogers@google.com> Assisted-by: Claude:claude-opus-4.6 Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Linus Torvalds [Sat, 6 Jun 2026 16:44:42 +0000 (09:44 -0700)]
Merge tag 'rust-fixes-7.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux
Pull Rust fixes from Miguel Ojeda:
"Toolchain and infrastructure:
- Fix 'rustc-option' (the Makefile one) when cross-compiling that
leads to build or boot failures in certain configs
- Work around a Rust compiler bug (already fixed for Rust 1.98.0)
thats lead to boot failures in certain configs due to missing
'uwtable' LLVM module flags
- Support a Rust compiler change (starting with Rust 1.98.0) in the
unstable target specification JSON files
- Forbid Rust + arm + KASAN configs, which do not build
'kernel' crate:
- Fix NOMMU build by adding a missing helper"
* tag 'rust-fixes-7.1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux:
rust: x86: support Rust >= 1.98.0 target spec
rust: arm64: set uwtable llvm module flag for CONFIG_UNWIND_TABLES
rust: helpers: add is_vmalloc_addr wrapper for NOMMU builds
rust: kasan/kbuild: fix rustc-option when cross-compiling
ARM: Do not select HAVE_RUST when KASAN is enabled
Cássio Gabriel [Fri, 5 Jun 2026 15:48:27 +0000 (12:48 -0300)]
ALSA: pcm: Fix unlocked runtime state reads in xfer ioctls
The recent runtime state locking cleanup converted several PCM ioctl state
checks to snd_pcm_get_state(), including snd_pcm_pre_prepare(),
snd_pcm_drain() and snd_pcm_kernel_ioctl(). The native and compat xfer
ioctl paths still sample runtime->state directly before dispatching to the
PCM transfer helpers, and snd_pcm_common_ioctl() still samples the
DISCONNECTED state directly in its common precheck.
Use snd_pcm_get_state() for those ioctl-side prechecks as well. This keeps
the externally visible ioctl entry checks consistent with the stream-locked
state access used by the recent PCM state-read cleanup.
HyeongJun An [Sat, 6 Jun 2026 04:09:13 +0000 (13:09 +0900)]
ALSA: seq: Fix partial userptr event expansion
snd_seq_expand_var_event_at() clamps the number of bytes to copy to the
remaining variable-event length, but passes the original buffer size to
expand_var_event().
For SNDRV_SEQ_EXT_USRPTR events, expand_var_event() copies exactly the
size argument from userspace. On the final chunk, when the remaining
event data is shorter than the caller's buffer, this can read past the
declared event data and can spuriously fail with -EFAULT if the extra
bytes cross an unmapped page.
Pass the clamped length instead. The chained and kernel-backed paths
already reclamp in dump_var_event(), but the user-pointer path handles
the size directly.
Rosen Penev [Sun, 17 May 2026 04:27:16 +0000 (21:27 -0700)]
wifi: ath9k: Clear DMA descriptors without memset
Clear ath9k DMA descriptors with explicit status word stores instead of
memset(). The descriptor rings are coherent DMA memory, which may be
mapped uncached on 32-bit powerpc. The optimized memset() path can use
dcbz there and trigger an alignment warning.
Use WRITE_ONCE() for the descriptor status words so the compiler keeps
the clears as ordinary stores instead of folding them back into bulk
memset(). This covers AR9003 TX status descriptors as well as the RX
status area cleared when setting up RX descriptors.
Rosen Penev [Wed, 6 May 2026 23:48:48 +0000 (16:48 -0700)]
wifi: ath9k_htc: use module_usb_driver
This follows the pattern with other USB Wifi drivers. There is nothing
special being done in the _init and _exit functions here. Simplifies and
saves some lines of code.
wifi: wcn36xx: fix OOB read from short trigger BA firmware response
The firmware response length is only checked against sizeof(*rsp) (20
bytes), but when candidate_cnt >= 1, a 22-byte candidate struct is read
at buf + 20 without verifying the response contains it. This causes an
out-of-bounds read of stale heap data, corrupting the BA session state.
Add validation that the response includes the candidate data.
wifi: wcn36xx: fix OOB read from firmware count in PRINT_REG_INFO indication
The firmware-controlled rsp->count field is used as the loop bound for
indexing into the flexible rsp->regs[] array without validation against
the message length. A count exceeding the actual data causes out-of-
bounds reads from the heap-allocated message buffer.
Add a check that count fits within the received message.
Fixes: 43efa3c0f241 ("wcn36xx: Implement print_reg indication") Signed-off-by: Tristan Madani <tristan@talencesecurity.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20260421135018.352774-3-tristmd@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
wifi: wcn36xx: fix heap overflow from oversized firmware HAL response
The firmware response dispatcher copies all synchronous HAL responses
into the 4096-byte hal_buf without validating the response length. A
response exceeding WCN36XX_HAL_BUF_SIZE causes a heap buffer overflow
with firmware-controlled content.
Add a bounds check on the response length.
Fixes: 8e84c2582169 ("wcn36xx: mac80211 driver for Qualcomm WCN3660/WCN3680 hardware") Signed-off-by: Tristan Madani <tristan@talencesecurity.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Link: https://patch.msgid.link/20260421135018.352774-2-tristmd@gmail.com Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Linus Torvalds [Sat, 6 Jun 2026 14:28:59 +0000 (07:28 -0700)]
Merge tag 'vfs-7.1-rc7.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs
Pull vfs fixes from Christian Brauner:
- Fix error handling in ovl_cache_get()
- Tighten access checks for exited tasks in pidfd_getfd()
- Fix selftests leak in __wait_for_test()
- Limit FUSE_NOTIFY_RETRIEVE to uptodate folios
- Reject fuse_notify() pagecache ops on directories
- Clear JOBCTL_PENDING_MASK for caller in zap_other_threads()
- Fix failure to unlock in nfsd4_create_file()
- Fix pointer arithmetic in qnx6 directory iteration
- Fix UAF due to unlocked ->mnt_ns read in may_decode_fh()
- Avoid potential null folio->mapping deref during iomap error
reporting
* tag 'vfs-7.1-rc7.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs:
iomap: avoid potential null folio->mapping deref during error reporting
fhandle: fix UAF due to unlocked ->mnt_ns read in may_decode_fh()
fs/qnx6: fix pointer arithmetic in directory iteration
VFS: fix possible failure to unlock in nfsd4_create_file()
signal: clear JOBCTL_PENDING_MASK for caller in zap_other_threads()
fuse: reject fuse_notify() pagecache ops on directories
fuse: limit FUSE_NOTIFY_RETRIEVE to uptodate folios
selftests: harness: fix pidfd leak in __wait_for_test
pidfd: refuse access to tasks that have started exiting harder
ovl: keep err zero after successful ovl_cache_get()
When `I2cAdapter::get` executes, it first calls
`bindings::i2c_get_adapter()` which increments the device and module
reference counts. It then takes a reference to the raw pointer and
converts it to an `ARef` via `.into()`.
The implementation of `From<&T> for ARef<T>` where `T: AlwaysRefCounted`
unconditionally calls `T::inc_ref()`. This leads to a second increment
to the reference counts.
Since the returned `ARef` will only release a single reference when
dropped via `dec_ref()`, this leaks one device and module reference count
on every call.
perf mmap: Fix NULL deref in aio cleanup on alloc failure
perf_mmap__aio_mmap() sets map->aio.nr_cblocks before allocating the
data array. If calloc() for aiocb or cblocks fails before the data
array is allocated, the return -1 path leads to perf_mmap__aio_munmap()
which loops nr_cblocks times calling perf_mmap__aio_free(). Both
versions of perf_mmap__aio_free() (NUMA and non-NUMA) dereference
map->aio.data[idx] without checking if data is NULL, causing a NULL
pointer dereference.
Add NULL checks for map->aio.data at the top of both
perf_mmap__aio_free() variants so the cleanup path is safe when
allocation fails partway through perf_mmap__aio_mmap().
projects / thirdparty / kernel / linux.git / log
