- 18 Mar, 2021 5 commits
-
-
Rakesh Babu authored
With the existing rsrc_alloc's format, there is misalignment for the pcifunc entries whose VF's index is a double digit. This patch fixes this. pcifunc NPA NIX0 NIX1 SSO GROUP SSOWS TIM CPT0 CPT1 REE0 REE1 PF0:VF0 8 5 PF0:VF1 9 3 PF0:VF10 18 10 PF0:VF11 19 8 PF0:VF12 20 11 PF0:VF13 21 9 PF0:VF14 22 12 PF0:VF15 23 10 PF1 0 0 Fixes: 23205e6d ("octeontx2-af: Dump current resource provisioning status") Signed-off-by:Rakesh Babu <rsaladi2@marvell.com> Signed-off-by:
Hariprasad Kelam <hkelam@marvell.com> Signed-off-by:
Sunil Kovvuri Goutham <sgoutham@marvell.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Subbaraya Sundeep authored
In the ETHTOOL_GRXCLSRLALL ioctl ethtool uses below structure to read number of rules from the driver. struct ethtool_rxnfc { __u32 cmd; __u32 flow_type; __u64 data; struct ethtool_rx_flow_spec fs; union { __u32 rule_cnt; __u32 rss_context; }; __u32 rule_locs[0]; }; Driver must not modify rule_cnt member. But currently driver modifies it by modifying rss_context. Hence fix it by using a local variable. Fixes: 81a43620 ("octeontx2-pf: Add RSS multi group support") Signed-off-by:Subbaraya Sundeep <sbhatta@marvell.com> Signed-off-by:
-
Mian Yousaf Kaukab authored
Since commit 8e850f25 ("net: socionext: Stop PHY before resetting netsec") netsec_netdev_init() power downs phy before resetting the controller. However, the state is not restored once the reset is complete. As a result it is not possible to bring up network on a platform with Broadcom BCM5482 phy. Fix the issue by restoring phy power state after controller reset is complete. Fixes: 8e850f25 ("net: socionext: Stop PHY before resetting netsec") Cc: stable@vger.kernel.org Signed-off-by:
Mian Yousaf Kaukab <ykaukab@suse.de> Signed-off-by:
-
Jakub Kicinski authored
This reverts commit 6af1799a. Commit 6af1799a ("ipv6: drop incoming packets having a v4mapped source address") introduced an input check against v4mapped addresses. Use of such addresses on the wire is indeed questionable and not allowed on public Internet. As the commit pointed out https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02 lists potential issues. Unfortunately there are applications which use v4mapped addresses, and breaking them is a clear regression. For example v4mapped addresses (or any semi-valid addresses, really) may be used for uni-direction event streams or packet export. Since the issue which sparked the addition of the check was with TCP and request_socks in particular push the check down to TCPv6 and DCCP. This restores the ability to receive UDPv6 packets with v4mapped address as the source. Keep using the IPSTATS_MIB_INHDRERRORS statistic to minimize the user-visible changes. Fixes: 6af1799a ("ipv6: drop incoming packets having a v4mapped source address") Reported-by:
Sunyi Shao <sunyishao@fb.com> Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Acked-by:
Mat Martineau <mathew.j.martineau@linux.intel.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Signed-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfDavid S. Miller authored
Daniel Borkmann says: ==================== pull-request: bpf 2021-03-18 The following pull-request contains BPF updates for your *net* tree. We've added 10 non-merge commits during the last 4 day(s) which contain a total of 14 files changed, 336 insertions(+), 94 deletions(-). The main changes are: 1) Fix fexit/fmod_ret trampoline for sleepable programs, and also fix a ftrace splat in modify_ftrace_direct() on address change, from Alexei Starovoitov. 2) Fix two oob speculation possibilities that allows unprivileged to leak mem via side-channel, from Piotr Krysiuk and Daniel Borkmann. 3) Fix libbpf's netlink handling wrt SOCK_CLOEXEC, from Kumar Kartikeya Dwivedi. 4) Fix libbpf's error handling on failure in getting section names, from Namhyung Kim. 5) Fix tunnel collect_md BPF selftest wrt Geneve option handling, from Hangbin Liu. ==================== Signed-off-by:
-
- 17 Mar, 2021 12 commits
-
-
Kumar Kartikeya Dwivedi authored
Otherwise, there exists a small window between the opening and closing of the socket fd where it may leak into processes launched by some other thread. Fixes: 949abbe8 ("libbpf: add function to setup XDP") Signed-off-by:
Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Toke Høiland-Jørgensen <toke@redhat.com> Link: https://lore.kernel.org/bpf/20210317115857.6536-1-memxor@gmail.com
-
Namhyung Kim authored
When it failed to get section names, it should call into bpf_object__elf_finish() like others. Fixes: 88a82120 ("libbpf: Factor out common ELF operations and improve logging") Signed-off-by:
Namhyung Kim <namhyung@kernel.org> Signed-off-by:
-
Alexei Starovoitov authored
The fexit/fmod_ret programs can be attached to kernel functions that can sleep. The synchronize_rcu_tasks() will not wait for such tasks to complete. In such case the trampoline image will be freed and when the task wakes up the return IP will point to freed memory causing the crash. Solve this by adding percpu_ref_get/put for the duration of trampoline and separate trampoline vs its image life times. The "half page" optimization has to be removed, since first_half->second_half->first_half transition cannot be guaranteed to complete in deterministic time. Every trampoline update becomes a new image. The image with fmod_ret or fexit progs will be freed via percpu_ref_kill and call_rcu_tasks. Together they will wait for the original function and trampoline asm to complete. The trampoline is patched from nop to jmp to skip fexit progs. They are freed independently from the trampoline. The image with fentry progs only will be freed via call_rcu_tasks_trace+call_rcu_tasks which will wait for both sleepable and non-sleepable progs to complete. Fixes: fec56f58 ("bpf: Introduce BPF trampoline") Reported-by:
Andrii Nakryiko <andrii@kernel.org> Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
-
Wei Wang authored
Currently, napi_thread_wait() checks for NAPI_STATE_SCHED bit to determine if the kthread owns this napi and could call napi->poll() on it. However, if socket busy poll is enabled, it is possible that the busy poll thread grabs this SCHED bit (after the previous napi->poll() invokes napi_complete_done() and clears SCHED bit) and tries to poll on the same napi. napi_disable() could grab the SCHED bit as well. This patch tries to fix this race by adding a new bit NAPI_STATE_SCHED_THREADED in napi->state. This bit gets set in ____napi_schedule() if the threaded mode is enabled, and gets cleared in napi_complete_done(), and we only poll the napi in kthread if this bit is set. This helps distinguish the ownership of the napi between kthread and other scenarios and fixes the race issue. Fixes: 29863d41 ("net: implement threaded-able napi poll loop support") Reported-by:
Martin Zaharinov <micron10@gmail.com> Suggested-by:
Wei Wang <weiwan@google.com> Cc: Alexander Duyck <alexanderduyck@fb.com> Cc: Eric Dumazet <edumazet@google.com> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Hannes Frederic Sowa <hannes@stressinduktion.org> Signed-off-by:
-
Piotr Krysiuk authored
Fix up test_verifier error messages for the case where the original error message changed, or for the case where pointer alu errors differ between privileged and unprivileged tests. Also, add alternative tests for keeping coverage of the original verifier rejection error message (fp alu), and newly reject map_ptr += rX where rX == 0 given we now forbid alu on these types for unprivileged. All test_verifier cases pass after the change. The test case fixups were kept separate to ease backporting of core changes. Signed-off-by:
Piotr Krysiuk <piotras@gmail.com> Co-developed-by:
-
Piotr Krysiuk authored
Given we know the max possible value of ptr_limit at the time of retrieving the latter, add basic assertions, so that the verifier can bail out if anything looks odd and reject the program. Nothing triggered this so far, but it also does not hurt to have these. Signed-off-by:
-
David S. Miller authored
Merge tag 'mac80211-for-net-2021-03-17' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211 Johannes Berg says: ==================== First round of fixes for 5.12-rc: * HE (802.11ax) elements can be extended, handle that * fix locking in network namespace changes that was broken due to the RTNL-redux work * various other small fixes ==================== Signed-off-by:
-
wenxu authored
The ct_state validate should not only check the mask bit and also check mask_bit & key_bit.. For the +new+est case example, The 'new' and 'est' bits should be set in both state_mask and state flags. Or the -new-est case also will be reject by kernel. When Openvswitch with two flows ct_state=+trk+new,action=commit,forward ct_state=+trk+est,action=forward A packet go through the kernel and the contrack state is invalid, The ct_state will be +trk-inv. Upcall to the ovs-vswitchd, the finally dp action will be drop with -new-est+trk. Fixes: 1bcc51ac ("net/sched: cls_flower: Reject invalid ct_state flags rules") Fixes: 3aed8b63 ("net/sched: cls_flower: validate ct_state for invalid and reply flags") Signed-off-by:
wenxu <wenxu@ucloud.cn> Reviewed-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
-
Shannon Nelson authored
We were linearizing non-TSO skbs that had too many frags, but we weren't checking number of frags on TSO skbs. This could lead to a bad page reference when we received a TSO skb with more frags than the Tx descriptor could support. v2: use gso_segs rather than yet another division don't rework the check on the nr_frags Fixes: 0f3154e6 ("ionic: Add Tx and Rx handling") Signed-off-by:Shannon Nelson <snelson@pensando.io> Signed-off-by:
-
Piotr Krysiuk authored
Instead of having the mov32 with aux->alu_limit - 1 immediate, move this operation to retrieve_ptr_limit() instead to simplify the logic and to allow for subsequent sanity boundary checks inside retrieve_ptr_limit(). This avoids in future that at the time of the verifier masking rewrite we'd run into an underflow which would not sign extend due to the nature of mov32 instruction. Signed-off-by:
-
Piotr Krysiuk authored
retrieve_ptr_limit() computes the ptr_limit for registers with stack and map_value type. ptr_limit is the size of the memory area that is still valid / in-bounds from the point of the current position and direction of the operation (add / sub). This size will later be used for masking the operation such that attempting out-of-bounds access in the speculative domain is redirected to remain within the bounds of the current map value. When masking to the right the size is correct, however, when masking to the left, the size is off-by-one which would lead to an incorrect mask and thus incorrect arithmetic operation in the non-speculative domain. Piotr found that if the resulting alu_limit value is zero, then the BPF_MOV32_IMM() from the fixup_bpf_calls() rewrite will end up loading 0xffffffff into AX instead of sign-extending to the full 64 bit range, and as a result, this allows abuse for executing speculatively out-of- bounds loads against 4GB window of address space and thus extracting the contents of kernel memory via side-channel. Fixes: 979d63d5 ("bpf: prevent out of bounds speculation on pointer arithmetic") Signed-off-by:
-
Piotr Krysiuk authored
The purpose of this patch is to streamline error propagation and in particular to propagate retrieve_ptr_limit() errors for pointer types that are not defining a ptr_limit such that register-based alu ops against these types can be rejected. The main rationale is that a gap has been identified by Piotr in the existing protection against speculatively out-of-bounds loads, for example, in case of ctx pointers, unprivileged programs can still perform pointer arithmetic. This can be abused to execute speculatively out-of-bounds loads without restrictions and thus extract contents of kernel memory. Fix this by rejecting unprivileged programs that attempt any pointer arithmetic on unprotected pointer types. The two affected ones are pointer to ctx as well as pointer to map. Field access to a modified ctx' pointer is rejected at a later point in time in the verifier, and 7c696732 ("bpf: Permit map_ptr arithmetic with opcode add and offset 0") only relevant for root-only use cases. Risk of unprivileged program breakage is considered very low. Fixes: 7c696732 ("bpf: Permit map_ptr arithmetic with opcode add and offset 0") Fixes: b2157399 ("bpf: prevent out-of-bounds speculation") Signed-off-by:
-
- 16 Mar, 2021 23 commits
-
-
Alexei Starovoitov authored
The following sequence of commands: register_ftrace_direct(ip, addr1); modify_ftrace_direct(ip, addr1, addr2); unregister_ftrace_direct(ip, addr2); will cause the kernel to warn: [ 30.179191] WARNING: CPU: 2 PID: 1961 at kernel/trace/ftrace.c:5223 unregister_ftrace_direct+0x130/0x150 [ 30.180556] CPU: 2 PID: 1961 Comm: test_progs W O 5.12.0-rc2-00378-g86bc10a0a711-dirty #3246 [ 30.182453] RIP: 0010:unregister_ftrace_direct+0x130/0x150 When modify_ftrace_direct() changes the addr from old to new it should update the addr stored in ftrace_direct_funcs. Otherwise the final unregister_ftrace_direct() won't find the address and will cause the splat. Fixes: 0567d680 ("ftrace: Add modify_ftrace_direct()") Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Link: https://lore.kernel.org/bpf/20210316195815.34714-1-alexei.starovoitov@gmail.com
-
Geoff Levand authored
Change the Spidernet network driver from supported to maintained, add the linuxppc-dev ML, and add myself as a 'maintainer'. Cc: Ishizaki Kou <kou.ishizaki@toshiba.co.jp> Signed-off-by:
Geoff Levand <geoff@infradead.org> Signed-off-by:
-
David S. Miller authored
Simon Horman says: ==================== Fixes for nfp pre_tunnel code Louis Peens says: The following set of patches fixes up a few bugs in the pre_tun decap code paths which has been hiding for a while. ==================== Signed-off-by: -
Louis Peens authored
pre_tun_rule flows does not follow the usual add-flow path, instead they are used to update the pre_tun table on the firmware. This means that if the mask-id gets allocated here the firmware will never see the "NFP_FL_META_FLAG_MANAGE_MASK" flag for the specific mask id, which triggers the allocation on the firmware side. This leads to the firmware mask being corrupted and causing all sorts of strange behaviour. Fixes: f12725d9 ("nfp: flower: offload pre-tunnel rules") Signed-off-by:
Louis Peens <louis.peens@corigine.com> Signed-off-by:
Simon Horman <simon.horman@netronome.com> Signed-off-by:
-
Louis Peens authored
Differentiate between ipv4 and ipv6 flows when configuring the pre_tunnel table to prevent them trampling each other in the table. Fixes: 78346160 ("nfp: flower: update flow merge code to support IPv6 tunnels") Signed-off-by:
-
Louis Peens authored
There are some pre_tunnel flows combinations which are incorrectly being offloaded without proper support, fix these. - Matching on MPLS is not supported for pre_tun. - Match on IPv4/IPv6 layer must be present. - Destination MAC address must match pre_tun.dev MAC Fixes: 120ffd84 ("nfp: flower: verify pre-tunnel rules") Signed-off-by:
-
Geert Uytterhoeven authored
Merely enabling compile-testing should not enable additional code. To fix this, restrict the automatic enabling of BCM4908_ENET to ARCH_BCM4908. Fixes: 4feffead ("net: broadcom: bcm4908enet: add BCM4908 controller driver") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Acked-by:
Florian Fainelli <f.fainelli@gmail.com> Acked-by:
Rafał Miłecki <rafal@milecki.pl> Signed-off-by:
-
wenxu authored
When openvswitch conntrack offload with act_ct action. The first rule do conntrack in the act_ct in tc subsystem. And miss the next rule in the tc and fallback to the ovs datapath but miss set post_ct flag which will lead the ct_state_key with -trk flag. Fixes: 7baf2429 ("net/sched: cls_flower add CT_FLAGS_INVALID flag support") Signed-off-by:
-
David S. Miller authored
Merge tag 'linux-can-fixes-for-5.12-20210316' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2021-03-16 this is a pull request of 11 patches for net/master. The first patch is by Martin Willi and fixes the deletion of network name spaces with physical CAN interfaces in them. The next two patches are by me an fix the ISOTP protocol, to ensure that unused flags in classical CAN frames are properly initialized to zero. Stephane Grosjean contributes a patch for the pcan_usb_fd driver, which add MODULE_SUPPORTED_DEVICE lines for two supported devices. Angelo Dureghello's patch for the flexcan driver fixes a potential div by zero, if the bitrate is not set during driver probe. Jimmy Assarsson's patch for the kvaser_pciefd disables bus load reporting in the device, if it was previously enabled by the vendor's out of tree drier. A patch for the kvaser_usb adds support for a new device, by adding the appropriate USB product ID. Tong Zhang contributes two patches for the c_can driver. First a use-after-free in the c_can_pci driver is fixed, in the second patch the runtime PM for the c_can_pci is fixed by moving the runtime PM enable/disable from the core driver to the platform driver. The last two patches are by Torin Cooper-Bennun for the m_can driver. First a extraneous msg loss warning is removed then he fixes the RX-path, which might be blocked by errors. ==================== Signed-off-by:
-
Zenghui Yu authored
The ena.rst documentation referred to end_start_xmit() when it should refer to ena_start_xmit(). Fix the typo. Signed-off-by:
Zenghui Yu <yuzenghui@huawei.com> Acked-by:
Shay Agroskin <shayagr@amazon.com> Signed-off-by:
-
Carlos Llamas authored
Fix multiple warnings seen with gcc 10.2.1: reuseaddr_ports_exhausted.c:32:41: warning: missing braces around initializer [-Wmissing-braces] 32 | struct reuse_opts unreusable_opts[12] = { | ^ 33 | {0, 0, 0, 0}, | { } { } Fixes: 7f204a7d ("selftests: net: Add SO_REUSEADDR test to check if 4-tuples are fully utilized.") Signed-off-by:Carlos Llamas <cmllamas@google.com> Signed-off-by:
-
Jarod Wilson authored
Build currently fails with -Werror=maybe-uninitialized set: net/wireless/nl80211.c: In function '__cfg80211_wdev_from_attrs': net/wireless/nl80211.c:124:44: error: 'wdev_id' may be used uninitialized in this function [-Werror=maybe-uninitialized] Easy fix is to just initialize wdev_id to 0, since it's value doesn't otherwise matter unless have_wdev_id is true. Fixes: a05829a7 ("cfg80211: avoid holding the RTNL when calling the driver") CC: Johannes Berg <johannes@sipsolutions.net> CC: "David S. Miller" <davem@davemloft.net> CC: Jakub Kicinski <kuba@kernel.org> CC: linux-wireless@vger.kernel.org CC: netdev@vger.kernel.org Signed-off-by:
Jarod Wilson <jarod@redhat.com> Link: https://lore.kernel.org/r/20210312163651.1398207-1-jarod@redhat.comSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Karthikeyan Kathirvel authored
Even if the first channel from sband channel list is invalid or disabled mac80211 ends up choosing it as the default channel for monitor interfaces, making them not usable. Fix this by assigning the first available valid or enabled channel instead. Signed-off-by:
Karthikeyan Kathirvel <kathirve@codeaurora.org> Link: https://lore.kernel.org/r/1615440547-7661-1-git-send-email-kathirve@codeaurora.org [reword commit message, comment, code cleanups] Signed-off-by:
-
Johannes Berg authored
We have all the network interfaces marked as netns-local since the only reasonable thing to do right now is to set a whole device, including all netdevs, into a different network namespace. For this reason, we also have our own way of changing the network namespace. Unfortunately, the RTNL locking changes broke this, and it now results in many RTNL assertions. The trivial fix for those (just hold RTNL for the changes) however leads to deadlocks in the cfg80211 netdev notifier. Since we only need the wiphy, and that's still protected by the RTNL, add a new NL80211_FLAG_NO_WIPHY_MTX flag to the nl80211 ops and use it to _not_ take the wiphy mutex but only the RTNL. This way, the notifier does all the work necessary during unregistration/registration of the netdevs from the old and in the new namespace. Reported-by:
Sid Hayn <sidhayn@gmail.com> Fixes: a05829a7 ("cfg80211: avoid holding the RTNL when calling the driver") Signed-off-by:
-
Daniel Phan authored
crypto_aead_encrypt returns <0 on error, so if these calls are not checked, execution may continue with failed encrypts. It also seems that these two crypto_aead_encrypt calls are the only instances in the codebase that are not checked for errors. Signed-off-by:
Daniel Phan <daniel.phan36@gmail.com> Link: https://lore.kernel.org/r/20210309204137.823268-1-daniel.phan36@gmail.comSigned-off-by:
-
Brian Norris authored
We observed some Cisco APs sending the following HE Operation IE in associate response: ff 0a 24 f4 3f 00 01 fc ff 00 00 00 Its HE operation parameter is 0x003ff4, so the expected total length is 7 which does not match the actual length = 10. This causes association failing with "HE AP is missing HE Capability/operation." According to P802.11ax_D4 Table9-94, HE operation is extensible, and according to 802.11-2016 10.27.8, STA should discard the part beyond the maximum length and parse the truncated element. Allow HE operation element to be longer than expected to handle this case and future extensions. Fixes: e4d005b8 ("mac80211: refactor extended element parsing") Signed-off-by:
Brian Norris <briannorris@chromium.org> Signed-off-by:
Yen-lin Lai <yenlinlai@chromium.org> Link: https://lore.kernel.org/r/20210223051926.2653301-1-yenlinlai@chromium.orgSigned-off-by:
-
Johannes Berg authored
This probably came in through some refactoring and what is now a call to minstrel_ht_group_min_rate_offset(), remove the unused variable. Reported-by:
kernel test robot <lkp@intel.com> Acked-by:
Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20210219105744.f2538a80f6cf.I3d53554c158d5b896ac07ea546bceac67372ec28@changeidSigned-off-by:
-
Markus Theil authored
Clear beacon ie pointer and ie length after free in order to prevent double free. ================================================================== BUG: KASAN: double-free or invalid-free \ in ieee80211_ibss_leave+0x83/0xe0 net/mac80211/ibss.c:1876 CPU: 0 PID: 8472 Comm: syz-executor100 Not tainted 5.11.0-rc6-syzkaller #0 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 print_address_description.constprop.0.cold+0x5b/0x2c6 mm/kasan/report.c:230 kasan_report_invalid_free+0x51/0x80 mm/kasan/report.c:355 ____kasan_slab_free+0xcc/0xe0 mm/kasan/common.c:341 kasan_slab_free include/linux/kasan.h:192 [inline] __cache_free mm/slab.c:3424 [inline] kfree+0xed/0x270 mm/slab.c:3760 ieee80211_ibss_leave+0x83/0xe0 net/mac80211/ibss.c:1876 rdev_leave_ibss net/wireless/rdev-ops.h:545 [inline] __cfg80211_leave_ibss+0x19a/0x4c0 net/wireless/ibss.c:212 __cfg80211_leave+0x327/0x430 net/wireless/core.c:1172 cfg80211_leave net/wireless/core.c:1221 [inline] cfg80211_netdev_notifier_call+0x9e8/0x12c0 net/wireless/core.c:1335 notifier_call_chain+0xb5/0x200 kernel/notifier.c:83 call_netdevice_notifiers_info+0xb5/0x130 net/core/dev.c:2040 call_netdevice_notifiers_extack net/core/dev.c:2052 [inline] call_netdevice_notifiers net/core/dev.c:2066 [inline] __dev_close_many+0xee/0x2e0 net/core/dev.c:1586 __dev_close net/core/dev.c:1624 [inline] __dev_change_flags+0x2cb/0x730 net/core/dev.c:8476 dev_change_flags+0x8a/0x160 net/core/dev.c:8549 dev_ifsioc+0x210/0xa70 net/core/dev_ioctl.c:265 dev_ioctl+0x1b1/0xc40 net/core/dev_ioctl.c:511 sock_do_ioctl+0x148/0x2d0 net/socket.c:1060 sock_ioctl+0x477/0x6a0 net/socket.c:1177 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reported-by: syzbot+93976391bf299d425f44@syzkaller.appspotmail.com Signed-off-by:
Markus Theil <markus.theil@tu-ilmenau.de> Link: https://lore.kernel.org/r/20210213133653.367130-1-markus.theil@tu-ilmenau.deSigned-off-by:
-
Johannes Berg authored
Coverity reported the strange "if (~...)" condition that's always true. It suggested that ! was intended instead of ~, but upon further analysis I'm convinced that what really was intended was a comparison to 0xff/0xffff (in HT/VHT cases respectively), since this indicates that all of the rates are enabled. Change the comparison accordingly. I'm guessing this never really mattered because a reset to not having a rate mask is basically equivalent to having a mask that enables all rates. Reported-by:
Colin Ian King <colin.king@canonical.com> Fixes: 2ffbe6d3 ("mac80211: fix and optimize MCS mask handling") Fixes: b119ad6e ("mac80211: add rate mask logic for vht rates") Reviewed-by:
-
Torin Cooper-Bennun authored
For M_CAN peripherals, m_can_rx_handler() was called with quota = 1, which caused any error handling to block RX from taking place until the next time the IRQ handler is called. This had been observed to cause RX to be blocked indefinitely in some cases. This is fixed by calling m_can_rx_handler with a sensibly high quota. Fixes: f524f829 ("can: m_can: Create a m_can platform framework") Link: https://lore.kernel.org/r/20210303144350.4093750-1-torin@maxiluxsystems.comSuggested-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
Torin Cooper-Bennun <torin@maxiluxsystems.com> Signed-off-by:
-
Torin Cooper-Bennun authored
Message loss from RX FIFO 0 is already handled in m_can_handle_lost_msg(), with netdev output included. Removing this warning also improves driver performance under heavy load, where m_can_do_rx_poll() may be called many times before this interrupt is cleared, causing this message to be output many times (thanks Mariusz Madej for this report). Fixes: e0d1f481 ("can: m_can: add Bosch M_CAN controller support") Link: https://lore.kernel.org/r/20210303103151.3760532-1-torin@maxiluxsystems.comReported-by:
Mariusz Madej <mariusz.madej@xtrack.com> Signed-off-by:
-
Tong Zhang authored
Currently doing modprobe c_can_pci will make the kernel complain: Unbalanced pm_runtime_enable! this is caused by pm_runtime_enable() called before pm is initialized. This fix is similar to 227619c3, move those pm_enable/disable code to c_can_platform. Fixes: 4cdd34b2 ("can: c_can: Add runtime PM support to Bosch C_CAN/D_CAN controller") Link: http://lore.kernel.org/r/20210302025542.987600-1-ztong0001@gmail.comSigned-off-by:Tong Zhang <ztong0001@gmail.com> Tested-by:
Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by:
-
Tong Zhang authored
There is a UAF in c_can_pci_remove(). dev is released by free_c_can_dev() and is used by pci_iounmap(pdev, priv->base) later. To fix this issue, save the mmio address before releasing dev. Fixes: 5b92da04 ("c_can_pci: generic module for C_CAN/D_CAN on PCI") Link: https://lore.kernel.org/r/20210301024512.539039-1-ztong0001@gmail.comSigned-off-by:
-
