Mark Brown [Thu, 21 May 2026 23:15:05 +0000 (00:15 +0100)]
ASoC: AMD: ACP7.x initial PCI driver bring-up
Vijendar Mukunda <Vijendar.Mukunda@amd.com> says:
This series adds initial AMD ACP 7.x support for ACP7.D / 7.E / 7.F
platforms.
Compared to earlier ACP generations, ACP7.x includes substantial design
changes, including an updated register set/layout. For that reason,
the ACP7.x implementation is placed under a separate sound/soc/amd/acp7x/
directory instead of extending older-generation code paths,
keeping ACP7.x-specific logic and register definitions cleanly separated
and easier to maintain.
This initial version is intentionally focused on the core PCI driver
bring-up: register definitions, probe/remove, basic helper wiring, and
system sleep + runtime PM integration. A follow-up series will add support
for additional Audio I/O blocks, including SoundWire and the ACP PDM
controller.
The primary goal of this series is to unblock power validation, since the
ACP IP currently does not have a driver available with PM ops support on
these platforms.
Jakub Kicinski [Thu, 21 May 2026 23:00:06 +0000 (16:00 -0700)]
Merge tag 'wireless-next-2026-05-21' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next
Johannes Berg says:
====================
Not much going on here right now:
- mac80211/hwsim:
- some NAN related things
- MCS/NSS rate issues with S1G
- p54: port SPI version to device-tree
- (a few other random things)
* tag 'wireless-next-2026-05-21' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next:
ARM: dts: omap2: add stlc4560 spi-wireless node
p54spi: convert to devicetree
dt-bindings: net: add st,stlc4560/p54spi binding
wifi: mac80211: allow cipher change on NAN_DATA interfaces
wifi: mac80211_hwsim: Do not declare NAN support for Extended Key ID
wifi: cfg80211: add a function to parse UHR DBE
wifi: mac80211: don't call ieee80211_handle_reconfig_failure when not needed
wifi: mac80211: Allow per station GTK for NAN Data interfaces
wifi: mac80211_hwsim: advertise NPCA capability
wifi: mac80211_hwsim: reject NAN on multi-radio wiphys
wifi: plfxlc: use module_usb_driver() macro
wifi: mac80211: don't recalc min def for S1G chan ctx
wifi: mac80211: skip NSS and BW init for S1G sta
wifi: mac80211: check stations are removed before MLD change
wifi: rt2x00: allocate anchor with rt2x00dev
====================
The eDP PHY nodes on lemans were missing the reference clock voting.
This initially went unnoticed because the clock was implicitly enabled
by the UFS PHY driver, and the eDP PHY happened to rely on that.
After commit 77d2fa54a945 ("scsi: ufs: qcom : Refactor phy_power_on/off
calls"), the UFS driver no longer keeps the reference clock enabled.
As a result, the eDP PHY fails to power on.
To fix this, add eDP reference clock for eDP PHYs on lemans chipset
ensuring reference clock is enabled.
Linus Torvalds [Thu, 21 May 2026 22:02:12 +0000 (15:02 -0700)]
Merge tag 'pci-v7.1-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci
Pull PCI fixes from Bjorn Helgaas:
- Remove obsolete PCIe maintainer addresses (Florian Eckert, Hans
Zhang)
- Restore a brcmstb link speed assignment that was inadvertently
removed, reducing bcm2712 performance (Florian Fainelli)
* tag 'pci-v7.1-fixes-2' of git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci:
PCI: brcmstb: Assign pcie->gen from of_pci_get_max_link_speed()
MAINTAINERS: Remove Jianjun Wang as PCIe mediatek maintainer
MAINTAINERS: Remove Chuanhua Lei as PCIe intel-gw maintainer
Linus Torvalds [Thu, 21 May 2026 21:39:12 +0000 (14:39 -0700)]
Merge tag 'net-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Including fixes from Bluetooth, wireless and netfilter.
Craziness continues with no end in sight. Even discounting the driver
revert this is a pretty huge PR for standards of the previous era. I'd
speculate - we haven't seen the worst of it, yet. Good news, I guess,
is that so far we haven't seen many (any?) cases of "AI reported a
bug, we fixed it and a real user regressed".
Current release - fix to a fix:
- Bluetooth: btmtk: accept too short WMT FUNC_CTRL events
- vsock/virtio: relax the recently added memory limit a little
Current release - regressions:
- IB/IPoIB: make sure IB drivers always use async set_rx_mode since
some (mlx5) are now required to use it due to locking changes
Previous releases - regressions:
- udp: fix UDP length on last GSO_PARTIAL segment
- af_unix: fix UAF read of tail->len in unix_stream_data_wait()
- tcp: fix stale per-CPU tcp_tw_isn leak enabling ISN prediction
- mlx5e: fix unlocked writing to ICOSQ, breaking AF_XDP
Previous releases - always broken:
- tap: fix stack info leak in tap_ioctl() SIOCGIFHWADDR
- ipv4: raw: reject IP_HDRINCL packets with ihl < 5
- Bluetooth: a lot of locking and concurrency fixes (as always)
- batman-adv (mesh wireless networking): a lot of random fixes for
issues reported by security researchers and Sashiko
- netfilter: same thing, a lot of small security-ish fixes all over
the place, nothing really stands out
Misc:
- bring back the old 3c509 driver, Maciej wants to maintain it"
* tag 'net-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (187 commits)
net: enetc: avoid VF->PF mailbox timeout during SR-IOV teardown
net: enetc: fix init and teardown order to prevent use of unsafe resources
net: enetc: fix unbounded loop and interrupt handling in VF-to-PF messaging
net: enetc: fix DMA write to freed memory in enetc_msg_free_mbx()
net: enetc: fix race condition in VF MAC address configuration
net: enetc: fix TOCTOU race and validate VF MAC address
net: enetc: add ratelimiting to VF mailbox error messages
net: enetc: fix missing error code when pf->vf_state allocation fails
net: enetc: fix incorrect mailbox message status returned to VFs
net: bridge: prevent too big nested attributes in br_fill_linkxstats()
l2tp: use list_del_rcu in l2tp_session_unhash
net: bcmgenet: keep RBUF EEE/PM disabled
ethernet: 3c509: Fix most coding style issues
ethernet: 3c509: Update documentation to match MAINTAINERS
ethernet: 3c509: Add GPL 2.0 SPDX license identifier
ethernet: 3c509: Fix AUI transceiver type selection
Revert "drivers: net: 3com: 3c509: Remove this driver"
tools: ynl: support listening on all nsids
net: gro: don't merge zcopy skbs
pds_core: ensure null-termination for firmware version strings
...
Bjorn Andersson [Thu, 21 May 2026 21:29:19 +0000 (16:29 -0500)]
Merge branch '20260416-qcom_ice_power_and_clk_vote-v5-13-5ccf5d7e2846@oss.qualcomm.com' into arm64-fixes-for-7.1
Merge the fixes to add power-domain and correct clocks for the ICC block
in Eliza and Milos through a topic branch, to allow them to be merged
also into arm64-for-7.2 to resolve the merge conflicts that would
otherwise appear.
Bjorn Andersson [Thu, 21 May 2026 21:31:44 +0000 (16:31 -0500)]
Merge branch '20260416-qcom_ice_power_and_clk_vote-v5-13-5ccf5d7e2846@oss.qualcomm.com' into arm64-for-7.2
Merge the two fixes for ICC blocks in Milos and Eliza through a topic
branch, in order to resolve the introduced DT validation errors in
v7.1-rc while avoiding the merge conflicts against arm64-for-7.2.
Harshal Dev [Thu, 16 Apr 2026 11:59:28 +0000 (17:29 +0530)]
arm64: dts: qcom: sm8750: Add power-domain and iface clk for ice node
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the
GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for
sm8750.
Harshal Dev [Thu, 16 Apr 2026 11:59:27 +0000 (17:29 +0530)]
arm64: dts: qcom: sm8650: Add power-domain and iface clk for ice node
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sm8650.
Harshal Dev [Thu, 16 Apr 2026 11:59:26 +0000 (17:29 +0530)]
arm64: dts: qcom: sm8550: Add power-domain and iface clk for ice node
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sm8550.
Fixes: b8630c48b43fc ("arm64: dts: qcom: sm8550: Add the Inline Crypto Engine node") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-9-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Harshal Dev [Thu, 16 Apr 2026 11:59:25 +0000 (17:29 +0530)]
arm64: dts: qcom: sm8450: Add power-domain and iface clk for ice node
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sm8450.
Fixes: 86b0aef435851 ("arm64: dts: qcom: sm8450: Use standalone ICE node for UFS") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-8-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Harshal Dev [Thu, 16 Apr 2026 11:59:24 +0000 (17:29 +0530)]
arm64: dts: qcom: kodiak: Add power-domain and iface clk for ice node
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the
GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for
kodiak.
Harshal Dev [Thu, 16 Apr 2026 11:59:23 +0000 (17:29 +0530)]
arm64: dts: qcom: sc7180: Add power-domain and iface clk for ice node
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for sc7180.
Harshal Dev [Thu, 16 Apr 2026 11:59:22 +0000 (17:29 +0530)]
arm64: dts: qcom: monaco: Add power-domain and iface clk for ice node
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the
GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for
monaco.
Fixes: cc9d29aad876d ("arm64: dts: qcom: qcs8300: enable the inline crypto engine") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-5-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Harshal Dev [Thu, 16 Apr 2026 11:59:21 +0000 (17:29 +0530)]
arm64: dts: qcom: lemans: Add power-domain and iface clk for ice node
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for lemans.
Harshal Dev [Thu, 16 Apr 2026 11:59:20 +0000 (17:29 +0530)]
arm64: dts: qcom: kaanapali: Add power-domain and iface clk for ice node
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the
GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for
kaanapali.
Harshal Dev [Thu, 16 Apr 2026 11:59:30 +0000 (17:29 +0530)]
arm64: dts: qcom: eliza: Add power-domain and iface clk for ice node
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the GCC_UFS_PHY_GDSC power domain is enabled. Specify both the
GCC_UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for
eliza.
Fixes: af20af39fc09b ("arm64: dts: qcom: Introduce Eliza Soc base dtsi") Signed-off-by: Harshal Dev <harshal.dev@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Fixes: 54a4f0239f2e ("KVM: MMU: make kvm_mmu_zap_page() return the Reviewed-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com> Link: https://lore.kernel.org/r/20260416-qcom_ice_power_and_clk_vote-v5-13-5ccf5d7e2846@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Harshal Dev [Thu, 16 Apr 2026 11:59:29 +0000 (17:29 +0530)]
arm64: dts: qcom: milos: Add power-domain and iface clk for ice node
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core' clock
the 'iface' clock should also be turned on by the driver. This can only be
done if the UFS_PHY_GDSC power domain is enabled. Specify both the
UFS_PHY_GDSC power domain and the 'iface' clock in the ICE node for milos.
KVM: SVM: Flush the current TLB when transitioning from xAVIC => x2AVIC
Flush the current TLB when xAVIC *or* x2AVIC is activated, as KVM is
(apparently) responsible for purging TLB entries when transitioning from
xAVIC to x2AVIC. The APM says a whole lot of nothing about TLB flushing
with respect to (x2)AVIC, but empirical data strongly suggests hardware
also does a whole lot of nothing.
Failure to flush the TLB when enabling x2AVIC can lead to guest accesses
to the APIC base address getting incorrectly redirected to the virtual
APIC page. The flaw most visibly manifests as failures in KVM-Unit-Test's
verify_disabled_apic_mmio() testcase when x2APIC is enabled (though for
reasons unknown, the test only reliably fails with EFI builds).
Fixes: 0ccf3e7cb95a ("KVM: SVM: Flush the "current" TLB when activating AVIC") Fixes: 4d1d7942e36a ("KVM: SVM: Introduce logic to (de)activate x2AVIC mode") Cc: stable@vger.kernel.org Cc: Naveen N Rao (AMD) <naveen@kernel.org> Link: https://patch.msgid.link/20260515171536.1841645-1-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com>
Emily Ehlert [Mon, 18 May 2026 13:59:56 +0000 (13:59 +0000)]
KVM: x86: Fix ERAPS RAP clear on INVPCID single-context invalidation
Use kvm_register_mark_dirty() instead of kvm_register_is_dirty() to
actually mark VCPU_EXREG_ERAPS as dirty when emulating
INVPCID_TYPE_SINGLE_CTXT. kvm_register_is_dirty() is a read-only
predicate whose return value is discarded, making the call a no-op.
Without this fix, a single-context INVPCID will not trigger a RAP clear
on the next VMRUN, breaking the ERAPS security guarantee.
Linus Torvalds [Thu, 21 May 2026 21:17:28 +0000 (14:17 -0700)]
Merge tag 'ceph-for-7.1-rc5' of https://github.com/ceph/ceph-client
Pull ceph fix from Ilya Dryomov:
"A fix for an 'rbd unmap' race condition which popped up on a
production setup where many RBD devices are frequently mapped and
unmapped, marked for stable"
* tag 'ceph-for-7.1-rc5' of https://github.com/ceph/ceph-client:
rbd: eliminate a race in lock_dwork draining on unmap
Abel Vesa [Wed, 13 May 2026 11:11:02 +0000 (14:11 +0300)]
dt-bindings: cache: qcom,llcc: Document Eliza LLCC block
Document the Last Level Cache Controller on Eliza SoC. Eliza LLCC has 2
base register regions and an additional AND, OR broadcast region, total 4
register regions.
lockd: fix TEST handling when not all permissions are available.
The F_GETLK fcntl can work with either read access or write access or
both. It can query F_RDLCK and F_WRLCK locks in either case.
However lockd currently treats F_GETLK similar to F_SETLK in that read
access is required to query an F_RDLCK lock and write access is required
to query a F_WRLCK lock.
This is wrong and can cause problems - e.g. when qemu accesses a
read-only (e.g. iso) filesystem image over NFS (though why it queries
if it can get a write lock - I don't know. But it does, and this works
with local filesystems).
So we need TEST requests to be handled differently. To do this:
- change nlm_do_fopen() to accept O_RDWR as a mode and in that case
succeed if either a O_RDONLY or O_WRONLY file can be opened.
- change nlm_lookup_file() to accept a mode argument from caller,
instead of deducing base on lock time, and pass that on to nlm_do_fopen()
- change nlm4svc_retrieve_args() and nlmsvc_retrieve_args() to detect
TEST requests and pass O_RDWR as a mode to nlm_lookup_file, passing
the same mode as before for other requests. Also set
lock->fl.c.flc_file to whichever file is available for TEST requests.
- change nlmsvc_testlock() to also not calculate the mode, but to use
whatever was stored in lock->fl.c.flc_file.
This behaviour of lockd - requesting O_WRONLY access to TEST for
exclusive locks - has been present at least since git history began.
However it was hidden until recently because knfsd ignored the access
requested by lockd and required only READ access for all locking
requests (unless the underlying filesystem provided an f_op->open
function which checked access permissions).
The commit mentioned in Fixes: below changed nfsd_permission() to NOT
override the access request for LOCK requests and this exposed the bug
that we are now fixing.
Note that there is another issue that this patch does not address.
The flock(.., LOCK_EX) call is permitted on a read-only file descriptor.
Linux NFS maps this to NLM locking as whole-file byte-range locks.
nfsd will see this as though it were fcntl( F_SETLK (F_WRLCK)) and will
now require write access, which it might not be able to get.
It is not clear if this is a problem in practice, or what the best
solution might be. So no attempt is made to address it.
Reported-by: Tj <tj.iam.tj@proton.me> Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1128861 Fixes: 4cc9b9f2bf4d ("nfsd: refine and rename NFSD_MAY_LOCK") Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: NeilBrown <neil@brown.name> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Tue, 21 Apr 2026 19:20:21 +0000 (15:20 -0400)]
NFSD: Report whether fh_key was actually updated
The nfsd_ctl_fh_key_set tracepoint was introduced to capture
operator activity on the filehandle signing key. Earlier revisions
logged the key bytes verbatim; the version that landed hashes the
16 key bytes through crc32_le and stores the result.
CRC32 is a linear projection of its input rather than a one-way
function, and truncating any hash of fixed-size secret material
leaves the key recoverable under offline brute force when the
threat model includes an attacker with access to the trace ring.
The operational question the fingerprint was meant to answer is
whether a NFSD_CMD_THREADS_SET call that carries an
NFSD_A_SERVER_FH_KEY attribute actually replaced the active key or
re-installed the value already in place. Answer that question
directly: compare the incoming key bytes against the current
nn->fh_key inside nfsd_nl_fh_key_set() and surface a single bit to
the tracepoint. The event now prints "updated" when the stored
key changed and "unmodified" otherwise. A first set that fails
kmalloc reports "unmodified" because no key was installed.
Reported-by: jaeyeong <fin@spl.team> Fixes: 62346217fd72 ("NFSD: Add a key for signing filehandles") Cc: Benjamin Coddington <bcodding@hammerspace.com> Reviewed-by: Benjamin Coddington <bcodding@hammerspace.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Chuck Lever [Tue, 21 Apr 2026 16:11:25 +0000 (12:11 -0400)]
sunrpc: prevent out-of-bounds read in __cache_seq_start()
Commit 7b546bd89975 ("sunrpc/cache: improve RCU safety in
cache_list walking.") changed the tail of __cache_seq_start()
to unconditionally store
*pos = ((long long)hash << 32) + 1
before returning, dropping a prior "hash >= cd->hash_size"
guard. When the while loop exits because every remaining
bucket was empty, hash equals cd->hash_size, so the stored
*pos is one position past the table's last valid bucket.
seq_read_iter() caches that index in m->index. A subsequent
pread(2) at the same file offset skips traverse() and hands
the stored index back to __cache_seq_start(), which decodes
hash = cd->hash_size and dereferences
cd->hash_table[cd->hash_size] -- one hlist_head past the end
of the kzalloc'd table.
KASAN reports an eight-byte slab-out-of-bounds read at the
tail of the 2048-byte hash_table allocation for the NFSD
export cache (EXPORT_HASHMAX * sizeof(struct hlist_head) ==
256 * 8).
Reject an input hash that is out of range before touching the
hash table. cache_seq_next() already bounds-checks its own
loop; the start routine needs to be symmetric.
Reported-by: syzbot+60cfa08822470bbebe44@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=60cfa08822470bbebe44 Fixes: 7b546bd89975 ("sunrpc/cache: improve RCU safety in cache_list walking.") Reviewed-by: Benjamin Coddington <bcodding@hammerspace.com> Reviewed-by: NeilBrown <neil@brown.name> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
arm64: dts: qcom: eliza: Sort nodes by unit address
Qualcomm DTS uses sorting of MMIO nodes by the unit address, so move
few nodes in Eliza DTSI to fix that.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Alexander Koskovich <akoskovich@pm.me> Link: https://lore.kernel.org/r/20260418-eliza-imem-v3-1-bfbd499b6e77@pm.me
[bjorn: Rebased on top of branch] Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Linus Torvalds [Thu, 21 May 2026 21:05:09 +0000 (14:05 -0700)]
Merge tag 'trace-ringbuffer-v7.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
Pull ring-buffer fixes from Steven Rostedt:
- Fix reporting MISSED EVENTS in trace iterator
When the "trace" file is read with tracing enabled, if the writer
were to pass the iterator reader, it resets, sets a "missed_events"
flag and continues. The tracing output checks for missed events and
if there are some, it prints out "[LOST EVENTS]" to let the user know
events were dropped.
But the clearing of the missed_events happened when the tracing
system queried the ring buffer iterator about missed events. This was
premature as the ring buffer is per CPU, and the tracing code reads
all the CPU buffers and checks for missed events when it is read. If
the CPU iterator that had missed events isn't printed next, the
output for the LOST EVENTS is lost.
Clear the missed_events flag when the iterator moves to the next
event and not when the missed_events flag is queried. Also clear it
on reset.
- Flush and stop the persistent ring buffer on panic
On panic the persistent ring buffer is used to debug what caused the
panic. But on some architectures, it requires flushing the memory
from cache, otherwise, the ring buffer persistent memory may not have
the last events and this could also cause the ring buffer to be
corrupted on the next boot.
- Fix nr_subbufs initialization in simple_ring_buffer_init_mm
The remote simple ring buffer meta data nr_subbufs is initialized too
early and gets cleared later on, making it zero and not reflect the
actual number of sub-buffers.
- Fix unload_page for simple_ring_buffer init rollback
On error, the pages loaded need to be unloaded. To unload a page it
is expected that: page = load_page(va); -> unload_page(page). But the
code was doing: unload_page(va) and not unload_page(page).
- Create output file from cmd_check_undefined
The check for undefined symbols checks if the file *.o.checked exists
and if so it skips doing the work. But the *.o.checked file never was
created making every build do the work even when it was already done
previously.
* tag 'trace-ringbuffer-v7.1-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace:
tracing: Create output file from cmd_check_undefined
tracing: Fix unload_page for simple_ring_buffer init rollback
tracing: Fix nr_subbufs initialization in simple_ring_buffer_init_mm()
ring-buffer: Flush and stop persistent ring buffer on panic
ring-buffer: Fix reporting of missed events in iterator
Describe the missing Eliza SoC nodes for the QUPv3 WRAP1 and WRAP2 serial
engines, add the matching GPI DMA controllers, the SDHCI controllers and
the LLCC system cache controller.
Also add the TLMM pinctrl states for the QUPv3 serial engines and the
SD card/eMMC interfaces, plus OPP tables for the SDHCI controllers.
Keith Busch [Thu, 21 May 2026 19:02:53 +0000 (12:02 -0700)]
blk-mq: pop cached request if it is usable
When submitting a bio to blk-mq, if the task should sleep after peeking
a cached request, but before it pops it, the plug flushes and calls
blk_mq_free_plug_rqs, freeing the cached_rqs. This creates a
use-after-free bug. Fix this by popping the cached request before any
possible blocking calls if it is suitable for use.
Popping this request first holds a queue reference, so avoid any
serialization races with queue freezes and can safely proceed with
dispatching that request to the driver. This potentially increases a
timing window from when a driver wants to freeze its queue to when
requests stop being dispatched. That scenario is off the fast path
though, and drivers need to appropriately handle requests during a
freeze request anyway.
The downside is the popped element needs to be individually freed when
we performed a bio plug merge. The cached request would have had to be
freed later anyway, but this patch does it inline with building the plug
list instead of after flushing it.
Fixes: b0077e269f6c1 ("blk-mq: make sure active queue usage is held for bio_integrity_prep()") Fixes: 7b4f36cd22a65 ("block: ensure we hold a queue reference when using queue limits") Signed-off-by: Keith Busch <kbusch@kernel.org> Link: https://patch.msgid.link/20260521190253.242065-1-kbusch@meta.com Signed-off-by: Jens Axboe <axboe@kernel.dk>
Jeongjun Park [Thu, 21 May 2026 11:37:12 +0000 (20:37 +0900)]
ASoC: codecs: pcm512x: fix null-ptr dereference in pcm512x_overclock_xxx_put()
In the pcm512x chipset driver, pcm512x_overclock_xxx_put() is defined as
a general mixer kcontrol instead of a DAPM kcontrol, so struct
snd_soc_dapm_context must not be accessed via
snd_soc_dapm_kcontrol_to_dapm().
This causes a NULL pointer dereference, so it must be modified to use
snd_soc_component_to_dapm().
Cc: stable@kernel.org Closes: https://github.com/raspberrypi/linux/issues/7242 Fixes: 02dbbb7e982a ("ASoC: codecs: pcm512x: convert to snd_soc_dapm_xxx()") Signed-off-by: Jeongjun Park <aha310510@gmail.com> Link: https://patch.msgid.link/20260521113712.227438-1-aha310510@gmail.com Signed-off-by: Mark Brown <broonie@kernel.org>
Charles Keepax [Wed, 20 May 2026 16:36:30 +0000 (17:36 +0100)]
ASoC: Intel: soc-acpi-intel-ptl-match: Remove unnecessary cs42l43 match
For PTL onwards Cirrus are intending to rely on function topologies,
rather than using a match table for each system type. Remove this
unnecessary match table entry. Having the match entries can
mean that systems match when they should use function topologies
instead, resulting in incorrect audio configurations. Although,
admittedly this is not too likely with this 6x amp configuration
as those are quite rare, but best to follow best practice.
Charles Keepax [Wed, 20 May 2026 16:36:29 +0000 (17:36 +0100)]
ASoC: soc-acpi-intel-ptl-match: Make Chrome matches conditional
For PTL onwards Cirrus are intending to rely on function
topologies, rather than using a match table for each system
type. Chrome systems tend to have custom magic in the topology
and thus need to load a specific file. This causes problems as
these system can have the same layout as generic laptops causing
the match to apply to other laptops. Add a DMI quirk that forces
these matches to only apply to specific devices.
Cosmin Tanislav [Wed, 20 May 2026 20:31:15 +0000 (23:31 +0300)]
irqchip/renesas-rzt2h: Use pm_runtime_put_sync() in probe error path
pm_runtime_put() may trigger the idle check after pm_runtime_disable()
is run as part of devm_pm_runtime_enable()'s cleanup action, leaving
runtime PM active.
Use pm_runtime_put_sync() to ensure the idle check runs synchronously.
Jakub Kicinski [Thu, 21 May 2026 18:03:58 +0000 (11:03 -0700)]
Merge tag 'wireless-2026-05-21' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless
Johannes Berg says:
====================
Quite a few more updates:
- cfg80211/mac80211:
- various security(-ish) fixes
- fix A-MSDU subframe handling
- fix multi-link element parsing
- ath10: avoid sending commands to dead device
- ath11k:
- fix WMI buffer leaks on error conditions
- fix UAF in RX MSDU coalesce path
- allow peer ID 0 on RX path (legal for mobile devices)
- reinitialize shared SRNG pointers on restart
- ath12k:
- fix 20 MHz-only parsing of EHT-MCS map
- iwlwifi:
- fix TSO segmentation explosion
- don't TX to dead device
- fix warning in WoWLAN
- fix TX rates on old devices
- disconnect on beacon loss only if also no other traffic
- fill NULL-ptr deref
- fix STEP_URM hardware access
* tag 'wireless-2026-05-21' of https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless: (24 commits)
wifi: cfg80211: wext: validate chandef in monitor mode
wifi: mac80211: consume only present negotiated TTLM maps
wifi: wilc1000: fix dma_buffer leak on bus acquire failure
wifi: mac80211: capture fast-RX rate before mesh reuses skb->cb
wifi: mac80211: fix multi-link element inheritance
wifi: mac80211: fix MLE defragmentation
wifi: mac80211: don't override max_amsdu_subframes
wifi: mac80211: bounds-check link_id in ieee80211_ml_epcs
wifi: ath12k: fix EHT TX MCS limitation due to wrong 20 MHz-only parsing
wifi: ath11k: clear shared SRNG pointer state on restart
wifi: ath11k: fix use after free in ath11k_dp_rx_msdu_coalesce()
wifi: ath11k: fix peer resolution on rx path when peer_id=0
wifi: iwlwifi: mld: disconnect only after 6 beacons without Rx
wifi: iwlwifi: mld: don't WARN on WoWLAN suspend w/o BSS vif
wifi: iwlwifi: use correct function to read STEP_URM register
wifi: iwlwifi: mvm: fix driver-set TX rates on old devices
wifi: iwlwifi: mld: don't dereference a pointer before NULL checking it
wifi: iwlwifi: mld: stop TX during firmware restart
wifi: iwlwifi: mld: fix TSO segmentation explosion when AMSDU is disabled
wifi: ath10k: skip WMI and beacon transmission when device is wedged
...
====================
This fixes an inconsistency where io_nop() called req_set_fail()
based on ret, but passed just nop->result to userspace.
Originally, ret is a even copy of nop->result, but is set to an error
when such happens subsequently. Now that's also passed to userspace.
Dhabaleshwar Das [Wed, 20 May 2026 18:30:00 +0000 (00:00 +0530)]
accel/rocket: fix UAF via dangling GEM handle in create_bo
rocket_ioctl_create_bo() inserts a GEM handle into the file's IDR via
drm_gem_handle_create() early on, then performs several operations that
can fail (sgt allocation, drm_mm insert, iommu_map). If any fail after
the handle is live, the error path calls drm_gem_shmem_object_free()
which kfree's the object without removing the handle from the IDR.
This leaves a dangling handle pointing to freed slab memory. Any
subsequent ioctl using that handle (PREP_BO, FINI_BO, SUBMIT) calls
drm_gem_object_lookup() and dereferences freed memory (UAF).
Fix by moving drm_gem_handle_create() to after all fallible operations
succeed, matching the pattern used by panfrost, lima, and etnaviv.
Also fix drm_mm_insert_node_generic() whose return value was silently
overwritten by iommu_map_sgtable() on the next line. Add the missing
error check.
[tomeu: Move handle creation to the very end]
Fixes: 658ebeac3351 ("accel/rocket: Add IOCTL for BO creation") Reported-by: Dhabaleshwar Das <dhabal123@gmail.com> Signed-off-by: Dhabaleshwar Das <dhabal123@gmail.com> Reviewed-by: Tomeu Vizoso <tomeu@tomeuvizoso.net> Link: https://patch.msgid.link/20260521165720.2113571-1-tomeu@tomeuvizoso.net Signed-off-by: Tomeu Vizoso <tomeu@tomeuvizoso.net>
Florian Schmaus [Thu, 7 May 2026 08:48:54 +0000 (10:48 +0200)]
kunit: fix use-after-free in debugfs when using kunit.filter
When the kernel is booted with a kunit filter (e.g.,
kunit.filter="speed!=slow"), the kunit executor dynamically allocates
copies of the filtered test suites using kmalloc/kmemdup.
During the initial boot execution, kunit_debugfs_create_suite() creates
debugfs files (such as /sys/kernel/debug/kunit/<suite>/run) and
permanently stores a pointer to the dynamically allocated suite in the
inode's i_private field.
Previously, the executor freed this dynamically allocated suite_set
immediately after executing the boot-time tests. Because the debugfs
nodes were not destroyed, any subsequent interaction with the debugfs
`run` file from userspace triggered a use-after-free (UAF). On systems
with architectural capabilities, like CHERI RISC-V, this resulted in
an immediate fatal hardware exception due to the invalidation of the
capability tags on the reclaimed memory. On other architectures, it
resulted in silent memory corruption.
Fix this UAF by properly coupling the lifetime of the filtered suite
memory allocation to the lifetime of the kunit subsystem and its
associated VFS nodes. Ownership of the boot-time suite_set is now
transferred to a global tracker ('kunit_boot_suites'), and the memory
is cleanly released in kunit_exit() during module teardown.
Link: https://lore.kernel.org/r/20260507084854.233984-1-florian.schmaus@codasip.com Fixes: e2219db280e3 ("kunit: add debugfs /sys/kernel/debug/kunit/<suite>/results display") Signed-off-by: Florian Schmaus <florian.schmaus@codasip.com> Reviewed-by: Martin Kaiser <martin@kaiser.cx> Reviewed-by: David Gow <david@davidgow.net> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Cristian Marussi [Sun, 10 May 2026 16:05:27 +0000 (17:05 +0100)]
firmware: arm_scmi: optee: Rework transport probe sequence
Use the new per-instance transport handles helpers to synchronize and
optionally defer the core SCMI driver probe up until the transport driver
has completely been initialized and it is fully operational as a supplier.
Introduce proper module init/exit routines while removing the ugly trick of
registering a driver from within the probe sequence of another one, just to
avoid to have to deal with probe deferrals.
Cristian Marussi [Sun, 10 May 2026 16:05:26 +0000 (17:05 +0100)]
firmware: arm_scmi: virtio: Rework transport probe sequence
Use the new per-instance transport handles helpers to synchronize and
optionally defer the core SCMI driver probe up until the transport driver
has completely been initialized and it is fully operational as a supplier.
Introduce proper module init/exit routines while removing the ugly trick of
registering a driver from within the probe sequence of another one, just to
avoid to have to deal with probe deferrals.
Cristian Marussi [Sun, 10 May 2026 16:05:25 +0000 (17:05 +0100)]
firmware: arm_scmi: Add a generic transport supplier
Add the capability to define a common generic transport supplier which
embeds the logic needed to support one single unique instance of transport
supplier.
Cristian Marussi [Sun, 10 May 2026 16:05:24 +0000 (17:05 +0100)]
firmware: arm_scmi: Add transport instance handles
SCMI transport drivers are initialized first and then the control is passed
to the SCMI core stack: some of these transports are dependent also on some
external subsytem which will have to be initialized upfront, before the
transport driver itself can be deemed operational.
Transport drivers like virtio or optee need a way to defer the core SCMI
probing till they are fully initialized and operational and also a way to
pass back the device reference to be used as a supplier while building the
devlink relations.
SCMI transport drivers can be probed multiple times when used in a multiple
instance configuration but the capability to carry-on with multiple probes
depends on the support provided by the underlying transport driver.
This change will also allow for the removal of the frowned-upon trick of
registering a platform driver only after the end of the transport drivers
porbe to avoid explicit probe deferrals.
Samuele Mariotti [Thu, 21 May 2026 10:59:11 +0000 (12:59 +0200)]
sched_ext: Fix spurious WARN on stale ops_state in ops_dequeue()
ops_dequeue() can race with finish_dispatch() and spuriously trigger the
"queued task must be in BPF scheduler's custody" warning.
ops_dequeue() snapshots p->scx.ops_state via atomic_long_read_acquire()
and then, in the SCX_OPSS_QUEUED arm, asserts that SCX_TASK_IN_CUSTODY
is set. The two reads are not atomic w.r.t. a concurrent
finish_dispatch() running on another CPU:
The race has been observed via two distinct call chains: the most common
goes through sched_setaffinity(), a rarer variant through
sched_change_begin().
For SCX_DSQ_GLOBAL / SCX_DSQ_BYPASS, dispatch_enqueue() clears
SCX_TASK_IN_CUSTODY before clearing ops_state to SCX_OPSS_NONE
(intentional, to avoid concurrent non-atomic RMW of p->scx.flags against
ops_dequeue()). The window between those two writes is exactly what
ops_dequeue() observes as "QUEUED without custody".
The observed state is not actually inconsistent, it just means CPU 1 has
already claimed the task and the QUEUED value held by CPU 2 is stale.
Re-read ops_state in that case; the next read is guaranteed to return
SCX_OPSS_DISPATCHING or SCX_OPSS_NONE, both of which exit the switch
cleanly. The retry is bounded: once IN_CUSTODY is cleared, ops_state has
already advanced past QUEUED for this dispatch cycle, and a fresh QUEUED
would require re-enqueue under p's rq lock, which CPU 2 holds.
Changes in v2:
- Use READ_ONCE() for p->scx.flags to ensure fresh reads and prevent
compiler reordering in the lockless path
- Add cpu_relax() to reduce power consumption and improve performance
during the spin-wait
- Use unlikely() to optimize branch prediction for the common case
- Expand the in-code comment to document the race condition and
bounded retry guarantee
Fredric Cover [Wed, 13 May 2026 20:19:15 +0000 (13:19 -0700)]
smb: client: change allocation requirements in DUP_CTX_STR macro
Currently, the macro DUP_CTX_STR allocates new_ctx->field using
GFP_ATOMIC. DUP_CTX_STR is only used in smb3_fs_context_dup(), which
is never called in an atomic context. Using GFP_ATOMIC puts unnecessary
pressure on emergency memory pools.
Change GFP_ATOMIC to GFP_KERNEL.
Signed-off-by: Fredric Cover <fredric.cover.lkernel@gmail.com> Signed-off-by: Steve French <stfrench@microsoft.com>
smb: client: require net admin for CIFS SWN netlink
CIFS_GENL_CMD_SWN_NOTIFY is the userspace witness-notify command. The
intended sender is the cifs.witness helper, but the generic-netlink
operation currently has no capability flag, so any local process can send
RESOURCE_CHANGE or CLIENT_MOVE notifications to the in-kernel witness
handler.
The same family exposes CIFS_GENL_MCGRP_SWN without multicast-group
capability flags. Register messages sent to that group include the witness
registration id and, for NTLM-authenticated mounts, the username, domain,
and password attributes copied from the CIFS session. An unprivileged
local process should not be able to join that group and receive those
messages.
Require CAP_NET_ADMIN for incoming SWN_NOTIFY commands with
GENL_ADMIN_PERM, and require CAP_NET_ADMIN over the network namespace for
joining the SWN multicast group with GENL_MCAST_CAP_NET_ADMIN. The
cifs.witness service runs with the privileges needed for both operations.
Fixes: fed979a7e082 ("cifs: Set witness notification handler for messages from userspace daemon") Cc: stable@vger.kernel.org Signed-off-by: Michael Bommarito <michael.bommarito@gmail.com> Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Steve French <stfrench@microsoft.com>
====================
net: enetc: SR-IOV robustness and security fixes
This patch series addresses a number of robustness, security, and
correctness issues in the ENETC driver's SR-IOV subsystem, focusing
primarily on the VF-to-PF mailbox communication path.
The series can be grouped into the following categories:
1. DoS and security fixes:
- Prevent an unbounded loop DoS in the VF-to-PF message handler,
which could be triggered by a malicious or misbehaving VF.
- Fix a TOCTOU (Time-of-Check-Time-of-Use) race and add proper
validation of VF MAC addresses to prevent spoofing or invalid
configuration from being applied.
2. Race condition fixes:
- Fix a race condition in VF MAC address configuration that could
lead to inconsistent state between the VF request and PF
application.
- Fix a race condition during SR-IOV teardown that could cause
VF->PF mailbox operations to time out, resulting in unnecessary
errors during shutdown.
3. Memory safety fixes:
- Fix a DMA write to freed memory in enetc_msg_free_mbx(), which
could cause silent memory corruption or system instability.
4. Error handling and initialization fixes:
- Fix missing error code propagation when pf->vf_state allocation
fails, ensuring callers receive a proper errno instead of
succeeding silently.
- Fix incorrect mailbox message status values returned to VFs,
which could cause VFs to misinterpret PF responses.
- Fix initialization order to prevent the use of uninitialized
resources during driver probe, which could cause undefined
behavior on certain configurations.
5. Diagnostics improvement:
- Add rate limiting to VF mailbox error messages to prevent log
flooding in the presence of a misbehaving VF.
These fixes improve the overall stability and security of the ENETC
SR-IOV implementation, particularly in multi-tenant environments where
VFs may be assigned to untrusted guests.
====================
Wei Fang [Wed, 20 May 2026 06:44:21 +0000 (14:44 +0800)]
net: enetc: avoid VF->PF mailbox timeout during SR-IOV teardown
During SR-IOV teardown, enetc_msg_psi_free() disables the MR interrupt
before pci_disable_sriov() removes the VFs. If a VF sends a mailbox
message during this window, the PF cannot receive it, causing the VF to
timeout waiting for a reply.
Since the timeout occurs during SR-IOV teardown when the VF is about to
be removed anyway, it has no functional impact on operation. However,
more messages will be added in the future, some visible error logs may
confuse users. So fix it by calling pci_disable_sriov() first to remove
all VFs, then safely clean up the mailbox resources. This eliminates the
race window where VFs could send messages to an unresponsive PF.
This ordering is unsafe because if a spurious interrupt or pending
interrupt from a previous device state fires immediately after
request_irq() returns, the registered ISR enetc_msg_psi_msix() will
execute and unconditionally call:
schedule_work(&pf->msg_task)
At this point, pf->msg_task has not been initialized by INIT_WORK(), so
the work_struct contains garbage values in its internal linked list
pointers (work_struct->entry). Passing an uninitialized work_struct to
schedule_work() could corrupt the kernel's workqueue linked lists,
potentially leading to:
- Kernel panic in __queue_work()
- Memory corruption in workqueue data structures
- System deadlock or undefined behavior
Additionally, even if the work_struct was initialized, the mailbox DMA
buffers (pf->rxmsg[]) may not yet be allocated when the work handler
enetc_msg_task() runs, resulting in NULL pointer dereference.
Fix by reordering the initialization sequence to ensure all resources are
properly initialized before the interrupt handler can execute:
1. enetc_msg_alloc_mbx() <- Allocate all mailboxes
2. INIT_WORK(&pf->msg_task, ...) <- Initialize work first
3. request_irq(enetc_msg_psi_msix) <- Register IRQ last
4. Configure hardware & enable MR interrupts
This guarantees that when enetc_msg_psi_msix() runs:
- pf->msg_task is properly initialized (safe for schedule_work)
- pf->rxmsg[] buffers are allocated (safe for work handler access)
- Hardware is configured appropriately
As the inverse of enetc_msg_psi_init(), enetc_msg_psi_free() also has
similar problems. For example, if a pending interrupt fires between
enetc_msg_free_mbx() and free_irq(), the ISR enetc_msg_psi_msix() may
schedule the work handler again via schedule_work(), which could then
access already-freed DMA buffers (pf->rxmsg[]), leading to use-after-free
and potential memory corruption.
Therefore, the order of enetc_msg_psi_free() is adjusted:
1. enetc_msg_disable_mr_int() <- Stop new interrupts first
2. free_irq() <- Ensure no IRQ handler can run
3. cancel_work_sync() <- Wait for any pending work
4. enetc_msg_disable_mr_int() <- Re-disable in case work
re-enabled it
5. enetc_msg_free_mbx() <- Safe to free DMA buffers now
Wei Fang [Wed, 20 May 2026 06:44:19 +0000 (14:44 +0800)]
net: enetc: fix unbounded loop and interrupt handling in VF-to-PF messaging
The enetc_msg_task() function has several issues that need to be addressed:
1. Unbounded loop causing potential DoS:
enetc_msg_task() processes VF-to-PF mailbox messages in an unbounded
for(;;) loop that keeps polling ENETC_PSIMSGRR until no MR bits are set.
A malicious guest VM can exploit this by continuously sending messages at
a high rate - immediately sending a new message as soon as the PF
acknowledges the previous one. Since the worker thread never yields or
enforces a processing budget, the mr_mask check frequently evaluates to
non-zero, causing the PF to spin indefinitely and starving other tasks.
Fix this by replacing the unbounded loop with a single snapshot read at
task entry. The task processes only the VFs whose MR bits were set at
that point, then re-enables message interrupts before returning. This
bounds work per invocation to at most num_vfs iterations. No messages are
lost because the message interrupt is disabled in enetc_msg_psi_msix()
before scheduling enetc_msg_task(), so any new messages arriving during
processing will trigger a fresh interrupt once re-enabled, scheduling
another task invocation.
2. Write order of ENETC_PSIIDR and ENETC_PSIMSGRR:
Both ENETC_PSIIDR and ENETC_PSIMSGRR contain MR bits indicating messages
have been received from VSIs, but only ENETC_PSIIDR trigger the CPU
interrupt. Previously, ENETC_PSIMSGRR was written before ENETC_PSIIDR.
Writing ENETC_PSIMSGRR returns the message code to the VSI in its upper
16 bits, signaling to the VF that message processing is complete and it
may send the next message. If the VF sends a new message before
ENETC_PSIIDR is written, the subsequent w1c write to ENETC_PSIIDR would
inadvertently clear the MR bit set by the new message, causing the
interrupt to be lost and the new message to go unprocessed.
Therefore, write ENETC_PSIIDR first to clear the interrupt source, then
write ENETC_PSIMSGRR to acknowledge the message to the VSI.
3. Check both ENETC_PSIMSGRR and ENETC_PSIIDR for mr_status:
The write order change above introduces a potential race: if a VF sends
a new message in the window between the ENETC_PSIIDR w1c and the
ENETC_PSIMSGRR w1c, the ENETC_PSIMSGRR MR bit for the new message may
not be set. If mr_status was derived solely from ENETC_PSIMSGRR, this
message would never be detected despite ENETC_PSIIDR retaining its MR
bit, leading to an unacknowledged interrupt storm.
Fix this by computing mr_status as the union of both ENETC_PSIMSGRR and
ENETC_PSIIDR MR bits, ensuring all pending messages are detected
regardless of which register reflects the new message state.
Additionally, rename the per-register MR macros (ENETC_PSI*_MR_MASK,
ENETC_PSI*_MR) to register-agnostic names (ENETC_PSIMR_MASK,
ENETC_PSIMR_BIT) since the MR bit layout is shared across ENETC_PSIMSGRR,
ENETC_PSIIER, and ENETC_PSIIDR. Make the mask macro dynamic based on
the actual number of active VFs rather than hardcoded.
Wei Fang [Wed, 20 May 2026 06:44:18 +0000 (14:44 +0800)]
net: enetc: fix DMA write to freed memory in enetc_msg_free_mbx()
The teardown sequence in enetc_msg_psi_free() frees the DMA buffer before
clearing the device's DMA address registers. If a VF sends a message or a
pending DMA transfer completes within this window, the hardware will
perform a DMA write into the kernel memory that has already been returned
to the allocator.
The result is silent memory corruption that can affect arbitrary kernel
data structures. Therefore, clear the DMA address registers before the
DMA buffer is freed.
Wei Fang [Wed, 20 May 2026 06:44:17 +0000 (14:44 +0800)]
net: enetc: fix race condition in VF MAC address configuration
Sashiko reported a potential race condition between the VF message
handler and administrative VF MAC configuration from the host [1].
The VF message handler (enetc_msg_pf_set_vf_primary_mac_addr) runs
asynchronously in a workqueue context and accesses vf_state->flags
without any locking. Concurrently, the host can administratively
change the VF MAC address via enetc_pf_set_vf_mac(), which executes
under RTNL lock and modifies both vf_state->flags and hardware
registers.
This creates two race windows:
1) TOCTOU race on vf_state->flags: The check of ENETC_VF_FLAG_PF_SET_MAC
and subsequent MAC programming are not atomic, allowing the flag state
to change between check and use.
2) Torn MAC address writes: Hardware MAC programming requires multiple
non-atomic register writes (__raw_writel for lower 32 bits and
__raw_writew for upper 16 bits). Concurrent updates from VF mailbox
and PF admin paths can interleave these operations, resulting in a
corrupted MAC address being programmed into the hardware.
Fix by introducing a per-VF mutex to serialize access to vf_state and
hardware MAC register updates. Both enetc_pf_set_vf_mac() and
enetc_msg_pf_set_vf_primary_mac_addr() now acquire this lock before
accessing vf_state->flags or programming the MAC address, ensuring
atomic read-modify-write sequences and preventing register write
interleaving.
Wei Fang [Wed, 20 May 2026 06:44:16 +0000 (14:44 +0800)]
net: enetc: fix TOCTOU race and validate VF MAC address
Sashiko reported that the PF driver accepts arbitrary MAC address from
from VF mailbox messages without proper validation, creating a security
vulnerability [1].
In enetc_msg_pf_set_vf_primary_mac_addr(), the MAC address is extracted
directly from the message buffer (cmd->mac.sa_data) and programmed into
hardware via pf->ops->set_si_primary_mac() without any validity checks.
A malicious VF can configure a multicast, broadcast, or all-zero MAC
address. Therefore, a validation to check the MAC address provided by VF
is required.
However, simply checking the MAC address is not enough, because it also
has the potential TOCTOU race [2]: The code reads the MAC address from
the DMA buffer to validate it via is_valid_ether_addr(), if validation
passes, reads the same DMA buffer a second time when calling
enetc_pf_set_primary_mac_addr() to program the hardware. A malicious VF
can exploit this window by overwriting the MAC address in the DMA buffer
between the validation check and the hardware programming, bypassing the
validation entirely.
Therefore, allocate a local buffer in enetc_msg_handle_rxmsg() and copy
the message content from the DMA buffer via memcpy() before processing.
This ensures the PF operates on a stable snapshot that the VF cannot
modify.
Wei Fang [Wed, 20 May 2026 06:44:15 +0000 (14:44 +0800)]
net: enetc: add ratelimiting to VF mailbox error messages
Sashiko reported that a buggy or malicious guest VM can flood the host
kernel log by repeatedly sending VF-to-PF messages at a high rate,
degrading host performance and hiding important system logs [1].
Fix by replacing dev_err()/dev_warn() with dev_err_ratelimited(),
limiting output to the default kernel ratelimit. This ensures errors are
still logged for debugging while preventing log flooding attacks.
Wei Fang [Wed, 20 May 2026 06:44:14 +0000 (14:44 +0800)]
net: enetc: fix missing error code when pf->vf_state allocation fails
In enetc_pf_probe(), when the memory allocation for pf->vf_state fails,
the code jumps to the error handling label but the variable 'err' is not
assigned an appropriate error code beforehand. This causes the function
to return 0 (success) on an allocation failure path, misleading the
caller into thinking the probe succeeded. So set err to -ENOMEM before
jumping to the error handling label when the allocation for pf->vf_state
returns NULL.
Wei Fang [Wed, 20 May 2026 06:44:13 +0000 (14:44 +0800)]
net: enetc: fix incorrect mailbox message status returned to VFs
There are two cases where VFs receive an incorrect success status from
the PF mailbox message handler, misleading them into believing their
requests have been fulfilled:
In enetc_msg_handle_rxmsg(), *status is pre-initialized to
ENETC_MSG_CMD_STATUS_OK. When an unsupported command type is received,
the default case only logs an error without updating *status, so it
remains as ENETC_MSG_CMD_STATUS_OK.
In enetc_msg_pf_set_vf_primary_mac_addr(), when the PF has already
assigned a MAC address for the VF (ENETC_VF_FLAG_PF_SET_MAC is set),
the function rejects the request but returns ENETC_MSG_CMD_STATUS_OK
instead of ENETC_MSG_CMD_STATUS_FAIL.
Therefore, correct the status value for the two cases mentioned above.
Eric Dumazet [Wed, 20 May 2026 11:42:07 +0000 (11:42 +0000)]
net: bridge: prevent too big nested attributes in br_fill_linkxstats()
After commit ff205bf8c554 ("netlink: add one debug check in nla_nest_end()")
syzbot found that br_fill_linkxstats() can send corrupted netlink packets.
Make sure the nested attribute size is bounded.
Fixes: a60c090361ea ("bridge: netlink: export per-vlan stats") Reported-by: syzbot+a35f9259d08f907c06e6@syzkaller.appspotmail.com Closes: https://lore.kernel.org/netdev/6a0b0da3.050a0220.175f0c.0000.GAE@google.com/ Signed-off-by: Eric Dumazet <edumazet@google.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Acked-by: Nikolay Aleksandrov <razor@blackwall.org> Link: https://patch.msgid.link/20260520114207.1394241-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
An unprivileged local user can pin a host CPU indefinitely in
l2tp_session_get_by_ifname() by issuing L2TP_CMD_SESSION_GET on
L2TP_ATTR_IFNAME concurrently with L2TP_CMD_SESSION_CREATE and
L2TP_CMD_SESSION_DELETE on the same tunnel. All three commands take
GENL_UNS_ADMIN_PERM, so CAP_NET_ADMIN in the netns user namespace
suffices; on any host that has l2tp_core loaded the trigger is
reachable from a standard `unshare -Urn` sandbox.
l2tp_session_unhash() removes a session from tunnel->session_list
with list_del_init(), but that list is walked by
l2tp_session_get_by_ifname() with list_for_each_entry_rcu() under
rcu_read_lock_bh(). list_del_init() leaves the deleted entry's
next/prev self-pointing; a reader that has loaded the entry and
then advances pos->list.next reads &session->list, container_of()s
back to the same session, and list_for_each_entry_rcu() never
reaches the list head. The CPU stays in strcmp() inside the
walker, with BH and preemption disabled, so RCU grace periods on
the host stall behind it and the wedged thread cannot be killed
(SIGKILL is delivered on syscall return).
Use list_del_rcu() to match the existing list_add_rcu() in
l2tp_session_register(); the deleted session remains visible to
in-flight walkers with consistent next/prev pointers until
kfree_rcu() in l2tp_session_free() releases it. tunnel->session_list
has exactly one list_del_init() call site; the list_del_init
(&session->clist) at l2tp_core.c:533 operates on the per-collision
list, which is not walked under RCU. list_empty(&session->list) is
not used anywhere in net/l2tp/ after the unhash point, so dropping
the post-delete self-init is safe; the fix has no userspace-visible
behavior change.
Linus Torvalds [Thu, 21 May 2026 15:43:26 +0000 (08:43 -0700)]
Merge tag 'soc-fixes-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull SoC fixes from Arnd Bergmann:
- The ff-a firmware driver gets 11 individual bugfixes for a number of
issues with robustness to buggy firmware or client implementations.
Another firmware fix address suspend to RAM via PSCI firmware.
- The final code change is for the old Arm Integrator reference
platform that recently started exposing an old NULL pointer
dereference bug.
- The MAINTAINERS file gets two updates, notably James Tai and Yu-Chun
Lin are stepping up as co-maintainers for the Realtek platform.
- The remaining patches are all for devicetree files. Two of these are
for riscv boards, the rest are all for enesas Arm platforms,
addressing build time checking issues as well as minor configuration
problems.
* tag 'soc-fixes-7.1' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (30 commits)
firmware: psci: Set pm_set_resume/suspend_via_firmware() for SYSTEM_SUSPEND
ARM: realtek: MAINTAINERS: Include pin controller drivers
MAINTAINERS: Add maintainers for ARM/REALTEK ARCHITECTURE
ARM: integrator: Fix early initialization
firmware: arm_ffa: Fix sched-recv callback partition lookup
firmware: arm_ffa: Snapshot notifier callbacks under lock
firmware: arm_ffa: Align RxTx buffer size before mapping
firmware: arm_ffa: Validate framework notification message layout
firmware: arm_ffa: Keep framework RX release under lock
firmware: arm_ffa: Bound PARTITION_INFO_GET_REGS copies
firmware: arm_ffa: Unregister bus notifier on teardown for FF-A v1.0
firmware: arm_ffa: Fix per-vcpu self notifications handling in workqueue
firmware: arm_ffa: Avoid collapsing NPI work from different CPUs
firmware: arm_ffa: Skip free_pages on RX buffer alloc failure
firmware: arm_ffa: Check for NULL FF-A ID table while driver registration
riscv: dts: microchip: fix icicle i2c pinctrl configuration
riscv: dts: starfive: jh7110: Drop CAMSS node
arm64: dts: renesas: r9a09g056: Add #mux-state-cells to usb20phyrst
arm64: dts: renesas: r9a09g057: Add #mux-state-cells to usb2{0,1}phyrst
ARM: dts: renesas: rskrza1: Drop superfluous cells
...
Nicolai Buchwitz [Wed, 20 May 2026 18:43:20 +0000 (20:43 +0200)]
net: bcmgenet: keep RBUF EEE/PM disabled
Setting RBUF_EEE_EN | RBUF_PM_EN in RBUF_ENERGY_CTRL breaks the RX
path on GENET hardware once MAC EEE becomes active. RX traffic stops
flowing while the link stays up and the usual descriptor/RX error
counters remain quiet. In that state the MAC still accepts frames
(rbuf_ovflow_cnt keeps climbing) but RBUF no longer forwards them to
DMA, so rx_packets is no longer incremented at the netdev level. On
some boards the corruption ends up as a paging fault in
skb_release_data via bcmgenet_rx_poll on an LPI exit.
Reproduced on Pi 4B (BCM2711 + BCM54213PE) and confirmed by Florian
Fainelli on an internal Broadcom 4908-family board with the same crash
signature. RBUF_PM_EN is not publicly documented.
This shows up more often now that phy_support_eee() enables EEE by
default, but it also affects older kernels as soon as TX LPI is
turned on via ethtool, so it is not specific to recent changes.
Always clear RBUF_EEE_EN | RBUF_PM_EN in bcmgenet_eee_enable_set so
the bits stay off across resets. UMAC and TBUF setup is left alone so
TX-side EEE keeps working.
tracing: Do not call map->ops->elt_free() if elt_alloc() fails
In paths where tracing_map_elt_alloc() failed to allocate objects,
the map->ops->elt_alloc() call was never successful. In this case,
map->ops->elt_free() should not be called.
====================
ethernet: 3c509: Bring driver back and make some fixes
As per the previous discussions[1][2] this patch series brings the 3c509
driver back. Picking up net rather than net-next as I consider it a fix
to accidental removal and so that any downstream users do not suffer from
disruption when using released kernels.
In the course of making the coding style changes requested I have come
across an actual bug in transceiver type selection code, where the old
setting is not masked out before ORing in the new one, causing no change
to be actually made in a requested transition from BNC to AUI. I guess
this code must have been executed exceedingly rarely, as it's always been
wrong ever since it was added in 2.5.42 back in 2002.
Therefore I find it not worth backporting to stable branches, however for
the sake of appropriateness, in case someone downstream does want to have
the fix, I chose to apply it second in the series, right after the actual
revert and before code clean-ups.
The remaining patches of the series should be obvious; see the respective
commit descriptions for details.
[1] "drivers: net: 3com: 3c509: Remove this driver",
<https://lore.kernel.org/r/alpine.DEB.2.21.2604240004280.28583@angie.orcam.me.uk/>.
[2] "MAINTAINERS: Add self for the 3c509 network driver",
<https://lore.kernel.org/r/alpine.DEB.2.21.2604271056460.28583@angie.orcam.me.uk/>.
====================
Update the driver for our current coding style according to output from
`checkpatch.pl' and manual code review, where no change to binary code
results, as indicated by `objdump -dr'. Exceptions are as follows:
- incomplete reverse xmas tree in set_multicast_list(), as that would
change binary output,
- referring el3_start_xmit() verbatim rather than via `__func__' with
pr_debug(), likewise,
- a bunch of pr_cont() calls, likewise,
- a long udelay() call in el3_netdev_set_ecmd() made under a spinlock,
likewise plus it's not eligible for conversion to a sleep in the first
place,
- a blank line at the start of a block in el3_interrupt(), to improve
readability where the first statement would otherwise visually merge
with the controlling expression of the enclosing `while' statement.
These issues are benign and depending on circumstances may be adressed
with suitable code refactoring later on.
ethernet: 3c509: Update documentation to match MAINTAINERS
There has been apparently a single message only ever publicly posted by
David Ruggiero, back in 2002, which added this documentation piece among
others, and MAINTAINERS was never updated accordingly. It is therefore
doubtful that his maintainer status has actually come into effect. Just
replace the reference then so as not to confuse people.
This driver has landed with Linux 0.99.13k, which was covered by the GNU
General Public License version 2, and no further conditions as to
licensing terms have been specified within the copyright notice included
with the driver itself.
ethernet: 3c509: Fix AUI transceiver type selection
The transceiver type is held in bits 15:14 of the Address Configuration
Register, with the values of 0b00, 0b01, and 0b11 denoting TP, AUI, and
BNC types respectively. Therefore switching from BNC to AUI requires
bits to be cleared before setting bit 14 or the setting won't change.
NB this has always been wrong ever since this code was added in 2.5.42.
Maxime Ripard [Mon, 27 Apr 2026 10:04:59 +0000 (12:04 +0200)]
dma-buf: heaps: system: Turn the heap into a module
The system heap can be easily turned into a module by adding the usual
MODULE_* macros, importing the proper namespaces and changing the
Kconfig symbol to a tristate.
This heap won't be able to unload though, since we're missing a lot of
infrastructure to make it safe.
Maxime Ripard [Mon, 27 Apr 2026 10:04:58 +0000 (12:04 +0200)]
dma-buf: heaps: cma: Turn the heap into a module
All the symbols used by the CMA heap are already exported, so turning it
into a module is straightforward. We only need to add the usual MODULE_*
macros, import the proper namespaces and change the Kconfig symbol to a
tristate.
This heap won't be able to unload though, since we're missing a lot of
infrastructure to make it safe.
Sabrina Dubroca [Wed, 20 May 2026 20:44:42 +0000 (22:44 +0200)]
net: gro: don't merge zcopy skbs
skb_gro_receive() can currently copy frags between the source and GRO
skb, without checking the zerocopy status, and in particular the
SKBFL_MANAGED_FRAG_REFS flag.
When SKBFL_MANAGED_FRAG_REFS is set, the skb doesn't hold a reference
on the pages in shinfo->frags. Appending those frags to another skb's
frags without fixing up the page refcount can lead to UAF.
When either the last skb in the GRO chain (the one we would append
frags to) or the source skb is zerocopy, don't merge the skbs.
projects / thirdparty / kernel / linux.git / log
