Changes in wext-core.c

b619c7ac - net: remove get_task_comm() and print task comm directly

Thu, 19 Dec 2024 02:34:50 +0000

net: remove get_task_comm() and print task comm directlySince task->comm is guaranteed to be NUL-terminated, we can print itdirectly without the need to copy it into a separate buffer. Thissimplifies the code and avoids unnecessary operations.Link: https://lkml.kernel.org/r/20241219023452.69907-4-laoar.shao@gmail.comSigned-off-by: Yafang Shao Cc: Johannes Berg Cc: "André Almeida" Cc: Andy Shevchenko Cc: Borislav Petkov (AMD) Cc: Danilo Krummrich Cc: Darren Hart Cc: Dave Hansen Cc: David Airlie Cc: Davidlohr Bueso Cc: Greg Kroah-Hartman Cc: "H. Peter Anvin" Cc: Ingo Molnar Cc: James Morris Cc: Jani Nikula Cc: Jiri Slaby Cc: Joonas Lahtinen Cc: Kalle Valo Cc: Karol Herbst Cc: Kees Cook Cc: Linus Torvalds Cc: Lyude Paul Cc: Oded Gabbay Cc: Paul Moore Cc: Peter Zijlstra Cc: Petr Mladek Cc: Rodrigo Vivi Cc: "Serge E. Hallyn" Cc: Simona Vetter Cc: Thomas Gleixner Cc: Tvrtko Ursulin Cc: Vineet Gupta Signed-off-by: Andrew Morton List of files: /linux-6.15/net/wireless/wext-core.c

db034888 - Revert "wifi: cfg80211: unexport wireless_nlevent_flush()"

Wed, 09 Oct 2024 06:33:05 +0000

Revert "wifi: cfg80211: unexport wireless_nlevent_flush()"Revert this, I neglected to take into account the fact thatcfg80211 itself can be a module, but wext is always builtin.Fixes: aee809aaa2d1 ("wifi: cfg80211: unexport wireless_nlevent_flush()")Signed-off-by: Johannes Berg List of files: /linux-6.15/net/wireless/wext-core.c

aee809aa - wifi: cfg80211: unexport wireless_nlevent_flush()

Mon, 07 Oct 2024 19:47:16 +0000

wifi: cfg80211: unexport wireless_nlevent_flush()This no longer needs to be exported, so don't export it.Link: https://patch.msgid.link/20241007214715.3dd736dc3ac0.I1388536e99c37f28a007dd753c473ad21513d9a9@changeidSigned-off-by: Johannes Berg List of files: /linux-6.15/net/wireless/wext-core.c

4b482281 - wifi: mac80211, cfg80211: miscellaneous spelling fixes

Fri, 13 Sep 2024 08:49:19 +0000

wifi: mac80211, cfg80211: miscellaneous spelling fixesCorrect spelling here and there as suggested by codespell.Signed-off-by: Dmitry Antipov Link: https://patch.msgid.link/20240913084919.118862-1-dmantipov@yandex.ruSigned-off-by: Johannes Berg List of files: /linux-6.15/net/wireless/wext-core.c

be23b2d7 - wifi: cfg80211: add a flag to disable wireless extensions

Thu, 14 Mar 2024 10:09:51 +0000

wifi: cfg80211: add a flag to disable wireless extensionsWireless extensions are already disabled if MLO is enabled,given that we cannot support MLO there with all the hard-coded assumptions about BSSID etc.However, the WiFi7 ecosystem is still stabilizing, and somedevices may need MLO disabled while that happens. In thatcase, we might end up with a device that supports wext (butnot MLO) in one kernel, and then breaks wext in the future(by enabling MLO), which is not desirable.Add a flag to let such drivers/devices disable wext even ifMLO isn't yet enabled.Cc: stable@vger.kernel.orgLink: https://msgid.link/20240314110951.b50f1dc4ec21.I656ddd8178eedb49dc5c6c0e70f8ce5807afb54f@changeidSigned-off-by: Johannes Berg List of files: /linux-6.15/net/wireless/wext-core.c

71e7552c - wifi: wext-core: Fix -Wstringop-overflow warning in ioctl_standard_iw_point()

Thu, 15 Jun 2023 18:04:07 +0000

