<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/net/wireless/core.c, branch v6.19.11</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.11</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.19.11'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-03-12T11:09:33+00:00</updated>
<entry>
<title>wifi: cfg80211: cancel rfkill_block work in wiphy_unregister()</title>
<updated>2026-03-12T11:09:33+00:00</updated>
<author>
<name>Daniil Dulov</name>
<email>d.dulov@aladdin.ru</email>
</author>
<published>2026-02-11T08:20:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cd2f52944c7b95dcdfe0d87f385a2d96458a3ae5'/>
<id>urn:sha1:cd2f52944c7b95dcdfe0d87f385a2d96458a3ae5</id>
<content type='text'>
commit 767d23ade706d5fa51c36168e92a9c5533c351a1 upstream.

There is a use-after-free error in cfg80211_shutdown_all_interfaces found
by syzkaller:

BUG: KASAN: use-after-free in cfg80211_shutdown_all_interfaces+0x213/0x220
Read of size 8 at addr ffff888112a78d98 by task kworker/0:5/5326
CPU: 0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: events cfg80211_rfkill_block_work
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x116/0x1f0
 print_report+0xcd/0x630
 kasan_report+0xe0/0x110
 cfg80211_shutdown_all_interfaces+0x213/0x220
 cfg80211_rfkill_block_work+0x1e/0x30
 process_one_work+0x9cf/0x1b70
 worker_thread+0x6c8/0xf10
 kthread+0x3c5/0x780
 ret_from_fork+0x56d/0x700
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;

The problem arises due to the rfkill_block work is not cancelled when wiphy
is being unregistered. In order to fix the issue cancel the corresponding
work in wiphy_unregister().

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.

Fixes: 1f87f7d3a3b4 ("cfg80211: add rfkill support")
Cc: stable@vger.kernel.org
Signed-off-by: Daniil Dulov &lt;d.dulov@aladdin.ru&gt;
Link: https://patch.msgid.link/20260211082024.1967588-1-d.dulov@aladdin.ru
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>wifi: cfg80211: allow only one NAN interface, also in multi radio</title>
<updated>2026-03-04T12:20:24+00:00</updated>
<author>
<name>Miri Korenblit</name>
<email>miriam.rachel.korenblit@intel.com</email>
</author>
<published>2026-01-07T11:51:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3b9dff583e8bc14d918ef4598801cd292e3dfd72'/>
<id>urn:sha1:3b9dff583e8bc14d918ef4598801cd292e3dfd72</id>
<content type='text'>
[ Upstream commit e69fda4d07701373354e52b0321bd40311d743d0 ]

According to Wi-Fi Aware (TM) 4.0 specification 2.8, A NAN device can
have one NAN management interface. This applies also to multi radio
devices.
The current code allows a driver to support more than one NAN interface,
if those are not in the same radio.

Fix it.

Reviewed-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20260107135129.fdaecec0fe8a.I246b5ba6e9da3ec1481ff197e47f6ce0793d7118@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: cfg80211: stop NAN and P2P in cfg80211_leave</title>
<updated>2026-02-26T23:01:06+00:00</updated>
<author>
<name>Miri Korenblit</name>
<email>miriam.rachel.korenblit@intel.com</email>
</author>
<published>2026-01-07T12:04:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4083d2d32da9e9a1d312eb78dbf80c9b4f644768'/>
<id>urn:sha1:4083d2d32da9e9a1d312eb78dbf80c9b4f644768</id>
<content type='text'>
[ Upstream commit e1696c8bd0056bc1a5f7766f58ac333adc203e8a ]

Seems that there is an assumption that this function should be called
only for netdev interfaces, but it can also be called in suspend, or
from nl80211_netlink_notify (indirectly).
Note that the documentation of NL80211_ATTR_SOCKET_OWNER explicitly
says that NAN interfaces would be destroyed as well in the
nl80211_netlink_notify case.

Fix this by also stopping P2P and NAN.

