David Carlier [Wed, 15 Apr 2026 05:23:00 +0000 (06:23 +0100)]
mm/memfd_luo: report error when restoring a folio fails mid-loop
memfd_luo_retrieve_folios() initialises err to -EIO, but the per-iteration
calls to mem_cgroup_charge(), shmem_add_to_page_cache() and
shmem_inode_acct_blocks() reuse and overwrite err. Once any iteration
completes successfully, err becomes zero.
If a later iteration's kho_restore_folio() returns NULL, the failure path
jumps to put_folios without resetting err, so the function returns 0.
The caller memfd_luo_retrieve() then takes the success path, sets
args->file and reports the restore as successful, leaving userspace with
a partially populated memfd and no indication that anything went wrong.
Set err to -EIO in the kho_restore_folio() failure branch so the error
is propagated to the caller.
The buffer parameters in populate_{security,string}_buffer() and
call_{biosattributes,password}_interface() are raw byte buffers, not
character strings - use 'u8 *' instead of 'char *' to reflect this.
Update the local buffer variables at the call sites and in
populate_security_buffer() accordingly.
Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20260410091633.2822-4-thorsten.blum@linux.dev Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
kho_fill_kimage() unconditionally populates the kimage with KHO
metadata for every kexec image type. When the image is a crash kernel,
this can be problematic as the crash kernel can run in a small reserved
region and the KHO scratch areas can sit outside it.
The crash kernel then faults during kho_memory_init() when it
tries phys_to_virt() on the KHO FDT address:
Unable to handle kernel paging request at virtual address xxxxxxxx
...
fdt_offset_ptr+...
fdt_check_node_offset_+...
fdt_first_property_offset+...
fdt_get_property_namelen_+...
fdt_getprop+...
kho_memory_init+...
mm_core_init+...
start_kernel+...
kho_locate_mem_hole() already skips KHO logic for KEXEC_TYPE_CRASH
images, but kho_fill_kimage() was missing the same guard. As
kho_fill_kimage() is the single point that populates image->kho.fdt
and image->kho.scratch, fixing it here is sufficient for both arm64
and x86 as the FDT and boot_params path are bailing out when these
fields are unset.
Fixes: d7255959b69a ("kho: allow kexec load before KHO finalization") Signed-off-by: Evangelos Petrongonas <epetron@amazon.de> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Link: https://patch.msgid.link/20260410011609.1103-1-epetron@amazon.de Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
ntfs: fix invalid PTR_ERR() usage in __ntfs_bitmap_set_bits_in_run()
The Smatch reported a warning in __ntfs_bitmap_set_bits_in_run():
"warn: passing a valid pointer to 'PTR_ERR'"
This occurs because the 'folio' variable might contain a valid pointer
when jumping to the 'rollback' label, specifically when 'cnt <= 0' is
detected during the subsequent page mapping loop. In such cases,
calling PTR_ERR(folio) is incorrect as it does not contain an error
code.
Fix this by introducing an explicit 'err' variable to track the error
status. This ensures that the rollback logic and the return value
consistently use a proper error code regardless of the state of the
folio pointer.
Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Remove the SCLP_OFB Kconfig option and enable the guarded code
unconditionally. This guards only a few lines of code, so the impact is
very low while at the same time this reduces the large number of Kconfig
options.
Acked-by: Christian Borntraeger <borntraeger@linux.ibm.com> Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com> Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com>
s390/debug: Reject zero-length input in debug_input_flush_fn()
debug_input_flush_fn() always copies one byte from the userspace buffer
with copy_from_user() regardless of the supplied write length. A
zero-length write therefore reads one byte beyond the caller's buffer.
If the stale byte happens to be '-' or a digit the debug log is
silently flushed. With an unmapped buffer the call returns -EFAULT.
Reject zero-length writes before copying from userspace.
s390/debug: Reject zero-length input before trimming a newline
debug_get_user_string() duplicates the userspace buffer with
memdup_user_nul() and then unconditionally looks at buffer[user_len - 1]
to strip a trailing newline.
A zero-length write reaches this helper unchanged, so the newline trim
reads before the start of the allocated buffer.
Reject empty writes before accessing the last input byte.
Add a real none bitmap backend that exposes the common bitmap sysfs
group and use it to keep bitmap/location available when an array has no
bitmap.
Then switch the bitmap location sysfs path to move only between none
and the classic bitmap backend, using the no-sysfs bitmap helpers while
merging or unmerging the internal bitmap sysfs group.
This restores mdadm --grow bitmap addition through bitmap/location.
Split the classic bitmap sysfs files into a common bitmap group with
the location attribute and a separate internal bitmap group for the
remaining files.
At the same time, convert bitmap operations from a single sysfs group
to a sysfs group array so backends can share part of their sysfs
layout while adding backend-specific attributes separately.
Switch the bitmap sysfs helpers to use sysfs_update_groups() for the
add and update path, and remove groups in reverse order so shared named
groups are unmerged before the last group removes the directory.
Also make bitmap operation lookup depend only on the currently selected
bitmap id matching the installed backend. This prepares the lookup path
for a later registered none backend.
md: factor bitmap creation away from sysfs handling
Factor bitmap creation and destruction into helpers that do not touch
bitmap sysfs registration.
This prepares the bitmap sysfs rework so callers such as the sysfs
bitmap location path can create or destroy a bitmap backend without
coupling that to sysfs group lifetime management.
Junrui Luo [Thu, 16 Apr 2026 03:39:56 +0000 (11:39 +0800)]
md/raid10: fix divide-by-zero in setup_geo() with zero far_copies
setup_geo() extracts near_copies (nc) and far_copies (fc) from the
user-provided layout parameter without checking for zero. When fc=0
with the "improved" far set layout selected, 'geo->far_set_size =
disks / fc' triggers a divide-by-zero.
Validate nc and fc immediately after extraction, returning -1 if
either is zero.
Keith Busch [Thu, 16 Apr 2026 14:03:45 +0000 (07:03 -0700)]
md/raid1,raid10: don't fail devices for invalid IO errors
BLK_STS_INVAL indicates the IO request itself was invalid, not that the
device has failed. When raid1 treats this as a device error, it retries
on alternate mirrors which fail the same way, eventually exceeding the
read error threshold and removing the device from the array.
This happens when stacking configurations bypass bio_split_to_limits()
in the IO path: dm-raid calls md_handle_request() directly without going
through md_submit_bio(), skipping the alignment validation that would
otherwise reject invalid bios early. The invalid bio reaches the
lower block layers, which fail the bio with BLK_STS_INVAL, and raid1
wrongly interprets this as a device failure.
Add BLK_STS_INVAL to raid1_should_handle_error() so that invalid IO
errors are propagated back to the caller rather than triggering device
removal. This is consistent with the previous kernel behavior when
alignment checks were done earlier in the direct-io path.
Fixes: 5ff3f74e145adc7 ("block: simplify direct io validity check") Reported-by: Tomáš Trnka <trnka@scm.com> Closes: https://lore.kernel.org/linux-block/2982107.4sosBPzcNG@electra/ Signed-off-by: Keith Busch <kbusch@kernel.org> Tested-by: Tomáš Trnka <trnka@scm.com> Link: https://lore.kernel.org/r/20260416140345.3872265-1-kbusch@meta.com Signed-off-by: Yu Kuai <yukuai@fnnas.com>
Xiao Ni [Tue, 14 Apr 2026 02:29:56 +0000 (10:29 +0800)]
MAINTAINERS: Add Xiao Ni as md/raid reviewer
I've been actively involved in the md subsystem, contributing bug
fixes, performance improvements, and participating in code reviews.
I will help improve patch review coverage and response time.
md/raid5: Fix UAF on IO across the reshape position
If make_stripe_request() returns STRIPE_WAIT_RESHAPE,
raid5_make_request() will free the cloned bio. But raid5_make_request()
can call make_stripe_request() multiple times, writing to the various
stripes. If that bio got added to the toread or towrite lists of a
stripe disk in an earlier call to make_stripe_request(), then it's not
safe to just free the bio if a later part of it is found to cross the
reshape position. Doing so can lead to a UAF error, when bio_endio()
is called on the bio for the earlier stripes.
Instead, raid5_make_request() needs to wait until all parts of the bio
have called bio_endio(). To do this, bios that cross the reshape
position while the reshape can't make progress are flagged as needing to
wait for all parts to complete. When raid5_make_request() has a bio that
failed make_stripe_request() with STRIPE_WAIT_RESHAPE, it sets
bi->bi_private to a completion struct and waits for completion after
ending the bio. When the bio_endio() is called for the last time on a
clone bio with bi->bi_private set, it wakes up the waiter. This
guarantees that raid5_make_request() doesn't return until the cloned bio
needing a retry for io across the reshape boundary is safely cleaned up.
There is a simple reproducer available at [1]. Compile the kernel with
KASAN for more useful reporting when the error is triggered (this is not
necessary to see the bug).
lib/fonts: Fix bit position when rotating by 180 degrees
Fix the horizontal bit position when rotating a glyph by 180°. The
original code in rotate_ud() rounded the value in width up to a
multiple of 8, aka the bit pitch, and calculated the rotated pixel
from that value. The new code stores the glyph's pitch in bit_pitch,
but fails to update the rotated pixel's output accordingly. Simply
replacing the variable does this.
The bug can be reproduced by setting a font with an unaligned width,
such as sun12x22, like this:
Randy Dunlap [Mon, 27 Apr 2026 18:32:36 +0000 (11:32 -0700)]
fbdev: ipu-v3: clean up kernel-doc warnings
Correct all kernel-doc warnings:
- fix a typedef kernel-doc comment
- mark a list_head as private
- use Returns: for function return values
Warning: include/video/imx-ipu-image-convert.h:31 struct member 'list' not
described in 'ipu_image_convert_run'
Warning: include/video/imx-ipu-image-convert.h:40 function parameter
'ipu_image_convert_cb_t' not described in 'void'
Warning: include/video/imx-ipu-image-convert.h:40 expecting prototype for
ipu_image_convert_cb_t(). Prototype was for void() instead
Warning: include/video/imx-ipu-image-convert.h:66 No description found for
return value of 'ipu_image_convert_verify'
Warning: include/video/imx-ipu-image-convert.h:90 No description found for
return value of 'ipu_image_convert_prepare'
Warning: include/video/imx-ipu-image-convert.h:125 No description found for
return value of 'ipu_image_convert_queue'
Warning: include/video/imx-ipu-image-convert.h:163 No description found for
return value of 'ipu_image_convert'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Helge Deller <deller@gmx.de>
net: mctp i2c: check length before marking flow active
Currently, mctp_i2c_get_tx_flow_state() is called before the packet length
sanity check. This function marks a new flow as active in the MCTP core.
If the sanity check fails, mctp_i2c_xmit() returns early without calling
mctp_i2c_lock_nest(). This results in a mismatched locking state: the
flow is active, but the I2C bus lock was never acquired for it.
When the flow is later released, mctp_i2c_release_flow() will see the
active state and queue an unlock marker. The TX thread will then
decrement midev->i2c_lock_count from 0, causing it to underflow to -1.
This underflow permanently breaks the driver's locking logic, allowing
future transmissions to occur without holding the I2C bus lock, leading
to bus collisions and potential hardware hangs.
Move the mctp_i2c_get_tx_flow_state() call to after the length sanity
check to ensure we only transition the flow state if we are actually
going to proceed with the transmission and locking.
Fixes: f5b8abf9fc3d ("mctp i2c: MCTP I2C binding driver") Signed-off-by: William A. Kennington III <william@wkennington.com> Acked-by: Jeremy Kerr <jk@codeconstruct.com.au> Link: https://patch.msgid.link/20260423074741.201460-1-william@wkennington.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 08:39:20 +0000 (04:39 -0400)]
KVM: VMX: replace vmx_spec_ctrl_restore_host with RESTORE_HOST_SPEC_CTRL_BODY
Reuse the same assembly as SVM, just with alternatives instead
of cpu_feature_enabled(X86_FEATURE_KERNEL_IBRS).
Note that Intel does need an LFENCE with eIBRS, unlike AMD's AutoIBRS.
However, it is not needed for X86_FEATURE_KERNEL_IBRS because there
are no conditional branches between FILL_RETURN_BUFFER and ret.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 15 Apr 2026 14:26:59 +0000 (10:26 -0400)]
KVM: SVM: adopt the same VMX_RUN_* flags as VMX
Rename VMX_RUN_* to KVM_ENTER_* (to not confuse with KVM_RUN_* that
already exists) and replace SVM's spec_ctrl_intercepted with that same
bitmask.
Note that KVM_ENTER_SAVE_SPEC_CTRL has the opposite polarity compared
to spec_ctrl_intercepted. That is, the guest value of the MSR must be
saved if it writes are *not* intercepted.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Wed, 8 Apr 2026 07:19:46 +0000 (03:19 -0400)]
KVM: SVM: prepare for making SPEC_CTRL switch common with VMX
Remove the local labels and restrict RESTORE_*_BODY to just
the restore code itself. Since the alternatives are different
between VMX and SVM, having labels in the per-vendor file and
jumps in another would be too confusing.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Paolo Bonzini [Fri, 28 Oct 2022 21:16:26 +0000 (17:16 -0400)]
KVM: VMX: more cleanups to __vmx_vcpu_run
Slightly improve register allocation, loading vmx only once
before vmlaunch/vmresume.
This also makes the code slightly more similar to the one for
AMD processors, in that both keep the pointer to struct vcpu_vmx
or vcpu_svm in %rdi. The code for restoring the guest value of
SPEC_CTRL is also the same for Intel and AMD.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
drm/i915/dp: Add a helper to decide if AS SDP can be used
Add a helper that determines whether AS SDP can be used for the
current DP configuration. For now this is true only when the sink
supports AS SDP and VRR is enabled, but more conditions may be added
later.
v2:
- Rename to intel_dp_needs_as_sdp(). (Ville)
- Add a #FIXME documenting non-atomic of DP SDP updates. (Ville)
Marco Crivellari [Fri, 31 Oct 2025 10:20:20 +0000 (11:20 +0100)]
drm/nouveau: WQ_PERCPU added to alloc_workqueue users
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistentcy cannot be addressed without refactoring the API.
alloc_workqueue() treats all queues as per-CPU by default, while unbound
workqueues must opt-in via WQ_UNBOUND.
This default is suboptimal: most workloads benefit from unbound queues,
allowing the scheduler to place worker threads where they’re needed and
reducing noise when CPUs are isolated.
This change adds a new WQ_PERCPU flag to explicitly request
alloc_workqueue() to be per-cpu when WQ_UNBOUND has not been specified.
With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
must now use WQ_PERCPU.
Once migration is complete, WQ_UNBOUND can be removed and unbound will
become the implicit default.
Marco Crivellari [Fri, 31 Oct 2025 10:20:19 +0000 (11:20 +0100)]
drm/nouveau: replace use of system_unbound_wq with system_dfl_wq
Currently if a user enqueue a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.
This lack of consistency cannot be addressed without refactoring the API.
system_unbound_wq should be the default workqueue so as not to enforce
locality constraints for random work whenever it's not required.
Adding system_dfl_wq to encourage its use when unbound work should be used.
The old system_unbound_wq will be kept for a few release cycles.
Thomas Huth [Mon, 27 Apr 2026 15:56:30 +0000 (17:56 +0200)]
efi: pstore: Drop efivar lock when efi_pstore_open() returns with an error
If kzalloc fails, the function returns -ENOMEM without calling
efivar_unlock(). Since open() returned an error, the calling site
in pstore_get_backend_records() won't call the close() function, so
the lock is never released. Thus drop the lock in case of errors here.
Sam Edwards [Wed, 22 Apr 2026 04:45:03 +0000 (21:45 -0700)]
net: stmmac: Prevent NULL deref when RX memory exhausted
The CPU receives frames from the MAC through conventional DMA: the CPU
allocates buffers for the MAC, then the MAC fills them and returns
ownership to the CPU. For each hardware RX queue, the CPU and MAC
coordinate through a shared ring array of DMA descriptors: one
descriptor per DMA buffer. Each descriptor includes the buffer's
physical address and a status flag ("OWN") indicating which side owns
the buffer: OWN=0 for CPU, OWN=1 for MAC. The CPU is only allowed to set
the flag and the MAC is only allowed to clear it, and both must move
through the ring in sequence: thus the ring is used for both
"submissions" and "completions."
In the stmmac driver, stmmac_rx() bookmarks its position in the ring
with the `cur_rx` index. The main receive loop in that function checks
for rx_descs[cur_rx].own=0, gives the corresponding buffer to the
network stack (NULLing the pointer), and increments `cur_rx` modulo the
ring size. After the loop exits, stmmac_rx_refill(), which bookmarks its
position with `dirty_rx`, allocates fresh buffers and rearms the
descriptors (setting OWN=1). If it fails any allocation, it simply stops
early (leaving OWN=0) and will retry where it left off when next called.
This means descriptors have a three-stage lifecycle (terms my own):
- `empty` (OWN=1, buffer valid)
- `full` (OWN=0, buffer valid and populated)
- `dirty` (OWN=0, buffer NULL)
But because stmmac_rx() only checks OWN, it confuses `full`/`dirty`. In
the past (see 'Fixes:'), there was a bug where the loop could cycle
`cur_rx` all the way back to the first descriptor it dirtied, resulting
in a NULL dereference when mistaken for `full`. The aforementioned
commit resolved that *specific* failure by capping the loop's iteration
limit at `dma_rx_size - 1`, but this is only a partial fix: if the
previous stmmac_rx_refill() didn't complete, then there are leftover
`dirty` descriptors that the loop might encounter without needing to
cycle fully around. The current code therefore panics (see 'Closes:')
when stmmac_rx_refill() is memory-starved long enough for `cur_rx` to
catch up to `dirty_rx`.
Fix this by explicitly checking, before advancing `cur_rx`, if the next
entry is dirty; exit the loop if so. This prevents processing of the
final, used descriptor until stmmac_rx_refill() succeeds, but
fully prevents the `cur_rx == dirty_rx` ambiguity as the previous bugfix
intended: so remove the clamp as well. Since stmmac_rx_zc() is a
copy-paste-and-tweak of stmmac_rx() and the code structure is identical,
any fix to stmmac_rx() will also need a corresponding fix for
stmmac_rx_zc(). Therefore, apply the same check there.
In stmmac_rx() (not stmmac_rx_zc()), a related bug remains: after the
MAC sets OWN=0 on the final descriptor, it will be unable to send any
further DMA-complete IRQs until it's given more `empty` descriptors.
Currently, the driver simply *hopes* that the next stmmac_rx_refill()
succeeds, risking an indefinite stall of the receive process if not. But
this is not a regression, so it can be addressed in a future change.
Fixes: b6cb4541853c7 ("net: stmmac: avoid rx queue overrun") Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221010 Cc: stable@vger.kernel.org Suggested-by: Russell King <linux@armlinux.org.uk> Signed-off-by: Sam Edwards <CFSworks@gmail.com> Link: https://patch.msgid.link/20260422044503.5349-1-CFSworks@gmail.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Maulik Shah [Thu, 23 Apr 2026 11:25:24 +0000 (16:55 +0530)]
pinctrl: qcom: Fix GPIO to PDC wake irq map for qcs615
PDC interrupts 122-125 were meant for ibi_i3c wakeup but qcs615 do not
support i3c. GPIOs 39,51,88 and 89 are also connected to different PDC
pin to support non-ibi wakeup. Update the wakeirq map to reflect same.
Fixes: b698f36a9d40 ("pinctrl: qcom: add the tlmm driver for QCS615 platform") Signed-off-by: Maulik Shah <maulik.shah@oss.qualcomm.com> Signed-off-by: Navya Malempati <navya.malempati@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
Accessing the pinconf-pins sysfs node may deadlock.
pinconf_pins_show() holds pctldev->mutex, and the platform driver
calls pinctrl_find_gpio_range_from_pin(), which tries to acquire
the same mutex again, leading to a deadlock.
Use pinctrl_find_gpio_range_from_pin_nolock() to fix this issue.
Fixes: 6e9be3abb78c ("pinctrl: Add driver support for Amlogic SoCs") Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Linus Walleij <linusw@kernel.org>
Various names for Qualcomm as a company are used in user-visible config
options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified
"Qualcomm" so it will be easier for users to identify the options when
for example running menuconfig.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
[linusw@kernel.org: Also fix the new IPQ9650] Signed-off-by: Linus Walleij <linusw@kernel.org>
QUP1_SE4 shares GPIO_36 & GPIO_37 for both L0/L1 and L3/L2 so the
function name cannot be the same or the alternate function cannot
be selected.
Split them up into individual lane functions so boards can specify.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
So when you select pin 42 and request function qup1_se6, it will select
the first instance of it in this group, which just happens to be
QUP1_SE6_L2, making the second instance (QUP1_SE6_L1_MIRA) effectively
unreachable.
Split each of these lanes that has an alternative GPIO into their own
function so they can actually be selected, following the pattern seen
in pinctrl-sm8550.c.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
dt-bindings: pinctrl: qcom,eliza-tlmm: Split QUP lane mirror alternates
Several QUP lanes have MIRA/MIRB mirror routings that let the same lane
be muxed out on alternative GPIOs. On Eliza these were all collapsed
under the base function name (e.g. qup1_se6), which prevented boards
from selecting the mirror variants.
Add explicit function names for each mirror lane, matching the pattern
already established by qcom,sm8550-tlmm and related bindings.
Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
Andrea Mayer [Tue, 21 Apr 2026 09:47:35 +0000 (11:47 +0200)]
net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels
seg6_input_core() and rpl_input() call ip6_route_input() which sets a
NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking
dst_hold() unconditionally.
On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can
release the underlying pcpu_rt between the lookup and the caching
through a concurrent FIB lookup on a shared nexthop.
Simplified race sequence:
ksoftirqd/X higher-prio task (same CPU X)
----------- --------------------------------
seg6_input_core(,skb)/rpl_input(skb)
dst_cache_get()
-> miss
ip6_route_input(skb)
-> ip6_pol_route(,skb,flags)
[RT6_LOOKUP_F_DST_NOREF in flags]
-> FIB lookup resolves fib6_nh
[nhid=N route]
-> rt6_make_pcpu_route()
[creates pcpu_rt, refcount=1]
pcpu_rt->sernum = fib6_sernum
[fib6_sernum=W]
-> cmpxchg(fib6_nh.rt6i_pcpu,
NULL, pcpu_rt)
[slot was empty, store succeeds]
-> skb_dst_set_noref(skb, dst)
[dst is pcpu_rt, refcount still 1]
rt_genid_bump_ipv6()
-> bumps fib6_sernum
[fib6_sernum from W to Z]
ip6_route_output()
-> ip6_pol_route()
-> FIB lookup resolves fib6_nh
[nhid=N]
-> rt6_get_pcpu_route()
pcpu_rt->sernum != fib6_sernum
[W <> Z, stale]
-> prev = xchg(rt6i_pcpu, NULL)
-> dst_release(prev)
[prev is pcpu_rt,
refcount 1->0, dead]
dst = skb_dst(skb)
[dst is the dead pcpu_rt]
dst_cache_set_ip6(dst)
-> dst_hold() on dead dst
-> WARN / use-after-free
For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without
PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release
the pcpu_rt. Shared nexthop objects provide such a path, as two routes
pointing to the same nhid share the same fib6_nh and its rt6i_pcpu
entry.
Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after
ip6_route_input() to force the NOREF dst into a refcounted one before
caching.
The output path is not affected as ip6_route_output() already returns a
refcounted dst.
Fixes: af4a2209b134 ("ipv6: sr: use dst_cache in seg6_input") Fixes: a7a29f9c361f ("net: ipv6: add rpl sr tunnel") Cc: stable@vger.kernel.org Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it> Reviewed-by: Simon Horman <horms@kernel.org> Reviewed-by: Justin Iurman <justin.iurman@gmail.com> Link: https://patch.msgid.link/20260421094735.20997-1-andrea.mayer@uniroma2.it Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Binding should require 'reg' property, because address space cannot be
missing in the hardware and is already needed by the Linux drivers.
Require also 'compatible' by convention, although it is not strictly
necessary.
pinctrl: aspeed: Enable compile testing outside of ARCH_ASPEED
Since inception in commit 4d3d0e4272d8 ("pinctrl: Add core support for
Aspeed SoCs"), the Aspeed pin controller drivers cannot be compile
tested, unless ARCH_ASPEED is selected. . That partially defeats the
purpose of compile testing, since ARCH_ASPEED is pulled when building
platform kernels.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
Currently NVIDIA Tegra pin controller drivers cannot be compile tested,
unless ARCH_TEGRA is selected. That partially defeats the purpose of
compile testing, since ARCH_TEGRA is pulled when building platform
kernels. Solve it and allow compile testing independently of ARCH_TEGRA
choice which requires few less usual changes:
1. Descent in Makefile in to drivers/pinctrl/tegra/ unconditionally,
because there is no menu option.
2. Depend on COMMON_CLK for PINCTRL_TEGRA20, because it uses
clk_register_mux().
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Linus Walleij <linusw@kernel.org>
Shixiong Ou [Fri, 24 Apr 2026 12:44:27 +0000 (20:44 +0800)]
drm/udl: Increase GET_URB_TIMEOUT
[WHY]
A situation has occurred where udl_handle_damage() executed successfully
and the kernel log appears normal, but the display fails to show any output.
This is because the call to udl_get_urb() in udl_crtc_helper_atomic_enable()
failed without generating any error message.
[HOW]
1. Increase timeout of getting urb.
2. Add error messages when calling udl_get_urb() failed in
udl_crtc_helper_atomic_enable().
Signed-off-by: Shixiong Ou <oushixiong@kylinos.cn> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 5320918b9a87 ("drm/udl: initial UDL driver (v4)") Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Cc: <stable@vger.kernel.org> # v3.4+ Link: https://patch.msgid.link/20260424124427.657-1-oushixiong1025@163.com
Cássio Gabriel [Tue, 28 Apr 2026 02:38:41 +0000 (23:38 -0300)]
ASoC: Intel: bytcr_wm5102: Fix MCLK leak on platform_clock_control error
If byt_wm5102_prepare_and_enable_pll1() fails in the
SND_SOC_DAPM_EVENT_ON() path, platform_clock_control() returns after
clk_prepare_enable(priv->mclk) without disabling the clock again.
This leaks an MCLK enable reference on failed power-up attempts. Add the
missing clk_disable_unprepare() on the error path, matching the unwind
used by the other Intel platform_clock_control() implementations.
Fixes: 9a87fc1e0619 ("ASoC: Intel: bytcr_wm5102: Add machine driver for BYT/WM5102") Cc: stable@vger.kernel.org Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Link: https://patch.msgid.link/20260427-bytcr-wm5102-mclk-leak-v1-1-02b96d08e99c@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
wifi: brcmsmac: phy_lcn: Remove dead code in wlc_lcnphy_radio_2064_channel_tune_4313()
The variable rfpll_doubler is initialized to 0 and then unconditionally
set to 1 on the very next line, making the subsequent check for
!rfpll_doubler always evaluate to false. This results in logically
dead code that has never been executed.
Remove the unused variable, the unreachable conditional branch, and
simplify the fpfd calculation to directly use the PLL doubler values.
The mpll3 clock is one parent clock of the sd_emmc and mipi_isp clocks
on the Amlogic T7 SoC, but was missing from t7-peripherals-clkc.yaml
bindings. Add the mpll3 clock source to the T7 peripherals clock
controller input clock list, so that sd_emmc and mipi_isp can use it.
For logical consistency, place the required mpll3 entry before the
optional entry.
This change breaks the ABI, but while the amlogic,t7-peripherals-clkc
bindings have been merged upstream, the corresponding DT has not been
merged yet. Thus, no real users or systems are affected.
Jeongjun Park [Wed, 22 Apr 2026 17:38:46 +0000 (02:38 +0900)]
wifi: rsi: fix kthread lifetime race between self-exit and external-stop
RSI driver use both self-exit(kthread_complete_and_exit) and external-stop
(kthread_stop) when killing a kthread. Generally, kthread_stop() is called
first, and in this case, no particular issues occur.
However, in rare instances where kthread_complete_and_exit() is called
first and then kthread_stop() is called, a UAF occurs because the kthread
object, which has already exited and been freed, is accessed again.
Therefore, to prevent this with minimal modification, you must remove
kthread_stop() and change the code to wait until the self-exit operation
is completed.
Cc: <stable@vger.kernel.org> Reported-by: syzbot+5de83f57cd8531f55596@syzkaller.appspotmail.com Closes: https://lore.kernel.org/all/69e5d03b.a00a0220.1bd0ca.0064.GAE@google.com/ Fixes: 4c62764d0fc2 ("rsi: improve kernel thread handling to fix kernel panic") Signed-off-by: Jeongjun Park <aha310510@gmail.com> Link: https://patch.msgid.link/20260422173846.37640-1-aha310510@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
arm64: tegra: Add aspm-l1-entry-delay-ns to PCIe nodes
Add the aspm-l1-entry-delay-ns device tree property to all PCIe Root Port
and PCIe Endpoint nodes in tegra194.dtsi and tegra234.dtsi so that ASPM L1
entrance latency is configured from device tree.
- Tegra194: 4000 ns (4 us) for both Root Port and Endpoint.
- Tegra234: 8000 ns (8 us) for Root Port, 16000 ns (16 us) for Endpoint.
Jon Hunter [Wed, 1 Apr 2026 10:29:41 +0000 (11:29 +0100)]
arm64: tegra: Fix Tegra234 MGBE PTP clock
The Tegra MGBE PTP clock is incorrectly named as 'ptp-ref' and not
'ptp_ref' and this causing the initialisation of the PTP clock to fail.
The device-tree binding doc for the device and the Tegra MGBE driver
have been updated to use the correct name and so update the device-tree
for Tegra234 as well.
Fixes: 610cdf3186bc ("arm64: tegra: Add MGBE nodes on Tegra234") Signed-off-by: Jon Hunter <jonathanh@nvidia.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
Most IXP4xx platforms are Device Tree-based, and GPIO consumers
use phandle-based descriptors rather than legacy integer GPIO numbers.
Audit of the IXP4xx platform shows:
- No gpio_request(), gpio_get_value(), or gpio_set_value() users
in arch/arm/mach-ixp4xx/
- No platform data using fixed GPIO numbers
This switches the gpiochip to dynamic base allocation, aligning
with modern gpiolib expectations where GPIO numbers are not globally
fixed and may be assigned dynamically.
Set gpiochip.base = -1 to allow gpiolib to assign the GPIO base
dynamically, avoiding global GPIO number space conflicts.
Johannes Berg [Fri, 17 Apr 2026 12:16:01 +0000 (14:16 +0200)]
wifi: mac80211: always allow transmitting null-data on TXQs
Jouni reported that certain sequences of tests caused some
WDS tests to fail after applying the upcoming hwsim changes
for NAN. I bisected that down to converting hwsim to TXQs,
and after a long debug session found that the 4-addr NDP was
getting dropped, because it goes out via a (management) TXQ
and is a data frame.
It's unclear to me now why this only happens in some test
sequences (e.g. "sigma_dut_sae_h2e_ap_loop ap_wds_sta" and
"sigma_dut_eap_ttls_all_akm_suites ap_wds_sta_open"), maybe
that affects timing and the frame is otherwise delayed in
some way.
Correct the check to only drop frames that actually carry
data, not NDPs.
Daniel Gabay [Wed, 15 Apr 2026 15:35:55 +0000 (18:35 +0300)]
wifi: cfg80211: validate cipher suite for NAN Data keys
Per Wi-Fi Aware v4.0 section 7.1.2, NAN Data interfaces shall only
use CCMP-128 or GCMP-256 for frame protection. Enforce this in
cfg80211_validate_key_settings() by passing the wdev down to it.
Johannes Berg [Wed, 15 Apr 2026 12:51:57 +0000 (14:51 +0200)]
wifi: mac80211: clarify an 802.11 VHT spec reference
Just saying "Table 9-250" isn't useful, without the version
of the spec. Fix the number according to the latest released
version (-2020) and add the table name.
When a (link) station connected to an AP interface is not
capable of EHT, it's possible that the AP interface is in
160 MHz but the HE channel is narrower, e.g. when EHT has
puncturing. In this case, the code doesn't correctly set
the STAs bandwidth, the station might be capable of using
160 MHz, but it can't use EHT 160 MHz with puncturing, so
it must be set to narrower.
Track the AP's 'he_and_lower_bw' bandwidth, use that when
calculating the maximum bandwidth to transmit to/from any
station not capable of EHT, and update all stations and
the chanctx min_def when it changes.
The per-STA bandwidth handling is completely confusing, given
the function names etc.
Move everything to sta_info.c and rename the functions to
accurately reflect what they return:
- ieee80211_sta_bw_capability()
- ieee80211_sta_current_bw() can return the appropriate
bandwidth in the desired direction (a new enum)
At any given time, the bandwidth with which we expect to receive
frames from a station may differ from the bandwidth with which
we may transmit frames to the station; this will happen either
during RX OMI negotiation, or for a long time if the station
used an HT Notify Channel Width frame. We also implement the
(VHT) Operating Mode Notification as an asymmetric setting, even
if the spec would seem to imply it could be symmetric.
Also rename the 'cur_max_bandwidth' value to 'op_mode_bw' which
matches the 'op_mode_nss', indicating more clearly what it _is_
rather than how it's _used_. It's not quite precise (NSS is)
since it's also HT chanwidth notification, but that seems OK.
Johannes Berg [Wed, 15 Apr 2026 12:42:16 +0000 (14:42 +0200)]
wifi: nl80211: always validate AP operation/PHY regulatory
Instead of validating the AP operation elements and PHY regulatory
individually in each caller, which missed CSA and color change,
pass the channel to the beacon parsing function and validate the
parameters there. This adds it to the missing places.
Johannes Berg [Wed, 15 Apr 2026 12:42:15 +0000 (14:42 +0200)]
wifi: cfg80211: provide HT/VHT operation for AP beacon
In addition to providing HE/EHT/UHR operation, also check
and provide HT/VHT operation, so that drivers have it and
can use it, e.g. to correctly calculate station bandwidth.
Johannes Berg [Wed, 15 Apr 2026 12:42:14 +0000 (14:42 +0200)]
wifi: nl80211: reject too short HT/VHT/HE/EHT capability/operation
If any of these are present, the code only assigns pointers when
they're also long enough. Instead of ignoring them in that case,
reject the configuration instead.
Johannes Berg [Wed, 15 Apr 2026 12:42:13 +0000 (14:42 +0200)]
wifi: cfg80211: move AP HT/VHT/... operation to beacon info
The HT/VHT/HE/EHT/UHR operation can change, and might thus be
updated on each beacon update. Move them to the beacon struct
and parse them out of the beacon also on updates, not just on
starting the AP.
This also fixes checks in two ways:
- Regulatory checks in nl80211_validate_ap_phy_operation() are
now done also on updates, disallowing enabling HE/EHT/UHR on
channels that don't allow that after start. This checks only
operation now, but clients can't use it without operation.
- NL80211_ATTR_UHR_OPERATION is now required whenever UHR is
present in the beacon, and rejected otherwise.
Johannes Berg [Wed, 15 Apr 2026 12:42:12 +0000 (14:42 +0200)]
wifi: nl80211: reject beacons with bad HE operation
The HE operation element not only needs to be longer than
the fixed part, but also have an appropriate size for the
variable part inside of it. Check this.
Johannes Berg [Wed, 15 Apr 2026 12:42:10 +0000 (14:42 +0200)]
wifi: mac80211: remove ieee80211_sta_cur_vht_bw()
We can now easily always call _ieee80211_sta_cur_vht_bw() with
a valid chandef, so do that, remove ieee80211_sta_cur_vht_bw()
and drop the underscore prefix.
Johannes Berg [Wed, 15 Apr 2026 12:42:09 +0000 (14:42 +0200)]
wifi: mac80211: clean up ieee80211_sta_cap_rx_bw()
There are three versions of this function, but now there's
no caller to ieee80211_sta_cap_rx_bw() and the chandef is
always given. Rename the functions to have one underscore
less and rely on the chandef being passed.
Johannes Berg [Wed, 15 Apr 2026 12:42:08 +0000 (14:42 +0200)]
wifi: mac80211: clean up initial STA NSS/bandwidth handling
Currently, the initial STA bandwidth is set during each
parsing of HT/VHT/... elements to the station capabilities,
multiple times, in a confusing way that's not very good in
the case of NAN stations either.
For now, keep the NULL chandef pointer and all that, but
clean up the initial handling of NSS/BW capabilities and
then apply the VHT operation mode on top of that. This
clarifies the code and the client code now also handles
the bandwidth change from Operating Mode Notification in
association response.
The HT code is completely unnecessary now, since the VHT
(soon to be renamed) function will be called and handles
HT as well.
Johannes Berg [Wed, 15 Apr 2026 12:42:07 +0000 (14:42 +0200)]
wifi: mac80211: clean up STA NSS handling
Move ieee80211_sta_init_nss() from VHT code to station code,
and disentangle it from rate control. This way, it becomes
clearer when 'rx_nss' is set up.
While doing this, fix the client side code to set up
link_sta->op_mode_nss instead of link_sta->pub->rx_nss for
the opmode element in association response, and remove the
(now wrong) comment about handling that in the function.
This function is only called for at least HT capable stations,
so doesn't need to differentiate 20/20_NOHT. Also, the check
for VHT 160 MHz support is wrong, since a station could have
support for both and the AP is using 80+80, but nothing cares
anyway, so we don't need that.
Simplify the function and move it to util.c since it now no
longer is related to VHT, and also doesn't need a station.
Also use the new function in ieee80211_get_sta_bw() for the
chandef calculations, it just needs to handle the 20/20-noht
separately; while at it fix that to handle HE stations.
The opmode change notification is entirely unused by existing
userspace except for printing out the values. As such, there's
no need to keep it perfectly accurate, and the implementation
in mac80211 doesn't report it correctly today. Add a note in
the documentation that it may not differentiate 80+80 and 160.
This function is only used by TDLS, but is more or less equivalent
to ieee80211_sta_cap_rx_bw() (which takes OMI into account, but that
won't be used in TDLS), except it tries to differentiate 80+80 and
160, but then caller doesn't care about that. Remove the function.
Johannes Berg [Wed, 15 Apr 2026 12:42:03 +0000 (14:42 +0200)]
wifi: mac80211: use chandef in TDLS chanctx handling
When getting the station's bandwidth for TDLS chanctx
updates, pass the chandef so that the band can be used
in _ieee80211_sta_cap_rx_bw(), instead of this using
ieee80211_sta_cap_rx_bw() which looks it up from the
link.
This removes the last user of ieee80211_sta_cap_rx_bw().
Johannes Berg [Wed, 15 Apr 2026 12:42:02 +0000 (14:42 +0200)]
wifi: mac80211: use chandef in ieee80211_get_sta_bw()
When getting the bandwidth the station uses in order to
calculate the channel context's min_def, pass the channel
for the link to _ieee80211_sta_cap_rx_bw() instead of using
ieee80211_sta_cap_rx_bw(), which looks it up.
Johannes Berg [Wed, 15 Apr 2026 12:42:01 +0000 (14:42 +0200)]
wifi: mac80211: use max BW for HT channel width update
When an HT channel width update comes in, don't use the
capability of the station, but rather set it to max as
the capability will be taken into account anyway when
using the value.
Johannes Berg [Wed, 15 Apr 2026 12:42:00 +0000 (14:42 +0200)]
wifi: mac80211: set cur_max_bandwidth to maximum
Instead of calculating the individual maximum for each
station from its capabilities, just unconditionally set
cur_max_bandwidth to IEEE80211_STA_RX_BW_MAX. This still
works because cur_max_bandwidth is only used together
with the capabilities of the station anyway, and then
adjusted by HT channel width notification or VHT opmode
notification action frames.
Johannes Berg [Wed, 15 Apr 2026 12:41:59 +0000 (14:41 +0200)]
wifi: mac80211: remove NAN guards on ieee80211_sta_cur_vht_bw() calls
The NAN guards here make little sense, just don't WARN inside
the function (and return maximum instead of minimum). Otherwise
we need to guard more calls, such as in EHT in the future.
Louis Kotze [Tue, 14 Apr 2026 12:27:28 +0000 (14:27 +0200)]
wifi: cfg80211: fix grammar in MLO group key error message
The error message emitted by nl80211_validate_key_link_id() when a group
key install on an MLO wdev is missing the link ID reads "link ID must
for MLO group key", which is missing the words "be set". This makes the
error harder to grep and parse in userspace logs, and is reported
verbatim by wpa_supplicant via its nl80211 extack relay, e.g.:
wpa_supplicant: nl80211: kernel reports: link ID must for MLO group key
The sibling error strings in the same helper already use grammatical
phrasing ("link ID not allowed for pairwise key", "invalid link ID for
MLO group key", "link ID not allowed for non-MLO group key"). Fix this
one to match.
No functional change.
Fixes: e7a7b84e3317 ("wifi: cfg80211: Add link_id parameter to various key operations for MLO") Signed-off-by: Louis Kotze <loukot@gmail.com> Link: https://patch.msgid.link/20260414122728.92234-1-loukot@gmail.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
wifi: cfg80211: reject duplicate wiphy cipher suite entries
Duplicate entries in wiphy->cipher_suites do not describe any
additional capability, but cfg80211 currently accepts them and leaves
individual consumers to deal with them.
One such consumer is the WEXT compatibility code, which appends a WEP
key length for each WEP cipher entry it sees. Repeated WEP entries can
therefore overflow the fixed iw_range::encoding_size array returned by
SIOCGIWRANGE.
Reject duplicate cipher suite entries in wiphy_register() instead.
This keeps the cipher suite invariant in one place and makes malformed
wiphy descriptions fail early with -EINVAL, rather than relying on a
single cfg80211 user to handle duplicates correctly.
Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Co-developed-by: Yuan Tan <yuantan098@gmail.com> Signed-off-by: Yuan Tan <yuantan098@gmail.com> Suggested-by: Xin Liu <bird@lzu.edu.cn> Signed-off-by: Yuqi Xu <xuyuqiabc@gmail.com> Signed-off-by: Ren Wei <n05ec@lzu.edu.cn> Link: https://patch.msgid.link/20260413123000.1480661-1-n05ec@lzu.edu.cn Signed-off-by: Johannes Berg <johannes.berg@intel.com>
projects / thirdparty / linux.git / log