wifi: wext-core: Fix -Wstringop-overflow warning in ioctl_standard_iw_point()-Wstringop-overflow is legitimately warning us about extra_sizepontentially being zero at some point, hence potenially endingup _allocating_ zero bytes of memory for extra pointer and thentrying to access such object in a call to copy_from_user().Fix this by adding a sanity check to ensure we never end uptrying to allocate zero bytes of data for extra pointer, beforecontinue executing the rest of the code in the function.Address the following -Wstringop-overflow warning seen when builtm68k architecture with allyesconfig configuration: from net/wireless/wext-core.c:11:In function '_copy_from_user', inlined from 'copy_from_user' at include/linux/uaccess.h:183:7, inlined from 'ioctl_standard_iw_point' at net/wireless/wext-core.c:825:7:arch/m68k/include/asm/string.h:48:25: warning: '__builtin_memset' writing 1 or more bytes into a region of size 0 overflows the destination [-Wstringop-overflow=] 48 | #define memset(d, c, n) __builtin_memset(d, c, n) | ^~~~~~~~~~~~~~~~~~~~~~~~~include/linux/uaccess.h:153:17: note: in expansion of macro 'memset' 153 | memset(to + (n - res), 0, res); | ^~~~~~In function 'kmalloc', inlined from 'kzalloc' at include/linux/slab.h:694:9, inlined from 'ioctl_standard_iw_point' at net/wireless/wext-core.c:819:10:include/linux/slab.h:577:16: note: at offset 1 into destination object of size 0 allocated by '__kmalloc' 577 | return __kmalloc(size, flags); | ^~~~~~~~~~~~~~~~~~~~~~This help with the ongoing efforts to globally enable-Wstringop-overflow.Link: https://github.com/KSPP/linux/issues/315Signed-off-by: Gustavo A. R. Silva Reviewed-by: Simon Horman Link: https://lore.kernel.org/r/ZItSlzvIpjdjNfd8@workSigned-off-by: Johannes Berg List of files: /linux-6.15/net/wireless/wext-core.c

52fd9063 - wifi: wext: warn about usage only once

Fri, 24 Feb 2023 12:59:34 +0000

wifi: wext: warn about usage only onceWarn only once since the ratelimit parameters are stillallowing too many messages to happen. This will no longertell you all the different processes, but still gives aheads-up of sorts.Also modify the message to note that wext stops workingfor future Wi-Fi 7 hardware, this is already implementedin commit 4ca69027691a ("wifi: wireless: deny wirelessextensions on MLO-capable devices") and is maybe of morerelevance to users than the fact that we'd like to havewireless extensions deprecated.The issue with Wi-Fi 7 is that you can now have multipleconnections to the same AP, so a whole bunch of thingsnow become per link rather than per netdev, which can'treally be handled in wireless extensions.Signed-off-by: Johannes Berg Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230224135933.94104aeda1a0.Ie771c6a66d7d6c3cf67da5f3b0c66cea66fd514c@changeid List of files: /linux-6.15/net/wireless/wext-core.c

4ca69027 - wifi: wireless: deny wireless extensions on MLO-capable devices

Wed, 18 Jan 2023 09:51:53 +0000

wifi: wireless: deny wireless extensions on MLO-capable devicesThese are WiFi 7 devices that will be introduced into the marketin 2023, with new drivers. Wireless extensions haven't been inreal development since 2006. Since wireless has evolved a lot,and continues to evolve significantly with Multi-Link Operation,there's really no good way to still support wireless extensionsfor devices that do MLO.Stop supporting wireless extensions for new devices. We don'tconsider this a regression since no such devices (apart fromhwsim) exist yet.Signed-off-by: Johannes Berg Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230118105152.45f85078a1e0.Ib9eabc2ec5bf6b0244e4d973e93baaa3d8c91bd8@changeid List of files: /linux-6.15/net/wireless/wext-core.c

dc09766c - wifi: wireless: warn on most wireless extension usage

Wed, 18 Jan 2023 09:51:52 +0000

wifi: wireless: warn on most wireless extension usageWith WiFi 7 (802.11ax, MLO/EHT) around the corner, we're going toremove support for wireless extensions with new devices since MLO(multi-link operation) cannot be properly indicated using them.Add a warning to indicate which processes are still using wirelessextensions, if being used with modern (i.e. cfg80211) drivers.Signed-off-by: Johannes Berg Signed-off-by: Kalle Valo Link: https://lore.kernel.org/r/20230118105152.a7158a929a6f.Ifcf30eeeb8fc7019e4dcf2782b04515254d165e1@changeid List of files: /linux-6.15/net/wireless/wext-core.c

e3e6e1d1 - wifi: wext: use flex array destination for memcpy()

Mon, 26 Sep 2022 23:34:59 +0000