Fixes: cb3b7d87652a ("cfg80211: add start / stop NAN commands")
Reviewed-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20260107140430.dab142cbef0b.I290cc47836d56dd7e35012ce06bec36c6da688cd@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: cfg80211: stop radar detection in cfg80211_leave()</title>
<updated>2025-11-24T12:05:23+00:00</updated>
<author>
<name>Johannes Berg</name>
<email>johannes.berg@intel.com</email>
</author>
<published>2025-11-21T16:40:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9f33477b9a31a1edfe2df9f1a0359cccb0e16b4c'/>
<id>urn:sha1:9f33477b9a31a1edfe2df9f1a0359cccb0e16b4c</id>
<content type='text'>
If an interface is set down or, per the previous patch, changes
type, radar detection for it should be cancelled. This is done
for AP mode in mac80211 (somewhat needlessly, since cfg80211 can
do it, but didn't until now), but wasn't handled for mesh, so if
radar detection was started and then the interface set down or
its type switched (the latter sometimes happning in the hwsim
test 'mesh_peer_connected_dfs'), radar detection would be around
with the interface unknown to the driver, later leading to some
warnings around chanctx usage.

Link: https://patch.msgid.link/20251121174021.290120e419e3.I2a5650c9062e29c988992dd8ce0d8eb570d23267@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: cfg80211: replace use of system_unbound_wq with system_dfl_wq</title>
<updated>2025-11-20T09:26:17+00:00</updated>
<author>
<name>Marco Crivellari</name>
<email>marco.crivellari@suse.com</email>
</author>
<published>2025-11-13T16:20:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=fec4d9d6ffd297b1ce8f19a8f723f5b0aaac5b3e'/>
<id>urn:sha1:fec4d9d6ffd297b1ce8f19a8f723f5b0aaac5b3e</id>
<content type='text'>
Currently if a user enqueues a work item using schedule_delayed_work() the
used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
schedule_work() that is using system_wq and queue_work(), that makes use
again of WORK_CPU_UNBOUND.

This lack of consistency cannot be addressed without refactoring the API.
For more details see the Link tag below.

This continues the effort to refactor workqueue APIs, which began with
the introduction of new workqueues and a new alloc_workqueue flag in:

commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")

Switch to using system_dfl_wq because system_unbound_wq is going away as part of
a workqueue restructuring.

Suggested-by: Tejun Heo &lt;tj@kernel.org&gt;
Signed-off-by: Marco Crivellari &lt;marco.crivellari@suse.com&gt;
Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
Link: https://patch.msgid.link/20251113162032.394804-4-marco.crivellari@suse.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: cfg80211: use a C99 initializer in wiphy_register</title>
<updated>2025-11-11T10:04:38+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2025-11-10T12:03:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=706edca67984faa3d83e397334fa5ec4190f63ba'/>
<id>urn:sha1:706edca67984faa3d83e397334fa5ec4190f63ba</id>
<content type='text'>
struct regulatory request was not fully initialized. While this is not
really a big deal because nl80211_send_reg_change_event doesn't look at
the other fields, it still makes sense to zero all the other fields as
Coverity suggests.

Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Reviewed-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20251110140230.f8d4fcb1328b.I87170b1caef04356809838e684c9499f5806e624@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net</title>
<updated>2025-11-06T17:27:40+00:00</updated>
<author>
<name>Jakub Kicinski</name>
<email>kuba@kernel.org</email>
</author>
<published>2025-11-06T17:25:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1ec9871fbb80ba7db84f868f6aa40d38bc43f0e0'/>
<id>urn:sha1:1ec9871fbb80ba7db84f868f6aa40d38bc43f0e0</id>
<content type='text'>
Cross-merge networking fixes after downstream PR (net-6.18-rc5).

Conflicts:

drivers/net/wireless/ath/ath12k/mac.c
  9222582ec524 ("Revert "wifi: ath12k: Fix missing station power save configuration"")
  6917e268c433 ("wifi: ath12k: Defer vdev bring-up until CSA finalize to avoid stale beacon")
https://lore.kernel.org/11cece9f7e36c12efd732baa5718239b1bf8c950.camel@sipsolutions.net

Adjacent changes:

drivers/net/ethernet/intel/Kconfig
  b1d16f7c0063 ("libie: depend on DEBUG_FS when building LIBIE_FWLOG")
  93f53db9f9dc ("ice: switch to Page Pool")

Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
</content>
</entry>
<entry>
<title>wifi: cfg80211: add an hrtimer based delayed work item</title>
<updated>2025-10-28T13:56:30+00:00</updated>
<author>
<name>Benjamin Berg</name>
<email>benjamin.berg@intel.com</email>
</author>
<published>2025-10-28T10:58:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7ceba45a6658ce637da334cd0ebf27f4ede6c0fe'/>
<id>urn:sha1:7ceba45a6658ce637da334cd0ebf27f4ede6c0fe</id>
<content type='text'>
The normal timer mechanism assume that timeout further in the future
need a lower accuracy. As an example, the granularity for a timer
scheduled 4096 ms in the future on a 1000 Hz system is already 512 ms.
This granularity is perfectly sufficient for e.g. timeouts, but there
are other types of events that will happen at a future point in time and
require a higher accuracy.

Add a new wiphy_hrtimer_work type that uses an hrtimer internally. The
API is almost identical to the existing wiphy_delayed_work and it can be
used as a drop-in replacement after minor adjustments. The work will be
scheduled relative to the current time with a slack of 1 millisecond.

CC: stable@vger.kernel.org # 6.4+
Signed-off-by: Benjamin Berg &lt;benjamin.berg@intel.com&gt;
Reviewed-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Link: https://patch.msgid.link/20251028125710.7f13a2adc5eb.I01b5af0363869864b0580d9c2a1770bafab69566@changeid
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: cfg80211: Add debugfs support for multi-radio wiphy</title>
<updated>2025-10-27T08:18:41+00:00</updated>
<author>
<name>Roopni Devanathan</name>
<email>quic_rdevanat@quicinc.com</email>
</author>
<published>2025-10-24T04:46:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=7cc986c04a9b07d91684f7e326fa5b960215bc97'/>
<id>urn:sha1:7cc986c04a9b07d91684f7e326fa5b960215bc97</id>
<content type='text'>
In multi-radio wiphy architecture, where a single wiphy can have
multiple radios tied to it, radio specific configuration parameters
and global wiphy parameters are maintained for the entire physical
device and common to all radios. But, each radio in a wiphy can have
different values for each radio configuration parameter, like RTS
threshold. With the current debugfs directory structure, the values
of global wiphy configuration parameters can be viewed, but, values
of individual radio configuration parameters cannot be viewed, as
radio specific configuration parameters are not maintained, separately.

To address this, in addition to maintaining global wiphy configuration
parameters common to all radios, create separate debugfs directories
for each radio in a wiphy to maintain parameters corresponding to that
radio in this directory.

In implementation, maintain a dentry structure in wiphy_radio_cfg, a
structure  containing radio configurations of a wiphy. This struct is
maintained to denote per-radio configurations of a wiphy. Create
separate directories representing each radio within phy#X directory in
debugfs during wiphy registration.

Sample directory structure with this change:
ls /sys/kernel/debug/ieee80211/phy0/radio
radio0/ radio1/ radio2/

Signed-off-by: Roopni Devanathan &lt;quic_rdevanat@quicinc.com&gt;
Link: https://patch.msgid.link/20251024044649.483557-2-quic_rdevanat@quicinc.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
<entry>
<title>wifi: nl80211: allow drivers to support subset of NL80211_CMD_SET_BSS</title>
<updated>2025-09-04T09:19:02+00:00</updated>
<author>
<name>Arend van Spriel</name>
<email>arend.vanspriel@broadcom.com</email>
</author>
<published>2025-08-17T19:04:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=24185534915b5d926ded098336f47bdcca333aec'/>
<id>urn:sha1:24185534915b5d926ded098336f47bdcca333aec</id>
<content type='text'>
The so-called fullmac devices rely on firmware functionality and/or API to
change BSS parameters. Today there are limited drivers supporting the
nl80211 primitive, but they only handle a subset of the bss parameters
passed if any. The mac80211 driver does handle all parameters and stores
their configured values. Some of the BSS parameters were already conditional
by wiphy-&gt;features. For these the wiphy-&gt;bss_param_support and wiphy-&gt;features
fields are silently aligned in wiphy_register(). Maybe better to issue a warning
instead when they are misaligned.

Signed-off-by: Arend van Spriel &lt;arend.vanspriel@broadcom.com&gt;
Link: https://patch.msgid.link/20250817190435.1495094-2-arend.vanspriel@broadcom.com
Signed-off-by: Johannes Berg &lt;johannes.berg@intel.com&gt;
</content>
</entry>
</feed>
