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>
Charles Keepax [Mon, 8 Jun 2026 10:27:12 +0000 (11:27 +0100)]
ASoC: wcd939x: 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.
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260608102714.2503120-9-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Charles Keepax [Mon, 8 Jun 2026 10:27:11 +0000 (11:27 +0100)]
ASoC: wcd938x: 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.
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260608102714.2503120-8-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Charles Keepax [Mon, 8 Jun 2026 10:27:10 +0000 (11:27 +0100)]
ASoC: wcd937x: 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.
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260608102714.2503120-7-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Charles Keepax [Mon, 8 Jun 2026 10:27:09 +0000 (11:27 +0100)]
ASoC: pm4125: 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.
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260608102714.2503120-6-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Charles Keepax [Mon, 8 Jun 2026 10:27:08 +0000 (11:27 +0100)]
ASoC: rt5682: 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-5-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Charles Keepax [Mon, 8 Jun 2026 10:27:06 +0000 (11:27 +0100)]
ASoC: wsa881x: Use new SoundWire enumeration helper
Now the new wait for SoundWire enumeration helper no longer depends on
unattach_request it can be used for code that also doesn't check this
flag. Update the driver to use the new core helper.
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20260608102714.2503120-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
Charles Keepax [Mon, 8 Jun 2026 10:27:05 +0000 (11:27 +0100)]
soundwire: Always wait for initialisation of unattached devices
Currently in sdw_slave_wait_for_init() the waiting can be skipped
if unattach_request is not set. Doing so was added in [1] likely
because the core used to do a complete() on the completion so
waiting in the case an unattach hadn't actually happened would
block for the full timeout. However patch [2] updated the core to
use complete_all() which means that the wait_for_completion() will
now simply return if the device is already attached skipping the
completion doesn't add much.
Additionally, unattach_request is only set if the host initiates
a bus reset. However, the host doing a bus reset is not the only
reason a device may be unattached from the bus. Other options
could include the driver probing before the device enumerates, a
sync-loss, or the device itself powering down.
Removing the skip using unattached_request, doesn't cost much in
terms of efficiency and allows the sdw_slave_wait_for_init() helper
to be used outside of runtime resume.
[1] b2bd75f806c4 ("soundwire: sdw_slave: track unattach_request to handle all init sequences")
[2] c40d6b3249b1 ("soundwire: fix enumeration completion")
Mark Brown [Thu, 11 Jun 2026 19:44:46 +0000 (20:44 +0100)]
ASoC: Validate written enum values in custom controls
HyeongJun An <sammiee5311@gmail.com> says:
Some custom ASoC kcontrol put() handlers use the written enum value
(ucontrol->value.enumerated.item[0]) to index a table or compute a bit
shift before validating that the value is within the control's enum range.
An out-of-range value written from userspace is therefore consumed before
it is rejected.
This is the same class addressed for the Meson codecs in commit 1e001206804b ("ASoC: meson: g12a-tohdmitx: Validate written enum values")
and commit 3150b70e944e ("ASoC: meson: g12a-toacodec: Validate written
enum values").
Fix four more instances:
- hdac_hdmi reads e->texts[item] before validation.
- aiu converts the item before validating it.
- fsl_audmix converts the item and uses the result before validation.
- tegra210_ahub reads e->values[item] before validation.
HyeongJun An [Tue, 9 Jun 2026 12:43:16 +0000 (21:43 +0900)]
ASoC: tegra: tegra210_ahub: Validate written enum value
tegra_ahub_put_value_enum() reads e->values[item[0]] before
checking whether item[0] is within the enum item range. The existing
check therefore happens too late to prevent an out-of-range read of the
values array.
Move the check before the array access.
Fixes: 16e1bcc2caf4 ("ASoC: tegra: Add Tegra210 based AHUB driver") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An <sammiee5311@gmail.com> Link: https://patch.msgid.link/20260609124317.38046-5-sammiee5311@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
HyeongJun An [Tue, 9 Jun 2026 12:43:15 +0000 (21:43 +0900)]
ASoC: fsl: fsl_audmix: Validate written enum values
fsl_audmix_put_mix_clk_src() and fsl_audmix_put_out_src()
convert the user-provided enum item with snd_soc_enum_item_to_val()
before checking whether the item is within the enum's item count.
The generic snd_soc_put_enum_double() helper performs that
validation, but these callbacks use the converted value first: the
clock-source path tests it with BIT(), and the output-source path
indexes the prms transition table with it.
Reject out-of-range enum items before converting them.
Fixes: be1df61cf06e ("ASoC: fsl: Add Audio Mixer CPU DAI driver") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An <sammiee5311@gmail.com> Link: https://patch.msgid.link/20260609124317.38046-4-sammiee5311@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
HyeongJun An [Tue, 9 Jun 2026 12:43:14 +0000 (21:43 +0900)]
ASoC: meson: aiu: Validate written enum values
The AIU HDMI and internal codec mux put callbacks use the written enum
value with snd_soc_enum_item_to_val() before checking whether the value is
valid for the enumeration.
Reject out-of-range values before converting the enum item, matching the
validation already done by the G12A HDMI and internal codec mux controls.
Fixes: b82b734c0e9a ("ASoC: meson: aiu: add hdmi codec control support") Fixes: 65816025d461 ("ASoC: meson: aiu: add internal dac codec control support") Assisted-by: Claude:claude-opus-4-8 Signed-off-by: HyeongJun An <sammiee5311@gmail.com> Link: https://patch.msgid.link/20260609124317.38046-3-sammiee5311@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
HyeongJun An [Tue, 9 Jun 2026 12:43:13 +0000 (21:43 +0900)]
ASoC: codecs: hdac_hdmi: Validate written enum value
hdac_hdmi_set_pin_port_mux() uses the written enum value to index the
texts array before calling snd_soc_dapm_put_enum_double(), which validates
that the value is within the enum item range.
An out-of-range value can therefore make the driver read past the texts
array before the helper rejects the write. Move the lookup after the helper
has accepted the value.
Mark Brown [Thu, 11 Jun 2026 19:43:33 +0000 (20:43 +0100)]
ASoC: img: Use guard() for spin locks
bui duc phuc <phucduc.bui@gmail.com> says:
This series converts spinlock handling in several IMG ASoC drivers
to use guard() helpers.
All patches are straightforward cleanups with no functional change
intended.
Merge branches 'pm-sleep', 'pm-powercap' and 'pm-tools'
Merge updates related to system sleep support, two updates of the
intel_rapl power capping driver, and a pm-graph utility fix for
7.2-rc1:
- Add sysctl interface for DPM watchdog timeouts (Tzung-Bi Shih)
- Use complete() instead of complete_all() in device_pm_sleep_init() to
avoid a false-positive warning from lockdep_assert_RT_in_threaded_ctx()
when CONFIG_PROVE_RAW_LOCK_NESTING is enabled (Jiakai Xu)
- Use a flexible array for CRC uncompressed buffers during hibernation
image saving (Rosen Penev)
- Make the LZ4 algorithm available for hibernation compression (l1rox3)
- Move the preallocate_image() call during hibernation after the
"prepare" phase of the "freeze" transition (Matthew Leach)
- Fix a memory leak in rapl_add_package_cpuslocked() in the intel_rapl
power capping driver and use sysfs_emit() in cpumask_show() in that
driver (Sumeet Pawnikar, Yury Norov)
- Fix ValueError when parsing incomplete device properties in the
pm-graph utility (Gongwei Li)
* pm-sleep:
PM: dpm_watchdog: Add sysctl interface for DPM watchdog timeouts
PM: hibernate: Use flexible array for CRC uncompressed buffers
PM: hibernate: make LZ4 available for hibernation compression
PM: sleep: Use complete() in device_pm_sleep_init()
PM: hibernate: call preallocate_image() after freeze prepare
* pm-powercap:
powercap: intel_rapl: Use sysfs_emit() in cpumask_show()
powercap: intel_rapl: Fix memory leak in rapl_add_package_cpuslocked()
When SND_SOC_SOF_INTEL_LNL is set, SND_SOF_SOF_HDA_SDW_BPT must also
be enabled, in order to let the soundwire support call into it.
However, there are configurations with SND_SOF_SOF_HDA_SDW_BPT=m
and SND_SOF_SOF_HDA_SDW_BPT=m but SOUNDWIRE_INTEL=y, which still
lead to a link failure:
aarch64-linux-ld: drivers/soundwire/intel_ace2x.o: in function `intel_ace2x_bpt_wait':
intel_ace2x.c:(.text+0xfc8): undefined reference to `hda_sdw_bpt_wait'
aarch64-linux-ld: drivers/soundwire/intel_ace2x.o: in function `intel_ace2x_bpt_send_async':
intel_ace2x.c:(.text+0x1ff8): undefined reference to `hda_sdw_bpt_get_buf_size_alignment'
Address this by moving the 'select SND_SOF_SOF_HDA_SDW_BPT' into
SND_SOC_SOF_HDA_GENERIC.
Fixes: 614d416dd8ae ("ASoC: SOF: Intel: hda-sdw-bpt: fix SND_SOF_SOF_HDA_SDW_BPT dependencies") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Link: https://patch.msgid.link/20260611132310.137688-2-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
Arnd Bergmann [Thu, 11 Jun 2026 13:23:05 +0000 (15:23 +0200)]
ASoC: SOF: Intel: select SND_SOC_SDW_UTILS=y from SND_SOC_SOF_HDA_GENERIC=y
When SND_SOC_SOF_HDA_GENERIC=y but SND_SOC_SOF_INTEL_SOUNDWIRE=m, the
SND_SOC_SDW_UTILS is also set to =m even though there is a direct link
dependency from the hda.c:
aarch64-linux-ld: sound/soc/sof/intel/hda.o: in function `hda_machine_select':
hda.c:(.text+0x21ac): undefined reference to `codec_info_list'
hda.c:(.text+0x241c): undefined reference to `asoc_sdw_get_dai_type'
hda.c:(.text+0x25b4): undefined reference to `asoc_sdw_get_codec_info_list_count'
hda.c:(.text+0x25d8): undefined reference to `asoc_sdw_get_codec_info_list_count'
Change this the same way as the other related 'select' statements
to allow linking against it.
Fixes: 2b4d53eb5cf3 ("ASoC: SOF: Intel: select SND_SOC_SDW_UTILS in SND_SOC_SOF_HDA_GENERIC") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Tested-by: Julian Braha <julianbraha@gmail.com> Link: https://patch.msgid.link/20260611132310.137688-1-arnd@kernel.org Signed-off-by: Mark Brown <broonie@kernel.org>
ASoC: cs35l56: Fix wrong error test on simple_write_to_buffer()
In cs35l56_cal_data_debugfs_write() fix the if statement that checks for
error return to only check for negative values.
Reported by Sashiko:
simple_write_to_buffer() returns the positive number of bytes copied
on success. Since the condition returns immediately on any non-zero
value, is it possible that the written calibration data is discarded
and cs35l56_stash_calibration() is never called?
ASoC: soc-core: Create device_link to ensure correct suspend order
In snd_soc_bind_card() create a device_link from card to all components
to ensure correct order of system_suspend. The card is the consumer and
the components are the supplier, so that the card will system_suspend
before any of the components.
The PM core will normally system_suspend drivers in the opposite order
that they registered. This ensures children are suspended before their
parents, for example users of a bus driver should suspend before the bus
driver suspends.
For ASoC, snd_soc_suspend() shuts down any active audio, which requires
that the components are still able to communicate with their hardware.
Previously there was nothing to ensure this ordering, because there is
(usually) no relationship between a machine driver and component drivers.
If the machine driver registered before the codec drivers, the codec
drivers would be suspended before the machine driver snd_soc_suspend()
runs, so that ASoC is attempting to stop audio on a driver that has
already suspended.
Creating a device_link is safe if there is already a device_link between
those devices because of multiple components sharing the same dev.
device_link_add() kernel doc says:
"if a device link between the given @consumer and @supplier pair
exists already when this function is called for them, the existing link
will be returned regardless of its current type and status ...
The caller of this function is then expected to treat
the link as though it has just been created, so (in particular) if
DL_FLAG_STATELESS was passed in @flags, the link needs to be released
explicitly when not needed any more"
For the same reason it is safe if the codec driver or machine driver
later call device_link_add() to create a link between the same two
devices.
(I have tested creating multiple links between the card->dev and a
component->dev and did not encounter any problems with suspend/resume or
module unloading.)
The DL_FLAG_AUTOREMOVE_* flags assume that they are being called from
the probe() function of that device. This isn't guaranteed in ASoC card
binding because of deferred binding. The exact behavior and consequences
of the DL_FLAG_AUTOREMOVE_* are also unclear from the documentation.
So DL_FLAG_STATELESS is used for safety, and the links are removed
explicitly when the card unbinds or if the bind fails.
Tzung-Bi Shih [Mon, 8 Jun 2026 02:15:26 +0000 (02:15 +0000)]
PM: dpm_watchdog: Add sysctl interface for DPM watchdog timeouts
Introduce sysctl knobs to allow configuring DPM watchdog timeouts at
runtime.
Currently, these timeouts are fixed at compile time via
CONFIG_DPM_WATCHDOG_TIMEOUT and CONFIG_DPM_WATCHDOG_WARNING_TIMEOUT.
This limits flexibility if the timeouts need to be adjusted for
different testing scenarios or hardware behaviors without rebuilding
the kernel.
Add the following sysctl files under /proc/sys/kernel/:
- dpm_watchdog_timeout_secs: The total timeout before panic. The
maximum value is capped at CONFIG_DPM_WATCHDOG_TIMEOUT to prevent
unreasonably large timeouts.
- dpm_watchdog_warning_timeout_secs: The warning timeout. The maximum
value is capped at the current dpm_watchdog_timeout_secs.
projects / thirdparty / linux.git / log