wifi: wext: use flex array destination for memcpy()Syzkaller reports buffer overflow false positive as follows:------------[ cut here ]------------memcpy: detected field-spanning write (size 8) of single field "&compat_event->pointer" at net/wireless/wext-core.c:623 (size 4)WARNING: CPU: 0 PID: 3607 at net/wireless/wext-core.c:623 wireless_send_event+0xab5/0xca0 net/wireless/wext-core.c:623Modules linked in:CPU: 1 PID: 3607 Comm: syz-executor659 Not tainted 6.0.0-rc6-next-20220921-syzkaller #0[...]Call Trace: ioctl_standard_call+0x155/0x1f0 net/wireless/wext-core.c:1022 wireless_process_ioctl+0xc8/0x4c0 net/wireless/wext-core.c:955 wext_ioctl_dispatch net/wireless/wext-core.c:988 [inline] wext_ioctl_dispatch net/wireless/wext-core.c:976 [inline] wext_handle_ioctl+0x26b/0x280 net/wireless/wext-core.c:1049 sock_ioctl+0x285/0x640 net/socket.c:1220 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd [...] Wireless events will be sent on the appropriate channels inwireless_send_event(). Different wireless events may have differentpayload structure and size, so kernel uses **len** and **cmd** fieldin struct __compat_iw_event as wireless event common LCP part, uses**pointer** as a label to mark the position of remaining different part.Yet the problem is that, **pointer** is a compat_caddr_t type, which maybe smaller than the relative structure at the same position. So duringwireless_send_event() tries to parse the wireless events payload, it maytrigger the memcpy() run-time destination buffer bounds checking when therelative structure's data is copied to the position marked by **pointer**.This patch solves it by introducing flexible-array field **ptr_bytes**,to mark the position of the wireless events remaining part next toLCP part. What's more, this patch also adds **ptr_len** variable inwireless_send_event() to improve its maintainability.Reported-and-tested-by: syzbot+473754e5af963cf014cf@syzkaller.appspotmail.comLink: https://lore.kernel.org/all/00000000000070db2005e95a5984@google.com/Suggested-by: Kees Cook Reviewed-by: Kees Cook Signed-off-by: Hawkins Jiawei Signed-off-by: Johannes Berg List of files: /linux-6.15/net/wireless/wext-core.c

51225651 - wext: fix NULL-ptr-dereference with cfg80211's lack of commit()

Thu, 21 Jan 2021 16:16:22 +0000

