Takashi Iwai [Wed, 10 Jun 2026 15:45:31 +0000 (17:45 +0200)]
ALSA: Add simple refcount helper functions
There are many open-code to manage the same pattern for refcount +
wakeup sync at closing. Let's provide the common helper functions to
replace the open-code.
- The recount is kept in struct snd_refcount, where it's initialized
by snd_refcount_init().
- The user can simply reference or unreference via snd_refcount_get()
and snd_refcount_put() functions
- The user can wait for the all usages gone by snd_refcount_sync()
Note that here we use atomic_t instead of refcount_t since the current
users allow reusing the refcount after sync again. The design of
refcount_t prevents exactly this behavior, so it doesn't fit.
Eric Biggers [Sun, 31 May 2026 19:17:35 +0000 (12:17 -0700)]
crypto: xilinx-trng - Remove crypto_rng interface
Implementing the crypto_rng interface has no purpose, as it isn't used
in practice. It's being removed from other drivers too. Just remove
it. This leaves hwrng, which is actually used.
Tagging with 'Cc stable' due to the bugs that this removes:
- xtrng_trng_generate() sometimes returned success even when it didn't
fill in all the bytes.
- It was possible for xtrng_trng_generate() and
xtrng_hwrng_trng_read() to run concurrently and interfere with each
other, as the locking code in xtrng_hwrng_trng_read() was broken.
Fixes: 8979744aca80 ("crypto: xilinx - Add TRNG driver for Versal") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Eric Biggers [Sun, 31 May 2026 17:59:31 +0000 (10:59 -0700)]
crypto: exynos-rng - Remove exynos-rng driver
This driver has no purpose. It doesn't feed into the Linux RNG, nor
does it implement the hwrng interface. It is accessible only via the
"rng" algorithm type of AF_ALG, which isn't used in practice. Everyone
uses either the Linux RNG, or rarely /dev/hwrng.
Moreover, this is a PRNG whose only source of entropy is the 160-bit
seed the user passes in. So this can be used only by a user who already
has a source of cryptographically secure random numbers, such as
/dev/random. Which they can, and do, just use in the first place.
Just remove this driver. There's no need to keep useless code around.
Note that the other crypto_rng drivers in drivers/crypto/ are similarly
unused and are being removed too. This commit just handles exynos-rng.
Signed-off-by: Eric Biggers <ebiggers@kernel.org> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Eric Biggers [Sat, 30 May 2026 20:26:23 +0000 (13:26 -0700)]
crypto: hisi-trng - Remove crypto_rng interface
drivers/crypto/hisilicon/trng/trng.c exposes the same hardware through
two completely separate interfaces, crypto_rng and hwrng. However, the
implementation of this is buggy because it permits generation operations
from these interfaces to run concurrently with each other, accessing the
same registers. That is, hisi_trng_generate() synchronizes with itself
but not with hisi_trng_read(). This results in potential repetition of
output from the RNG, output of non-random values, etc.
Fortunately, there's actually no point in hardware RNG drivers
implementing the crypto_rng interface. It's not actually used by
anything besides the "rng" algorithm type of AF_ALG, which in turn is
not actually used in practice. Other crypto_rng hardware drivers are
likewise being phased out, leaving just the hwrng support.
Thus, remove it to simplify the code and avoid conflict (and confusion)
with the hwrng interface which is the one that actually matters.
Fixes: e4d9d10ef4be ("crypto: hisilicon/trng - add support for PRNG") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Eric Biggers [Fri, 29 May 2026 23:32:08 +0000 (16:32 -0700)]
crypto: loongson - Remove broken and unused loongson-rng
The loongson-rng rng_alg has several vulnerabilities, including not
providing forward security, and a use-after-free bug due to the use of
wait_for_completion_interruptible().
Meanwhile, the rng_alg framework doesn't really have any purpose in the
first place other than to access the software algorithms crypto/drbg.c
and crypto/jitterentropy.c. Hardware-specific rng_algs have no
in-kernel user, and unlike hwrng there's no feed into the actual Linux
RNG. As such, there's really no point to this code. There are of
course other rng_alg drivers that are similarly unused, but they're
similarly in the process of being phased out, e.g.
https://lore.kernel.org/r/20260529193648.18172-1-ebiggers@kernel.org and
https://lore.kernel.org/r/20260529220430.34135-1-ebiggers@kernel.org
Given that, there's no point in fixing forward these vulnerabilities,
and it makes much more sense to simply roll back the addition of this
driver. If this platform provides TRNG (not PRNG) functionality, it
could make sense to add a hwrng driver, but it would be quite different.
Eric Biggers [Fri, 29 May 2026 22:04:30 +0000 (15:04 -0700)]
crypto: crypto4xx - Remove insecure and unused rng_alg
Remove crypto4xx_rng, as it is insecure and unused:
- It has only a 64-bit security strength, which is highly inadequate.
This can be seen by the fact that crypto4xx_hw_init() seeds it with
only 64 bits of entropy, and the fact that the original commit
mentions that it implements ANSI X9.17 Annex C.
Another issue was that this driver didn't implement the crypto_rng API
correctly, as crypto4xx_prng_generate() didn't return 0 on success.
- No user of this code is known. It's usable only theoretically via the
"rng" algorithm type of AF_ALG. But userspace actually just uses the
actual Linux RNG (/dev/random etc) instead. And rng_algs don't
contribute entropy to the actual Linux RNG either. (This may have
been confused with hwrng, which does contribute entropy.)
Fixes: d072bfa48853 ("crypto: crypto4xx - add prng crypto support") Cc: stable@vger.kernel.org Signed-off-by: Eric Biggers <ebiggers@kernel.org> Acked-by: Christian Lamparter <chunkeey@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Giovanni Cabiddu [Thu, 28 May 2026 15:57:44 +0000 (16:57 +0100)]
crypto: qat - validate RSA CRT component lengths
The generic RSA key parser (rsa_helper.c) bounds each CRT component (p,
q, dp, dq, qinv) by the modulus size n_sz, but qat_rsa_setkey_crt()
allocates half-size DMA buffers (key_sz / 2) and right-aligns each
component with:
memcpy(dst + half_key_sz - len, src, len)
When a CRT component is larger than half_key_sz the subtraction
underflows and memcpy writes past the DMA buffer, causing memory
corruption.
Add a len > half_key_sz check next to the existing !len check for each
of the five CRT components so the driver falls back to the non-CRT path
instead of writing out of bounds.
Fixes: 879f77e9071f ("crypto: qat - Add RSA CRT mode") Cc: stable@vger.kernel.org Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Reviewed-by: Ahsan Atta <ahsan.atta@intel.com> Reviewed-by: Laurent M Coquerel <laurent.m.coquerel@intel.com> Tested-by: Laurent M Coquerel <laurent.m.coquerel@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Pei Xiao [Thu, 11 Jun 2026 00:44:14 +0000 (08:44 +0800)]
hwmon: (gpd-fan) Reject EC PWM value 0 as invalid
The EC firmware is expected to return values in [1, pwm_max]. A read of 0
is illegal and would cause underflow in the conversion formula. Explicitly
check for 0 and return -EIO.
Add tail-call selftests for prog-array ownership when cgroup storage
is in use. Verify that loading succeeds when callers and callees reuse
the owner's cgroup storage map, and that loading fails for a different
storage map and for the A(storage) -> B(no storage) -> C(storage)
bridge case addressed in the previous commit.
Also verify that a storage-less leaf program which cannot perform tail
calls itself is still allowed to join a storage-owned prog array, while
a storage-less tail-caller is rejected also at map update time.
Signed-off-by: Lin Ma <malin89@huawei.com> Signed-off-by: Rongzhen Cui <cuirongzhen@huawei.com> Signed-off-by: Jingguo Tan <tanjingguo@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20260610105539.705887-2-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Daniel Borkmann [Wed, 10 Jun 2026 10:55:38 +0000 (12:55 +0200)]
bpf: Tighten cgroup storage cookie checks for prog arrays
The fix in commit abad3d0bad72 ("bpf: Fix oob access in cgroup local
storage") is still incomplete. The prog-array compatibility check
treats a program with no cgroup storage as compatible with any stored
storage cookie. This allows a storage-less program to bridge a tail
call chain between an entry program and a storage-using callee even
though cgroup local storage at runtime still follows the caller's
context, that is, A -> B(no storage) -> C(storage) path.
Requiring exact cookie equality would break the legitimate case of a
storage-less leaf program being tail called from a storage-using one.
Instead, only accept a zero storage cookie if the program cannot
perform tail calls itself. This keeps A -> B(no storage) working
while rejecting the A -> B(no storage) -> C(storage) bridge.
Fixes: abad3d0bad72 ("bpf: Fix oob access in cgroup local storage") Reported-by: Lin Ma <malin89@huawei.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Yonghong Song <yonghong.song@linux.dev> Link: https://lore.kernel.org/r/20260610105539.705887-1-daniel@iogearbox.net Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Abel Vesa [Tue, 9 Jun 2026 12:02:49 +0000 (15:02 +0300)]
pinctrl: qcom: eliza: Add missing sdc2 pin function mappings
GPIOs 38, 39, 48 and 49 support the SDC2 DATA function, while
GPIO 51 supports SDC2 CMD and GPIO 62 supports SDC2 CLK.
However, the sdc2 pin function is not listed in the corresponding
pingroup definitions, preventing these pins from being muxed for
SDC2 operation.
Add the missing sdc2 function mappings.
Fixes: 6f26989e15fb ("pinctrl: qcom: Add Eliza pinctrl driver") Signed-off-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>
pinctrl: Use named initializers for arrays of i2c_device_data
While being less compact, using named initializers allows to more easily
see which members of the structs are assigned which value without having
to lookup the declaration of the struct. And it's also more robust
against changes to the struct definition.
The mentioned robustness is relevant for a planned change to struct
i2c_device_id that replaces .driver_data by an anonymous union.
While touching all these arrays, unify usage of whitespace in the list
terminator.
This patch doesn't modify the compiled arrays, only their representation
in source form benefits. The former was confirmed with x86 and arm64
builds.
Rosen Penev [Wed, 3 Jun 2026 03:11:35 +0000 (20:11 -0700)]
i2c: mxs: add missing kernel-doc for struct mxs_i2c_dev members
Add kernel-doc documentation for the struct members that were previously
undocumented. This fixes warnings when building with W=1 and ensures
the struct is fully documented per kernel-doc conventions.
Arnd Bergmann [Wed, 10 Jun 2026 20:41:54 +0000 (22:41 +0200)]
Merge tag 'imx-dt64-7.2-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into soc/dt
i.MX arm64 device tree changes for v7.2 (part2)
- Revert the 32-bit non-prefetchable PCIe window from 3 GiB back to 1 GiB
to prevent overlap between inbound DMA address space and low system RAM.
Such overlap can cause DMA transactions to be routed to a BAR on the same
host bridge instead of system memory.
* tag 'imx-dt64-7.2-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux:
arm64: dts: lx2160a-rev2: avoid 32-bit pcie window system ram overlap
Arnd Bergmann [Wed, 10 Jun 2026 20:39:38 +0000 (22:39 +0200)]
Merge tag 'imx-dt64-7.2' of git://git.kernel.org/pub/scm/linux/kernel/git/frank.li/linux into soc/dt
i.MX dt64 changes for v7.2
New Board Support:
Added 15+ new boards including i.MX95 (FRDM PRO, Aquila, Audio Board v2),
i.MX93/91 (Variscite DART/VAR-SOM), i.MX8 (TQMa8QM, SolidRun i.MX8DXL
HummingBoard), Toradex Verdin Zinnia variants, and LX2160A Half Twins.
PCIe Improvements:
Added Root Port nodes and PERST properties across
iMX8MM/MP/MQ/DXL/QM/QXP/95, new PCIe support for iMX94/943, common M.2
PCIe overlay, fixed outbound address space configuration
Graphics, Camera and Display:
Mali G310 GPU for iMX952, HDMI for iMX8MP PhyBoard, extensive DH
Electronics panel overlays, Extensive overlay ecosystem for DH
Electronics iMX8MP boards, PhyBoard PEB-AV-18, camera (OV5640), and
ethernet configuration overlays
Peripheral Support:
S32G2/G3 PIT/ADC/PWM, iMX8ULP CSI/ISI, iMX943 SD WiFi, USB hub for
LX2160A, TPM/CAN/ADC support for Variscite boards, Bluetooth and UART
enhancements for Toradex SMARC boards.
pinctrl: qcom: lpass-lpi: drop unused runtime-PM write helper
lpi_gpio_write() became unused after the PM clock runtime conversion
switched write paths to register helper calls inside callers that already
hold an active runtime-PM reference.
With -Werror this triggers:
error: 'lpi_gpio_write' defined but not used [-Wunused-function]
Drop the dead wrapper and rename the low-level MMIO helpers from
__lpi_gpio_* to lpi_gpio_*_reg for neutral register-accessor naming.
qat_vf_resume_write() checks filp->f_pos before taking migf->lock, but
copies into the migration-state buffer after taking the lock and
re-reading the shared file position.
Two concurrent writers could therefore pass the bounds check with the
old offset, then have the second writer copy after the first advanced
f_pos, writing past the end of the migration-state buffer.
Take migf->lock before doing the boundary checks.
Fixes: bb208810b1ab ("vfio/qat: Add vfio_pci driver for Intel QAT SR-IOV VF devices") Reviewed-by: Ahsan Atta <ahsan.atta@intel.com> Signed-off-by: Giovanni Cabiddu <giovanni.cabiddu@intel.com> Link: https://lore.kernel.org/r/20260608151317.136613-1-giovanni.cabiddu@intel.com Signed-off-by: Alex Williamson <alex@shazbot.org>
Danny D. [Mon, 1 Jun 2026 21:18:28 +0000 (00:18 +0300)]
HID: intel-thc-hid: intel-quickspi: reset touch IC on system resume
On the Surface Pro 10 (Meteor Lake) the touchscreen stops working after a
suspend/resume cycle and only recovers after a reboot. The driver logs
"GET_DEVICE_INFO: recv failed: -11" on resume.
This platform suspends through s2idle: /sys/power/mem_sleep exposes
"[s2idle]" as the only state, there is no "deep"/S3 entry at all. The
touch IC nonetheless loses power across that s2idle suspend, the same
way it does across hibernation. quickspi_resume() only re-selects the
THC port, restores interrupts and DMA and sends a HIDSPI_ON command,
assuming the touch IC kept its power and state. When it has actually
lost power the HIDSPI_ON command is never acknowledged and the
descriptor read fails, leaving the touchscreen dead until the module is
reloaded.
quickspi_restore() already handles this for hibernation by
reconfiguring the THC SPI/LTR settings and running reset_tic() to
re-enumerate the device. Make quickspi_resume() do the same when the
device is not a wake source. A wake-enabled device keeps its power and
state across suspend, so it stays on the light restore path: resetting
it would discard a pending wake touch event and break wake-on-touch.
The non-wake path mirrors the existing quickspi_restore() sequence,
including enabling interrupts before reset_tic(), so it introduces no
new ordering relative to code already in the driver.
This change has been validated on a Surface Pro 10 running the
linux-surface kernel across multiple s2idle suspend/resume cycles; it
has not been tested on a mainline build.
Closes: https://github.com/linux-surface/linux-surface/issues/1799 Signed-off-by: Danny D. <d3z.the.dev@gmail.com> Reviewed-by: Even Xu <even.xu@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
Armin Wolf [Wed, 10 Jun 2026 18:01:41 +0000 (20:01 +0200)]
hwmon: (dell-smm) Add Dell Latitude 7530 to fan control whitelist
A user reported that the Dell Latitude 7530 needs to be whitelisted
for the special SMM calls necessary for globally enabling/disabling
BIOS fan control.
Marius Cristea [Wed, 10 Jun 2026 15:19:47 +0000 (18:19 +0300)]
hwmon: temperature: add support for EMC1812
This is the hwmon driver for Microchip EMC1812/13/14/15/33
Multichannel Low-Voltage Remote Diode Sensor Family.
EMC1812 has one external remote temperature monitoring channel.
EMC1813 has two external remote temperature monitoring channels.
EMC1814 has three external remote temperature monitoring channels,
channels 2 and 3 support anti parallel diode.
EMC1815 has four external remote temperature monitoring channels and
channels 1/2 and 3/4 support anti parallel diode.
EMC1833 has two external remote temperature monitoring channels and
channels 1 and 2 support anti parallel diode.
Resistance Error Correction is supported on channels 1/2 and 3/4.
Marius Cristea [Wed, 10 Jun 2026 15:19:46 +0000 (18:19 +0300)]
dt-bindings: hwmon: temperature: add support for EMC1812
This is the devicetree schema for Microchip EMC1812/13/14/15/33
Multichannel Low-Voltage Remote Diode Sensor Family. It also
updates the MAINTAINERS file to include the new driver.
EMC1812 has one external remote temperature monitoring channel.
EMC1813 has two external remote temperature monitoring channels.
EMC1814 has three external remote temperature monitoring channels and
channels 2 and 3 support anti parallel diode.
EMC1815 has four external remote temperature monitoring channels and
channels 1/2 and 3/4 support anti parallel diode.
EMC1833 has two external remote temperature monitoring channels and
channels 1 and 2 support anti parallel diode.
Resistance Error Correction is supported on channels 1/2 and 3/4.
Linus Torvalds [Wed, 10 Jun 2026 18:53:55 +0000 (11:53 -0700)]
Merge tag 'pm-7.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull power management fixes from Rafael Wysocki:
"These address some remaining fallout after introducing dynamic EPP
support in the amd-pstate driver during the current development cycle:
- Restore allowing writing EPP of 0 when in performance mode in the
amd-pstate driver which was unnecessarily disallowed by one of the
recent updates (Mario Limonciello)
- Remove stale documentation of the epp_cached field in struct
amd_cpudata that has been dropped recently (Zhan Xusheng)"
* tag 'pm-7.1-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
cpufreq/amd-pstate: Fix setting EPP in performance mode
cpufreq/amd-pstate: drop stale @epp_cached kdoc
David Laight [Mon, 8 Jun 2026 18:51:21 +0000 (19:51 +0100)]
drivers/of/overlay: Use memcpy() to copy known length strings
Avoid calls to strcpy().
The lengths of the strings have been used for the kzalloc(), replace
the strcpy() calls with memcpy() using the known lengths.
Daniel Golle [Wed, 27 May 2026 19:32:34 +0000 (20:32 +0100)]
dt-bindings: add self-test fixtures for style checker
Provide good/ and bad/ DTS and YAML fixtures plus a small runner that
feeds them to dt-check-style and diffs the output against expected
text files. Wired into a new top-level dt_style_selftest make target
so the suite can be exercised independently of the full tree.
Daniel Golle [Wed, 27 May 2026 19:32:26 +0000 (20:32 +0100)]
dt-bindings: wire style checker into dt_binding_check
Run dt-check-style as part of dt_binding_check_one. The recipe wraps
the tool with scripts/jobserver-exec so worker count follows the GNU
make jobserver -- `make -j N dt_binding_check` constrains the checker
to N workers rather than spawning one per CPU.
Default mode (relaxed) is zero-violation on the current tree, so this
does not introduce new warnings into make dt_binding_check. Stricter
rules are available via --mode=strict (eg. for use by checkpatch.pl in
a future series).
Daniel Golle [Wed, 27 May 2026 19:32:18 +0000 (20:32 +0100)]
scripts/jobserver-exec: propagate child exit status
main() called JobserverExec().run() and discarded its return value,
then the script exited with the implicit status 0. As a result, any
Makefile that wired a build step through jobserver-exec saw the step
silently succeed even when the wrapped command had failed.
Two in-tree callers were affected:
Documentation/devicetree/bindings/Makefile
cmd_chk_style runs a python checker via jobserver-exec and uses
"&& touch $@ || true" so failures leave the stamp file untouched
and the next make rerun reports them again. The swallowed exit
code made the stamp file get created even on failure, caching the
failed run and hiding the reported issues until the inputs change.
scripts/Makefile.vmlinux_o
cmd_gen_initcalls_lds runs scripts/generate_initcall_order.pl via
jobserver-exec; a perl failure was masked by the wrapper.
Return the subprocess exit code from main() and pass it to sys.exit()
so the wrapped command's status reaches make.
Daniel Golle [Wed, 27 May 2026 19:32:10 +0000 (20:32 +0100)]
dt-bindings: add DTS style checker
Add a Python tool that checks DTS coding style on examples in YAML
binding files and on .dts/.dtsi/.dtso source files. Rules are kept in
a small declarative registry, each tagged 'relaxed' (default; must be
zero-violation on the current tree) or 'strict' (opt-in for new
submissions). Promoting a rule from strict to relaxed is a one-line
edit once the tree is clean.
Relaxed mode covers trailing whitespace, tab characters in YAML
examples, mixed tab+space indents, and missing tabs in .dts files.
Strict adds indent unit and consistency checks, blank-line placement,
sibling address ordering, "compatible" and "reg" ordering, and unused
labels.
The tool reads file paths from @argfile and parallelises across CPUs
via -j N. With no -j given it picks up $PARALLELISM (set by
scripts/jobserver-exec from the GNU make jobserver) and falls back to
os.cpu_count() otherwise. Running as one Python invocation amortises
the ruamel.yaml import across the whole tree -- ~2s on a 32-CPU host
vs ~28s sequential.
Carlos Llamas [Sat, 6 Jun 2026 18:15:52 +0000 (18:15 +0000)]
HID: uhid: convert to hid_safe_input_report()
Commit 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing
bogus memset()"), added a check in hid_report_raw_event() to reject
reports if the received data size is smaller than expected. This was
intended to prevent OOB errors by no longer allowing zeroing-out of
shorter reports due to the lack of buffer size information.
However, this leads to regressions in hid_report_raw_event(), where
shorter than expected reports are rejected, even though their buffers
are sufficiently large to be zero-padded.
To solve this issue, Benjamin introduced a safer alternative in commit 206342541fc8 ("HID: core: introduce hid_safe_input_report()"), which
forwards the buffer size and allows hid_report_raw_event() to safely
zero-pad the data.
Convert uhid to use hid_safe_input_report() and pass UHID_DATA_MAX as
the buffer size. This prevents the reported regressions [1], allowing
hid core to zero-pad the shorter reports safely as expected.
Cc: stable@vger.kernel.org Fixes: 0a3fe972a7cb ("HID: core: Mitigate potential OOB by removing bogus memset()") Closes: https://lore.kernel.org/all/ahsh0UtTX6e0ZeHa@google.com/ [1] Signed-off-by: Carlos Llamas <cmllamas@google.com> Reviewed-by: Lee Jones <lee@kernel.org> Closes: https://lore.kernel.org/all/ahsh0UtTX6e0ZeHa@google.com/ Signed-off-by: Jiri Kosina <jkosina@suse.com>
of: cpu: add check in __of_find_n_match_cpu_property()
In __of_find_n_match_cpu_property(), checking the variable ac for 0 won't
prevent a possible overflow when multiplying it by sizeof(*cell). Besides,
of_read_number() (called in the *for* loop) can't return correct result if
that variable (which equals the #address-cells prop's value) exceeds 2, so
additionally checking for that seems logical...
Found by Linux Verification Center (linuxtesting.org) with the Svace static
analysis tool.
Dave Jiang [Fri, 5 Jun 2026 18:44:26 +0000 (11:44 -0700)]
cxl/test: Zero out LSA backing memory to avoid leaking to user
Memory through vmalloc() is not zeroed out. When this memory is copied
into output payload, it leaks memory content to user. Use vzalloc()
instead to zero out the memory.
Dave Jiang [Fri, 5 Jun 2026 17:12:38 +0000 (10:12 -0700)]
cxl/test: Fix integer overflow in mock LSA bounds checks
Pre-existing issue discovered by sashiko-bot.
mock_get_lsa() and mock_set_lsa() validate the requested LSA range with
"offset + length > LSA_SIZE". Both offset and length are u32 and, in
mock_get_lsa(), both are taken directly from the user-supplied payload.
The addition is evaluated modulo 2^32, so a large offset combined with a
small length wraps around and passes the check.
Rewrite the checks to first bound offset, then compare length against the
remaining LSA size.
Dave Jiang [Fri, 5 Jun 2026 18:15:08 +0000 (11:15 -0700)]
cxl/test: Verify cmd->size_in before accessing payload
Several mock mailbox handlers access input payload fields before
verifying that cmd->size_in is large enough for the corresponding
structure.
To ensure invalid commands are rejected before any payload data is
consumed, add missing size checks and move existing checks ahead of
the first payload field access.
[dj: Updated commit log per Alison's comments. ]
Fixes: 7d3eb23c4ccf ("tools/testing/cxl: Introduce a mock memory device + driver") Fixes: d1dca858f058 ("cxl/test: Add generic mock events") Fixes: f6448cb5f2f3 ("tools/testing/cxl: add firmware update emulation to CXL memdevs") Fixes: e77e9c107978 ("cxl/test: Add Get Feature support to cxl_test") Link: https://lore.kernel.org/linux-cxl/20260605143748.235271F00893@smtp.kernel.org/ Suggested-by: sashiko-bot Tested-by: Alison Schofield <alison.schofield@intel.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
cxl/port: update reference to removed CONFIG_PROVE_CXL_LOCKING
A comment in drivers/cxl/port.c refers to CONFIG_PROVE_CXL_LOCKING,
which was removed in commit 38a34e10768c ("cxl: Drop
cxl_device_lock()"). That commit switched CXL subsystem locking to
custom lock classes, which can be validated via the standard
CONFIG_PROVE_LOCKING option. Update the comment to reflect this.
Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.
Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Reviewed-by: Dan Williams <djbw@kernel.org> Reviewed-by: Richard Cheng <icheng@nvidia.com> Reviewed-by: Alison Schofield <alison.schofield@intel.com> Link: https://patch.msgid.link/20260610042101.222349-1-enelsonmoore@gmail.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Maher Sanalla [Tue, 9 Jun 2026 11:16:38 +0000 (14:16 +0300)]
RDMA/core: Fix broadcast address falsely detected as local
When rdma_resolve_addr() is invoked with a broadcast destination on an
IPoIB interface, is_dst_local() inspects the resolved route and
incorrectly concludes that the address is local. As a result, the
resolution fails with -ENODEV.
The issue stems from using '&' to compare rt_type with RTN_LOCAL. The
RTN_* values form a sequential enum, not a bitmask (RTN_LOCAL=2,
RTN_BROADCAST=3). Thus, "rt_type & RTN_LOCAL" yields a non-zero result
for a broadcast route as well.
Replace '&' with '==' when comparing rt_type against RTN_LOCAL.
Link: https://patch.msgid.link/r/20260609-fix-rdma-resolve-addr-v1-1-449b8b4e6c09@nvidia.com Cc: stable@vger.kernel.org Fixes: c31e4038c97f ("RDMA/core: Use route entry flag to decide on loopback traffic") Signed-off-by: Maher Sanalla <msanalla@nvidia.com> Reviewed-by: Vlad Dumitrescu <vdumitrescu@nvidia.com> Signed-off-by: Edward Srouji <edwards@nvidia.com> Reviewed-by: Parav Pandit <parav@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Ruoyu Wang [Sat, 6 Jun 2026 04:06:44 +0000 (12:06 +0800)]
RDMA/bnxt_re: Check debugfs parameter allocation for failure
bnxt_re_debugfs_add_pdev() allocates per-file private data for the CC
configuration debugfs entries. The loop that initializes those entries
uses rdev->cc_config_params immediately, so allocation failure would lead
to NULL pointer dereferences while setting up debugfs.
Debugfs is best-effort. If the CC configuration private data cannot be
allocated just stop.
Tianchu Chen [Fri, 29 May 2026 13:42:47 +0000 (13:42 +0000)]
HID: hid-goodix-spi: validate report size to prevent stack buffer overflow
goodix_hid_set_raw_report() builds a protocol frame in a 128-byte stack
buffer (tmp_buf), writing an 11-12 byte header followed by the
caller-supplied report data. The HID core caps report size at
HID_MAX_BUFFER_SIZE (16384) by default, while the driver does not set
hid_ll_driver.max_buffer_size and performs no bounds checking before
copying the payload:
memcpy(tmp_buf + tx_len, buf, len);
A hidraw SET_REPORT ioctl with a report larger than ~116 bytes
overflows the stack buffer.
Add a size check after constructing the header, rejecting reports that
would exceed the buffer capacity.
Discovered by Atuin - Automated Vulnerability Discovery Engine.
drm/xe: include all registered queues in TLB invalidation
Context-based TLB invalidation currently selects only scheduling-active
exec queues via q->ops->active(). During rebind flows, queues may be
suspended (or transitioning through resume) while still owning valid
translations, causing them to be skipped from invalidation and leading
to missed TLB invalidations on LR rebinds.
The underlying issue is a TOCTOU: q->guc->state bits are flipped lock-free
from enable_scheduling(), disable_scheduling{,_deregister}(), the
suspend/resume sched-msg handlers, handle_sched_done(), and
guc_exec_queue_stop(); nothing in send_tlb_inval_ctx_ppgtt() serializes
against them, so any state-based predicate can race.
Include all the registered queues so that TLB invalidations are not
missed. This is race-free because list membership on vm->exec_queues.list
is stable under vm->exec_queues.lock held by the caller. The performance
impact is expected to be minimal and harmless. If it does turn out to be
a concern, we can come back with a race-safe solution to ignore certain
queues.
Fixes: 6cdaa5346d6f ("drm/xe: Add context-based invalidation to GuC TLB invalidation backend") Assisted-by: Claude:claude-opus-4.6 Suggested-by: Thomas Hellstrom <thomas.hellstrom@linux.intel.com> Signed-off-by: Tangudu Tilak Tirumalesh <tilak.tirumalesh.tangudu@intel.com> Reviewed-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Brost <matthew.brost@intel.com> Link: https://patch.msgid.link/20260608162745.338725-2-tilak.tirumalesh.tangudu@intel.com Signed-off-by: Shuicheng Lin <shuicheng.lin@intel.com>
(cherry picked from commit aa625e1e9f0710e424fe4f0e3f032807df81b5b0) Signed-off-by: Matthew Brost <matthew.brost@intel.com>
Raag Jadav [Tue, 2 Jun 2026 04:48:43 +0000 (10:18 +0530)]
drm/xe/drm_ras: Add per node cleanup action
cleanup_node_param() is not registered for previous node in case of counter
allocation failure, which results in stale memory of previous node that
isn't cleaned up on unwind. Add per node cleanup action which guarantees
cleanup on unwind and also simplifies the cleanup logic.
Raag Jadav [Tue, 2 Jun 2026 04:48:42 +0000 (10:18 +0530)]
drm/xe/drm_ras: Make counter allocation drm managed
cleanup_node_param() is not registered for previous node in case of counter
allocation failure, which results in stale memory of previous node that
isn't cleaned up on unwind. Fix this using drm managed allocation, which is
guaranteed to be cleaned up on unwind.
Jani Nikula [Fri, 15 May 2026 16:09:20 +0000 (19:09 +0300)]
drm/xe/display: fix oops in suspend/shutdown without display
The xe driver keeps track of whether to probe display, and whether
display hardware is there, using xe->info.probe_display. It gets set to
false if there's no display after intel_display_device_probe(). However,
the display may also be disabled via fuses, detected at a later time in
intel_display_device_info_runtime_init().
In this case, the xe driver does for_each_intel_crtc() on uninitialized
mode config in xe_display_flush_cleanup_work(), leading to a NULL
pointer dereference, and generally calls display code with display info
cleared.
Check for intel_display_device_present() after
intel_display_device_info_runtime_init(), and reset
xe->info.probe_display as necessary. Also do unset_display_features()
for completeness, although display runtime init has already done
that. This will need to be unified across all cases later.
Move intel_display_device_info_runtime_init() call slightly earlier,
similar to i915, to avoid a bunch of unnecessary setup for no display
cases.
Note #1: The xe driver has no business doing low level display plumbing
like for_each_intel_crtc() to begin with. It all needs to happen in
display code.
Note #2: The actual bug is present already in commit 44e694958b95
("drm/xe/display: Implement display support"), but the oops was likely
introduced later at commit ddf6492e0e50 ("drm/xe/display: Make display
suspend/resume work on discrete").
Hector Zelaya [Wed, 27 May 2026 16:01:32 +0000 (10:01 -0600)]
HID: nintendo: add support for HORI Wireless Switch Pad
Add support for the HORI Wireless Switch Pad (vendor 0x0f0d, product
0x00f6), a licensed third-party Nintendo Switch Pro Controller.
The controller reports controller type 0x06 (vs 0x03 for first-party
Pro Controllers) and has the following quirks:
- SPI flash calibration data is incompatible; use default stick
calibration values instead.
- X and Y button bits are swapped compared to first-party controllers;
add a dedicated button mapping table.
- Rumble and IMU enable may timeout (no vibration motor in hardware);
treat as non-fatal for licensed controllers.
Tested over Bluetooth on NixOS with kernel 7.0.5 and 7.0.10:
- All 14 buttons map correctly
- Player LED sets on connect
- Sticks report correctly with default calibration
- IMU/gyro data streams at 60Hz
- D-pad reports on ABS_HAT0X/HAT0Y
Device information:
Bluetooth name: Lic Pro Controller
Bluetooth HID: 0005:0F0D:00F6
Dave Carey [Thu, 14 May 2026 19:32:58 +0000 (15:32 -0400)]
HID: multitouch: Honor ContactCount for Yoga Book 9 to suppress ghost contacts
The INGENIC 17EF:6161 firmware on the Lenovo Yoga Book 9 14IAH10
does not clear stale contact slots when fingers are lifted. Each
HID report contains up to 10 finger slots, but only the first
ContactCount slots represent valid contacts; the remaining slots
retain TipSwitch=1 with positions from previous touches.
Raw HID capture confirms this: across a 60-second capture with
repeated multi-finger gestures, 90% of frames had more TipSwitch=1
slots than the reported ContactCount. The ContactCount field itself
is always accurate.
Add MT_QUIRK_CONTACT_CNT_ACCURATE to the MT_CLS_YOGABOOK9I class so
the driver stops processing slots once ContactCount valid contacts
have been consumed, discarding the stale ghost entries per HID
specification section 17. MT_QUIRK_NOT_SEEN_MEANS_UP (already in
the class) ensures that any slot skipped by this guard is released
via INPUT_MT_DROP_UNUSED at frame sync.
Signed-off-by: Dave Carey <carvsdriver@gmail.com> Tested-by: Dave Carey <carvsdriver@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
Davide Ornaghi [Wed, 10 Jun 2026 10:39:13 +0000 (12:39 +0200)]
netfilter: nft_meta_bridge: fix stale stack leak via IIFHWADDR register
NFT_META_BRI_IIFHWADDR declares its destination register with
len = ETH_ALEN (6 bytes), which the register-init tracking rounds up to
two 32-bit registers (8 bytes). nft_meta_bridge_get_eval() then does
memcpy(dest, br_dev->dev_addr, ETH_ALEN), writing only 6 bytes and
leaving the upper 2 bytes of the second register as uninitialised
nft_do_chain() stack. A downstream load of that register span leaks
those stale bytes to userspace.
Zero the second register before the memcpy so the full declared span is
written.
Oleg Makarenko [Tue, 9 Jun 2026 16:00:27 +0000 (19:00 +0300)]
HID: pidff: Use correct effect type in effect update
When updating an existing effect, the effect type from the last created
effect was sent to the device instead of the updated one.
This caused incorrect reports when a game creates multiple different
effects and updates only one that is not the last created.
Fixes FFB in multiple games that create multiple simultaneous effects
(Forza Horizon 5/6).
Davide Ornaghi [Wed, 10 Jun 2026 10:39:12 +0000 (12:39 +0200)]
netfilter: nft_fib: fix stale stack leak via the OIFNAME register
For NFT_FIB_RESULT_OIFNAME the destination register is declared with
len = IFNAMSIZ (four 32-bit registers), but on the lookup-fail,
RTN_LOCAL and oif-mismatch paths nft_fib{4,6}_eval() only writes one
register via "*dest = 0". The remaining three registers are left as
whatever was on the stack in nft_do_chain()'s struct nft_regs, and a
downstream expression that loads the register span can leak that
uninitialised kernel stack to userspace.
The NFTA_FIB_F_PRESENT existence check has the same shape: it is only
meaningful for NFT_FIB_RESULT_OIF, yet it was accepted for any result type
while the eval stores a single byte via nft_reg_store8(), leaving the rest
of the declared span stale.
Fix both:
- replace the bare "*dest = 0" in the eval with nft_fib_store_result(),
which strscpy_pad()s the whole IFNAMSIZ for OIFNAME (and is already
used on the other early-return path), and
- restrict NFTA_FIB_F_PRESENT to NFT_FIB_RESULT_OIF and declare its
destination as a single u8, so the marked span matches the one byte
the eval writes.
netfilter: nft_exthdr: fix register tracking for F_PRESENT flag
nft_exthdr_init() passes user-controlled priv->len to
nft_parse_register_store(), which marks that many bytes in the
register bitmap as initialized. However, when NFT_EXTHDR_F_PRESENT
is set, the eval paths write only 1 byte (nft_reg_store8) or
4 bytes (*dest = 0 on TCP/DCCP error path). When len > 4,
registers beyond the first are never written, retaining
uninitialized stack data from nft_regs.
Bail out if userspace requests too much data when F_PRESENT is set.
Reported-by: Ji'an Zhou <eilaimemedsnaimel@gmail.com> Fixes: c078ca3b0c5b ("netfilter: nft_exthdr: Add support for existence check") Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Xiang Mei [Tue, 9 Jun 2026 22:55:02 +0000 (15:55 -0700)]
netfilter: nf_log: validate MAC header was set before dumping it
The fallback path of dump_mac_header() guards the MAC header access
only with "skb->mac_header != skb->network_header", without checking
skb_mac_header_was_set(). When the MAC header is unset, mac_header is
0xffff, so the test passes and skb_mac_header(skb) returns
skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads
dev->hard_header_len bytes out of bounds into the kernel log.
This is reachable via the netdev logger: nf_log_unknown_packet() calls
dump_mac_header() unconditionally, and an skb sent through AF_PACKET
with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still
unset (__dev_queue_xmit(), which would reset it, is bypassed).
Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already
uses, and replace the open-coded MAC header length test with
skb_mac_header_len(). Only skbs with an unset MAC header are affected;
valid ones are dumped as before.
The native and compat get-entries paths copy the fixed rule entry header
from the kernelized rule blob to userspace before overwriting the entry's
counter fields with a sanitized counter snapshot.
On SMP kernels, entry->counters.pcnt contains the percpu allocation
address used by x_tables rule counters. A caller can provide a userspace
buffer that faults during the initial fixed-header copy after pcnt has
been copied but before the later sanitized counter copy runs. The syscall
then returns -EFAULT while leaving the raw percpu pointer in userspace.
Copy only the fixed entry prefix before counters from the kernelized rule
blob, then copy the sanitized counter snapshot into the counter field.
Apply this ordering to the IPv4, IPv6, and ARP native and compat
get-entries implementations so a fault cannot expose the internal percpu
counter pointer.
Fixes: 71ae0dff02d7 ("netfilter: xtables: use percpu rule counters") Signed-off-by: Kyle Zeng <kylebot@openai.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Weiming Shi [Wed, 3 Jun 2026 07:38:17 +0000 (00:38 -0700)]
netfilter: nf_conntrack: destroy stale expectfn expectations on unregister
NAT helpers such as nf_nat_h323 store a raw pointer to module text in
exp->expectfn (e.g. ip_nat_q931_expect). nf_ct_helper_expectfn_unregister()
only unlinks the callback descriptor and never walks the expectation table,
so an expectation pending at module removal survives with a dangling
exp->expectfn into freed module text.
When the expected connection arrives, init_conntrack() invokes
exp->expectfn(), now a stale pointer into the unloaded module. Reproduced
on a KASAN build by loading the H.323 helpers, creating a Q.931
expectation, unloading nf_nat_h323, then connecting to the expected port:
Reaching the dangling state requires CAP_SYS_MODULE in the initial user
namespace to remove a NAT helper that still has live expectations, so this
is a robustness fix; leaving an expectation pointing at freed text is wrong
regardless.
Add nf_ct_helper_expectfn_destroy(), which walks the expectation table and
drops every expectation whose ->expectfn matches the descriptor being torn
down. Call it from each NAT helper's exit path after the existing RCU grace
period, so no expectation outlives the code it points at and no extra
synchronize_rcu() is introduced. With the fix, the same reproducer runs to
completion without the Oops.
Fixes: f587de0e2feb ("[NETFILTER]: nf_conntrack/nf_nat: add H.323 helper port") Reported-by: Xiang Mei <xmei5@asu.edu> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Weiming Shi <bestswngs@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
ebt_redirect_tg() dereferences br_port_get_rcu() return without a
NULL check, causing a kernel panic when the bridge port has been
removed between the original hook invocation and an NFQUEUE
reinject.
A mere NULL check isn't sufficient, however. As sashiko review
points out userspace can not only remove the port from the bridge,
it could also place the device in a different virtual device, e.g.
macvlan.
If this happens, we must drop the packet, there is no way for us to
reinject it into the bridge path.
Switch to _upper API, we don't need the bridge port structure.
Also, this fix keeps another bug intact:
Both nfnetlink_log and nfnetlink_queue use CONFIG_BRIDGE_NETFILTER
too aggressive, which prevents certain logging features when queueing
in bridge family: NETFILTER_FAMILY_BRIDGE can be enabled while the old
CONFIG_BRIDGE_NETFILTER cruft is off.
Fixes tag is a common ancestor, this was always broken.
Fixes: f350a0a87374 ("bridge: use rx_handler_data pointer to store net_bridge_port pointer") Reported-by: Ji'an Zhou <eilaimemedsnaimel@gmail.com> Assisted-by: Claude:claude-sonnet-4-6 Signed-off-by: Florian Westphal <fw@strlen.de> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Myeonghun Pak [Thu, 4 Jun 2026 04:56:58 +0000 (13:56 +0900)]
HID: wacom: stop hardware after post-start probe failures
wacom_parse_and_register() starts HID hardware before registering inputs
and initializing pad LEDs/remotes. Those later steps can fail, but their
error paths currently release Wacom resources without stopping the HID
hardware.
Route post-hid_hw_start() failures through hid_hw_stop() before
releasing driver resources.
This issue was identified during our ongoing static-analysis research while
reviewing kernel code.
Fixes: c1d6708bf0d3 ("HID: wacom: Do not register input devices until after hid_hw_start") Cc: stable@vger.kernel.org Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.com>
Matteo Croce [Sat, 23 May 2026 10:55:45 +0000 (12:55 +0200)]
HID: core: demote warning to debug level
The log level for short messages was changed from debug to warning,
flooding syslog on systems with devices that regularly send
short reports, in my case an UPS:
$ dmesg |grep -c 'Event data for report .* was too short'
35
Felix Gu [Wed, 10 Jun 2026 12:08:17 +0000 (20:08 +0800)]
spi: rzv2h-rspi: Fix SPDR read access width for 16-bit RX
The RZ/V2H hardware manual (section 7.5.2.2.1) specifies that read access
size for the SPI Data Register (SPDR) are fixed at 32 bits. The
RZV2H_RSPI_RX macro for the 16-bit data path used readw(), violating
this requirement.
Switch to readl() for the 16-bit RX path to conform to the hardware
specification.
Fixes: 8b61c8919dff ("spi: Add driver for the RZ/V2H(P) RSPI IP") Suggested-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Felix Gu <ustc.gu@gmail.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com> Link: https://patch.msgid.link/20260610-rzv2h-rspi-v2-1-40c80b4a2c90@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
Vishnu Sankar [Fri, 22 May 2026 05:06:32 +0000 (14:06 +0900)]
HID: lenovo: Use KEY_PERFORMANCE capability for ThinkPad X12 Tab Gen 2
The X12 Tab Gen 2 emits KEY_PERFORMANCE via Fn+F8 through the raw
event handler but never declared the capability via
input_set_capability(). This prevents userspace tools from
discovering the key through evdev capability bits.
Vishnu Sankar [Fri, 22 May 2026 05:06:31 +0000 (14:06 +0900)]
HID: lenovo: Add support for ThinkPad X13 Folio keyboard
Add USB ID support for the ThinkPad X13 detachable keyboard.
The Keyboard uses the same HID raw event protocol as the ThinkPad
X12 Gen 2. The functionality stays the same with X12 Gen 2 Keyboards.
Also declare KEY_PERFORMANCE capability in lenovo_input_configured()
for X13 detachable, allowing userspace to discover the key via evdev
capability bits.
Yuho Choi [Mon, 8 Jun 2026 16:22:30 +0000 (12:22 -0400)]
sctp: Unwind address notifier registration on failure
sctp_v4_add_protocol() and sctp_v6_add_protocol() register their
address notifiers before registering the SCTP protocol handlers. If
protocol registration fails, the functions return without unregistering
the notifiers.
Unregister the notifiers on the protocol registration failure paths.
Also propagate notifier registration failures instead of ignoring them.
Josua Mayer [Wed, 10 Jun 2026 11:45:23 +0000 (13:45 +0200)]
arm64: dts: lx2160a-rev2: avoid 32-bit pcie window system ram overlap
A 3GB non-prefetchable PCIe bus window can overlap with inbound DMA
addresses for low system RAM, so DMA transactions may be routed to a BAR
on the same host bridge instead of memory.
Change the 32-bit non-prefetchable PCIe window back from 3GB to 1GB on all
controllers, avoiding that overlap while keeping the added 64-bit
prefetchable region.
This partially reverts commit 9ed301397090 ("arm64: dts: lx2160a-rev2:
extend 32-bit and add 64-bit pci regions").
Fixes: 9ed301397090 ("arm64: dts: lx2160a-rev2: extend 32-bit and add 64-bit pci regions") Reported-by: Arnd Bergmann <arnd@arndb.de> Closes: https://lore.kernel.org/r/9e6326f6-dad1-4169-a63c-e62ee5b341f2@app.fastmail.com Signed-off-by: Josua Mayer <josua@solid-run.com> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Frank Li <Frank.Li@nxp.com>
Breno Leitao [Mon, 8 Jun 2026 09:32:05 +0000 (02:32 -0700)]
rds: mark snapshot pages dirty in rds_info_getsockopt()
rds_info_getsockopt() pins the destination user pages with FOLL_WRITE and
the RDS_INFO_* producers memcpy the snapshot into them through
kmap_atomic(). Because that copy goes through the kernel direct map, the
dirty bit on the user PTE is never set, so unpin_user_pages() releases the
pages without marking them dirty. A file-backed destination page can then
be reclaimed without writeback, silently discarding the copied data.
Use unpin_user_pages_dirty_lock() with make_dirty=true so the modified
pages are marked dirty before they are unpinned.
Eric Dumazet [Mon, 8 Jun 2026 16:46:13 +0000 (16:46 +0000)]
ip6_vti: fix incorrect tunnel matching in vti6_tnl_lookup()
In vti6_tnl_lookup(), when an exact match for a tunnel fails,
the code falls back to searching for wildcard tunnels:
- Tunnels matching the packet's local address, with any remote address
wildcard remote).
- Tunnels matching the packet's remote address, with any local address
(wildcard local).
However, vti6 stores all these different types of tunnels in the same
hash table (ip6n->tnls_r_l) prone to hash collisions.
The bug is that the fallback search loops in vti6_tnl_lookup() were
missing checks to ensure that the candidate tunnel actually has
a wildcard address.
Fixes: fbe68ee87522 ("vti6: Add a lookup method for tunnels with wildcard endpoints.") Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Steffen Klassert <steffen.klassert@secunet.com> Reviewed-by: Nicolas Dichtel <nicolas.dichtel@6wind.com> Link: https://patch.msgid.link/20260608164613.933023-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Yizhou Zhao [Sun, 7 Jun 2026 11:24:04 +0000 (19:24 +0800)]
fddi: validate skb length before parsing headers
fddi_type_trans() reads FDDI header fields from skb->data without first
checking that the received frame is long enough for those fields.
The destination address spans offsets 1-6 and the LLC dsap field is at
offset 13. For SNAP frames, fddi->hdr.llc_snap.ethertype is at offsets
19-20. A truncated 15-byte frame with dsap != 0xe0 therefore enters the
SNAP branch and reads the ethertype past the end of the frame.
KASAN reports this when such a frame is processed through a dummy FDDI
netdev that calls the real fddi_type_trans() on an exact kmalloc() copy
of the frame:
BUG: KASAN: slab-out-of-bounds in fddi_type_trans+0x385/0x3a0
Read of size 2 at addr ffff888009c6fe33
The buggy address is located 4 bytes to the right of
allocated 15-byte region [ffff888009c6fe20, ffff888009c6fe2f)
Reject short frames before reading the fields: require the minimum 802.2
header length before accessing dsap or daddr, and require the full SNAP
header length before reading the SNAP ethertype. Returning protocol 0
causes the malformed packet to be ignored by protocol handlers.
Cc: <stable+noautosel@kernel.org> # devices should drop runt frames, repro uses a fake driver Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn> Reported-by: Ao Wang <wangao@seu.edu.cn> Reported-by: Xuewei Feng <fengxw06@126.com> Reported-by: Qi Li <qli01@tsinghua.edu.cn> Reported-by: Ke Xu <xuke@tsinghua.edu.cn> Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260607112408.92988-1-zhaoyz24@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Yonghong Song [Wed, 10 Jun 2026 05:18:31 +0000 (22:18 -0700)]
selftests/bpf: Fix bpf_iter/task_vma test
For selftest bpf_iter/task_vma, I got a failure like below on my qemu run:
test_task_vma_common:FAIL:compare_output unexpected compare_output:
actual
'561593546000-561593585000r--p0000000000:241256579534/root/devshare/bpf-next/tools/testing/selftests/bpf/test_progs'
!= expected
'561593546000-561593585000r--p0000000000:245551546830/root/devshare/bpf-next/tools/testing/selftests/bpf/test_progs'
Further debugging found out file->f_inode->i_ino value may exceed 32bit,
e.g., i_ino = 0x14c2eae35, but the format string is '%u'. This caused
inode mismatch between bpf iter and proc result.
Fix the issue by using format string '%llu' to accommodate 64bit i_ino.
Fixes: e8168840e16c ("selftests/bpf: Add test for bpf_iter_task_vma") Signed-off-by: Yonghong Song <yonghong.song@linux.dev> Acked-by: Leon Hwang <leon.hwang@linux.dev> Link: https://lore.kernel.org/r/20260610051831.1346659-1-yonghong.song@linux.dev Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Jakub Kicinski [Wed, 10 Jun 2026 14:59:45 +0000 (07:59 -0700)]
Merge tag 'wireless-next-2026-06-10' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Johannes Berg says:
====================
Quite a few last updates, notably:
- b43: new support for an 11n device
- mt76:
- mt792x broken usb transport detection
- mt7921 regd improvements
- mt7927 support
- iwlwifi:
- more kunit tests
- FW version updates
- ath12k: WDS support
- rtw89:
- RTL8922AU support
- USB 3 mode switch for performance
- better monitor radiotap support
- RTL8922DE preparations
- cfg80211/mac80211:
- update UHR to D1.4, UHR DBE support
- finally remove 5/10 MHz support
- S1G rate reporting
- multicast encapsulation offload
* tag 'wireless-next-2026-06-10' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next: (285 commits)
b43: add RF power offset for N-PHY r8 + radio 2057 r8
b43: add channel info table for N-PHY r8 + radio 2057 r8
b43: add IPA TX gain table for N-PHY r8 + radio 2057 r8
b43: support radio 2057 rev 8
b43: route d11 corerev 22 to 24-bit indirect radio access
b43: add d11 core revision 0x16 to id table
b43: add firmware mappings for rev22
rfkill: Replace strcpy() with memcpy()
wifi: brcmfmac: flowring: simplify flow allocation
wifi: brcm80211: change current_bss to value
wifi: ath12k: enable IEEE80211_VHT_EXT_NSS_BW_CAPABLE when NSS ratio is reported
wifi: ath12k: fix EAPOL TX failure caused by stale tcl_metadata bits
wifi: ath: Update copyright in testmode_i.h
wifi: ath10k: Update Qualcomm copyrights
wifi: ath11k: Update Qualcomm copyrights
wifi: ath12k: Update Qualcomm copyrights
wifi: mt76: Drop unneeded mt76_register_debugfs_fops() return checks
wifi: mt76: mt7921: assert sniffer on chanctx change
wifi: mt76: mt7996: fix potential tx_retries underflow
wifi: mt76: mt7925: fix potential tx_retries underflow
...
====================
Heiko Carstens [Tue, 9 Jun 2026 10:33:43 +0000 (12:33 +0200)]
s390/tishift: Convert __ashlti3(), __ashrti3(), __lshrti3() to C
There is no reason to have __ashlti3(), __ashrti3(), and __lshrti3()
implemented in assembler. Convert them all to C, which allows the
compiler to optimize the code if newer instructions allow that.
Heiko Carstens [Tue, 9 Jun 2026 10:33:42 +0000 (12:33 +0200)]
s390/memmove: Optimize backward copy case
memmove() copies byte wise for the backward copy case, when the mvc
instruction cannot be used. This is quite slow, but can be optimized
with the mvcrl instruction, which is available since z15.
Some numbers (measured on a shared z16 LPAR) show that the new
implementation is nearly always faster, except for the non realistic
one and two byte cases:
Heiko Carstens [Tue, 9 Jun 2026 10:33:41 +0000 (12:33 +0200)]
s390/string: Convert memset(16|32|64)() to C
Convert memset(16|32|64)() from assembler to C, which should make it
easier to read and change, if required. And it allows the compiler to
optimize the code, and use different instructions, except for the used
inline assemblies.
Heiko Carstens [Tue, 9 Jun 2026 10:33:40 +0000 (12:33 +0200)]
s390/string: Convert memcpy() to C
Convert memcpy() from assembler to C, which should make it easier to
read and change, if required. And it allows the compiler to optimize
the code, and use different instructions, except for the used inline
assemblies.
Heiko Carstens [Tue, 9 Jun 2026 10:33:39 +0000 (12:33 +0200)]
s390/string: Convert memset() to C
Convert memset() from assembler to C, which should make it easier to
read and change, if required. And it allows the compiler to optimize
the code, and use different instructions, except for the used inline
assemblies.
Heiko Carstens [Tue, 9 Jun 2026 10:33:38 +0000 (12:33 +0200)]
s390/string: Convert memmove() to C
Convert memmove() from assembler to C, which should make it easier to
read and change, if required. And it allows the compiler to optimize
the code, and use different instructions, except for the used inline
assemblies.
Heiko Carstens [Tue, 9 Jun 2026 10:33:36 +0000 (12:33 +0200)]
s390: Add .noinstr.text to boot and purgatory linker scripts
Upcoming changes will result in a .noinstr.text section within the
boot and purgatory string.o binary. Explicitly add the new section to
avoid orphaned warnings from the linker.
The purgatory code is compiled without the -march option. This means the
default architecture level of the compiler is used. This can cause
problems, e.g. if instructions used in inline assemblies are for a higher
architecture level than the default architecture level of the compiler.
Use z10 as minimum architecture level, similar to the boot code, to enforce
a defined architecture level set.
Yun Zhou [Mon, 8 Jun 2026 15:25:21 +0000 (23:25 +0800)]
ext4: validate donor file superblock early in EXT4_IOC_MOVE_EXT
Reject the EXT4_IOC_MOVE_EXT ioctl early if the donor file does not
belong to the same superblock as the original file. Currently, this
validation is performed inside ext4_move_extents() by
mext_check_validity(), but only after lock_two_nondirectories() has
already acquired the inode locks. When the donor fd refers to a file
on a different filesystem (e.g., overlayfs), this late validation
creates a circular lock dependency:
With a concurrent freeze operation holding sb_writers write side, this
forms a deadlock cycle: CPU0 waits for freeze to complete, freeze waits
for CPU1's sb_writers reader to exit, CPU1 waits for CPU0's inode lock.
Since EXT4_IOC_MOVE_EXT exchanges physical extents between two files,
it fundamentally requires both files to reside on the same ext4
filesystem. Moving the superblock check before any lock acquisition
is both semantically correct and eliminates the circular dependency
by ensuring that cross-filesystem donor fds are rejected before
sb_writers or inode locks are taken.
Fixes: fcf6b1b729bc ("ext4: refactor ext4_move_extents code base") Reported-by: syzbot+ad6118a7584b607c67f2@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=ad6118a7584b607c67f2 Signed-off-by: Yun Zhou <yun.zhou@windriver.com> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Andreas Dilger <adilger@dilger.ca> Link: https://patch.msgid.link/20260608152521.1292656-1-yun.zhou@windriver.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
ext4: fix kernel BUG in ext4_write_inline_data_end
When the data=journal mount option is used, the ext4_journalled_write_end()
function incorrectly calls ext4_write_inline_data_end() without checking
if the EXT4_STATE_MAY_INLINE_DATA flag is still set on the inode.
If a previous attempt to convert the inline data to an extent failed (e.g.
due to ENOSPC), the EXT4_STATE_MAY_INLINE_DATA flag is cleared, but
the EXT4_INODE_INLINE_DATA flag remains set. In this scenario, the next
call to ext4_write_begin() will not prepare the inline data xattr for
writing, but ext4_journalled_write_end() will incorrectly attempt to write
to it, triggering a BUG_ON(pos + len > EXT4_I(inode)->i_inline_size) in
ext4_write_inline_data() since i_inline_size was not expanded.
Fix this by ensuring that ext4_journalled_write_end() only calls
ext4_write_inline_data_end() if the EXT4_STATE_MAY_INLINE_DATA flag is
set, mirroring the behavior of ext4_write_end() and ext4_da_write_end().
Reported-by: syzbot+0c89d865531d053abb2d@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=0c89d865531d053abb2d Fixes: 3fdcfb668fd7 ("ext4: add journalled write support for inline data") Signed-off-by: Aditya Prakash Srivastava <aditya.ansh182@gmail.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20260608065227.3018-1-aditya.ansh182@gmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu>
====================
bonding: 3ad: fix carrier state with no usable slaves
This series addresses a blackholing issue and a subsequent link-flapping
issue in the 802.3ad bonding driver when dealing with inactive slaves
and the `min_links` parameter.
When an 802.3ad (LACP) bonding interface has no slaves in the
collecting/distributing state, the bonding master still reports
carrier as up as long as at least 'min_links' slaves have carrier.
In this situation, only one slave is effectively used for TX/RX,
while traffic received on other slaves is dropped. Upper-layer
daemons therefore consider the interface operational, even though
traffic may be blackholed if the lack of LACP negotiation means
the partner is not ready to deal with traffic.
This patchset introduces an optional behavior, widely adopted across
the industry, to address this issue. It consists of bringing the
bonding master interface down to signal to upper-layer processes
that it is not usable.
Patch 2 adds missing broadcast-neigh to YAML rt-link specs.
Patch 3 introduces the lacp_strict configuration knob, which is
applied in the subsequent patch. The default (off) mode preserves
the existing behavior, while the strict mode (on) is intended to force
the bonding master carrier down in this situation.
Patch 4 addresses the core issue when lacp_strict is set to strict.
It ensures that carrier is asserted only when at least 'min_links'
slaves are in the Collecting/Distributing state.
Patch 5 fixes a side effect of the previous patch. Tightening the carrier
logic exposes a state persistence bug: when a physical link goes down,
the LACP collecting/distributing flags remain set. When the link returns,
the interface briefly hallucinates that it is ready, bounces the carrier
up, and then drops it again once LACP renegotiation starts. Fix by
resetting Collecting and Distributing state as soon as the link goes
down.
Patch 6 adds a test for bonding lacp_strict both modes.
====================
Louis Scalbert [Wed, 3 Jun 2026 15:03:30 +0000 (17:03 +0200)]
bonding: 3ad: fix mux port state on oper down
When the bonding interface has carrier down due to the absence of
usable slaves and a slave transitions from down to up, the bonding
interface briefly goes carrier up, then down again, and finally up
once LACP negotiates collecting and distributing on the port.
When lacp_strict mode is on, the interface should not transition to
carrier up until LACP negotiation is complete.
This happens because the actor and partner port states remain in
Collecting_Distributing when the port goes down. When the port
comes back up, it temporarily remains in this state until LACP
renegotiation occurs.
Previously this was mostly cosmetic, but since the bonding carrier
state may depend on the LACP negotiation state, it causes the
interface to flap.
According to IEEE 802.3ad-2000 and IEEE 802.1ax-2014, Collecting and
Distributing should be reset when a port goes down:
- In the Receive state machine, port_enabled == FALSE causes a
transition to the PORT_DISABLED state, which is expected to clear
Partner_Oper_Port_State.Synchronization.
- In the Mux state machine, Partner_Oper_Port_State.Synchronization ==
FALSE causes a transition to the ATTACHED state, which disables
Collecting and Distributing.
However, Partner_Oper_Port_State.Synchronization is not cleared in the
PORT_DISABLED state.
Clear Partner_Oper_Port_State.Synchronization in the Receive
PORT_DISABLED state.
Louis Scalbert [Wed, 3 Jun 2026 15:03:28 +0000 (17:03 +0200)]
bonding: 3ad: add lacp_strict configuration knob
When an 802.3ad (LACP) bonding interface has no slaves in the
collecting/distributing state, the bonding master still reports
carrier as up as long as at least 'min_links' slaves have carrier.
In this situation, only one slave is effectively used for TX/RX,
while traffic received on other slaves is dropped. Upper-layer
daemons therefore consider the interface operational, even though
traffic may be blackholed if the lack of LACP negotiation means
the partner is not ready to deal with traffic.
Introduce a configuration knob to control this behavior. It allows
the bonding master to assert carrier only when at least 'min_links'
slaves are in Collecting_Distributing state.
The default mode preserves the existing behavior. This patch only
introduces the knob; its behavior is implemented in the subsequent
commit.
===================
Rust support on s390 requires a small set of architecture-specific pieces
before the generic Rust kernel infrastructure can be used.
The series wires up s390 as a Rust-capable 64-bit architecture, adds the
missing assembly interfaces needed by Rust for WARN/BUG reporting and for
static branches, adjusts bindgen parameters to avoid repr layout conflicts
caused by packed and aligned s390 structures, and fixes issues discovered
during testing.
s390 currently requires rustc with support for -Zpacked-stack, and the
minimum tool version gating is adjusted accordingly.
Hongling Zeng [Thu, 4 Jun 2026 07:36:47 +0000 (15:36 +0800)]
ext4: fix ERR_PTR(0) in ext4_mkdir()
When mkdir succeeds, ext4_mkdir() returns ERR_PTR(0) which is incorrect.
It should return NULL instead for success and ERR_PTR() only with
negative error codes for failure.
Fixes: 88d5baf69082 ("Change inode_operations.mkdir to return struct dentry *") Signed-off-by: Hongling Zeng <zenghongling@kylinos.cn> Reviewed-by: Jan Kara <jack@suse.cz> Reviewed-by: Baokun Li <libaokun@linux.alibaba.com> Link: https://patch.msgid.link/20260604073647.211279-1-zenghongling@kylinos.cn Signed-off-by: Theodore Ts'o <tytso@mit.edu>
When jbd2 was originally written, kmalloc() would not guarantee memory
alignment for the requested objects. Since commit 59bb47985c1d in 2019,
kmalloc has guaranteed natural alignment for power-of-two allocations.
We can now remove the jbd2 special slabs and just use kmalloc() directly.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org> Reviewed-by: Jan Kara <jack@suse.cz> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> Reviewed-by: Tal Zussman <tz2294@columbia.edu> Link: https://patch.msgid.link/20260528171413.1088143-1-willy@infradead.org Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cássio Gabriel [Wed, 10 Jun 2026 11:31:30 +0000 (08:31 -0300)]
ALSA: pcm: Fix unlocked state reads in read/write file ops
The PCM read/write and readv/writev file operations reject streams in
OPEN or DISCONNECTED state before accessing the configured runtime
parameters. However, each operation reads runtime->state without the
PCM stream lock.
PCM state updates are serialized by the stream lock and may occur
concurrently from IRQ context. Use a local predicate based on
snd_pcm_get_state() to take a locked state snapshot for these VFS entry
checks.
This also consolidates the duplicated OPEN and DISCONNECTED tests. The
conditions and returned errors remain unchanged.
projects / thirdparty / kernel / stable.git / log
