| Age | Commit message (Collapse) | Author |
|---|
|
Regulatory code updates channels holding only RTNL. Since
I removed RTNL everywhere, most reading code doesn't take
it, so it races with the updates.
Update the relevant regulatory data under wiphy mutex to
avoid (most of?) those races.
Some drivers acquire the wiphy mutex, so don't cover the
calls to the regulatory notifiers.
For beacon hints the order of operation changes, and the
driver notifier will be called only once later, but that
seems acceptable (even better) to drivers as I see it.
Link: https://patch.msgid.link/20261006120655.8c614b6d2f40.Id85777e278fbcf05b1ae1c42d2424acf6ed75fd6@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Most (wdev-related) dumps also take RTNL just for lookup.
Apply the same logic as for pre_doit() in the previous
commit to avoid the RTNL. Since I refactored the checks
there into a helper to use here, it even simplifies the
code.
Link: https://patch.msgid.link/20261006120655.37954ad94c77.Ica4719b0054c949abf2528d9c4c13a5d6b7a1a49@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We currently always take the RTNL for the lookup only
to drop it again if the command doesn't want it, but
now that we can do lookups with RCU, do that unless
the command still wants RTNL anyway.
This basically just means looking up under RCU, then
holding a reference briefly, and checking state (and
link IDs) under the wiphy mutex when it's acquired to
avoid races on unregistration etc.
Commands that don't want either mutex can only work
with netdevs since wdevs could go away, so warn on
others. None such can exist since there are no flags
for it, and I noted there it wouldn't be valid.
Link: https://patch.msgid.link/20261006120655.ea80a5ecd9b8.I9c4f85fb60160f377a24c1b8e5173966744e5f09@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We already modify our wiphy/wdev lists in RCU-safe ways,
so we can do lookups in RCU critical sections. Prepare
more of the code to be able to do that.
Link: https://patch.msgid.link/20261006120655.86d9cf36d8bb.I07b7ce5a69391d5168dc31c598b5079917a29bff@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
wdev_running() uses netif_running() for netdevs, which
can only be used under RTNL in a completely race-free
way.
Track the state for all wdevs via the existing netdev
notifier so we can check the state under wiphy mutex
in later changes.
Link: https://patch.msgid.link/20261006120655.7ed32b42c297.I9ac8bb8e7cd07c962116949aa0c56aab4e87839b@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
reg_query_regdb_wmm() is only used by iwlwifi, but even when
it was introduced was already broken, as it reads the global
db without any locking (drivers can't really guarantee any).
Certainly iwlwifi doesn't since it calls it for FW messages.
Therefore, it can race against regdb updates. The function
uses a local pointer, but doesn't help.
Use RCU to protect the regdb pointer to fix that, and update
the documentation to mention this (and do some cleanups).
Fixes: 19d3577e35e0 ("cfg80211: Add API to allow querying regdb for wmm_rule")
Link: https://patch.msgid.link/20261006120655.7c261d237cae.If21cf0af3b0d7e8c62c45ece5dc654b30c9d7757@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
An open debugfs file retains its file_operations pointer in the
debugfs proxy state. However, hwsim_background_cac_ops and
hwsim_simulate_incumbent_signal_fops in mac80211_hwsim_main.c have no
.owner set to THIS_MODULE.
As a result, full_proxy_open_regular() calls fops_get() which succeeds
without taking a reference to the mac80211_hwsim module. When a userspace
process opens either of these debugfs files, a subsequent module unload
(rmmod mac80211_hwsim) can succeed while the file descriptor remains open.
When the userspace process subsequently closes the descriptor,
full_proxy_release() accesses the already unmapped file_operations
structure, triggering a kernel oops in full_proxy_release():
BUG: unable to handle page fault for address: fffffbfff84f49e7
Oops: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:full_proxy_release+0x8e/0x140
Call Trace:
<TASK>
__fput+0x39f/0xa60
__x64_sys_close+0x80/0xe0
do_syscall_64+0xc3/0x590
entry_SYSCALL_64_after_hwframe+0x76/0x7e
</TASK>
The issue was discovered via manual code audit of mac80211_hwsim_main.c
and reproduced on a Linux 7.3-rc6 test VM with CONFIG_MAC80211_HWSIM=m.
Set .owner = THIS_MODULE on both debugfs file_operations structures in
mac80211_hwsim_main.c so that debugfs pins the module until close has
completed.
Signed-off-by: Bui Viet Dung <dungvn2345@gmail.com>
Link: https://patch.msgid.link/20261008122838.224835-1-dungvn2345@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
An open debugfs file retains its file_operations pointer in the
debugfs proxy state. However, the file_operations defined by the
DEBUGFS_READONLY_FILE and DEBUGFS_RADIO_READONLY_FILE macros, as well
as ht40allow_map_ops in net/wireless/debugfs.c, have no .owner set to
THIS_MODULE.
As a result, full_proxy_open_regular() calls fops_get() which succeeds
without taking a reference to the cfg80211 module. When CONFIG_CFG80211=m
and wireless debugfs is enabled, a userspace process can open any of these
debugfs files (e.g. /sys/kernel/debug/ieee80211/phy0/rts_threshold or
ht40allow_map) and keep the file descriptor open while the module is
unloaded (rmmod cfg80211).
When the userspace process subsequently closes the descriptor,
full_proxy_release() accesses the already unmapped file_operations
structure, triggering a kernel oops in full_proxy_release():
BUG: unable to handle page fault for address: fffffbfff8056f03
#PF: supervisor read access in kernel mode
Oops: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:full_proxy_release+0x8e/0x140
Call Trace:
<TASK>
__fput+0x39f/0xa60
fput_close_sync+0xff/0x200
__x64_sys_close+0x8c/0xf0
do_syscall_64+0x115/0x6a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
The issue was discovered via manual code audit of
net/wireless/debugfs.c.
Set .owner = THIS_MODULE on all debugfs file_operations tables in
net/wireless/debugfs.c so that debugfs pins the module until all open
file descriptors have been closed.
Signed-off-by: Bui Viet Dung <dungvn2345@gmail.com>
Link: https://patch.msgid.link/20261008052936.555554-1-dungvn2345@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
An open debugfs file retains its file_operations pointer in the
debugfs proxy state. However, hwflags_ops in net/mac80211/debugfs.c
has no .owner set to THIS_MODULE.
As a result, full_proxy_open_regular() calls fops_get() which succeeds
without taking a reference to the mac80211 module. When CONFIG_MAC80211=m
and wireless debugfs is enabled, a userspace process can open the
hwflags debugfs file and keep the file descriptor open while the module
is unloaded (rmmod mac80211).
When the userspace process subsequently closes the descriptor,
full_proxy_release() accesses the already unmapped file_operations
structure, triggering a kernel oops in full_proxy_release():
BUG: unable to handle page fault for address: fffffbfff8056f03
#PF: supervisor read access in kernel mode
Oops: 0000 [#1] SMP KASAN NOPTI
RIP: 0010:full_proxy_release+0x8e/0x140
Call Trace:
<TASK>
__fput+0x39f/0xa60
fput_close_sync+0xff/0x200
__x64_sys_close+0x8c/0xf0
do_syscall_64+0x115/0x6a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
</TASK>
The issue was discovered via manual code audit of
net/mac80211/debugfs.c.
Set .owner = THIS_MODULE on hwflags_ops so that debugfs pins the
module until all open file descriptors have been closed.
Signed-off-by: Bui Viet Dung <dungvn2345@gmail.com>
Link: https://patch.msgid.link/20261008052412.541780-1-dungvn2345@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
ieee80211_inform_bss() currently calls ieee802_11_parse_elems to
parse the beacon elements, which internally sets the params->mode
to IEEE80211_CONN_MODE_HIGHEST. This means any S1G specific parsing
is bypassed entirely (in the beacon case it is the shorter TIM)
and the beacon is marked as corrupt:
wlan0: operating as S1G STA
wlan0: associating to AP 0c:bf:74:00:30:fd with corrupt beacon
wlan0: associate with 0c:bf:74:00:30:fd (try 1/3)
In this case, we can simply call ieee802_11_parse_elems_full and
build the params locally (similar to most mlme paths) such that we
can set the conn mode to ensure the S1G specific parsing occurs.
Once this is done, the beacon is no longer considered corrupt:
wlan0: operating as S1G STA
wlan0: associate with 0c:bf:74:00:30:fd (try 1/3)
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20261008030939.474493-3-lachlan.hodges@morsemicro.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
An S1G TIM, unlike the regular TIM, can exclude both the bitmap
control and the PVB. As a result it's minimum length is actually 2.
Fix this by allowing a shorter TIM for S1G connections.
Suggested-by: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
Link: https://patch.msgid.link/20261008030939.474493-2-lachlan.hodges@morsemicro.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Struct field cross-references in kernel-doc use @field, not %field (which
is for constants and #defines). Fix eight instances, while also correcting
%elems -> @elem naming in cfg80211_mbssid_elems and cfg80211_rnr_elems.
Assisted-by: LLM
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Link: https://patch.msgid.link/20261007-cfg80211-kdoc-v1-1-157b358b291f@oss.qualcomm.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
WEXT IBSS and managed mode store the BSSID in the same
wdev->wext.bssid buffer. cfg80211_ibss_wext_siwap() keeps a pointer to
that buffer in wext.ibss.bssid. After changing to station mode,
cfg80211_mgd_wext_siwap() accepts a multicast AP address and copies it
to the buffer. Switching back to IBSS then follows that pointer and
uses the multicast address as a fixed BSSID.
mac80211 can create a beacon with that address, but cfg80211_get_bss()
rejects it, causing WARN_ON(!bss) in cfg80211_ibss_joined() after the
join has been reported.
Reject invalid station BSSIDs before copying them. A mac80211_hwsim WEXT
ioctl test reproduces the reported BSSID and warning; the original
syzbot report has no reproducer.
Reported-by: syzbot+d0a52209bddfa0948065@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=d0a52209bddfa0948065
Signed-off-by: Eduard Zateev <hackerowskiy@gmail.com>
Link: https://patch.msgid.link/20261007142855.1472524-1-hackerowskiy@gmail.com
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Felix Fietkau says:
===================
mt76 patches for 7.4
- mt7625 NAN fixes
- mt7996 connection monitor fix
- offchannel/scan improvements
- MLO fixes
- other minor fixes
===================
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Make sure to drop the reference taken by usb_anchor_urb() when removing
URBs from the delayed URB anchor to prevent them from leaking when the
device is later disconnected.
Fixes: 383cedc3bb43 ("USB: serial: full autosuspend support for the option driver")
Reported-by: Wentao Liang <vulab@iscas.ac.cn>
Link: https://lore.kernel.org/20260916165608.2085613-1-vulab@iscas.ac.cn
Cc: stable@vger.kernel.org # 2.6.32
Cc: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
If TDLS setup packets are created by AF_PACKET or so, then
the payload may not be present. Since we only care about
those mac80211 generated (which are linear), just replace
the skb->len check with a skb_headlen() check to avoid any
out-of-bounds accesses.
Assisted-by: LLM
Link: https://patch.msgid.link/20261005224950.c3cf023d5191.Id537db8aca13e6df999938a3bc4cc6ce2a28f733@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
For injection we only check the header is in the skb
head, but e.g. ACK/CTS are really short, and we then
try to use A2 anyway. Require A1 (no S1G extension
frames) and use A2 only when present.
Assisted-by: LLM
Link: https://patch.msgid.link/20261005224950.0f3c3e88abde.I03477f2444a9f2cb2888d00320ac7c4504f150a3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
These structs are placed after the tail, but that can make
them unaligned. Change the order so the structs are after
one another, and then followed by the head/tail/elements.
Assisted-by: LLM
Fixes: 2b3171c6fe0a ("mac80211: MBSSID beacon handling in AP mode")
Link: https://patch.msgid.link/20261005224950.2f554b2c7c10.Ie961eb6b1435f956446e052936258758b966c67f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The mesh and MPP path generation counters (for netlink)
are updated wrongly and sometimes unlocked. Fix those
issues.
Assisted-by: LLM
Link: https://patch.msgid.link/20261005224950.373dd5c1e46a.I29b95bc3f62b846084700599a261a203a6e459b4@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
With radiotap injection the HT/VHT MCSes can be just
about anything, but that can later get problematic.
Limit them to the rates the device reports, which is
presumably going to be a subset of what mac80211 can
do, except for HT MCS 32 which some devices report as
supported, but then TX status can't deal with it.
If it's not supported just ignore the config.
Assisted-by: LLM
Fixes: dfdfc2beb0dd ("mac80211: Parse legacy and HT rate in injected frames")
Fixes: 646e76bb5daf ("mac80211: parse VHT info in injected frames")
Link: https://patch.msgid.link/20261005224950.68e210b8487a.I2ee0e4664c54cf31002eb9e4f5190fd05ff4130f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The radiotap iterator initialization will already parse
the presence bitmaps, so it accesses a good part of the
header. This might not be present in the linear part of
the SKB, we haven't checked it at this point. Check the
lengths first.
Assisted-by: LLM
Fixes: cb17ed29a7a5 ("mac80211: parse radiotap header when selecting Tx queue")
Link: https://patch.msgid.link/20261005224950.b5c2c31790d2.I091422db411b595bde4dba2de69334cd2aeb33b0@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
That's a nonsensical configuration, and we get errors
reported further down in mac80211 for it; hostapd has
code that only adds the nested element if it'll not be
an empty list.
Remove an unnecessary NULL check while at it.
Fixes: dbbb27e183b1 ("cfg80211: support RNR for EMA AP")
Assisted-by: LLM
Link: https://patch.msgid.link/20261005224950.97db49d9d104.I5765a3310528b3d1cb1673dc90ad5ab5fc3ea571@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
We never kill the wake_txqs_tasklet so it could be running
while the hardware is being freed. Kill it, late enough to
never be able to restart afterwards.
Assisted-by: LLM
Fixes: 21a5d4c3a45c ("mac80211: add stop/start logic for software TXQs")
Link: https://patch.msgid.link/20261005224950.3fdb8d0ff377.I851e79ac625c4926e211642ee7a7e458728b0ad3@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The mesh paths walk list used under RCU, so we must use
hlist_add_head_rcu() to publish an entry. Fix one place
that didn't do that.
Assisted-by: LLM
Fixes: b4c3fbe63601 ("mac80211: Use linked list instead of rhashtable walk for mesh tables")
Link: https://patch.msgid.link/20261005224950.e0db543145e1.Ieaf30d3546e8ff63ccf400f6fb26e027c218721f@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
In practice, we probably shouldn't end up with a fragmented
frame that's protected, filled into the cache, finished or
dropped and then the next frame is unprotected, since only
unicast data frames can be fragmented.
However, tools complain and it's more correct to be able to
do this (e.g. an unencrypted fragmented EAPOL _could_, at
least in theory, happen), so clear the flag when the entry
is reused.
Assisted-by: LLM
Fixes: 7e44a0b597f0 ("mac80211: prevent attacks on TKIP/WEP as well")
Link: https://patch.msgid.link/20261005224950.c3e4106f34d5.I866c0862db031c3a810d2333acdd22e2733d2b8c@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The ASR modem used in the Tuoshi LT22M exposes an RNDIS function on
interfaces 0 and 1, a diagnostic port on interface 2, and AT ports on
interfaces 3 and 4. Match only the vendor-specific serial interfaces
so option does not bind to the RNDIS function.
Link: https://lore.kernel.org/all/d12635f9-9706-4dbd-8adb-d673c6a77202@wyraz.de/
Signed-off-by: Michael Wyraz <michael@wyraz.de>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
Add Rolling Wireless RN947R 0x9300 compositions:
Standard mode: DIAG + ADB + NMEA + MODEM + RMNET + QDSS + ADPL
T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 6 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=ef(misc ) Sub=02 Prot=01 MxPS=64 #Cfgs= 1
P: Vendor=33f8 ProdID=9300 Rev= 0.00
S: Manufacturer=Rolling Wireless
S: Product=RN947R
S: SerialNumber=xxxxxxxxxxx
C:* #Ifs= 7 Cfg#= 1 Atr=a0 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=usbfs
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
E: Ad=84(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
E: Ad=86(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 8 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=50 Driver=qmi_wwan
E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
E: Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#=21 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=70 Driver=(none)
E: Ad=89(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#=22 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=80 Driver=(none)
E: Ad=8a(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
QDL mode:
T: Bus=01 Lev=01 Prnt=01 Port=02 Cnt=02 Dev#= 12 Spd=480 MxCh= 0
D: Ver= 2.10 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=33f8 ProdID=9300 Rev= 0.00
S: Manufacturer=Rolling Wireless
S: Product=RN947R
S: SerialNumber=xxxxxxxxxxx
C:* #Ifs= 1 Cfg#= 1 Atr=a0 MxPwr= 2mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=10 Driver=option
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Signed-off-by: Reinhard Speyerer <rspmn@arcor.de>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
usb_wwan_port_probe() allocates the transfer buffers for the read URBs.
These buffers can be allocated with kmalloc() as there's nothing special
about them to go directly to the page allocator.
kmalloc() provides a better API that does not require ugly casts and
kfree() does not need to know the size of the freed object.
Performance difference between kmalloc() and __get_free_pages() is not
measurable as both allocators take an object/page from a per-CPU list for
fast path allocations.
For the slow path the performance is anyway determined by the amount of
reclaim involved rather than by what allocator is used.
While on it, allocate IN_BUFLEN bytes rather than a full page. IN_BUFLEN
is the transfer_buffer_length of the read URBs, the page allocator was
only used because IN_BUFLEN happens to equal PAGE_SIZE on x86.
Replace use of __get_free_page() with kmalloc() and free_page() with
kfree().
Link: https://lore.kernel.org/all/635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com
Assisted-by: copilot:claude-opus
Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
|
|
The FQ reply parser code blindly advanced the walk pointer by a length
value read directly from the hardware reply payload without checking
that the advance stayed within the allocated reply buffer. A corrupt
or malicious device response could push ptr beyond the cprbmem region,
causing an out-of-bounds dereference or kernel memory exposure via the
subsequent memcpy().
Fix this by tracking the remaining reply buffer space in a variable
and validating each device-supplied length field against it before
advancing or dereferencing the pointer.
Fixes: 2004b57cde6b ("s390/zcrypt: code cleanup")
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Cc: stable@vger.kernel.org
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
|
The previous array_index_nospec() placement only covered the admin
permission check, leaving ap_test_config_usage_domain() and
ap_test_config_ctrl_domain() in the CCA path exposed to speculative
execution.
Move the sanitization to before all permission and config checks in
both the CCA and EP11 paths. Hold the sanitized domain value in
another variable so that the later use can choose to use either the
original value (subject to speculative execution) or the sanitized
value (which may in case of AUTOSEL_DOM reflect the wrong
value). Before that, check the domain value to be either AUTOSEL_DOM
or in range 0...AP_DOMAINS-1 and return with -EINVAL in case this check
does not pass.
Fixes: e935cd525af4 ("s390/zcrypt: Close speculative mem read possibility")
Signed-off-by: Harald Freudenberger <freude@linux.ibm.com>
Cc: stable@vger.kernel.org
Reviewed-by: Holger Dengler <dengler@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
|
Make sure to drop the reference taken by usb_anchor_urb() when removing
URBs from the delayed URB anchor to prevent them from leaking when the
device is later disconnected.
Fixes: 140cb81ac8c6 ("USB: cdc-acm: fix broken runtime suspend")
Reported-by: Wentao Liang <vulab@iscas.ac.cn>
Link: https://lore.kernel.org/20260917161217.2161883-1-vulab@iscas.ac.cn/
Cc: stable@vger.kernel.org # 3.16
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://patch.msgid.link/20261009122934.464142-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
Heiko Carstens says:
====================
s390's virtual timer infrastructure has only a single user and the
semantics of the interface are not straightforward: a virtual timer
fires if the sum of elapsed CPU time over all CPUs exceeds a specified
value.
This is suboptimal since the number of active CPUs defines how
frequently the timer fires. With many CPUs and short intervals this can
be very frequent. Furthermore the required accounting in the vtime code
uses a single 64-bit value to accumulate elapsed CPU time. In busy
systems this can lead to cache line bouncing when the value is updated
concurrently on several CPUs; which is the reason why other accounting
mechanisms use per-CPU data structures for this purpose.
In practice this is not a problem with the appldata default interval
of 10 seconds, however the interval is configurable via sysctl with a
minimum value of 1ms.
Given that there is only a single user, emulate the virtual timer in
appldata using delayed work: the work is scheduled for the minimum
possible wall-clock time until the configured CPU-time interval elapses
(remaining CPU time / number of online CPUs), with a minimum delay of
100ms. The work then reads per-CPU statistics of all online CPUs to
check whether enough CPU time has elapsed, and if so runs the
registered callbacks.
The calculation is more expensive, but avoids potential cache line
bouncing problem. In addition it allows to remove the entire vtimer
infrastructure code with a subsequent patch.
====================
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
|
The only user is gone - remove the vtimer infrastructure.
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
|
Emulate the virtual timer in appldata using delayed work: the work is
scheduled for the minimum possible wall-clock time until the
configured CPU-time interval elapses (remaining CPU time / number of
online CPUs), with a minimum delay of 100ms. The work then reads
per-CPU statistics of all online CPUs to check whether enough CPU time
has elapsed, and if so runs the registered callbacks.
This is slightly more expensive, but allows to subsequently remove the
entire vtimer infrastructure.
Reviewed-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Tested-by: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
|
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next
Mika writes:
thunderbolt: Fix for v7.3-rc7
This incluces a single fix to make the runtime PM completion complete
devices that are actually part of the domain. Needed for firmware
connection manager based systems.
This has been in linux-next for few days with no reported issues.
* tag 'thunderbolt-for-v7.3-rc7' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
thunderbolt: Do not RPM complete unrelated subtrees on unplug
|
|
cfg80211 already holds the RTNL here, so this will
just deadlock. Remove the extra RTNL acquisition.
Oddly enough this was all true even back when the
locking here was added, so this is just a revert
of a broken ~13 year old commit.
Fixes: bc52aab380c7 ("ath6kl: Protect ath6kl_cfg80211_vif_cleanup using rtnl_locks")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://patch.msgid.link/20261008165646.48866f0521af.I1c166be830384473f67677eeb187afa7e54106ea@changeid
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
Firmware supplies the hardware mode count and the PHY bitmap for each
mode in the service-ready-ext event. ath12k_wmi_save_all_mac_phy_info()
uses those bitmaps to populate svc_ext_info->mac_phy_info, but the
destination is a fixed array of ATH12K_MAX_MAC_PHY_CAP elements.
If the total number of advertised PHY entries exceeds that limit, the
loop writes beyond mac_phy_info and corrupts adjacent memory.
ath12k_wmi_mac_phy_caps_parse() allocates the source array for
tot_phy_id entries and rejects excess capability TLVs. However, if the
event contains fewer capability TLVs than advertised, the remaining
allocated entries stay zeroed and are saved as invalid PHY information.
After parsing the MAC/PHY capability TLVs, validate the destination
capacity and reject an incomplete capability list before saving any
entries.
Fixes: 062ade23991e ("wifi: ath12k: parse and save hardware mode info from WMI_SERVICE_READY_EXT_EVENTID event for later use")
Cc: stable@vger.kernel.org
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20261003101944.596546-1-yaojiale02@163.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
ath12k supports creating vdevs with addresses provided by mac80211.
Userspace can already make concurrent interfaces work by explicitly
assigning different locally administered addresses.
However, ath12k does not advertise an address list, so when a second
interface is created without an explicit address, mac80211 has nothing
to pick from and falls back to the permanent address. If the first
interface is already running with that address, bringing up the second
one fails with -ENOTUNIQ.
As in ath11k, provide a list of usable addresses so
ieee80211_assign_perm_addr() can hand each new interface an unused one.
Keep the first entry as the wiphy's permanent MAC address. Generate the
remaining entries as locally administered variants by changing only the
upper nibble of the first octet, which naturally limits the pool to 16
unique addresses.
The cfg80211 definition of wiphy->addresses does not specify where the
addresses must come from. Some ath12k platforms use it as an interface
MAC address pool, while others use it for firmware-provided per-radio
addresses. Gate the generated address pool behind
advertise_iface_mac_pool and enable it for WCN7850 and QCC2072. The flag
is read from the first radio, as all radios behind a wiphy are
expected to have the same setting.
Other platforms keep the existing behavior.
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.1.c7-00108-QCAHMTSWPL_V1.0_V2.0_SILICONZ_UPSTREAM-3
Tested-on: QCC2072 hw1.0 PCI WLAN.COL.1.0.c2-00074-QCACOLSWPL_V1_TO_SILICONZ-1
Assisted-by: LLM
Signed-off-by: Vitor Soares <vitor.soares@toradex.com>
Tested-by: Kang Yang <kang.yang@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Link: https://patch.msgid.link/20260922200643.1133491-2-ivitro@gmail.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
|
|
Sumanth Korikkar says:
====================
The cpu hotplug callbacks start and stop counter sets for every active
hwctr session without checking the session cpu mask. This causes a
reference count underflow when an unrelated cpu goes offline, and
silently adds cpus to a session when they come online.
Patch 1 fixes the reference count underflow in cfset_offline_cpu() and
is suitable for stable kernels. It does not change the online behavior,
so no matching lshwc change is required.
Patch 2 extends the mask check to cfset_online_cpu() and keeps the
userspace provided cpu mask unchanged across hotplug events. It requires
a matching lshwc change and is therefore kept separate from patch 1.
====================
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
|
cfset_online_cpu() and cfset_offline_cpu() cpu hotplug callbacks start
and stop counter sets for every active hwctr session without checking
the session cpu mask, and dynamically modify that mask on each hotplug
event.
For example, assume cpu0 and cpu1 are online and cpu2 is offline. Start
an hwctr session restricted to cpu0 and cpu1, and then bring cpu2 online:
lshwc -l 9999 -i 5 0-1:b
chcpu -e 2
Although cpu2 is not part of the requested mask, cfset_online_cpu()
starts the counter sets on cpu2 and adds it to the session mask. cpu2
can then appear in lshwc output (s390-tools) and is handled as part of
the session until it is stopped.
Keep the userspace provided cpu mask unchanged and update counter sets
only when the hotplugged cpu belongs to that mask. For all cpu requests,
lshwc should supply the possible cpu mask so that cpus coming online later
remain part of the session.
Note:
A corresponding lshwc (s390-tools) change is needed to supply the
possible cpu mask for allcpu sessions, ensuring that cpus coming online
later remain part of the session. Without it, newly online cpus would be
silently excluded from an active session.
Since this userspace change is not yet available, the patch is not
suitable for stable kernels and intentionally omits a Fixes: tag. The
prerequisite bug fix is in "s390/cpum_cf: Check session mask before cpu
offline".
Reported-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
|
cfset_offline_cpu() stops counter sets for every active session without
checking whether the outgoing cpu belongs to the session mask.
For example, run an hwctr session on cpu0 and a cpu bound perf event on
cpu1:
lshwc -l 9999 -i 5 0:b
perf stat -C 1 -e cpum_cf/CPU_CYCLES/ sleep 120
chcpu -d 1
chcpu -e 1
Although the hwctr session does not include cpu1, cfset_offline_cpu()
decrements its counter set reference count. The subsequent perf teardown
decrements it again, causing it to underflow.
The perf event keeps the percpu state alive across hotplug. When cpu1
comes online, the hwctr session is started there and the reference count
moves from -1 to 0. Stopping the hwctr session then decrements it to -1
again, so the zero triggered counter set disable path is skipped.
Check the session mask before stopping counter sets on the outgoing cpu.
This prevents the unmatched decrement and the resulting reference count
underflow.
Fixes: a029a4eab39e ("s390/cpumf: Allow concurrent access for CPU Measurement Counter Facility")
Reported-by: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: stable@vger.kernel.org # v5.14+
Signed-off-by: Sumanth Korikkar <sumanthk@linux.ibm.com>
Reviewed-by: Heiko Carstens <hca@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
|
With [1] the generated string initializers were changed to use an
array instead of a non-NUL-terminated string. The reason was that GCC 15
warns about string initializers that truncate the NUL terminator with
-Wunterminated-string-initialization.
The better solution is to use the __nonstring annotation, which exists
to deal exactly with this problem. Therefore use it and basically
revert [1] in order to generate more readable initializers:
Before:
[LONG_INSN_ALGHSIK] = { 'a', 'l', 'g', 'h', 's', 'i', 'k', },
After:
[LONG_INSN_ALGHSIK] = "alghsik",
[1] commit 7cbae7ea3de5 ("s390/tools: Use array instead of string initializer")
Reviewed-by: Jens Remus <jremus@linux.ibm.com>
Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
|
|
The Mayflower ARC AMP DAC (USB ID 0493:4170, MAG Technology front-end)
at times gets stuck reporting feedback of nominal+1 sample/frame (97
instead of 96 at 96 kHz) and does not recover. The driver follows this
feedback, and audible pops occur every 1-2s until the stream is
restarted.
Add a quirk for this device that ignores feedback values more than
1/128 (~0.8%) away from nominal and uses the nominal rate instead.
Normal feedback corrections are far smaller than that and pass
through unchanged. Other devices are not affected.
Signed-off-by: Dimitri Wegner <d@zerovolt.org>
Link: https://patch.msgid.link/20261009-mayflower-fb-v1-1-a84e82e05ac9@zerovolt.org
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The C200 (046d:0802) reports a mic capture volume range of
1536..7680 with a resolution of 1 (6144 steps), triggering
"Warning! Unlikely big volume step count (=6144), linear volume or
wrong cval->res?" at probe and exposing a uselessly fine-grained
mixer control. This is the same firmware behavior as the other
UVC-era Logitech webcams already carrying QUIRK_FLAG_MIC_RES_384
(C500, C600, C210, C270, C310, C510, C525, ...), so apply the same
quirk: CTL_MSG_DELAY_1M (which the Logitech VENDOR_FLG would provide
if the device-specific entry did not short-circuit the lookup) plus
MIC_RES_384.
Verified on real hardware: with the quirk the warning disappears and
the driver logs "set resolution quirk: cval->res = 384".
Signed-off-by: Olivier Kaloudoff <olivier.kaloudoff@gmail.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20261008230844.11246-1-olivier.kaloudoff@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The shutdown procedure needs to cancel the delayed probe work in case
where the probe work stalls or is slow but still possible to
reactivated.
Fixes: c0f1886de7e1 ("ALSA: hda: intel: Allow repeatedly probing on codec configuration errors")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://patch.msgid.link/20261008192553.300025-2-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
When a creation of input or output compress-offload task fails in
fsl-asrc driver, the task->input or task->output pointer is left with
ERR_PTR(), which is non-NULL. Then it's handled in the compress
offload core and it tries to release via dma_buf_put(), resulting in
an access to a wrong address.
Clear the bogus pointers properly before returning an error.
Fixes: 24a01710f627 ("ASoC: fsl_asrc_m2m: Add memory to memory function")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://patch.msgid.link/20261008192553.300025-9-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
line6_capture_copy() copies the data for the original byte size, but
the buffer overwrap is checked against the frame size. Because of it,
when the data size isn't aligned in frames, the remaining bytes might
be still copied above the buffer size.
For avoiding the potential OOB write, correct the copied data size in
line6_capture_copy() to be aligned with frames.
Fixes: 1027f476f507 ("staging: line6: sync with upstream")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://patch.msgid.link/20261008192553.300025-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Although the LINE6 driver has a sanity check for the given max packet
sizes, it still has an implicit requirement of the minimal size being
bytes-per-frame; e.g. the impulse test signal assuming the fixed size,
and when a too small size is specified by a malformed USB descriptor,
this may lead to an OOB access.
Change the sanity check conditions to reject too small max packet
sizes for avoiding the scenario above.
Fixes: 3450121997ce ("ALSA: line6: Fix write on zero-sized buffer")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://patch.msgid.link/20261008192553.300025-10-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
All get and put callbacks for us16x08 mixer have no proper protection,
hence the concurrent accesses to multiple elements may face data
races, resulting in unexpected values.
Put the new mixer->lock mutex for protecting the concurrent accesses.
Fixes: d2bb390a2081 ("ALSA: usb-audio: Tascam US-16x08 DSP mixer quirk")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://patch.msgid.link/20261008192553.300025-8-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
URB completion and rawmidi trigger callbacks can race with each other,
which may put the state inconsistent, causing double submissions, etc.
Guard both with a new spinlock for avoiding the races.
Fixes: f3f80a9205da ("ALSA: caiaq - Fix Oops with MIDI")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Link: https://patch.msgid.link/20261008192553.300025-7-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