wext: fix NULL-ptr-dereference with cfg80211's lack of commit()Since cfg80211 doesn't implement commit, we never really cared aboutthat code there (and it's configured out w/o CONFIG_WIRELESS_EXT).After all, since it has no commit, it shouldn't return -EIWCOMMIT toindicate commit is needed.However, EIWCOMMIT is actually an alias for EINPROGRESS, which _can_happen if e.g. we try to change the frequency but we're already inthe process of connecting to some network, and drivers could returnthat value (or even cfg80211 itself might).This then causes us to crash because dev->wireless_handlers is NULLbut we try to check dev->wireless_handlers->standard[0].Fix this by also checking dev->wireless_handlers. Also simplify thecode a little bit.Cc: stable@vger.kernel.orgReported-by: syzbot+444248c79e117bc99f46@syzkaller.appspotmail.comReported-by: syzbot+8b2a88a09653d4084179@syzkaller.appspotmail.comLink: https://lore.kernel.org/r/20210121171621.2076e4a37d5a.I5d9c72220fe7bb133fb718751da0180a57ecba4e@changeidSigned-off-by: Johannes Berg List of files: /linux-6.15/net/wireless/wext-core.c

e1611965 - wireless: wext: avoid gcc -O3 warning

Tue, 07 Jan 2020 20:07:35 +0000

wireless: wext: avoid gcc -O3 warningAfter the introduction of CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3,the wext code produces a bogus warning:In function 'iw_handler_get_iwstats', inlined from 'ioctl_standard_call' at net/wireless/wext-core.c:1015:9, inlined from 'wireless_process_ioctl' at net/wireless/wext-core.c:935:10, inlined from 'wext_ioctl_dispatch.part.8' at net/wireless/wext-core.c:986:8, inlined from 'wext_handle_ioctl':net/wireless/wext-core.c:671:3: error: argument 1 null where non-null expected [-Werror=nonnull] memcpy(extra, stats, sizeof(struct iw_statistics)); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~In file included from arch/x86/include/asm/string.h:5,net/wireless/wext-core.c: In function 'wext_handle_ioctl':arch/x86/include/asm/string_64.h:14:14: note: in a call to function 'memcpy' declared hereThe problem is that ioctl_standard_call() sometimes calls the handlerwith a NULL argument that would cause a problem for iw_handler_get_iwstats.However, iw_handler_get_iwstats never actually gets called that way.Marking that function as noinline avoids the warning and leadsto slightly smaller object code as well.Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20200107200741.3588770-1-arnd@arndb.deSigned-off-by: Johannes Berg List of files: /linux-6.15/net/wireless/wext-core.c

10256deb - net: Don't take rtnl_lock() in wireless_nlevent_flush()

Thu, 29 Mar 2018 16:20:44 +0000

net: Don't take rtnl_lock() in wireless_nlevent_flush()This function iterates over net_namespace_list and flushesthe queue for every of them. What does this rtnl_lock()protects?! Since we may add skbs to net::wext_nleventswithout rtnl_lock(), it does not protects us about queuers.It guarantees, two threads can't flush the queue in parallel,that can change the order, but since skb can be queuedin any order, it doesn't matter, how many threads do thisin parallel. In case of several threads, this will be evenfaster.So, we can remove rtnl_lock() here, as it was used foriteration over net_namespace_list only.Signed-off-by: Kirill Tkhai Signed-off-by: David S. Miller List of files: /linux-6.15/net/wireless/wext-core.c

f0b07bb1 - net: Introduce net_rwsem to protect net_namespace_list

Thu, 29 Mar 2018 16:20:32 +0000

net: Introduce net_rwsem to protect net_namespace_listrtnl_lock() is used everywhere, and contention is very high.When someone wants to iterate over alive net namespaces,he/she has no a possibility to do that without exclusive lock.But the exclusive rtnl_lock() in such places is overkill,and it just increases the contention. Yes, there is alreadyfor_each_net_rcu() in kernel, but it requires rcu_read_lock(),and this can't be sleepable. Also, sometimes it may be needreally prevent net_namespace_list growth, so for_each_net_rcu()is not fit there.This patch introduces new rw_semaphore, which will be usedinstead of rtnl_mutex to protect net_namespace_list. It issleepable and allows not-exclusive iterations over netnamespaces list. It allows to stop using rtnl_lock()in several places (what is made in next patches) and makesless the time, we keep rtnl_mutex. Here we just add new lock,while the explanation of we can remove rtnl_lock() there arein next patches.Fine grained locks generally are better, then one big lock,so let's do that with net_namespace_list, while the situationallows that.Signed-off-by: Kirill Tkhai Signed-off-by: David S. Miller List of files: /linux-6.15/net/wireless/wext-core.c

2f635cee - net: Drop pernet_operations::async

Tue, 27 Mar 2018 15:02:13 +0000

net: Drop pernet_operations::asyncSynchronous pernet_operations are not allowed anymore.All are asynchronous. So, drop the structure member.Signed-off-by: Kirill Tkhai Signed-off-by: David S. Miller List of files: /linux-6.15/net/wireless/wext-core.c

6c0075d0 - net: Convert wext_pernet_ops

Tue, 13 Feb 2018 09:29:33 +0000

net: Convert wext_pernet_opsThese pernet_operations initialize and purge net::wext_nleventsqueue, and are not touched by foreign pernet_operations.Mark them async.Signed-off-by: Kirill Tkhai Acked-by: Andrei Vagin Signed-off-by: David S. Miller List of files: /linux-6.15/net/wireless/wext-core.c

b1b0c245 - lift handling of SIOCIW... out of dev_ioctl()

Mon, 02 Oct 2017 00:13:08 +0000

lift handling of SIOCIW... out of dev_ioctl()Signed-off-by: Al Viro List of files: /linux-6.15/net/wireless/wext-core.c

68dd02d1 - dev_ioctl: copy only the smaller struct iwreq for wext

Wed, 14 Jun 2017 07:28:11 +0000

dev_ioctl: copy only the smaller struct iwreq for wextUnfortunately, struct iwreq isn't a proper subset of struct ifreq,but is still handled by the same code path. Robert reported thatthen applications may (randomly) fault if the struct iwreq theypass happens to land within 8 bytes of the end of a mapping (thestruct is only 32 bytes, vs. struct ifreq's 40 bytes).To fix this, pull out the code handling wireless extension ioctlsand copy only the smaller structure in this case.This bug goes back a long time, I tracked that it was introducedinto mainline in 2.1.15, over 20 years ago!This fixes https://bugzilla.kernel.org/show_bug.cgi?id=195869Reported-by: Robert O'Callahan Signed-off-by: Johannes Berg List of files: /linux-6.15/net/wireless/wext-core.c

4f39a1f5 - wireless: wext: use struct iwreq earlier in the call chain

Wed, 14 Jun 2017 07:21:58 +0000

wireless: wext: use struct iwreq earlier in the call chainTo make it clear that we never use struct ifreq, cast from itdirectly in the wext entrypoint and use struct iwreq from thereon. The next patch will remove the cast again and pass thecorrect struct from the beginning.Signed-off-by: Johannes Berg List of files: /linux-6.15/net/wireless/wext-core.c

8bfb3676 - wireless: wext: remove ndo_do_ioctl fallback

Wed, 14 Jun 2017 07:17:38 +0000

wireless: wext: remove ndo_do_ioctl fallbackThere are no longer any drivers (in the tree proper, I didn'tcheck all the staging drivers) that take WEXT ioctls throughthis API, the only remaining ones that even have ndo_do_ioctlare using it only for private ioctls.Therefore, we can remove this call.Signed-off-by: Johannes Berg List of files: /linux-6.15/net/wireless/wext-core.c