Filipe Manana [Thu, 14 May 2026 15:11:43 +0000 (16:11 +0100)]
btrfs: tracepoints: add trace event for btrfs_sync_log()
btrfs_sync_log() is one of the main functions called during a fsync.
Add trace events for when entering and exiting that function.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Filipe Manana [Mon, 11 May 2026 15:38:25 +0000 (16:38 +0100)]
btrfs: tracepoints: add trace event for btrfs_log_new_name()
btrfs_log_new_name() is an important function that affects inode logging
and is called during link and rename operations. Add trace events for when
entering and exiting that function.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Filipe Manana [Mon, 11 May 2026 15:13:18 +0000 (16:13 +0100)]
btrfs: tracepoints: add trace event for btrfs_record_new_subvolume()
btrfs_record_new_subvolume() is an important operation that affects
inode logging and is called during subvolume creation. Add a trace event
for it to help debug issues.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Filipe Manana [Mon, 11 May 2026 15:05:13 +0000 (16:05 +0100)]
btrfs: tracepoints: add trace event for btrfs_record_snapshot_destroy()
btrfs_record_snapshot_destroy() is an important operation that affects
inode logging and is called during subvolume/snapshot deletion as well as
during rmdir. Add a trace event for it to help debug issues.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Filipe Manana [Mon, 11 May 2026 14:51:13 +0000 (15:51 +0100)]
btrfs: tracepoints: add trace event for btrfs_record_unlink_dir()
btrfs_record_unlink_dir() is an important operation that affects inode
logging and is called during unlink and rename operations. Add a trace
event for it to help debug issues.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Filipe Manana [Fri, 8 May 2026 16:09:48 +0000 (17:09 +0100)]
btrfs: tracepoints: add trace event for log_new_delayed_dentries()
log_new_delayed_dentries() is an important step called during a fsync, as
well as during rename and link operations on inodes that were previously
logged. Add trace events for when entering and exiting that function.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Filipe Manana [Thu, 7 May 2026 12:05:16 +0000 (13:05 +0100)]
btrfs: use simple assertions where enough during inode logging and replay
In overwrite_item():
There's no point in printing the root's ID if the assertion fails, since
it can only be BTRFS_TREE_LOG_OBJECTID if it fails.
In log_new_delayed_dentries():
There's no point in using a verbose assertion to print the value of
ctx->logging_new_delayed_dentries because it's a boolean, so if the
assertion fails we know its value is true (1).
So convert them to simpler assertion to make the code less verbose.
It also slightly reduces the object size, at least on x86_64 using
Debian's gcc 14.2.0-19 (if CONFIG_BTRFS_ASSERT is enabled in the kernel
config, which is the case for SUSE distributions for example).
Before:
$ size fs/btrfs/btrfs.ko
text data bss dec hex filename 2028244 197176 15624 2241044 223214 fs/btrfs/btrfs.ko
After:
$ size fs/btrfs/btrfs.ko
text data bss dec hex filename 2028228 197176 15624 2241028 223204 fs/btrfs/btrfs.ko
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Filipe Manana [Thu, 7 May 2026 12:03:13 +0000 (13:03 +0100)]
btrfs: tracepoints: add trace event for log_conflicting_inodes()
log_conflicting_inodes() is an important step called during a fsync, as
well as during rename and link operations on inodes that were previously
logged. Add trace events for when entering and exiting that function.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Filipe Manana [Thu, 7 May 2026 10:17:55 +0000 (11:17 +0100)]
btrfs: tracepoints: add trace event for add_conflicting_inode()
add_conflicting_inode() is an important step called during a fsync, as
well as during rename and link operations on inodes that were previously
logged. Add trace events for when entering and exiting that function.
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Merge tag 'mtk-dts64-for-v7.2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into soc/dt
MediaTek ARM64 DeviceTree updates
This adds improvements for already supported SoCs and devices.
In particular:
- Adds support for the MT7981 SoC's Crypto Accelerator
- Enables gpio-keys and leds found on the MT7981b based
Xiaomi AX3000T router
- Adds new variants of MT7988 BananaPi BPi-R4 Pro
- ...and some spare cleanups for all BPi-R4 Pro boards
- Adds a MediaTek MT6365 devicetree and uses it in all of
the relevant supported boards in place of MT6359, where
needed (the MT6365 PMIC is a fully compatible variant
of the MT6359 PMIC, but still not named MT6359).
- Adds correct power supplies for CPUs and devices on a
variety of MediaTek Chromebooks and Genio AIoT boards,
including:
- MT8186 Corsola Chromebooks
- MT8192 Asurada Chromebooks
- MT8195 Cherry Chromebooks
- MT8390 Genio based boards
- MT8395 Genio based boards
- Adds HDMI TX support for Ezurio Tungsten 510/700 boards.
* tag 'mtk-dts64-for-v7.2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mediatek/linux: (37 commits)
arm64: dts: mediatek: add LED and key support on Xiaomi AX3000T
arm64: dts: mediatek: mt8195-cherry: Sort top level nodes correctly
arm64: dts: mediatek: mt8195-cherry: Fix names for EC controlled regulators
arm64: dts: mediatek: mt8192-asurada: Add (BT|WIFI)_KILL_1V8_L GPIO line names
arm64: dts: mediatek: mt8192-asurada: Fix SPI-NOR flash compatible
arm64: dts: mediatek: mt8390-tungsten-smarc: add HDMI support
arm64: dts: mediatek: mt8188-geralt: Add little core CPU power supplies
arm64: dts: mediatek: mt8188-geralt: Add MT6359 PMIC supplies
arm64: dts: mediatek: mt8195-cherry: Add vusb33 supplies for XHCI controllers
arm64: dts: mediatek: mt8195-cherry: Add supply for SPI NOR flash
arm64: dts: mediatek: mt8195-cherry: Fix VBUS regulator description
arm64: dts: mediatek: mt8195-cherry: Add supplies for ChromeOS EC regulators
arm64: dts: mediatek: mt8195-cherry: Add MT6315 PMIC supplies
arm64: dts: mediatek: mt8195-cherry: Add MT6359 PMIC supplies
arm64: dts: mediatek: mt8192-asurada: Fix WiFi regulator description
arm64: dts: mediatek: mt8192-asurada: Add SPI NOR flash power supply
arm64: dts: mediatek: mt8192-asurada: Add CPU power supplies
arm64: dts: mediatek: mt8192-asurada: Add supplies for ChromeOS EC regulators
arm64: dts: mediatek: mt8192-asurada: Add MT6315 PMIC supplies
arm64: dts: mediatek: mt8192-asurada: Add MT6359 PMIC supplies
...
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
These are some of the issues that LLM reported to netconsole, and they
are being addressed here before big refactors.
I was doing some big refactors, and got some "pre-existent-issues"
during LLM review of the refactor, that make them hard to guarantee that
refactor is not introducing any bug, so, let's clean these pre-existent
bugs first, and then submit the refactor.
The issues fixed in this patchset were reported during the review of
https://lore.kernel.org/all/20260524-netconsole_move_more-v1-0-909d1ab398b4@debian.org/
Not all of them got fixed, but, those that were easy to reason about.
Why net-next and not 'net' tree.
Most of the functions that are being fixed here moved from netpoll to
netconsole, thus, fixing this on net will cause merge conflicts from
'net' to 'net-next', thus I decided to fix it on 'net-next', given we
are on 7.1-rc6 already. Sorry if that is not the right approach.
====================
Breno Leitao [Thu, 4 Jun 2026 16:10:14 +0000 (09:10 -0700)]
netconsole: close netdevice unregister window during target resume
process_resume_target() removes the target from target_list before
calling resume_target() so that netpoll_setup() can run with interrupts
enabled, then re-adds it once setup completes. netpoll_setup() acquires a
net_device reference (netdev_hold()) and releases the RTNL before
returning.
While the target is off target_list and the RTNL is not held,
netconsole_netdev_event() cannot find it. If the egress device is
unregistered in that window, the NETDEV_UNREGISTER notifier walks
target_list, misses the resuming target, and never tears it down. The
target is then re-added in STATE_ENABLED still holding a reference to the
now-unregistered device, leaking it and hanging unregister_netdevice() in
netdev_wait_allrefs().
Re-check under RTNL before re-publishing the target: if the device left
NETREG_REGISTERED while we were off the list, run do_netpoll_cleanup() and
mark the target disabled. Taking the RTNL across the check and the
list_add() serialises against the NETDEV_UNREGISTER notifier, which also
runs under RTNL, so the device is either still registered (and the
notifier will find the re-added target later) or already unregistering
(and we drop the reference here). netdev_wait_allrefs() runs from
netdev_run_todo() outside the RTNL, so dropping the reference here cannot
deadlock against the pending unregister.
Breno Leitao [Thu, 4 Jun 2026 16:10:13 +0000 (09:10 -0700)]
netconsole: clean up deactivated targets dropped before the cleanup worker
drop_netconsole_target() downgrades a STATE_DEACTIVATED target to
STATE_DISABLED and then only calls netpoll_cleanup() when the target is
STATE_ENABLED. A target becomes STATE_DEACTIVATED when its underlying
interface is unregistered: netconsole_netdev_event() moves it to
target_cleanup_list, and netconsole_process_cleanups_core() is expected
to run do_netpoll_cleanup() on it.
Now that drop_netconsole_target() takes target_cleanup_list_lock around
the unlink, a configfs removal racing with NETDEV_UNREGISTER can pull the
target off target_cleanup_list before the cleanup worker processes it.
The notifier drops the lock before calling
netconsole_process_cleanups_core(), so the worker then iterates a list
that no longer contains the target and never runs do_netpoll_cleanup() on
it. Because drop_netconsole_target() has already rewritten the state to
STATE_DISABLED, its own STATE_ENABLED check is false and netpoll_cleanup()
is skipped too. The net_device reference taken by netpoll_setup() is then
leaked and unregister_netdevice() hangs forever in netdev_wait_allrefs().
Capture whether the target still owns a netpoll before the state is
downgraded and clean it up for both STATE_ENABLED and STATE_DEACTIVATED
targets. netpoll_cleanup() is idempotent -- it skips when np->dev is
already NULL -- so it is safe even when the cleanup worker won the race
and already tore the netpoll down.
Breno Leitao [Thu, 4 Jun 2026 16:10:12 +0000 (09:10 -0700)]
netconsole: take target_cleanup_list_lock in drop_netconsole_target()
drop_netconsole_target() unlinks the target while only holding
target_list_lock. However, when the underlying interface has been
unregistered, netconsole_netdev_event() moves the target from
target_list to target_cleanup_list, and netconsole_process_cleanups_core()
walks that list under target_cleanup_list_lock only.
If a user removes the configfs target at the same time the cleanup
worker is iterating target_cleanup_list, list_del() can corrupt the list
because the two paths take disjoint locks while operating on the same
list node.
Acquire target_cleanup_list_lock around the list_del() so the unlink is
serialised against netconsole_process_cleanups_core() regardless of
which list the target currently belongs to. The state transition that
downgrades STATE_DEACTIVATED to STATE_DISABLED is left intact and is
performed under the same combined locking, preserving the existing
ordering with resume_target().
Breno Leitao [Thu, 4 Jun 2026 16:10:11 +0000 (09:10 -0700)]
netconsole: do not dequeue pooled skbs that cannot satisfy len
find_skb() falls back to np->skb_pool when the GFP_ATOMIC alloc_skb()
fails. The pool is refilled by refill_skbs(), which always allocates
buffers of MAX_SKB_SIZE (ethhdr + iphdr + udphdr + MAX_UDP_CHUNK ==
1502 bytes).
netconsole, however, computes the requested length dynamically as
total_len + np->dev->needed_tailroom
If the egress device declares a non-zero needed_tailroom (e.g. some
tunnel or hardware accelerator devices), the required length can exceed
MAX_SKB_SIZE. The pooled skb is then handed back to the caller, which
immediately performs skb_put(skb, len), trips the tail > end check, and
triggers skb_over_panic().
Leave the normal alloc_skb(len, GFP_ATOMIC) path untouched -- the slab
allocator can still satisfy oversized requests when memory is available,
so senders to devices with non-zero needed_tailroom keep working in the
common case. Only the pool fallback is gated: when alloc_skb() failed
and len exceeds the pool buffer size, skip the skb_dequeue() instead of
burning a pre-allocated skb on a request that would later trip
skb_over_panic(). Reserving pool entries for requests they can actually
satisfy also keeps the panic path, which depends on the pool being
primed, intact.
When that drop happens, emit a rate-limited net_warn() so the user
notices that netconsole is unable to push messages on the egress device.
The warn is skipped under in_nmi() for the same reason schedule_work()
is: printk machinery taken by net_warn_ratelimited() is not NMI-safe and
would risk recursing into the same nbcon console we are servicing.
MAX_SKB_SIZE / MAX_UDP_CHUNK were private to net/core/netpoll.c. Move
them to include/linux/netpoll.h so netconsole can reference the same
definition that refill_skbs() uses, keeping the two in sync by
construction. The header now pulls in <linux/ip.h> and <linux/udp.h>
explicitly so MAX_SKB_SIZE remains self-contained for any future user.
Breno Leitao [Thu, 4 Jun 2026 16:10:10 +0000 (09:10 -0700)]
netconsole: do not schedule skb pool refill from NMI
When alloc_skb() fails in find_skb(), the fallback path dequeues an skb
from np->skb_pool and unconditionally calls schedule_work() to top the
pool back up. schedule_work() ends up taking the workqueue pool locks,
which are not NMI-safe.
netconsole_write() is registered as the nbcon write_atomic callback and
is explicitly marked CON_NBCON_ATOMIC_UNSAFE, meaning it is invoked from
emergency/panic contexts including NMIs. If the NMI interrupts a thread
already holding the workqueue pool lock, calling schedule_work()
self-deadlocks and the panic message that was being printed is lost.
Introduce netcons_skb_pop() to fold the pool dequeue and the refill
request into a single helper. The helper skips schedule_work() when
called from NMI context; the pool is best-effort, so the refill is simply
deferred to the next non-NMI find_skb() call that exhausts alloc_skb()
and hits the fallback again. This keeps the fast path untouched and the
locking rules around the fallback pool documented in one place.
Note this only removes the schedule_work() hazard from the NMI path. The
allocation itself is still not fully NMI-safe: the alloc_skb(GFP_ATOMIC)
attempted first may take slab locks, and the skb_dequeue() fallback takes
np->skb_pool.lock, so either can deadlock if the NMI interrupts a holder
of those locks. Closing those windows requires an NMI-safe (lockless) skb
pool and is left to a follow-up; this patch addresses the schedule_work()
deadlock, which is both the most likely and the easiest to trigger.
Merge tag 'mtk-soc-for-v7.2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mediatek/linux into soc/drivers
MediaTek SoC driver updates
This adds subsys ID compatibility in MediaTek CMDQ, paving
the way for adding support for the MT8196 SoC, and fixes
the Multimedia System (MMSYS) routing masks for the MT8167
SoC.
* tag 'mtk-soc-for-v7.2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mediatek/linux:
soc: mediatek: mtk-mmsys: Restore MT8167 routing masks lost during merge
soc: mediatek: mtk-cmdq: Add cmdq_pkt_jump_rel_temp() for removing shift_pa
soc: mediatek: Use pkt_write function pointer for subsys ID compatibility
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Rui Qi [Thu, 4 Jun 2026 08:32:08 +0000 (16:32 +0800)]
selftests/livepatch: fix resource leak in test_klp_syscall init error path
In livepatch_init(), if klp_enable_patch() fails, the previously
created kobject and sysfs file are never cleaned up, causing a
resource leak. Capture the return value and add proper cleanup
on the error path.
Ingyu Jang [Tue, 19 May 2026 08:52:14 +0000 (17:52 +0900)]
wifi: mt76: Drop unneeded mt76_register_debugfs_fops() return checks
mt76_register_debugfs_fops() returns the dentry from
debugfs_create_dir(), which yields an error pointer on failure
(notably ERR_PTR(-ENODEV) when CONFIG_DEBUG_FS=n), never NULL. Per
commit ff9fb72bc077 ("debugfs: return error values, not NULL"),
callers do not need to check the return value.
Drop the dead !dir checks in mt7615/mt7915/mt7921/mt7925/mt7996
_init_debugfs(). Converting them to IS_ERR() instead would have
exposed a probe abort on CONFIG_DEBUG_FS=n, since each
*_init_debugfs() caller propagates the helper's return value.
This patch supersedes an earlier proposal that converted the checks
to IS_ERR().
Devin Wittmayer [Fri, 15 May 2026 18:39:21 +0000 (11:39 -0700)]
wifi: mt76: mt7921: assert sniffer on chanctx change
mt7921_change_chanctx() configures the channel for monitor vifs but
does not re-assert sniffer mode. mt7925_change_chanctx() does. Match
mt7925 by adding the missing mt7921_mcu_set_sniffer(true) call,
completing the architectural pattern from commit 914189af23b8 ("wifi:
mt76: mt7921: fix channel switch fail in monitor mode").
The user-visible regression this asymmetry produced on v6.17 and v6.18
was addressed by commit cdb2941a516c ("Revert "wifi: mt76: mt792x:
improve monitor interface handling"") in v6.19 and backported to the
6.17.y and 6.18.y stable trees. This patch is defense in depth in
case the NO_VIRTUAL_MONITOR change is reintroduced in a future series.
Dawei Feng [Thu, 4 Jun 2026 14:37:56 +0000 (22:37 +0800)]
octeontx2-af: fix memory leak in rvu_setup_hw_resources()
If rvu_npc_exact_init() fails in rvu_setup_hw_resources(), the function
returns directly instead of jumping to the error handling path. This
causes a resource leak for the previously initialized CGX, NPC, fwdata,
and MSI-X states.
Fix this by replacing the direct return with goto cgx_err to ensure
proper cleanup.
The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available. Manual inspection confirms that the bug is still present in
v7.1-rc6.
An x86_64 allyesconfig build showed no new warnings. As we do not have
access to Marvell OcteonTX2 RVU AF hardware to test with, no runtime
testing was able to be performed.
Fixes: 3571fe07a090 ("octeontx2-af: Drop rules for NPC MCAM") Cc: stable@vger.kernel.org Signed-off-by: Dawei Feng <dawei.feng@seu.edu.cn> Signed-off-by: Zilin Guan <zilin@seu.edu.cn> Link: https://patch.msgid.link/20260604143756.1524482-1-dawei.feng@seu.edu.cn Signed-off-by: Paolo Abeni <pabeni@redhat.com>
When FIELD_GET returns 0 for the retry count, subtracting 1 causes
an unsigned integer underflow, resulting in tx_retries becoming a
very large value (0xFFFFFFFF for u32).
Fix by checking if count is non-zero before subtracting 1.
When FIELD_GET returns 0 for the retry count, subtracting 1 causes
an unsigned integer underflow, resulting in tx_retries becoming a
very large value (0xFFFFFFFF for u32).
Fix by checking if count is non-zero before subtracting 1.
When FIELD_GET returns 0 for the retry count, subtracting 1 causes
an unsigned integer underflow, resulting in tx_retries becoming a
very large value (0xFFFFFFFF for u32).
Fix by checking if count is non-zero before subtracting 1.
When FIELD_GET returns 0 for the retry count, subtracting 1 causes
an unsigned integer underflow, resulting in tx_retries becoming a
very large value (0xFFFFFFFF for u32).
Fix by checking if count is non-zero before subtracting 1.
JB Tsai [Tue, 3 Mar 2026 05:36:36 +0000 (13:36 +0800)]
wifi: mt76: mt7921: add auto regdomain switch support
Implement 802.11d-based automatic regulatory domain switching to
dynamically determine the regulatory domain at runtime.
The scan-done event structure by reusing reserved padding and appending
new fields; the layout and values remains backward-compatible with
existing users.
Jakub Kicinski [Sun, 7 Jun 2026 00:24:01 +0000 (17:24 -0700)]
selftests: drv-net: gro: signal over-coalescing more reliably
GRO test is very timing-sensitive, packets may be delayed
by the network or just sent slowly. Because of this we retry
each test case up to 6 times.
This makes perfect sense for positive cases, in which we want
to see coalescing. Negative test cases, which modify headers
and expect no coalescing should have opposite treatment.
We should really try 6 times and make sure that each time
the test failed. This would, however, require that we annotate
each test to indicate whether its positive or negative.
Let's start with a simpler improvement. Do not allow
retries if we detected over-coalescing. Previously the negative
case would have to get lucky at least once in 6 tries to pass.
Now the first failure breaks the retry loop.
For background - NICs tend to ignore the contents of the TCP
timestamp option, so that test case commonly fails. In NIPA
having 6 attempts, however, was enough for some NICs to get
multiple successful runs in a row, getting the test cases
auto-classified as expected to pass, even tho the NIC does
not comply with the expectations.
Bryam Vargas [Sun, 7 Jun 2026 01:18:27 +0000 (01:18 +0000)]
isofs: bound Rock Ridge symlink components to the SL record
get_symlink_chunk() and the SL handling in
parse_rock_ridge_inode_internal() walk the variable-length components of
a Rock Ridge "SL" (symbolic link) record. Each component is a two-byte
header (flags, len) followed by len bytes of text, so it occupies
slp->len + 2 bytes. Both loops read slp->len and advance to the next
component, and get_symlink_chunk() additionally does
memcpy(rpnt, slp->text, slp->len), but neither checks that the component
lies within the SL record before dereferencing it.
A crafted SL record whose component declares a len that runs past the
record (rr->len) therefore triggers an out-of-bounds read of up to 255
bytes. When the record sits at the tail of its backing buffer - for
example a small kmalloc()ed continuation block reached through a CE
record - the read crosses the allocation; get_symlink_chunk() then
copies the out-of-bounds bytes into the symlink body returned to user
space by readlink(), disclosing adjacent kernel memory.
ISO 9660 images are routinely mounted from untrusted removable media -
desktop environments auto-mount them (e.g. via udisks2) without
CAP_SYS_ADMIN - so the record contents are attacker-controlled.
Reject any component that does not fit in the remaining record bytes
before using it. In get_symlink_chunk() return NULL, like the existing
output-buffer (plimit) checks, so a malformed record makes readlink()
fail with -EIO rather than silently returning a truncated target; in
parse_rock_ridge_inode_internal() stop the inode-size walk.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Cc: stable@vger.kernel.org Suggested-by: Michael Bommarito <michael.bommarito@gmail.com> Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Link: https://patch.msgid.link/20260607011823.217748-1-hexlabsecurity@proton.me Signed-off-by: Jan Kara <jack@suse.cz>
Sean Wang [Wed, 1 Apr 2026 18:23:22 +0000 (13:23 -0500)]
wifi: mt76: mt792x: report txpower for the requested vif link
mt792x currently reports txpower from the generic PHY cached state,
which may not match the requested vif/link context.
Resolve the requested link channel and derive txpower from that channel
instead, with fallback to the current PHY chandef if no valid chanctx is
available.
Reported-by: Devin Wittmayer <lucid_duck@justthetip.ca> Closes: https://lore.kernel.org/linux-wireless/20260130215839.53270-1-lucid_duck@justthetip.ca/ Tested-by: Devin Wittmayer <lucid_duck@justthetip.ca> Tested-by: Satadru Pramanik <satadru@gmail.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260401182322.64355-3-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
wifi: mt76: mt7996: limit work in set_bitrate_mask
Calls to mt7996_set_bitrate_mask() would propagate work for all stations
on the ieee80211_hw regardless of the vif specified in the call. To
prevent unnecessary work in FW, limit setting the sta_rate to only the
specified vif in mt7996_sta_rate_ctrl_update().
Fixes: afff4325548f0 ("wifi: mt76: mt7996: Use proper link_id in link_sta_rc_update callback") Signed-off-by: Dylan Eskew <dylan.eskew@candelatech.com> Acked-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260408145057.2356878-2-dylan.eskew@candelatech.com Signed-off-by: Felix Fietkau <nbd@nbd.name>
wifi: mt76: mt7996: reduce phy work in set_coverage
In mt7996_set_coverage_class(), each phy is iterated over in calling
mt7996_mac_set_coverage_class(). Thus, the phy2 and phy3 configuration
logic in mt7996_mac_set_coverage_class() can be dropped.
Sean Wang [Sat, 25 Apr 2026 16:09:30 +0000 (11:09 -0500)]
wifi: mt76: mt7921u: add MT7902 USB support
Add the 0e8d:7902 USB ID and select the MT7902 WM firmware. Use the
same USB queue mapping as mt7921/mt7925 so MT7902U can bind and probe
through mt7921u driver.
Jiajia Liu [Tue, 2 Jun 2026 05:43:49 +0000 (13:43 +0800)]
wifi: mt76: transform aspm_conf for pci_disable_link_state
commit b478e162f227 ("PCI/ASPM: Consolidate link state defines") changed
PCIE_LINK_STATE_L0S (1) to (BIT(0) | BIT(1)). PCI_EXP_LNKCTL_ASPM_L0S (1)
and PCI_EXP_LNKCTL_ASPM_L1 (2) are no longer matched with
PCIE_LINK_STATE_L0S (3) and PCIE_LINK_STATE_L1 (4).
On the platform enabling ASPM L0s and L1, mt76_pci_disable_aspm is not able
to disable L1. Fix this by transforming aspm_conf to pcie link state.
Jiajia Liu [Thu, 28 May 2026 03:38:14 +0000 (11:38 +0800)]
wifi: mt76: add wcid publish check in mt76_sta_add
Since mt7925_mac_sta_add publishes wcid, add publish check in mt76_sta_add
to avoid reinitializing the wcid->poll_list.
Found dev->sta_poll_list corruption when using mt7925 and 7.1-rc4.
According to the corruption information, prev->next was changed to itself.
wlan0: disconnect from AP 90:fb:5d:94:8b:e3 for new auth to 90:fb:5d:94:8b:e2
wlan0: authenticate with 90:fb:5d:94:8b:e2 (local address=84:9e:56:9c:7e:6b)
wlan0: send auth to 90:fb:5d:94:8b:e2 (try 1/3)
slab kmalloc-8k start ffff8c80958a6000 pointer offset 4160 size 8192
list_add corruption. prev->next should be next (ffff8c808a7488f8), but was ffff8c80958a7040. (prev=ffff8c80958a7040).
Lorenzo Bianconi [Fri, 22 May 2026 07:24:52 +0000 (09:24 +0200)]
wifi: mt76: mt7996: remove redundant pdev->bus check in probe
Drop the unnecessary pdev->bus NULL check in mt7996_pci_probe() since
the pointer is already dereferenced earlier in mt76_pci_disable_aspm(),
making the check dead code. Silences the related Smatch warning.
Lorenzo Bianconi [Sun, 31 May 2026 08:55:04 +0000 (10:55 +0200)]
wifi: mt76: mt7996: fix reading zeroed info->control.flags after mt76_tx_status_skb_add()
mt76_tx_status_skb_add() zeroes the mt76_tx_cb struct stored at
info->status.status_driver_data via memset(). Since info->control and
info->status are members of the same union in ieee80211_tx_info,
this overwrites info->control.flags.
In mt7996_tx_prepare_skb(), mt76_tx_status_skb_add() is called before
mt7996_mac_write_txwi(), which re-reads info->control.flags to extract
IEEE80211_TX_CTRL_MLO_LINK. Because the field has been zeroed, the
link_id always resolves to 0 for frames using global_wcid, leading to
incorrect TXWI configuration.
Fix this by passing link_id as an explicit parameter to
mt7996_mac_write_txwi(). In mt7996_tx_prepare_skb(), the link_id is
already extracted from info->control.flags before the destructive
mt76_tx_status_skb_add() call. For the beacon and inband discovery
callers in mcu.c, use link_conf->link_id directly.
Lorenzo Bianconi [Sun, 31 May 2026 09:38:57 +0000 (11:38 +0200)]
wifi: mt76: mt7996: Fix possible NULL pointer dereference in mt7996_mac_write_txwi_80211()
For injected frames (e.g. via radiotap), mac80211 can pass
info->control.vif = NULL, as explicitly noted in struct ieee80211_tx_info.
Check vif pointer before executing ieee80211_vif_is_mld() in
mt7996_mac_write_txwi_80211 routine in order to avoid a possible NULL
pointer dereference.
Lorenzo Bianconi [Sun, 31 May 2026 09:10:59 +0000 (11:10 +0200)]
wifi: mt76: mt7996: Fix possible token leak in mt7996_tx_prepare_skb()
If link_conf or link_sta lookup fails in mt7996_tx_prepare_skb routine,
mt7996 driver leaks an already allocated tx token. Fix the issue
releasing the token in case of error.
wifi: mt76: mt7915: validate skb length in txpower SKU query
In mt7915_mcu_get_txpower_sku(), the response skb from
mt76_mcu_send_and_get_msg() is used in memcpy without validating
its length:
For TX_POWER_INFO_RATE:
memcpy(res, skb->data + 4, sizeof(res));
where sizeof(res) is MT7915_SKU_RATE_NUM * 2 = 322 bytes.
For TX_POWER_INFO_PATH:
memcpy(txpower, skb->data + 4, len);
In both cases, if the firmware returns a response shorter than
the expected size, the memcpy reads beyond the skb data buffer.
The data surfaces to userspace via debugfs (txpower_sku and
txpower_path).
Add length checks for both code paths before the memcpy.
where MT7925_EVT_RSP_LEN is 512. If the firmware returns a response
shorter than 520 bytes (8 + 512), this reads beyond the skb data
buffer. The over-read data is then returned to userspace via nla_put()
in mt7925_testmode_dump().
Add a length check before the memcpy to ensure the skb contains
sufficient data.
mt792x_tx() rewrites addr1/addr2/addr3 by treating skb->data as
an 802.11 header for MLD traffic.
That is only valid for native 802.11 frames. Direct 802.3 TX can also
reach this path with IEEE80211_TX_CTL_HW_80211_ENCAP set, where
skb->data is not an 802.11 header.
Skip the MLD header rewrite for HW-encap packets to avoid corrupting
802.3 frame contents.
Sean Wang [Sat, 25 Apr 2026 15:47:21 +0000 (10:47 -0500)]
wifi: mt76: mt7925: program BA state on active links
With MLO, traffic for one TID can be sent on any active link. Programming
BA state only on the default link leaves the other active links out of
sync.
Program BA state on all active links instead.
Fixes: 766ea2cf5a39 ("Revert "wifi: mt76: mt7925: Update mt7925_mcu_uni_[tx,rx]_ba for MLO"") Tested-by: Yao Ting Hsieh <yao-ting.hsieh@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260425154721.738101-3-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
Sean Wang [Sat, 25 Apr 2026 15:47:19 +0000 (10:47 -0500)]
wifi: mt76: mt7925: keep TX BA state in the primary WCID
For MLO, the same TID can run over different links. Keeping TX BA state in
a link WCID makes the state depend on which link starts aggregation first.
Store it in the primary WCID instead, so the BA state stays stable across
links.
Fixes: 44eb173bdd4f ("wifi: mt76: mt7925: add link handling in mt7925_txwi_free") Tested-by: Yao Ting Hsieh <yao-ting.hsieh@mediatek.com> Signed-off-by: Sean Wang <sean.wang@mediatek.com> Link: https://patch.msgid.link/20260425154721.738101-1-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
Sean Wang [Sat, 25 Apr 2026 19:50:09 +0000 (14:50 -0500)]
wifi: mt76: mt792x: enable CNM ops for MT7927
Enable CNM support for MT7927 so mac80211 keeps remain-on-channel callbacks
available. MT7927 needs them at runtime even when the capability is not
advertised through the normal firmware feature path.
Sean Wang [Sat, 25 Apr 2026 19:50:07 +0000 (14:50 -0500)]
wifi: mt76: mt7925: sync MT7927 BSS band assignment
MT7927 needs DBDC enabled and uses a fixed firmware band assignment for
2.4GHz and 5/6GHz BSS contexts.
Reprogram the STA dev context when the channel context is assigned so the
firmware sees the updated band_idx before the BSS is used. This avoids
stale band programming after band changes.
Sean Wang [Sat, 25 Apr 2026 19:50:03 +0000 (14:50 -0500)]
wifi: mt76: mt792x: add MT7927 WFSYS reset support
Add a dedicated MT7927 WFSYS reset path in mt792x_wfsys_reset().
Unlike the existing connac2/connac3 reset flow that toggles the WFSYS
software reset bit and waits for init-done, MT7927 reset is driven
through CBInfra and requires polling ROMCODE_INDEX until the MCU returns
to the idle value after reset.
Keep this dormant for now: no MT7927 PCI IDs are added by this patch, so
it only prepares the reset logic without making the driver bind to MT7927
hardware yet.
Javier Tia [Sat, 25 Apr 2026 19:49:59 +0000 (14:49 -0500)]
wifi: mt76: mt7925: disable ASPM and runtime PM for MT7927
Disable PCIe ASPM unconditionally for MT7927. The CONNINFRA power
domain and WFDMA register access are unreliable with PCIe L1 active,
causing throughput to drop from 1+ Gbps to ~200 Mbps.
Disable runtime PM and deep sleep for MT7927. The combo chip shares
a CONNINFRA power domain between WiFi (PCIe) and BT (USB).
SET_OWN/CLR_OWN transitions on the LPCTL register crash the BT
firmware, requiring a full power cycle to recover. PM enablement will
be addressed in a follow-up once safe power state transitions are
determined.
Javier Tia [Sat, 25 Apr 2026 19:49:58 +0000 (14:49 -0500)]
wifi: mt76: mt7925: use irq_map for chip-specific interrupt handling
The mac_reset and resume paths use the hardcoded MT_INT_RX_DONE_ALL
constant (bits 0-2) to re-enable RX interrupts. This is correct for
MT7925 (RX rings 0, 1, 2) but wrong for chips using different ring
indices.
Define a per-chip irq_map with the correct RX interrupt enable bits and
replace hardcoded MT_INT_RX_DONE_ALL with irq_map field reads in the
resume and mac_reset paths. Add the MT7927 irq_map with interrupt bits
matching its RX ring layout (rings 4, 6, 7), selected at probe time
based on PCI device ID.
This ensures the correct interrupt bits are enabled regardless of the
chip variant.
Tested-by: Marcin FM <marcin@lgic.pl> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com> Tested-by: George Salukvadze <giosal90@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo <samu.toljamo@gmail.com> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Thibaut François <tibo@humeurlibre.fr> Tested-by: 张旭涵 <Loong.0x00@gmail.com> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-9-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
Javier Tia [Sat, 25 Apr 2026 19:49:57 +0000 (14:49 -0500)]
wifi: mt76: mt7925: add MT7927 firmware paths
Add firmware path definitions for MT7927 WiFi firmware (WIFI_RAM_CODE
and PATCH_MCU) and the corresponding MODULE_FIRMWARE declarations. Add
MT7927 cases to mt792x_ram_name() and mt792x_patch_name() so the driver
loads the correct firmware for the 0x7927 chip ID.
PCI device table entries are deferred to a later patch to allow
infrastructure setup before device enablement.
Tested-by: Marcin FM <marcin@lgic.pl> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com> Tested-by: George Salukvadze <giosal90@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo <samu.toljamo@gmail.com> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Thibaut François <tibo@humeurlibre.fr> Tested-by: 张旭涵 <Loong.0x00@gmail.com> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-8-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
Javier Tia [Sat, 25 Apr 2026 19:49:56 +0000 (14:49 -0500)]
wifi: mt76: mt7925: add MT7927 chip ID helpers
The MediaTek MT7927 (Filogic 380) combo chip uses MT7927 WiFi silicon
that is architecturally compatible with MT7925. Extend is_mt7925() to
match chip ID 0x7927, and add is_mt7927() for code paths that need
MT7927-specific handling.
Also add 0x7927 to is_mt76_fw_txp() to match MT7925's TXP format.
Tested-by: Marcin FM <marcin@lgic.pl> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com> Tested-by: George Salukvadze <giosal90@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo <samu.toljamo@gmail.com> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Thibaut François <tibo@humeurlibre.fr> Tested-by: 张旭涵 <Loong.0x00@gmail.com> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-7-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
Javier Tia [Sat, 25 Apr 2026 19:49:55 +0000 (14:49 -0500)]
wifi: mt76: mt7925: advertise EHT 320MHz capabilities for 6GHz band
mt7925_init_eht_caps() only populates EHT MCS/NSS maps for BW <= 80
and BW = 160, but never sets BW = 320. This means iw phy shows no
320MHz MCS map entries even though the hardware supports 320MHz
operation in the 6GHz band.
Add the missing 320MHz capability bits for 6GHz:
- PHY_CAP0: IEEE80211_EHT_PHY_CAP0_320MHZ_IN_6GHZ
- PHY_CAP1: beamformee SS for 320MHz
- PHY_CAP2: sounding dimensions for 320MHz
- PHY_CAP6: MCS15 support for 320MHz width
- MCS/NSS: populate bw._320 maps for 6GHz band
Introduce is_320mhz_supported() to gate 320MHz on MT7927 only, since
MT7925 does not support 320MHz operation.
Tested-by: Marcin FM <marcin@lgic.pl> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com> Tested-by: George Salukvadze <giosal90@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo <samu.toljamo@gmail.com> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Thibaut François <tibo@humeurlibre.fr> Tested-by: 张旭涵 <Loong.0x00@gmail.com> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-6-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
Javier Tia [Sat, 25 Apr 2026 19:49:54 +0000 (14:49 -0500)]
wifi: mt76: mt7925: populate EHT 320MHz MCS map in sta_rec
The sta_rec_eht structure has a mcs_map_bw320 field, and the channel
width mapping includes NL80211_CHAN_WIDTH_320, but the 320MHz MCS/NSS
map was never copied from the station's EHT capabilities to the MCU TLV.
This prevents negotiation of 320MHz channel width even when both the
hardware and firmware advertise support for it.
Add the missing memcpy for the 320MHz MCS map, matching the existing
pattern for BW20, BW80, and BW160.
Tested-by: Marcin FM <marcin@lgic.pl> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com> Tested-by: George Salukvadze <giosal90@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo <samu.toljamo@gmail.com> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Thibaut François <tibo@humeurlibre.fr> Tested-by: 张旭涵 <Loong.0x00@gmail.com> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-5-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
Javier Tia [Sat, 25 Apr 2026 19:49:53 +0000 (14:49 -0500)]
wifi: mt76: mt7925: handle 320MHz bandwidth in RXV and TXS
The RX vector (RXV) and TX status (TXS) parsing in mac.c lack handling
for 320MHz channel width. When the hardware reports 320MHz in the
bandwidth field, mt7925_mac_fill_rx_rate() returns -EINVAL and
mt7925_mac_add_txs_skb() records no bandwidth stats.
Add IEEE80211_STA_RX_BW_320 cases to both functions. The RXV parser
also handles BW_320+1 since the hardware can report 320MHz in two
adjacent encoding positions.
Tested-by: Marcin FM <marcin@lgic.pl> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com> Tested-by: George Salukvadze <giosal90@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo <samu.toljamo@gmail.com> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Thibaut François <tibo@humeurlibre.fr> Tested-by: 张旭涵 <Loong.0x00@gmail.com> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-4-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
Javier Tia [Sat, 25 Apr 2026 19:49:52 +0000 (14:49 -0500)]
wifi: mt76: mt7925: add 320MHz bandwidth to bss_rlm_tlv
bss_rlm_tlv() in mt7925_mcu_bss_rlm_tlv() has no case for
NL80211_CHAN_WIDTH_320. When associated to a 320MHz BSS, the switch
falls through to default and sends bw=0 (CMD_CBW_20MHZ) to firmware
via BSS_RLM TLV. Firmware then configures the RX radio for 20MHz
and cannot decode the AP's 320MHz frames, resulting in complete data
path failure at 320MHz.
Add the missing NL80211_CHAN_WIDTH_320 case with CMD_CBW_320MHZ and
center_chan2.
Tested on ASUS RT-BE92U: 320MHz throughput goes from 0 Mbps to
841 Mbps (iperf3 -t30 -P8), PHY 4803 Mbps EHT-MCS11.
Reported-by: 张旭涵 <Loong.0x00@gmail.com> Closes: https://github.com/openwrt/mt76/issues/927 Tested-by: 张旭涵 <Loong.0x00@gmail.com> Tested-by: Marcin FM <marcin@lgic.pl> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com> Tested-by: George Salukvadze <giosal90@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo <samu.toljamo@gmail.com> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Thibaut François <tibo@humeurlibre.fr> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-3-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
Javier Tia [Sat, 25 Apr 2026 19:49:51 +0000 (14:49 -0500)]
wifi: mt76: mt7925: fix stale pointer comparisons in change_vif_links
In the error path of mt7925_change_vif_links(), the free: label iterates
over link_ids to clean up, but compares against `mconf` and `mlink`
which hold stale values from the last loop iteration rather than the
current link_id being freed.
Use array-indexed access (mconfs[link_id] / mlinks[link_id]) to compare
against the correct per-link pointers.
Fixes: 69acd6d910b0 ("wifi: mt76: mt7925: add mt7925_change_vif_links") Tested-by: Marcin FM <marcin@lgic.pl> Tested-by: Cristian-Florin Radoi <radoi.chris@gmail.com> Tested-by: George Salukvadze <giosal90@gmail.com> Tested-by: Evgeny Kapusta <3193631@gmail.com> Tested-by: Samu Toljamo <samu.toljamo@gmail.com> Tested-by: Ariel Rosenfeld <ariel.rosenfeld.750@gmail.com> Tested-by: Chapuis Dario <chapuisdario4@gmail.com> Tested-by: Thibaut François <tibo@humeurlibre.fr> Tested-by: 张旭涵 <Loong.0x00@gmail.com> Reviewed-by: Sean Wang <sean.wang@mediatek.com> Signed-off-by: Javier Tia <floss@jetm.me> Link: https://patch.msgid.link/20260425195011.790265-2-sean.wang@kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name>
Lorenzo Bianconi [Sat, 18 Apr 2026 18:04:16 +0000 (20:04 +0200)]
wifi: mt76: mt7996: Fix NULL pointer dereference in mt7996_init_tx_queues()
When MT76_NPU and CONFIG_NET_MEDIATEK_SOC_WED are enabled and
mt76 detects properly the Airoha NPU SoC, mt7996_init_tx_queues() will
dereference a NULL WED pointer.
Fix the issue by always passing the WED pointer from mt7996_dma_init().
Felix Fietkau [Tue, 24 Mar 2026 15:49:03 +0000 (15:49 +0000)]
wifi: mt76: mt7996: fix out-of-bounds array access during hardware restart
During hardware restart, link_id can be IEEE80211_LINK_UNSPECIFIED,
causing an out-of-bounds array access on msta->link[].
Add mt7996_sta_link() and mt7996_sta_link_protected() helper functions
for accessing sta links with proper RCU handling and bounds checking.
Use them for any sta link RCU access.
Johan Hovold [Thu, 30 Apr 2026 08:33:35 +0000 (10:33 +0200)]
wifi: mt7601u: drop redundant device reference
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Johan Hovold [Thu, 30 Apr 2026 08:33:34 +0000 (10:33 +0200)]
wifi: mt76: mt792xu: drop redundant device reference
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Johan Hovold [Thu, 30 Apr 2026 08:33:33 +0000 (10:33 +0200)]
wifi: mt76x2u: drop redundant device reference
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Johan Hovold [Thu, 30 Apr 2026 08:33:32 +0000 (10:33 +0200)]
wifi: mt76x0u: drop redundant device reference
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Johan Hovold [Thu, 30 Apr 2026 08:33:31 +0000 (10:33 +0200)]
wifi: mt76: drop redundant device reference
Driver core holds a reference to the USB interface and its parent USB
device while the interface is bound to a driver and there is no need to
take additional references unless the structures are needed after
disconnect.
Drop the redundant device reference to reduce cargo culting, make it
easier to spot drivers where an extra reference is needed, and reduce
the risk of memory leaks when drivers fail to release it.
Rajat Gupta [Thu, 7 May 2026 04:35:31 +0000 (21:35 -0700)]
wifi: mt76: use kfree_rcu for offchannel link in mt76_put_vif_phy_link
mt76_put_vif_phy_link() frees the offchannel mlink with plain kfree()
after rcu_assign_pointer(NULL). However, rcu_assign_pointer only prevents
future RCU readers from obtaining the pointer -- it does not wait for
existing readers that already hold it via rcu_dereference.
The TX datapath (e.g. mt7996_mac_write_txwi) dereferences mlink->wcid
and mlink->idx under rcu_read_lock. If a TX softirq obtained the pointer
via rcu_dereference just before the NULL assignment, it will dereference
freed memory after the kfree.
struct mt76_vif_link already contains an rcu_head field that is unused at
this free site -- a developer oversight, since the adjacent
kfree_rcu_mightsleep call for rx_sc in the same function shows the
pattern was understood.
Replace kfree(mlink) with kfree_rcu(mlink, rcu_head).
ElXreno [Wed, 6 May 2026 01:39:16 +0000 (04:39 +0300)]
wifi: mt76: mt7925: don't disable AP BSS when removing TDLS peer
On a STATION vif, removing a TDLS peer takes the mt7925_mac_sta_remove
-> mt7925_mac_sta_remove_links path. The first loop in that function
calls mt7925_mcu_add_bss_info(..., enable=false) for every link of the
station being removed. For a non-MLO STATION vif there is exactly one
link, link 0, whose bss_conf is the AP's. TDLS peers do not have their
own bss_conf - they share the AP's BSS.
The result is that every TDLS peer teardown sends a BSS_INFO_UPDATE
with enable=0 for the AP's BSS to the firmware, which wipes the AP-side
rate-control context. The connection stays associated and TX from the
host still works at the negotiated rate, but the AP's downlink to us
collapses to the lowest mandatory OFDM rate (HE-MCS 0 / 6 Mbit/s OFDM)
and only slowly recovers as rate adaptation re-learns under sustained
traffic. With brief or bursty traffic the link can stay at 6-72 Mbit/s
indefinitely, requiring a manual reconnect.
mt7925_mac_link_sta_remove() already guards its own
mt7925_mcu_add_bss_info(..., false) call with
"vif->type == NL80211_IFTYPE_STATION && !link_sta->sta->tdls".
Add the equivalent guard at the top of the cleanup loop in
mt7925_mac_sta_remove_links(), above the link_sta / link_conf /
mlink / mconf lookups, so TDLS peer teardown skips the loop body
entirely without doing the per-link work that would just be thrown
away.
Verified on mt7925e by triggering Samsung-S938B auto-TDLS via iperf3
and watching iw rx bitrate after teardown:
Before: rx bitrate collapses to 6.0-72.0 Mbit/s, oscillates 17/72/
137/288/432 Mbit/s for 30+ seconds, no full recovery without
a manual reassoc.
After: rx bitrate stays at 1200.9 Mbit/s HE-MCS 11 NSS 2 80 MHz
across the entire TDLS lifecycle.
bpftrace confirms a single mt7925_mcu_add_bss_info(enable=0) call per
teardown before the fix; zero such calls after.
ElXreno [Wed, 6 May 2026 01:39:15 +0000 (04:39 +0300)]
wifi: mt76: route TDLS-peer frames as 3-addr non-DS in HW encap
With HW TX encap offload enabled, the mt76 firmware builds the 802.11
header for the 802.3 frame using the per-WCID context. For a STATION
vif the HDR_TRANS TLV currently sets ToDS=1, which makes the firmware
default to the BSSID as A1 and emit STA->AP-formatted frames
regardless of which peer the WCID points to.
For TDLS-paired peers this is wrong. Data frames go on air addressed
to the AP, the AP MAC-ACKs and silently drops them per IEEE 802.11z
(an AP must not forward to a TDLS-paired peer). Management and
control frames bypass the HW encap path and still reach the peer;
only user data fails.
Add MT_WCID_FLAG_TDLS_PEER, set it in mt7915, mt7921, mt7925 and
mt7996 sta-add paths when sta->tdls is true, and override the
HDR_TRANS TLV in mt76_connac_mcu_wtbl_hdr_trans_tlv() (Connac2 -
mt7915 / mt7921 / mt7922), mt7925_mcu_sta_hdr_trans_tlv() (mt7925)
and mt7996_mcu_sta_hdr_trans_tlv() (mt7996) to set ToDS=0, FromDS=0
when the flag is set. The 3-addr non-DS form matches what 802.11z
uses for direct links; the firmware then constructs the frame with
A1=peer rather than A1=BSSID. HW encap offload remains enabled for
AP and any non-TDLS traffic.
Verified on mt7925e + Samsung S938B over a 5 GHz HE 80 MHz channel
with iperf3 -t 30 to the TDLS peer:
before fix: over the TDLS direct link, 7 TDLS Setup action
frames and 3 RTS frames reach the peer; 0 QoS
Data frames make it through (mgmt/control paths
bypass HW encap, the data path does not). iperf3
stalls.
after fix: 2.90 GBytes transferred at 830 Mbit/s sustained,
0 TCP retransmits.
mt7915, mt7921, mt7922 and mt7996 are not regression-tested in this
change for lack of hardware. Their HDR_TRANS handling mirrors the
verified mt7925 change; the firmware behavior is shared across these
chips.
wifi: mt76: mt7921/mt7925: fix NULL dereference in CSA beacon
This patch is based on a BUG as reported by Bongani Hlope at
https://lore.kernel.org/all/20260502125824.425d7159@bongani-mini.home.org.za/
When a channel-switch announcement (CSA) beacon is received,
cfg80211 queues a wiphy work item that eventually calls
mt7921_channel_switch_rx_beacon(). If the station disconnects
(or the channel context is otherwise torn down) between the
time the work is queued and the time it runs, the driver's
dev->new_ctx pointer can already have been cleared to NULL.
mt7921_channel_switch_rx_beacon() then dereferences new_ctx
unconditionally, triggering a NULL pointer dereference at
address 0x0:
The same missing guard exists in mt7925_channel_switch_rx_beacon(),
which shares the same code pattern introduced by the same commit.
Add an early-return NULL check for dev->new_ctx in both
mt7921_channel_switch_rx_beacon() and
mt7925_channel_switch_rx_beacon(). When new_ctx is NULL there is
no pending channel switch to process, so returning immediately is
the correct and safe action.
Hongling Zeng [Tue, 12 May 2026 06:52:45 +0000 (14:52 +0800)]
wifi: mt76: mt7921: fix resource leak in probe error path
When pcim_iomap_region() or devm_kmemdup() fail, the code returns
directly without cleaning up previously allocated resources:
- mt76_device allocated by mt76_alloc_device()
- pci irq vectors allocated by pci_alloc_irq_vectors()
Fix this by jumping to the existing error cleanup path instead of
returning directly.
Myeonghun Pak [Sun, 26 Apr 2026 14:33:36 +0000 (23:33 +0900)]
wifi: mt76: mt7925: clean up DMA on probe failure
mt7925_pci_probe() initializes DMA before registering the device. If
mt7925_register_device() fails, probe returns through err_free_irq without
tearing down DMA state.
That leaves the TX NAPI instance enabled and skips the DMA queue cleanup
that the normal remove path performs through mt7925e_unregister_device().
Add a dedicated unwind label for failures after mt7925_dma_init() succeeds.
Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips") Co-developed-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Ijae Kim <ae878000@gmail.com> Signed-off-by: Myeonghun Pak <mhun512@gmail.com> Link: https://patch.msgid.link/20260426143728.41534-1-pakmyeonghun@bagmyeonghun-ui-MacBookPro.local Signed-off-by: Felix Fietkau <nbd@nbd.name>
Victor Nogueira [Fri, 5 Jun 2026 21:22:39 +0000 (18:22 -0300)]
net/sched: Update function name in TCQ_F_NOPARENT comment
Commit 2ccccf5fb43f ("net_sched: update hierarchical backlog too") renamed
qdisc_tree_decrease_qlen() to qdisc_tree_reduce_backlog(), but this comment
was missed. Update it.
Krishna Chomal [Mon, 8 Jun 2026 13:42:55 +0000 (19:12 +0530)]
platform/x86: hp-wmi: Add support for Omen 16-ap0xxx (8E35)
The HP Omen 16-ap0xxx (board ID: 8E35) has the same WMI interface as
other Victus S boards, but requires quirks for correctly switching
thermal profile.
Add the DMI board name to victus_s_thermal_profile_boards[] table and
map it to omen_v1_legacy_thermal_params.
Testing on board 8E35 confirmed that platform profile is registered
successfully and fan RPMs are readable and controllable.
Tested-by: Ahmet Öztürk <sivasli-ahmet@gmx.de> Reported-by: Ahmet Öztürk <sivasli-ahmet@gmx.de> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221523 Cc: stable@vger.kernel.org # v6.18+ Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com> Link: https://patch.msgid.link/20260608134255.36280-1-krishna.chomal108@gmail.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Dmitry Osipenko [Thu, 4 Jun 2026 12:27:43 +0000 (15:27 +0300)]
drm/virtio: Fix driver removal with disabled KMS
DRM atomic and modesetting aren't initialized if virtio-gpu driver built
with disabled KMS, leading to access of uninitialized data on driver
removal/unbinding and crashing kernel. Fix it by skipping shutting down
atomic core with unavailable KMS.
David Howells [Thu, 4 Jun 2026 11:46:00 +0000 (12:46 +0100)]
rxrpc: Fix the ACK parser to extract the SACK table for parsing
Fix modification of the received skbuff in rxrpc_input_soft_acks() and a
potential incorrect access of the buffer in a fragmented UDP packet (the
packet would probably have to be deliberately pre-generated as fragmented)
when AF_RXRPC tries to extract the contents of the SACK table by copying
out the contents of the SACK table into a buffer before attempting to parse
AF_RXRPC assumes that it can just call skb_condense() and then validly
access the SACK table from skb->data and that it will be a flat buffer -
but skb_condense() can silently fail to do anything under some
circumstances.
Note that whilst rxrpc_input_soft_acks() should be able to parse extended
ACKs, the rest of AF_RXRPC doesn't currently support that.
Further, there's then no need to call skb_condense() in rxrpc_input_ack(),
so don't.
Fixes: d57a3a151660 ("rxrpc: Save last ACK's SACK table rather than marking txbufs") Reported-by: Michael Bommarito <michael.bommarito@gmail.com> Link: https://lore.kernel.org/r/20260513180907.2061972-1-michael.bommarito@gmail.com Signed-off-by: David Howells <dhowells@redhat.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Jeffrey Altman <jaltman@auristor.com>
cc: Eric Dumazet <edumazet@google.com>
cc: "David S. Miller" <davem@davemloft.net>
cc: Jakub Kicinski <kuba@kernel.org>
cc: Paolo Abeni <pabeni@redhat.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
cc: netdev@vger.kernel.org
cc: stable@kernel.org Link: https://patch.msgid.link/105362.1780573560@warthog.procyon.org.uk Signed-off-by: Paolo Abeni <pabeni@redhat.com>
projects / thirdparty / kernel / linux.git / log
