Wentao Liang [Thu, 4 Jun 2026 10:27:06 +0000 (10:27 +0000)]
crypto: tegra - fix refcount leak in tegra_se_host1x_submit()
The timeout error path in tegra_se_host1x_submit() returns without
calling host1x_job_put(), while all other paths (success, submit
error, pin error) properly release the job reference through the
job_put label. Since host1x_job_alloc() initializes the reference
count and host1x_job_put() is required to drop it, omitting it on
timeout causes a permanent refcount leak.
Fix this by redirecting the timeout return to the existing job_put
label, ensuring the job reference and any associated syncpt
references are consistently released.
Ilya Dryomov [Wed, 3 Jun 2026 15:50:04 +0000 (17:50 +0200)]
crypto: testmgr - allow authenc(hmac(sha{256,384}),cts(cbc(aes))) in FIPS mode
hmac(sha256), hmac(sha384) and cts(cbc(aes)) algorithms have been
marked as FIPS allowed for years. Mark the respective authenc()
constructions per RFC 8009 ("AES Encryption with HMAC-SHA2 for
Kerberos 5") as such as well.
SP 800-57 Part 3 Rev. 1 from Jan 2015 [1] links the draft of what
became RFC 8009 in Oct 2016 as approved in section 6.3 Procurement
Guidance (item/recommendation 3).
Wentao Liang [Wed, 3 Jun 2026 11:03:27 +0000 (11:03 +0000)]
hwrng: jh7110 - fix refcount leak in starfive_trng_read()
The starfive_trng_read() function acquires a runtime PM reference
via pm_runtime_get_sync() but fails to release it on two error
paths. If starfive_trng_wait_idle() or starfive_trng_cmd() returns
an error, the function exits without calling
pm_runtime_put_sync_autosuspend(), leaving the runtime PM usage
counter permanently elevated and preventing the device from entering
runtime suspend.
Refactor the function to use a unified error path that calls
pm_runtime_put_sync_autosuspend() before returning.
Thorsten Blum [Tue, 2 Jun 2026 22:25:19 +0000 (00:25 +0200)]
crypto: atmel-ecc - drop dead code in atmel_ecdh_max_size
atmel_ecdh_init_tfm() always allocates ctx->fallback, so it is never
NULL in atmel_ecdh_max_size(). Remove the dead code and return
crypto_kpp_maxsize() directly.
Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Felix Gu [Tue, 2 Jun 2026 14:55:35 +0000 (22:55 +0800)]
crypto: cavium/cpt - fix DMA cleanup using wrong loop index
The sg_cleanup error path used list[i] instead of list[j] when unmapping
DMA buffers, leaking successfully mapped entries and repeatedly unmapping
the failed one.
Fixes: c694b233295b ("crypto: cavium - Add the Virtual Function driver for CPT") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Felix Gu [Tue, 2 Jun 2026 14:38:26 +0000 (22:38 +0800)]
crypto: marvell/octeontx - fix DMA cleanup using wrong loop index
The sg_cleanup path used list[i] instead of list[j] when unmapping DMA
buffers, leaking successfully mapped entries and repeatedly unmapping
the failed one.
Fixes: 10b4f09491bf ("crypto: marvell - add the Virtual Function driver for CPT") Signed-off-by: Felix Gu <ustc.gu@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
MAINTAINERS: make myself the maintainer of the Qualcomm QCE driver
Qualcomm wants to keep supporting and extending the crypto engine driver.
Thara has not been active for many months, so change the maintainer to
myself and upgrade the driver to Supported.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com> Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Rosen Penev [Tue, 2 Jun 2026 01:46:45 +0000 (18:46 -0700)]
crypto: amcc - convert irq_of_parse_and_map to platform_get_irq
Replace the deprecated irq_of_parse_and_map() call with the modern
platform_get_irq() in the probe function. This also improves error
handling: platform_get_irq() returns a negative errno on failure,
whereas irq_of_parse_and_map() returned 0.
Change the irq field in struct crypto4xx_core_device from u32 to int
to match the return type of platform_get_irq().
Assisted-by: opencode:big-pickle Signed-off-by: Rosen Penev <rosenp@gmail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Eric Biggers [Mon, 1 Jun 2026 16:07:57 +0000 (16:07 +0000)]
crypto: sun4i-ss - Remove insecure and unused rng_alg
Remove sun4i_ss_rng, as it is insecure and unused:
- It has multiple vulnerabilities. sun4i_ss_prng_seed() is missing
locking and has a buffer overflow. sun4i_ss_prng_generate() fails to
fill the entire buffer with cryptographic random bytes, because it
rounds the destination length down and also doesn't actually wait for
the hardware to be ready before pulling bytes from it.
- 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.)
The sun4i_ss_prng_seed() buffer overflow was reported by Tianchu Chen
and discovered by Atuin - Automated Vulnerability Discovery Engine
There's no point in fixing all these vulnerabilities individually when
this is unused code, so let's just remove it.
Fixes: b8ae5c7387ad ("crypto: sun4i-ss - support the Security System PRNG") Cc: stable@vger.kernel.org Reported-by: Tianchu Chen <flynnnchen@tencent.com> Closes: https://lore.kernel.org/r/af749a8447bd7f0e9dd26ca6c87e9c6afecb09d9@linux.dev/ Acked-by: Corentin LABBE <clabbe.montjoie@gmail.com> Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Dave Jiang [Thu, 11 Jun 2026 23:03:55 +0000 (16:03 -0700)]
cxl/test: Unregister cxl_acpi in cxl_test_init() error path
In cxl_test_init(), Once cxl_mock_platform_device_add() succeeds, all
error paths after needs to call platform_device_unregister() instead of
platform_device_put() to clean up.
Fixes: 67dcdd4d3b83 ("tools/testing/cxl: Introduce a mocked-up CXL port hierarchy") Reported-by: sashiko-bot Reviewed-by: Alison Schofield <alison.schofield@intel.com> Link: https://patch.msgid.link/20260611230355.198912-1-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Jakub Kicinski [Fri, 12 Jun 2026 00:08:03 +0000 (17:08 -0700)]
Merge tag 'for-net-next-2026-06-11' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
Luiz Augusto von Dentz says:
====================
bluetooth-next pull request for net-next:
core:
- hci_sync: Add support for HCI_LE_Set_Host_Feature [v2]
- SMP: Use AES-CMAC library API
- sockets: convert to getsockopt_iter
- Add SPDX id lines to some source files
drivers:
- btintel_pcie: Support Product level reset
- btintel_pcie: Add support for smart trigger dump
- btintel_pcie: Add 50 ms delay before MAC init on BlazarIW
- btintel_pcie: Separate coredump work from RX work
- btmtk: add event filter to filter specific event
- btrtl: fix RTL8761B/BU broken LE extended scan
- btusb: Add Realtek RTL8922AE VID/PID 0bda/d922
- btusb: Add Realtek RTL8922AE VID/PID 0bda/d923
- btusb: MT7922: Add VID/PID 0e8d/223c
- btusb: MT7925: Add VID/PID 0e8d/8c38
- btusb: Add support for TP-Link TL-UB250
- btusb: Add Mercusys MA530 for Realtek RTL8761BUV
- btusb: Add TP-Link UB600 for Realtek 8761BUV
- btusb: Add support for Intel Lizard Peak 2 (0x8087:0x0040)
- btusb: Add USB ID 2c4e:0128 for Mercusys MA60XNB
- btusb: MT7925: Add VID/PID 13d3/3609
* tag 'for-net-next-2026-06-11' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next: (49 commits)
Bluetooth: btintel_pcie: Separate coredump work from RX work
Bluetooth: btmtksdio: fix infinite loop in btmtksdio_txrx_work()
Bluetooth: qca: Add BT FW build version to kernel log
Bluetooth: vhci: validate devcoredump state before side effects
Bluetooth: L2CAP: validate connectionless PSM length
Bluetooth: hci: validate codec capability element length
Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref
Bluetooth: btintel_pcie: Load IOSF debug regs by controller variant
Bluetooth: btintel_pcie: Add 50 ms delay before MAC init on BlazarIW
Bluetooth: Add SPDX id lines to some source files
Bluetooth: btintel_pcie: Add support for smart trigger dump
Bluetooth: hci_h5: reset hci_uart::priv in the close() method
Bluetooth: btusb: clean up probe error handling
Bluetooth: btusb: fix wakeup irq devres lifetime
Bluetooth: btusb: fix wakeup source leak on probe failure
Bluetooth: btusb: fix use-after-free on marvell probe failure
Bluetooth: btusb: fix use-after-free on registration failure
Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path
Bluetooth: hci_core: Fix UAF in hci_unregister_dev()
Bluetooth: hci_event: fix simultaneous discovery stuck in FINDING
...
====================
Jakub Kicinski [Fri, 12 Jun 2026 00:06:55 +0000 (17:06 -0700)]
Merge tag 'nfc-net-next-20260611' of https://codeberg.org/linux-nfc/linux
David Heidelberg says:
====================
NFC updates for net-next 20260611
- nxp-nci: Add ISO15693 support
- nxp-nci: treat -ENXIO in IRQ thread as no data available
- nci: uart: Constify struct tty_ldisc_ops
- trf7970a: fix comment typos
- Use named initializers for struct i2c_device_id
- MAINTAINERS: Update address for David Heidelberg
* tag 'nfc-net-next-20260611' of https://codeberg.org/linux-nfc/linux:
MAINTAINERS: Update address for David Heidelberg
nfc: Use named initializers for struct i2c_device_id
nfc: nxp-nci: treat -ENXIO in IRQ thread as no data available
nfc: nxp-nci: Add ISO15693 support
nfc: nci: uart: Constify struct tty_ldisc_ops
nfc: trf7970a: fix comment typos
====================
====================
tipc: fix netlink gate and receive-path bugs
This is v4 of the public TIPC series. The only change from v3 is in
patch 1: TIPC_NL_MEDIA_SET now uses GENL_UNS_ADMIN_PERM like the other
mutators, instead of GENL_ADMIN_PERM, so the whole series uses the
namespace-aware CAP_NET_ADMIN check that matches the legacy TIPC netlink
path. Patches 2 and 3 are unchanged.
Patch 1 gives the TIPCv2 mutating generic-netlink operations the admin
gate the legacy API already has, so a local unprivileged process can no
longer change TIPC state. Patch 2 drops CONN_ACK messages that
acknowledge more outstanding sends than exist, preventing the
snt_unacked underflow. Patch 3 rejects peer bindings with lower > upper,
which would otherwise leak binding-table memory.
====================
tipc: reject inverted service ranges from peer bindings
tipc_update_nametbl() inserts a binding advertised by a peer node using
the lower and upper service-range bounds taken directly from the wire,
without checking that lower <= upper. The local bind path validates the
ordering (tipc_uaddr_valid()), but the name-distribution path does not.
A binding with lower > upper is inserted at the far end of the
service-range rbtree (keyed on lower) where no lookup or withdrawal can
ever match it (service_range_foreach_match() requires sr->lower <= end).
The publication, its service_range node and the augmented rbtree entry
are then leaked for the lifetime of the namespace, and there is no
per-peer cap equivalent to TIPC_MAX_PUBL on locally created bindings.
Reject inverted ranges in the network path as well. A peer node can
otherwise leak unbounded binding-table memory by sending PUBLICATION
items with lower > upper.
Fixes: 37922ea4a310 ("tipc: permit overlapping service ranges in name table") Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech> Link: https://patch.msgid.link/20260610124003.3831170-4-michael.bommarito@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
tipc_sk_conn_proto_rcv() subtracts the peer-supplied connection ack count
from the unsigned 16-bit send counter snt_unacked without checking that it
does not exceed the number of messages actually outstanding:
tsk->snt_unacked -= msg_conn_ack(hdr);
msg_conn_ack() is read straight from a received CONN_MANAGER/CONN_ACK
message. If the ack count is larger than snt_unacked, the subtraction
wraps to a near-maximum value, leaving tsk_conn_cong() permanently true
and starving the connection of further transmits.
Validate the ACK count at the start of the CONN_ACK block and drop the
message if it acknowledges more messages than are outstanding. A peer (or,
for a local connection, the connected peer socket) can otherwise wedge a
TIPC connection's send side by sending an oversized connection ack.
tipc: require net admin for TIPCv2 netlink mutators
TIPCv2 registers mutating generic-netlink operations without admin
permission flags. Generic netlink only checks CAP_NET_ADMIN when an
operation sets GENL_ADMIN_PERM or GENL_UNS_ADMIN_PERM, so a local
unprivileged process can currently change TIPC state through commands
such as TIPC_NL_NET_SET, TIPC_NL_KEY_SET, TIPC_NL_KEY_FLUSH, and
bearer enable/disable.
The legacy TIPC netlink API already checks netlink_net_capable(...,
CAP_NET_ADMIN) for administrative commands. Give the TIPCv2 mutators
the equivalent generic-netlink gate. Use GENL_UNS_ADMIN_PERM, which
maps to the same namespace-aware CAP_NET_ADMIN check that
netlink_net_capable() performs, so the behaviour matches the legacy
path and keeps working for CAP_NET_ADMIN holders in a non-initial user
namespace (containers).
A QEMU/KASAN repro run as uid/gid 65534 with zero effective
capabilities previously succeeded in changing the network id and node
identity, setting and flushing key material, and enabling/disabling a
UDP bearer. With this patch applied the same operations fail with
-EPERM.
Lorenzo Bianconi [Wed, 10 Jun 2026 13:25:13 +0000 (15:25 +0200)]
net: airoha: simplify WAN device check in airoha_dev_init()
airoha_register_gdm_devices() iterates eth->ports[] in order, so GDM2's
netdev is always registered before GDM3/GDM4. This means the explicit
check for eth->ports[1] && eth->ports[1]->devs[0] is a redundant
special-case of what airoha_get_wan_gdm_dev() already covers, since
GDM2 is always marked as WAN during its own ndo_init.
Remove the redundant check and rely solely on airoha_get_wan_gdm_dev()
which handles both the GDM2-present and GDM2-absent cases.
Victor Nogueira [Wed, 10 Jun 2026 13:28:24 +0000 (10:28 -0300)]
net/sched: sch_hfsc: Don't make class passive twice
update_vf() is called from two places for the same class during a single
dequeue when the class's child qdisc (e.g. codel/fq_codel) drops its last
packets while dequeuing:
1. The child calls qdisc_tree_reduce_backlog(), which, now that the child
is empty, invokes hfsc_qlen_notify() -> update_vf(cl, 0, 0) and turns
the class passive (cl_nactive is decremented up the hierarchy).
2. hfsc_dequeue() then calls update_vf(cl, qdisc_pkt_len(skb), cur_time)
to charge the dequeued bytes.
On the second call the class is already passive, but its child qdisc is
still empty, so update_vf() arms go_passive again:
The leaf is then skipped by the cl_nactive == 0 check inside the loop,
which does not clear go_passive, so the stale go_passive propagates to the
parent and decrements its cl_nactive a second time. A parent that still
has other active children is driven to cl_nactive == 0 and removed from
the vttree, even though those siblings are still backlogged. They are
never dequeued again and the qdisc stalls.
Fix this by only arming go_passive when the class is actually active, so an
already-passive class no longer triggers a second passive transition. The
byte accounting (cl->cl_total += len) still runs for every ancestor, so
dequeued bytes continue to be counted exactly once.
Fixes: 51eb3b65544c ("sch_hfsc: make hfsc_qlen_notify() idempotent") Reported-by: Anirudh Gupta <anirudhrudr@gmail.com> Closes: https://lore.kernel.org/netdev/CAN2cbVe79oj0O9==m4+4x3v+O+qzRagA=2=wkrp9i9=CqYvyZA@mail.gmail.com/ Tested-by: Anirudh Gupta <anirudhrudr@gmail.com> Acked-by: Jamal Hadi Salim <jhs@mojatatu.com> Signed-off-by: Victor Nogueira <victor@mojatatu.com> Link: https://patch.msgid.link/20260610132824.3027549-1-victor@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Daniel Borkmann [Tue, 9 Jun 2026 21:22:40 +0000 (23:22 +0200)]
net: Stop leased rxq before uninstalling its memory provider
netif_rxq_cleanup_unlease() tears down the memory provider that was
installed on a physical RX queue through a netkit queue lease. It
currently revokes the provider's DMA mappings before stopping the
physical queue:
This inverts the ordering used by the regular teardown paths (normal
device unregister and the io_uring zcrx close path), which stop the
queue before revoking the provider's mappings.
With the physical queue still live, its NAPI can keep consuming
net_iov entries from the page_pool alloc cache after the
__netif_mp_uninstall_rxq() has already cleared their dma_addr,
opening a window for the device to DMA to a stale or zero address.
Fix it by swapping the two calls so the queue is stopped (and its
NAPI quiesced) before the provider is uninstalled. No functional
regression was observed across repeated runs of the nk_qlease.py
HW selftest, which exercises the lease teardown path; this was
tested against fbnic QEMU emulation.
Fixes: 5602ad61ebee ("net: Proxy netif_mp_{open,close}_rxq for leased queues") Reported-by: Ahmed Abdelmoemen <ahmedabdelmoumen05@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Cc: David Wei <dw@davidwei.uk> Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com> Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20260609212240.677889-1-daniel@iogearbox.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Wentao Liang [Tue, 9 Jun 2026 08:47:30 +0000 (08:47 +0000)]
mlxsw: fix refcount leak in mlxsw_sp_vrs_lpm_tree_replace()
When mlxsw_sp_vrs_lpm_tree_replace() fails after replacing some VRs,
the error rollback loop does not correctly revert the preceding
replacements. The loop decrements the index but fails to update the
vr pointer, which still points to the VR that caused the failure. As
a result, the condition and the rollback call always operate on the
same VR, potentially calling mlxsw_sp_vr_lpm_tree_replace() multiple
times on it while never rolling back the earlier VRs. Those VRs
continue to hold a reference to new_tree acquired via
mlxsw_sp_lpm_tree_hold(), leaking the reference count of new_tree.
Fix by reinitializing vr inside the error loop with the updated index:
vr = &mlxsw_sp->router->vrs[i];
so that the loop correctly iterates over all VRs that were actually
replaced.
Cc: stable@vger.kernel.org Fixes: fc922bb0dd94 ("mlxsw: spectrum_router: Use one LPM tree for all virtual routers") Signed-off-by: Wentao Liang <vulab@iscas.ac.cn> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260609084730.215732-1-vulab@iscas.ac.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Wentao Liang [Tue, 9 Jun 2026 08:37:09 +0000 (08:37 +0000)]
mlxsw: fix refcount leak in mlxsw_sp_port_lag_join()
When mlxsw_sp_port_lag_index_get() fails, mlxsw_sp_port_lag_join()
returns an error without releasing the lag reference obtained by
the earlier mlxsw_sp_lag_get(). All other error paths in the
function jump to the cleanup label that ends with
mlxsw_sp_lag_put(), so this is a single missed release.
Fix the leak by replacing the bare 'return err' with a goto to the
existing error cleanup label, which will drop the reference safely.
Cc: stable@vger.kernel.org Fixes: 0d65fc13042f ("mlxsw: spectrum: Implement LAG port join/leave") Signed-off-by: Wentao Liang <vulab@iscas.ac.cn> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260609083709.209743-1-vulab@iscas.ac.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
====================
ksz87xx: add support for low-loss cable equalizer errata
This patch implements the KSZ87xx short cable erratum
described in Microchip document DS80000687C for KSZ87xx switches
and the following support article:
Microchip documents two independent mechanisms to mitigate this issue:
adjusting the receiver low‑pass filter bandwidth and reducing the DSP
equalizer initial value. These registers are located in the switch’s
internal LinkMD table and cannot be accessed directly through a
stand‑alone PHY driver.
To keep the PHY‑facing API clean, this series models the erratum handling
as vendor‑specific Clause 22 PHY registers, virtualized by the KSZ8 DSA
driver. Accesses are intercepted by ksz8_r_phy() / ksz8_w_phy() and
translated into the appropriate indirect LinkMD register writes. The
erratum affects the shared PHY analog front‑end and therefore applies
globally to the switch.
Based on review feedback, the user‑visible interface is kept deliberately
simple and predictable:
- A boolean “short‑cable” PHY tunable applies a documented and
conservative preset (LPF bandwidth 62MHz, DSP EQ initial value 0).
This is the recommended KISS interface for the common short‑cable
scenario.
- Two additional integer PHY tunables allow advanced or experimental
tuning of the LPF bandwidth and the DSP EQ initial value. These
controls are orthogonal, have no ordering requirements, and simply
override the corresponding setting when written.
The tunables act as simple setters with no implicit state machine or
invalid combinations, avoiding surprises for userspace and not relying
on extended error reporting or netlink ethtool support.
This series contains:
1. Support for the KSZ87xx low‑loss cable erratum in the KSZ8 DSA driver,
including the short‑cable preset and orthogonal tuning controls.
2. Addition of vendor‑specific PHY tunable identifiers for the
short‑cable preset, LPF bandwidth, and DSP EQ initial value.
3. Exposure of these tunables through the Micrel PHY driver via
get_tunable / set_tunable callbacks.
This version follows the design agreed upon during v3 review and
reworks the interface accordingly.
====================
Add support for the KSZ87xx low-loss cable PHY tunables in the Micrel
PHY driver by implementing get_tunable and set_tunable callbacks.
These callbacks expose vendor-specific PHY tunables used to control the
KSZ87xx embedded PHY receiver behavior when operating with short or
low-loss Ethernet cables. The tunables provide:
- a boolean short-cable preset applying known good settings;
- an integer LPF bandwidth control;
- an integer DSP EQ initial value control.
The Micrel PHY driver forwards these tunables via standard phy_read() /
phy_write() operations, which are virtualized by the KSZ8 DSA driver and
translated into the appropriate indirect switch register accesses.
This patch implements the KSZ87xx short cable erratum
described in Microchip document DS80000687C for KSZ87xx switches
and the following support article:
KSZ87xx devices require a workaround for the Module 3 low-loss cable
condition, controlled through the switch TABLE_LINK_MD_V indirect
registers.
This change models the erratum handling as vendor-specific Clause 22 PHY
registers, virtualized by the KSZ8 DSA driver and accessed via
ksz8_r_phy() / ksz8_w_phy(). The following controls are provided:
- A boolean “short-cable” preset, which applies a documented and
conservative configuration (LPF 62 MHz bandwidth and DSP EQ initial
value 0), and is the recommended interface for typical use cases.
- Separate LPF bandwidth and DSP EQ initial value controls intended for
advanced or experimental tuning. These are orthogonal and independent,
and override the corresponding settings without requiring any specific
ordering.
The preset and tunables act as simple setters with no implicit state
machine or invalid combinations, keeping the API predictable and aligned
with the KISS principle.
The erratum affects the shared PHY analog front-end and therefore applies
globally to the switch.
Minxi Hou [Tue, 9 Jun 2026 16:57:25 +0000 (00:57 +0800)]
selftests/net/openvswitch: add flow modify test
Add mod_flow() and the mod-flow CLI command to ovs-dpctl.py, exercising
OVS_FLOW_CMD_SET. Add test_flow_set which first modifies an existing
flow with new actions and verifies the change via traffic, then modifies
the same flow without actions and verifies the kernel handles the
no-actions case gracefully.
The no-actions path is unreachable from userspace OVS tools (dpctl
mod-flow requires actions) but reachable via raw netlink. This is the
code path where Adrian Moreno found a possible kfree_skb of ERR_PTR
when reply allocation fails after locking.
Make parse() skip OVS_FLOW_ATTR_ACTIONS when actstr is None so the
kernel enters the post-lock allocation branch in ovs_flow_cmd_set().
After the no-actions set, verify via dump-flows that the flow retained
its drop action.
Nicolai Buchwitz [Wed, 10 Jun 2026 11:48:35 +0000 (13:48 +0200)]
net: bcmgenet: convert RX path to page_pool
Replace the per-packet __netdev_alloc_skb() + dma_map_single() in the
RX path with page_pool. SKBs are built from pool pages via
napi_build_skb() with skb_mark_for_recycle() so the network stack
returns pages to the pool, and DMA mapping happens once per page
instead of once per packet.
Reject HW-reported lengths smaller than the RSB so a runt cannot
underflow the SKB build path.
Drop the now-unused priv->rx_buf_len field and the rx_dma_failed soft
MIB counter (nothing increments it after the conversion). This
removes the "rx_dma_failed" entry from ethtool -S, which is a
user-visible change for monitoring tools that key on stat names.
net: airoha: move get_sport() callback at the beginning of airoha_enable_gdm2_loopback()
Move the get_sport() callback invocation at the beginning of
airoha_enable_gdm2_loopback() routine in order to avoid leaving the
hardware in a partially configured state if get_sport() fails.
Previously, get_sport() was called after GDM2 forwarding, loopback,
channel, length, VIP and IFC registers had already been programmed.
A failure at that point would return an error leaving GDM2 with
loopback enabled but WAN port, PPE CPU port and flow control mappings
not configured.
Performing the get_sport() lookup before any register write guarantees
the routine either completes the full configuration sequence or exits
with no side effects on the hardware.
====================
mptcp: pm: drop TCP TS with ADD_ADDRv6 + port
Up to this series, it was possible to add a "signal" MPTCP endpoint with
an IPv6 address and a port, or to directly request to send an ADD_ADDR
with a v6 address and a port, but the expected ADD_ADDR wasn't sent when
TCP timestamps was used for the connection.
In fact, such signalling option cannot be sent when TCP timestamps is
used due to a lack of option space: the limit is at 40 bytes, and, with
padding, TCP timestamps is taking 12 bytes, while an ADD_ADDR IPv6 +
port is taking 30 bytes. The selected solution here is to simply drop
the TCP timestamps option when such ADD_ADDR of 30 bytes needs to be
sent.
- Patches 1-3: small cleanups to avoid computing ADD/RM_ADDR twice.
- Patches 4-7: the new feature, controlled by a new sysctl knob.
- Patch 8: extra checks in the MPTCP Join selftests.
- Patches 9-15: A bunch of refactoring: renamed confusing helpers and
variables, and prevent future misused functions.
====================
mptcp_pm_announced_del_timer() removes the matched ADD_ADDR entry (if
found) from the ADD_ADDR list only if check_id is false. That's
dangerous, and not clear, because it means the caller should be free the
entry only in some cases, and it easy to miss that.
Instead, make it static, and call it from mptcp_pm_add_addr_echoed,
which is the only other case where mptcp_pm_add_addr_del_timer should be
called with check_id set to true. Bonus with that: a second call to
mptcp_pm_add_addr_lookup_by_addr() can be avoided.
Note that instead of adding the signature above to avoid a compilation
issue because this helper is called before the definition of the
function, the whole helper is moved above where it is first called. Its
content is untouched, except the addition of the 'static' keyboard.
Note that the signature is added above: it is easier than moving the
code around, because this helper depends on mptcp_pm_schedule_work which
is declared below.
While at it, explicitly mark it as to be called while pm->lock is held.
Similar to the two previous commits, using the 'add' prefix is
confusing, also confirmed by [1].
Now that the structure has been renamed to include 'add_addr' in its
name, easier to know the timer is linked to the ADD_ADDR, no need to
add the confusing prefix, or an unneeded longer one.
While at it, also update the ADD_ADDR timer helper to clearly specify it
is linked to ADD_ADDR, and it is not there to add a new timer.
Similar to the previous commit, only using the 'add' or 'anno' prefixes
is confusing -- generally associated to the action of adding something,
or the Latin name for "year" -- and lack of uniformity.
This has been causing issues in the past, e.g. del_add_timer seemed to
suggest the goal is to delete a previously added timer.
Instead, use the mptcp_pm_announced_ prefix.
While at it, slightly improves some helpers:
- mptcp_lookup_anno_list_by_saddr: no need to specify what is used to do
the lookup: mptcp_pm_announced_lookup.
- mptcp_pm_sport_in_anno_list: it doesn't just compare the port, but the
whole address linked to the sublow: mptcp_pm_announced_has_ssk.
- mptcp_pm_alloc_anno_list: it allocates one item of the list, not a
whole list: mptcp_pm_announced_alloc.
Using only the 'add' prefix is confusing: does it refer to a generic
added entry or address, or specifically to ADD_ADDRs. Using add_addr
removes this confusion.
Similar to most places in the MPTCP code. So instead of passing the
subflow list and use list_for_each_entry(subflow, list, node), pass the
msk and use mptcp_for_each_subflow(msk, subflow).
That's clearer and more uniform with the rest.
While at it, add 'pm_' prefix for the exported one to easily identify
the origin. Plus replace 'lookup' by 'has', because a bool is returned.
Before, they were only checked on demand, but it seems better to check
them each time received ADD_ADDRs are checked.
Errors are only reported when the counter exists, and the value is not
the expected one. This is similar to what is done in chk_join_nr: it
reduces the output, and avoids a lot of 'skip' when validating older
kernels. Also here, some tests need to adapt the default expected
counters, e.g. when ADD_ADDR echo are dropped on the reception side, or
it is not possible to send an ADD_ADDR due to the limited option space.
This validates the feature added by parent commit, where it is now
possible to send an ADD_ADDR with a v6 IP address and a port number,
while the connection is using TCP Timestamps.
This test is simply a copy of the previous one: "signal address with
port", but using IPv6 addresses. This test is only executed if the
add_addr_v6_port_drop_ts sysctl knob is available. If not, it means the
kernel doesn't support this feature.
With TCP-timestamps (padded) taking 12 bytes and ADD_ADDR IPv6 + port
taking 30 bytes, the 40-byte limit for the TCP options is reached. In
this case, it is then not possible to send the signal.
To be able to send this ADD_ADDR, the TCP timestamps option can now be
dropped. This is done, when needed by setting the *drop_ts parameter
from mptcp_established_options. This feature is controlled by a new
net.mptcp.add_addr_v6_port_drop_ts sysctl knob, enabled by default.
It is important to keep in mind that dropping the TCP timestamps option
for one packet of the connection could eventually disrupt some
middleboxes: even if it should be unlikely, they could drop the packet
or even block the connection. That's why this new feature can be
controlled by a sysctl knob.
With TCP-timestamps (padded) taking 12 bytes and ADD_ADDR IPv6 + port
taking 30 bytes, the 40-byte limit for the TCP options is reached. In
this case, it is then not possible to send the address signal.
The idea is to let MPTCP dropping the TCP-timestamps option for some
specific packets, to be able to send some specific pure ACK carrying >28
bytes of MPTCP options, like with this specific ADD_ADDR. A new
parameter is passed from tcp_established_options to the MPTCP side to
indicate if the TCP TS option is used, and if it should be dropped. The
next commit implements the part on MPTCP side, but split into two
patches to help TCP maintainers to identify the modifications on TCP
side. This feature will be controlled by a new add_addr_v6_port_drop_ts
MPTCP sysctl knob.
It is important to keep in mind that dropping the TCP timestamps option
for one packet of the connection could eventually disrupt some
middleboxes: even if it should be unlikely, they could drop the packet
or even block the connection. That's why this new feature will be
controlled by a sysctl knob.
Note that it would be technically possible to squeeze both options into
the header if the ADD_ADDR is first written, and then the TCP timestamps
without the NOPs preceding it. But this means more modifications on TCP
side, plus some middleboxes could still be disrupted by that.
In this implementation, an unused bit is used in mptcp_out_options
structure to avoid passing an address to a local variable. Reading and
setting it needs CONFIG_MPTCP, so the whole block now has this #if
condition: mptcp_established_options() is then no longer used without
CONFIG_MPTCP.
About alternatives, instead of passing a new boolean (has_ts), another
option would be to pass the whole option structure (opts), but
'struct tcp_out_options' is currently defined in tcp_output.c, and it
would need to be exported. Plus that means the removal of the TCP TS
option would be done on the MPTCP side, and not here on the TCP side.
It feels clearer to remove other TCP options from the TCP side, than
hiding that from the MPTCP side.
Yet an other alternative would be to pass the size already taken by the
other TCP options, and have a way to drop them all when needed. But this
feels better to target only the timestamps option where dropping it
should be safe, even if it is currently the only option that would be
set before MPTCP, when MPTCP is used.
This sysctl is going to be used in the next commits to drop TCP
timestamps option, to be able to send an ADD_ADDR with a v6 IP address
and a port number. It is enabled by default.
This knob is explicitly disabled in the MPTCP Join selftest, with the
"signal addr list progresses after tx drop" subtest, to continue
verifying the previous behaviour where the ADD_ADDR is not sent due to a
lack of space.
While at it, move syn_retrans_before_tcp_fallback down from struct
mptcp_pernet, to avoid creating another 3 bytes hole.
mptcp_add_addr_len helper was called twice: in mptcp_pm_add_addr_signal,
then just after in mptcp_established_options_add_addr. Both to check
the remaining space.
The second call is not needed: if there is not enough space,
mptcp_pm_add_addr_signal will return false, and the caller,
mptcp_established_options_add_addr, will do the same without re-checking
the size again. Instead, mptcp_pm_add_addr_signal can directly set the
size.
Note that the returned size can be negative when other suboptions are
dropped, e.g. to send an echo ADD_ADDR with a v4 address, and no port.
While at it:
- move mptcp_add_addr_len to pm.c, as it is now only used from there
- use 'int' in mptcp_add_addr_len for the size, instead of having a mix
- use a bool for 'ret' in mptcp_pm_add_addr_signal
mptcp_rm_addr_len helper was called twice: in mptcp_pm_rm_addr_signal,
then just after in mptcp_established_options_rm_addr. Both to check the
remaining space.
The second call is not needed: if there is not enough space,
mptcp_pm_rm_addr_signal will return false, and the caller,
mptcp_established_options_rm_addr, will do the same without re-checking
the size again. Instead, mptcp_pm_rm_addr_signal can directly set the
size.
While at it, move mptcp_rm_addr_len to pm.c, as it is now only used
there, once.
Use a signed int for the returned size, because when other options are
dropped, the size can be negative, e.g. to send an echo ADD_ADDR with a
v4 address, and no port.
The behaviour is not changed, because it was working as expected with an
overflow. But it is clearer like this, and it will help later on.
Even if, for the moment, only the ADD_ADDR size can be negative in some
cases, a signed int is now used for all mptcp_established_options_*()
helpers, not to mismatch the type, and as a question of uniformity.
====================
IPQ5018: Add and enable GEPHY RX and TX clocks
This patch series addresses a missing hardware description issue for
the Qualcomm IPQ5018 Internal Ethernet PHY, where the data paths fail
to function correctly unless their dedicated RX and TX clocks are
explicitly enabled.
Further testing revealed that leaving these clocks unmanaged by the
kernel, they were inadvertently left enabled by the bootloader / QSDK
platform, which masked the issue. Testing a fresh network configuration
path exposed that the data link fails to work without explicit software
gating.
To correctly introduce the required multi-clock properties, the IPQ5018
binding definition must first be split away from the shared
qca,ar803x.yaml schema. This isolation is required because ar803x
references the generic ethernet-phy.yaml, which enforces a strict
single-clock limit constraint.
- Patch 1: Moves the clocks property and its restriction out of the
generic ethernet-phy.yaml schema to individual bindings files
that need it to allow for PHYs that require multiple clocks.
- Patch 2: Add clocks property to qca,ar803x.yaml for the IPQ5018 PHY.
- Patch 3: Updates the Qualcomm AT803x PHY driver framework to acquire,
enable, and gate these clocks upon link state changes for
runtime power optimization.
====================
dt-bindings: net: ethernet-phy: increase max clock count to two
The clocks property has a restriction to maximum one.
Yet, some PHYs may require more than 1 clock such as the IPQ5018 PHY
which requires two clocks for RX and TX. As such, increase maxItems to
two.
Yizhou Zhao [Tue, 9 Jun 2026 08:00:52 +0000 (16:00 +0800)]
6lowpan: fix NHC entry use-after-free on error path
lowpan_nhc_do_uncompression() looks up an NHC descriptor while holding
lowpan_nhc_lock. If the descriptor has no uncompress callback, the error
path drops the lock before printing nhc->name.
lowpan_nhc_del() removes descriptors under the same lock and then relies
on synchronize_net() before the owning module can be unloaded. That only
waits for net RX RCU readers. lowpan_header_decompress() is also exported
and can be reached from callers that are not necessarily covered by the net
core RX critical section, for example the Bluetooth 6LoWPAN L2CAP receive
path.
This leaves a race where one task drops lowpan_nhc_lock in the error path,
another task unregisters and frees the matching descriptor after
synchronize_net() returns, and the first task then dereferences nhc->name
for the warning.
With the post-unlock window widened, KASAN reports:
BUG: KASAN: slab-use-after-free in lowpan_nhc_do_uncompression+0x1f4/0x220
Read of size 8
lowpan_nhc_do_uncompression
lowpan_header_decompress
Fix this by printing the warning before dropping lowpan_nhc_lock, so the
descriptor name is read while unregister is still excluded. The malformed
packet is still rejected with -ENOTSUPP.
Fixes: 92aa7c65d295 ("6lowpan: add generic nhc layer interface") Cc: stable@vger.kernel.org Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn> Reported-by: Ao Wang <wangao@seu.edu.cn> Reported-by: Xuewei Feng <fengxw06@126.com> Reported-by: Qi Li <qli01@tsinghua.edu.cn> Reported-by: Ke Xu <xuke@tsinghua.edu.cn> Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn> Acked-by: Alexander Aring <aahringo@redhat.com> Link: https://patch.msgid.link/20260609080054.4541-1-zhaoyz24@mails.tsinghua.edu.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: fec: remove reference to nonexistent CONFIG_GILBARCONAP option
The CONFIG_GILBARCONAP option has never been defined by the kernel, but
is referred to by drivers/net/ethernet/freescale/fec_main.c. Remove this
reference to eliminate dead code.
Discovered while searching for CONFIG_* symbols referenced in code but
not defined in any Kconfig file.
Samuel Moelius [Tue, 9 Jun 2026 23:22:45 +0000 (23:22 +0000)]
net: pfcp: allocate per-cpu tstats for PFCP netdevs
PFCP uses dev_get_tstats64() as its ndo_get_stats64 callback, but
pfcp_link_setup() does not request NETDEV_PCPU_STAT_TSTATS. The net
core therefore leaves dev->tstats NULL for PFCP devices.
Creating a PFCP rtnetlink device can immediately ask the new netdev for
stats while building the RTM_NEWLINK notification. That reaches
dev_get_tstats64() and dereferences the NULL dev->tstats pointer.
Set pcpu_stat_type to NETDEV_PCPU_STAT_TSTATS during PFCP link setup so
the net core allocates the storage expected by dev_get_tstats64().
Xin Long [Tue, 9 Jun 2026 22:14:28 +0000 (18:14 -0400)]
sctp: validate embedded address parameter length
sctp_verify_asconf() and sctp_verify_param() only validate ADD_IP, DEL_IP,
and SET_PRIMARY parameters against a fixed minimum size of sizeof(struct
sctp_addip_param) + sizeof(struct sctp_paramhdr). This ensures the outer
parameter is large enough to contain an embedded address parameter header,
but does not verify that the embedded address parameter's declared length
fits within the bounds of the outer parameter.
Later, sctp_process_param() and sctp_process_asconf_param() extract the
embedded address parameter and pass it to af->from_addr_param(), which uses
the address parameter length to parse the variable-length address payload.
A malformed peer can therefore advertise an embedded address parameter
length that exceeds the remaining bytes in the enclosing parameter.
Validate that addr_param->p.length does not exceed the space available
after the sctp_addip_param header before processing the embedded address
parameter. Reject malformed parameters when the embedded address length
extends beyond the enclosing parameter bounds.
This prevents out-of-bounds reads when parsing malformed parameters carried
in INIT or ASCONF processing paths.
Xiang Mei [Tue, 9 Jun 2026 06:51:16 +0000 (23:51 -0700)]
bridge: cfm: reject invalid CCM interval at configuration time
ccm_tx_work_expired() re-arms itself via queue_delayed_work() using
the configured exp_interval converted by interval_to_us(). When
exp_interval is BR_CFM_CCM_INTERVAL_NONE or out of range,
interval_to_us() returns 0, causing the worker to fire immediately in
a tight loop that allocates skbs until OOM.
Fix this by validating exp_interval at configuration time:
- Constrain IFLA_BRIDGE_CFM_CC_CONFIG_EXP_INTERVAL to the valid range
[BR_CFM_CCM_INTERVAL_3_3_MS, BR_CFM_CCM_INTERVAL_10_MIN] in the
netlink policy so userspace cannot set an invalid value.
- Reject starting CCM TX in br_cfm_cc_ccm_tx() when exp_interval has
not yet been configured (defaults to 0 from kzalloc).
Fixes: 2be665c3940d ("bridge: cfm: Netlink SET configuration Interface.") Reported-by: Weiming Shi <bestswngs@gmail.com> Signed-off-by: Xiang Mei <xmei5@asu.edu> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20260609065116.2818837-1-xmei5@asu.edu Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Haoxiang Li [Tue, 9 Jun 2026 07:46:10 +0000 (15:46 +0800)]
bnx2x: fix resource leaks in bnx2x_init_one() error paths
bnx2x_init_one() falls through to the common memory cleanup path for
several failures after probe has already acquired additional resources.
If register_netdev() fails after bnx2x_set_int_mode(), MSI/MSI-X remains
enabled. If later failures happen after bnx2x_iov_init_one(), PF SR-IOV
state can be left allocated. Also, failures after bnx2x_vfpf_acquire()
must release the PF resources before freeing the VF-PF mailbox allocated
by bnx2x_vf_pci_alloc().
Add error labels matching the resource acquisition order so probe failure
disables MSI/MSI-X, removes SR-IOV state, releases VF-PF resources,
deallocates VF PCI resources, and then frees the common driver memory.
Also clear PCI drvdata before freeing the netdev on probe failure.
Jamal Hadi Salim [Wed, 10 Jun 2026 10:18:39 +0000 (06:18 -0400)]
net/sched: cls_flow: Dont expose folded kernel pointers
The flow classifier falls back to addr_fold() for fields that are missing
from packet headers. In map mode, userspace controls mask, xor, rshift,
addend and divisor, and can observe the resulting classid through class
statistics. This allows a tc classifier in a user/network namespace to
recover the 32-bit folded value of skb->sk, skb_dst() or skb_nfct().
Align with standard kernel practices for pointer hashing and replace the
XOR folding with a keyed siphash (which is cryptographically secure)
Fixes: e5dfb815181f ("[NET_SCHED]: Add flow classifier") Reported-by: Kyle Zeng <kylebot@openai.com> Tested-by: Kyle Zeng <kylebot@openai.com> Tested-by: Victor Nogueira <victor@mojatatu.com> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260610101839.14135-1-jhs@mojatatu.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net: dsa: qca8k: fix led devicename when using external mdio bus
The qca8k dsa switch can use either an external or internal mdio bus.
This depends on whether the mdio node is defined under the switch node
itself. Upon registering the internal mdio bus, the internal_mdio_bus
of the dsa switch is assigned to this bus. When an external mdio bus is
used, the driver still uses the internal_mdio_bus id which is used to
create the device names of the leds.
This leads to the leds being prefixed with '(efault)' as the
internal_mii_bus is null. So let's fix this by adding a null check and
use the devicename of the external bus instead when an external bus is
configured.
Linus Torvalds [Thu, 11 Jun 2026 21:22:26 +0000 (14:22 -0700)]
Merge tag 'dma-mapping-7.1-2026-06-11' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux
Pull dma-mapping fix from Marek Szyprowski:
"Three more fixes for the DMA-mapping code, related to PCI P2PDMA, DMA
debug and DMA link ranges API (Li RongQing and Jason Gunthorpe)"
* tag 'dma-mapping-7.1-2026-06-11' of git://git.kernel.org/pub/scm/linux/kernel/git/mszyprowski/linux:
iommu/dma: Do not try to iommu_map a 0 length region in swiotlb
dma-debug: fix physical address retrieval in debug_dma_sync_sg_for_device
dma-mapping: direct: fix missing mapping for THRU_HOST_BRIDGE segments
Miguel Ojeda [Thu, 11 Jun 2026 05:55:38 +0000 (07:55 +0200)]
MAINTAINERS: add Onur Özkan as Rust reviewer
Onur has been involved with the Rust for Linux project for a year now. He
works on the Tyr driver for Arm Mali GPUs [1] and has been driving the
`ww_mutex` series and the SRCU abstractions, as well as improving the
core Rust support in several areas.
In addition, he is already a reviewer of the `RUST [SYNC]` entry and has
been involved with upstream Rust -- for instance, he led the bootstrap
team for two years.
His expertise with the language and its toolchain will be very useful to
have around in the future. Thus add him to the `RUST` entry as reviewer.
Miguel Ojeda [Thu, 11 Jun 2026 05:55:37 +0000 (07:55 +0200)]
MAINTAINERS: add Alexandre Courbot as Rust reviewer
Alexandre has been involved with the Rust for Linux project for more
than a year now. He is one of the main contributors to Nova [1], the
Rust driver for NVIDIA GPUs, and has authored core Rust infrastructure
motivated by that work, such as the `num` module with the `Bounded`
integer type, the `register!` and `bitfield!` macros, as well as
improvements to abstractions like DMA.
He maintains the nova-core driver, as well as the `RUST [NUM]`, `RUST
[BITFIELD]` and `RUST [INTEROP]` entries. In addition, he has been very
active reviewing Rust code in the mailing list.
He also proposed and implemented the `int_lowest_highest_one` feature
in the Rust standard library [2], which we should eventually use in
the kernel.
His experience maintaining a major Rust GPU driver and the abstractions
it needs will be very useful to have around in the future. Thus add him
to the `RUST` entry as reviewer.
Miguel Ojeda [Thu, 11 Jun 2026 05:55:36 +0000 (07:55 +0200)]
MAINTAINERS: add Tamir Duberstein as Rust reviewer
Tamir has been involved with the Rust for Linux project for more than
a year and a half now. He has been working on improving the integration
between the kernel and the Rust language and tooling: he led the effort
to replace the kernel's own `CStr` type with the standard library's,
and reworked the rust-analyzer integration, among other things.
He is already the maintainer of the `RUST [RUST-ANALYZER]` and `XARRAY API
[RUST]` entries. In addition, he has been active reviewing Rust code in
the mailing list.
He is also a long-time contributor to the upstream Rust project, including
on topics that matter for the Linux kernel [1].
His expertise with the language and its tooling will be very useful to
have around in the future. Thus add him to the `RUST` entry as reviewer.
Miguel Ojeda [Thu, 11 Jun 2026 05:55:35 +0000 (07:55 +0200)]
MAINTAINERS: add Daniel Almeida as Rust reviewer
Daniel has been involved with the Rust for Linux project for more than
three years now. He is the lead of the Tyr driver for Arm Mali GPUs
[1] and submitted many of the core abstractions that drivers need: the
`irq` module, system resources, `IoMem`, the regulator API, the `bits`
module, the basic USB abstractions... He is also working on the initial
Rust V4L2 support [2].
He is already a maintainer and reviewer of several Rust-related entries,
and he has been very active reviewing Rust code in the mailing list.
His experience building Rust drivers and the APIs they require will be
very useful to have around in the future. Thus add him to the `RUST`
entry as reviewer.
Zhao Dongdong [Wed, 10 Jun 2026 07:20:43 +0000 (15:20 +0800)]
ASoC: SOF: topology: fix memory leak in snd_sof_load_topology
When the topology filename contains "dummy" and tplg_cnt is 0, the
function returns -EINVAL directly without freeing the tplg_files
allocated by kcalloc() at line 2497. This leaks memory on every
such topology load attempt.
Fix this by setting ret = -EINVAL and jumping to the out: label,
which already handles the kfree(tplg_files) cleanup.
Fixes: 99c159279c6d ("ASoC: SOF: don't check the existence of dummy topology") Cc: stable@vger.kernel.org Signed-off-by: Zhao Dongdong <zhaodongdong@kylinos.cn> Acked-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com> Link: https://patch.msgid.link/tencent_3EED6D778DC52C3703A2D1EE8119372E8E08@qq.com Signed-off-by: Mark Brown <broonie@kernel.org>
Mark Brown [Thu, 11 Jun 2026 19:59:21 +0000 (20:59 +0100)]
ASoC: mediatek: Use guard() for mutex & spin locks
bui duc phuc <phucduc.bui@gmail.com> says:
This series converts mutex and spinlock handling in Mediatek ASoC drivers
to use guard() helpers.
Most patches are straightforward conversions to guard() helpers with no
functional change intended.
One exception is mt8192-afe-gpio, where the mutex release point moves from
immediately before dev_warn() to scope exit. However, the affected path
only emits a warning and immediately returns -EINVAL, without any further
processing.
ASoC: mediatek: mt8192: mt8192-afe-gpio: Use guard() for mutex locks
Convert the explicit mutex_lock()/mutex_unlock() pair to guard(mutex)
to simplify the locking logic and automatically release the mutex on
all exit paths.
This changes the mutex release point from immediately before dev_warn()
to automatic cleanup at scope exit. However, the affected path only emits
a warning and immediately returns -EINVAL, without any further processing.
Arnd Bergmann [Thu, 11 Jun 2026 12:59:39 +0000 (14:59 +0200)]
lib/crypto: gf128hash: mark clmul32() as noinline_for_stack
During randconfig testing, I came across a lot of warnings for the newly
added carryless multiplication function triggering excessive stack usage
from spilling temporary variables to the stack:
In addition to the possible risk of overflowing the kernel stack,
the generated object code surely performs very poorly.
This only happens on architectures that don't provide uint128_t
(which should be all 32-bit architectures on modern compilers), but
though I tested random x86 and arm configs, I only saw this with arm's
CONFIG_THUMB2_KERNEL, which adds more pressure to the register allocator.
The testing was done using clang-22, I don't know if gcc has the same
problem. Marking clmul32() as noinline_for_stack experimentally shows
all of the affected builds to completely solve the problem, reducing
the stack usage to a few bytes as expected.
Since u64 arithmetic frequently leads to compilers badly optimizing
32-bit targets, keeping clmul32 out of line is likely to help on
other 32-bit configurations as well when they run into this problem,
though it may also result in a small performance degradation in
configurations that would benefit from inlining.
Mark Brown [Thu, 11 Jun 2026 19:50:31 +0000 (20:50 +0100)]
ASoC: rockchip: Use guard() for spin locks
bui duc phuc <phucduc.bui@gmail.com> says:
This series converts spinlock handling in the Rockchip sound drivers
to use guard() helpers.
The changes are code cleanup only and should have no functional impact.
Mark Brown [Thu, 11 Jun 2026 19:49:43 +0000 (20:49 +0100)]
ASoC: rockchip: Reorder clock enable sequence
bui duc phuc <phucduc.bui@gmail.com> says:
This series reorders the runtime resume clock enable sequence in the
Rockchip SPDIF and PDM drivers to enable the bus clock before the
functional controller clock.
It also updates the SPDIF DT binding clock descriptions to match the
actual clock usage in the driver.
Additionally, this v2 adds two new patches addressing issues reported
by the Sashiko AI Review tool regarding regcache sync failure handling
and runtime PM resume status validation.
Testing:
- Patch 1: Verified (dt_binding_check passed).
- Patches 2 to 5: Compile tested only. Please help test if you have
the relevant Rockchip hardware.
ASoC: rockchip: rockchip_pdm: Handle runtime PM resume failures in set_fmt
rockchip_pdm_set_fmt() calls pm_runtime_get_sync() before accessing
hardware registers, but ignores its return value.
If the runtime resume fails, the function continues to perform register
accesses while the device state is undefined.
Replace pm_runtime_get_sync() with pm_runtime_resume_and_get() and
return early on failure to avoid unpowered register accesses.
Reported-by: Sashiko AI Review <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260522110302.349421F000E9@smtp.kernel.org/ Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260602101608.45137-6-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: rockchip: spdif: Restore regcache cache-only mode on sync failure
If regcache_sync() fails during runtime resume, the driver disables the
clocks and returns an error. However, the regmap cache-only mode is left
disabled.
Restore cache-only mode in the error path so subsequent register accesses
continue to use the cache while the device is inactive.
Reported-by: Sashiko AI Review <sashiko-bot@kernel.org> Closes: https://lore.kernel.org/all/20260522103713.6C09D1F000E9@smtp.kernel.org/ Signed-off-by: bui duc phuc <phucduc.bui@gmail.com> Link: https://patch.msgid.link/20260602101608.45137-5-phucduc.bui@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
Enable the 'hclk' bus clock before the 'clk' controller clock during
runtime resume.
The bus clock provides the register access interface, so enable it before
the controller clock. This also makes the resume sequence the reverse of
the suspend sequence, which keeps the clock ordering consistent.
Enable the 'hclk' bus clock before the 'mclk' controller clock during
runtime resume.
The bus clock provides the register access interface, so enable it before
the controller clock. This also makes the resume sequence the reverse of
the suspend sequence, which keeps the clock ordering consistent.
Sen Wang [Wed, 3 Jun 2026 21:18:30 +0000 (16:18 -0500)]
ASoC: ti: davinci-mcasp: Add audio-graph-card2 and DPCM support
Extend the McASP driver to support audio-graph-card2 of-graph topology,
while maintaining backwards compatibility for existing simple-audio-card
phandles and machine drivers, which now uses the default MCASP_GRAPH_NONE
code path.
Cássio Gabriel [Thu, 4 Jun 2026 03:10:58 +0000 (00:10 -0300)]
ASoC: topology: Check PCM and DAI name strings before use
Topology objects store several PCM and DAI names in fixed-size UAPI
arrays. Other topology parser paths validate these fields with bounded
strnlen() checks before using them as C strings, but the PCM and DAI
paths still pass some fixed-size arrays directly to strlen(),
devm_kstrdup(), DAI lookup, and diagnostic prints.
A malformed topology blob with a non-NUL-terminated PCM, DAI, or stream
capability name can therefore make the parser read past the end of the
fixed-size field.
Reject unterminated PCM and DAI name fields before consuming them as C
strings.
Fixes: 64527e8a3529 ("ASoC: topology: Add FE DAIs dynamically") Fixes: acfc7d46cddc ("ASoC: topology: Add FE DAI links dynamically") Fixes: 0038be9a84dc ("ASoC: topology: Add support for configuring existing BE DAIs") Signed-off-by: Cássio Gabriel <cassiogabrielcontato@gmail.com> Link: https://patch.msgid.link/20260604-asoc-topology-check-pcm-dai-names-v1-1-e1b0f6f7c2ce@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
Charles Keepax [Mon, 8 Jun 2026 10:27:14 +0000 (11:27 +0100)]
ASoC: cs35l56: Remove unnecessary conditionals waiting for enumeration
Commit [1] updated the core to use complete_all() which means that
the wait_for_completion() will now simply return if the device
is already attached, so skipping the completion isn't required
anymore. Update the code to simply call sdw_slave_wait_for_init()
unconditionally.
Charles Keepax [Mon, 8 Jun 2026 10:27:13 +0000 (11:27 +0100)]
ASoC: SDCA: Use new SoundWire enumeration helper
Now the new wait for SoundWire enumeration helper no longer depends on
unattach_request it is safe to use from probe time. Update the driver
to use the new core helper.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Link: https://patch.msgid.link/20260608102714.2503120-10-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
projects / thirdparty / kernel / stable.git / log
