- 31 Mar, 2022 36 commits
-
-
Stéphane Graber authored
When hitting the recirculation limit, the kernel would currently log something like this: [ 58.586597] openvswitch: ovs-system: deferred action limit reached, drop recirc action Which isn't all that useful to debug as we only have the interface name to go on but can't track it down to a specific flow. With this change, we now instead get: [ 58.586597] openvswitch: ovs-system: deferred action limit reached, drop recirc action (recirc_id=0x9e) Which can now be correlated with the flow entries from OVS. Suggested-by:
Frode Nordahl <frode.nordahl@canonical.com> Signed-off-by:
Stéphane Graber <stgraber@ubuntu.com> Tested-by:
Eelco Chaudron <echaudro@redhat.com> Link: https://lore.kernel.org/r/20220330194244.3476544-1-stgraber@ubuntu.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Jakub Kicinski authored
Merge tag 'linux-can-fixes-for-5.18-20220331' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2022-03-31 The first patch is by Oliver Hartkopp and fixes MSG_PEEK feature in the CAN ISOTP protocol (broken in net-next for v5.18 only). Tom Rix's patch for the mcp251xfd driver fixes the propagation of an error value in case of an error. A patch by me for the m_can driver fixes a use-after-free in the xmit handler for m_can IP cores v3.0.x. Hangyu Hua contributes 3 patches fixing the same double free in the error path of the xmit handler in the ems_usb, usb_8dev and mcba_usb USB CAN driver. Pavel Skripkin contributes a patch for the mcba_usb driver to properly check the endpoint type. The last patch is by me and fixes a mem leak in the gs_usb, which was introduced in net-next for v5.18. * tag 'linux-can-fixes-for-5.18-20220331' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: gs_usb: gs_make_candev(): fix memory leak for devices with extended bit timing configuration can: mcba_usb: properly check endpoint type can: mcba_usb: mcba_usb_start_xmit(): fix double dev_kfree_skb in error path can: usb_8dev: usb_8dev_start_xmit(): fix double dev_kfree_skb() in error path can: ems_usb: ems_usb_start_xmit(): fix double dev_kfree_skb() in error path can: m_can: m_can_tx_handler(): fix use after free of skb can: mcp251xfd: mcp251xfd_register_get_dev_id(): fix return of error value can: isotp: restore accidentally removed MSG_PEEK feature ==================== Link: https://lore.kernel.org/r/Signed-off-by:
-
Xiaolong Huang authored
Some function calls are not implemented in rxrpc_no_security, there are preparse_server_key, free_preparse_server_key and destroy_server_key. When rxrpc security type is rxrpc_no_security, user can easily trigger a null-ptr-deref bug via ioctl. So judgment should be added to prevent it The crash log: user@syzkaller:~$ ./rxrpc_preparse_s [ 37.956878][T15626] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 37.957645][T15626] #PF: supervisor instruction fetch in kernel mode [ 37.958229][T15626] #PF: error_code(0x0010) - not-present page [ 37.958762][T15626] PGD 4aadf067 P4D 4aadf067 PUD 4aade067 PMD 0 [ 37.959321][T15626] Oops: 0010 [#1] PREEMPT SMP [ 37.959739][T15626] CPU: 0 PID: 15626 Comm: rxrpc_preparse_ Not tainted 5.17.0-01442-gb47d5a4f #43 [ 37.960588][T15626] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1 04/01/2014 [ 37.961474][T15626] RIP: 0010:0x0 [ 37.961787][T15626] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6. [ 37.962480][T15626] RSP: 0018:ffffc9000d9abdc0 EFLAGS: 00010286 [ 37.963018][T15626] RAX: ffffffff84335200 RBX: ffff888012a1ce80 RCX: 0000000000000000 [ 37.963727][T15626] RDX: 0000000000000000 RSI: ffffffff84a736dc RDI: ffffc9000d9abe48 [ 37.964425][T15626] RBP: ffffc9000d9abe48 R08: 0000000000000000 R09: 0000000000000002 [ 37.965118][T15626] R10: 000000000000000a R11: f000000000000000 R12: ffff888013145680 [ 37.965836][T15626] R13: 0000000000000000 R14: ffffffffffffffec R15: ffff8880432aba80 [ 37.966441][T15626] FS: 00007f2177907700(0000) GS:ffff88803ec00000(0000) knlGS:0000000000000000 [ 37.966979][T15626] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 37.967384][T15626] CR2: ffffffffffffffd6 CR3: 000000004aaf1000 CR4: 00000000000006f0 [ 37.967864][T15626] Call Trace: [ 37.968062][T15626] <TASK> [ 37.968240][T15626] rxrpc_preparse_s+0x59/0x90 [ 37.968541][T15626] key_create_or_update+0x174/0x510 [ 37.968863][T15626] __x64_sys_add_key+0x139/0x1d0 [ 37.969165][T15626] do_syscall_64+0x35/0xb0 [ 37.969451][T15626] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 37.969824][T15626] RIP: 0033:0x43a1f9 Signed-off-by:
Xiaolong Huang <butterflyhuangxx@gmail.com> Tested-by:
David Howells <dhowells@redhat.com> Acked-by:
Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org Link: http://lists.infradead.org/pipermail/linux-afs/2022-March/005069.html Fixes: 12da59fc ("rxrpc: Hand server key parsing off to the security class") Link: https://lore.kernel.org/r/164865013439.2941502.8966285221215590921.stgit@warthog.procyon.org.ukSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
David Howells authored
The rxrpc_call struct has a timer used to handle various timed events relating to a call. This timer can get started from the packet input routines that are run in softirq mode with just the RCU read lock held. Unfortunately, because only the RCU read lock is held - and neither ref or other lock is taken - the call can start getting destroyed at the same time a packet comes in addressed to that call. This causes the timer - which was already stopped - to get restarted. Later, the timer dispatch code may then oops if the timer got deallocated first. Fix this by trying to take a ref on the rxrpc_call struct and, if successful, passing that ref along to the timer. If the timer was already running, the ref is discarded. The timer completion routine can then pass the ref along to the call's work item when it queues it. If the timer or work item where already queued/running, the extra ref is discarded. Fixes: a158bdd3 ("rxrpc: Fix call timeouts") Reported-by:
-
Paolo Abeni authored
Guangbin Huang says: ==================== net: hns3: add two fixes for -net This series adds two fixes for the HNS3 ethernet driver. ==================== Link: https://lore.kernel.org/r/20220330134506.36635-1-huangguangbin2@huawei.comSigned-off-by:
-
Guangbin Huang authored
When user delete vlan 0, as driver will not delete vlan 0 for hardware in function hclge_set_vlan_filter_hw(), so vlan 0 in software vlan talbe should not be deleted. Fixes: fe4144d4 ("net: hns3: sync VLAN filter entries when kill VLAN ID failed") Signed-off-by:
Guangbin Huang <huangguangbin2@huawei.com> Signed-off-by:
-
Yufeng Mo authored
Currently, the debugfs mechanism is that all functions share a global variable to save the pointer for obtaining data. When different functions concurrently access the same file node, repeated release exceptions occur. Therefore, the granularity of the pointer for storing the obtained data is adjusted to be private for each function. Fixes: 5e69ea7e ("net: hns3: refactor the debugfs process") Signed-off-by:
Yufeng Mo <moyufeng@huawei.com> Signed-off-by:
-
Paolo Abeni authored
Jakub Kicinski says: ==================== docs: update and move the netdev-FAQ A section of documentation for tree-specific process quirks had been created a while back. There's only one tree in it, so far, the tip tree, but the contents seem to answer similar questions as we answer in the netdev-FAQ. Move the netdev-FAQ. Take this opportunity to touch up and update a few sections. v3: remove some confrontational? language from patch 7 v2: remove non-git in patch 3 add patch 5 ==================== Link: https://lore.kernel.org/r/20220330042505.2902770-1-kuba@kernel.orgSigned-off-by: -
Jakub Kicinski authored
The documentation for the tip tree is really in quite a similar spirit to the netdev-FAQ. Move the netdev-FAQ to the process docs as well. Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
-
Jakub Kicinski authored
Convert the "should I use new or old comment formatting" to cover all formatting. This makes the question itself shorter. Signed-off-by:
-
Jakub Kicinski authored
Add the most important case to the question about "where are we in the cycle" - the case of net-next being closed. Signed-off-by:
-
Jakub Kicinski authored
I think double back ticks are more correct. Add where they are missing. Signed-off-by:
-
Jakub Kicinski authored
These days we often ask for selftests so let's update our testing requirements. Signed-off-by:
-
Jakub Kicinski authored
We have to tell people to stop reposting to often lately, or not to repost while the discussion is ongoing. Document this. Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Jakub Kicinski authored
Make the question shorter and adjust the start of the answer accordingly. Signed-off-by:
-
Jakub Kicinski authored
The semantics of "Under review" have shifted. Reword the question about it a bit and focus it on the response time. Signed-off-by:
-
Jakub Kicinski authored
Cut down the length of the question so it renders better in docs. Mention that Message-ID can be used to search patchwork. Signed-off-by:
-
Jakub Kicinski authored
Document that RFCs are allowed during the merge window. Signed-off-by:
-
Jakub Kicinski authored
Use the sphinx Warning box to make the net-next being closed stand out more. Signed-off-by:
-
Jakub Kicinski authored
We want people to mark their patches with net and net-next in the subject. Many miss doing that. Move the FAQ section which points that out up, and place it after the section which enumerates the trees, that seems like a pretty logical place for it. Since the two sections are together we can remove a little bit (not too much) of the repetition. v2: also remove the text for non-git setups, we want people to use git. Signed-off-by:
-
Jakub Kicinski authored
that -> those Signed-off-by:
-
Jakub Kicinski authored
Most people use (or should use) lore at this point. Replace the pointers to older archiving systems. Signed-off-by:
-
Marc Kleine-Budde authored
Some CAN-FD capable devices offer extended bit timing information for the data bit timing. The information must be read with an USB control message. The memory for this message is allocated but not free()ed (in the non error case). This patch adds the missing free. Fixes: 6679f4c5 ("can: gs_usb: add extended bt_const feature") Link: https://lore.kernel.org/all/20220329193450.659726-1-mkl@pengutronix.de Reported-by: syzbot+4d0ae90a195b269f102d@syzkaller.appspotmail.com Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Pavel Skripkin authored
Syzbot reported warning in usb_submit_urb() which is caused by wrong endpoint type. We should check that in endpoint is actually present to prevent this warning. Found pipes are now saved to struct mcba_priv and code uses them directly instead of making pipes in place. Fail log: | usb 5-1: BOGUS urb xfer, pipe 3 != type 1 | WARNING: CPU: 1 PID: 49 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 | Modules linked in: | CPU: 1 PID: 49 Comm: kworker/1:2 Not tainted 5.17.0-rc6-syzkaller-00184-g38f80f42 #0 | Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 | Workqueue: usb_hub_wq hub_event | RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502 | ... | Call Trace: | <TASK> | mcba_usb_start drivers/net/can/usb/mcba_usb.c:662 [inline] | mcba_usb_probe+0x8a3/0xc50 drivers/net/can/usb/mcba_usb.c:858 | usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396 | call_driver_probe drivers/base/dd.c:517 [inline] Fixes: 51f3baad ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer") Link: https://lore.kernel.org/all/20220313100903.10868-1-paskripkin@gmail.com Reported-and-tested-by: syzbot+3bc1dce0cc0052d60fde@syzkaller.appspotmail.com Signed-off-by:
Pavel Skripkin <paskripkin@gmail.com> Reviewed-by:
Vincent Mailhol <mailhol.vincent@wanadoo.fr> Signed-off-by:
-
Hangyu Hua authored
There is no need to call dev_kfree_skb() when usb_submit_urb() fails because can_put_echo_skb() deletes original skb and can_free_echo_skb() deletes the cloned skb. Fixes: 51f3baad ("can: mcba_usb: Add support for Microchip CAN BUS Analyzer") Link: https://lore.kernel.org/all/20220311080208.45047-1-hbh25y@gmail.comSigned-off-by:
Hangyu Hua <hbh25y@gmail.com> Signed-off-by:
-
Hangyu Hua authored
There is no need to call dev_kfree_skb() when usb_submit_urb() fails because can_put_echo_skb() deletes original skb and can_free_echo_skb() deletes the cloned skb. Fixes: 0024d8ad ("can: usb_8dev: Add support for USB2CAN interface from 8 devices") Link: https://lore.kernel.org/all/20220311080614.45229-1-hbh25y@gmail.com Cc: stable@vger.kernel.org Signed-off-by:
-
Hangyu Hua authored
There is no need to call dev_kfree_skb() when usb_submit_urb() fails beacause can_put_echo_skb() deletes the original skb and can_free_echo_skb() deletes the cloned skb. Link: https://lore.kernel.org/all/20220228083639.38183-1-hbh25y@gmail.com Fixes: 702171ad ("ems_usb: Added support for EMS CPC-USB/ARM7 CAN/USB interface") Cc: stable@vger.kernel.org Cc: Sebastian Haas <haas@ems-wuensche.com> Signed-off-by:
-
Marc Kleine-Budde authored
can_put_echo_skb() will clone skb then free the skb. Move the can_put_echo_skb() for the m_can version 3.0.x directly before the start of the xmit in hardware, similar to the 3.1.x branch. Fixes: 80646733 ("can: m_can: update to support CAN FD features") Link: https://lore.kernel.org/all/20220317081305.739554-1-mkl@pengutronix.de Cc: stable@vger.kernel.org Reported-by:
-
Tom Rix authored
Clang static analysis reports this issue: | mcp251xfd-core.c:1813:7: warning: The left operand | of '&' is a garbage value | FIELD_GET(MCP251XFD_REG_DEVID_ID_MASK, dev_id), | ^ ~~~~~~ dev_id is set in a successful call to mcp251xfd_register_get_dev_id(). Though the status of calls made by mcp251xfd_register_get_dev_id() are checked and handled, their status' are not returned. So return err. Fixes: 55e5b97f ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Link: https://lore.kernel.org/all/20220319153128.2164120-1-trix@redhat.comSigned-off-by:
Tom Rix <trix@redhat.com> Signed-off-by:
-
Oliver Hartkopp authored
In commit 42bf50a1 ("can: isotp: support MSG_TRUNC flag when reading from socket") a new check for recvmsg flags has been introduced that only checked for the flags that are handled in isotp_recvmsg() itself. This accidentally removed the MSG_PEEK feature flag which is processed later in the call chain in __skb_try_recv_from_queue(). Add MSG_PEEK to the set of valid flags to restore the feature. Fixes: 42bf50a1 ("can: isotp: support MSG_TRUNC flag when reading from socket") Link: https://github.com/linux-can/can-utils/issues/347#issuecomment-1079554254 Link: https://lore.kernel.org/all/20220328113611.3691-1-socketcan@hartkopp.netReported-by:
Derek Will <derekrobertwill@gmail.com> Suggested-by:
Oliver Hartkopp <socketcan@hartkopp.net> Signed-off-by:
-
Randy Dunlap authored
Fix build errors when BRIDGE=m and SPARX5_SWITCH=y: riscv64-linux-ld: drivers/net/ethernet/microchip/sparx5/sparx5_switchdev.o: in function `.L305': sparx5_switchdev.c:(.text+0xdb0): undefined reference to `br_vlan_enabled' riscv64-linux-ld: drivers/net/ethernet/microchip/sparx5/sparx5_switchdev.o: in function `.L283': sparx5_switchdev.c:(.text+0xee0): undefined reference to `br_vlan_enabled' Fixes: 3cfa11ba ("net: sparx5: add the basic sparx5 driver") Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Reported-by:
kernel test robot <lkp@intel.com> Cc: Horatiu Vultur <horatiu.vultur@microchip.com> Cc: Lars Povlsen <lars.povlsen@microchip.com> Cc: Steen Hegelund <Steen.Hegelund@microchip.com> Cc: UNGLinuxDriver@microchip.com Cc: Paolo Abeni <pabeni@redhat.com> Link: https://lore.kernel.org/r/20220330012025.29560-1-rdunlap@infradead.orgSigned-off-by:
-
Jakub Kicinski authored
Jason A. Donenfeld says: ==================== wireguard patches for 5.18-rc1 Here's a small set of fixes for the next net push: 1) Pipacs reported a CFI violation in a cleanup routine, which he triggered using grsec's RAP. I haven't seen reports of this yet from the Android/CFI world yet, but it's only a matter of time there. 2) A small rng cleanup to the self test harness to make it initialize faster on 5.18. 3) Wang reported and fixed a skb leak for CONFIG_IPV6=n. 4) After Wang's fix for the direct leak, I investigated how that code path even could be hit, and found that the netlink layer still handles IPv6 endpoints, when it probably shouldn't. ==================== Link: https://lore.kernel.org/r/20220330013127.426620-1-Jason@zx2c4.comSigned-off-by:
-
Jason A. Donenfeld authored
The previous commit fixed a memory leak on the send path in the event that IPv6 is disabled at compile time, but how did a packet even arrive there to begin with? It turns out we have previously allowed IPv6 endpoints even when IPv6 support is disabled at compile time. This is awkward and inconsistent. Instead, let's just ignore all things IPv6, the same way we do other malformed endpoints, in the case where IPv6 is disabled. Fixes: e7096c13 ("net: WireGuard secure network tunnel") Signed-off-by:
Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
-
Wang Hai authored
I got a memory leak report: unreferenced object 0xffff8881191fc040 (size 232): comm "kworker/u17:0", pid 23193, jiffies 4295238848 (age 3464.870s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814c3ef4>] slab_post_alloc_hook+0x84/0x3b0 [<ffffffff814c8977>] kmem_cache_alloc_node+0x167/0x340 [<ffffffff832974fb>] __alloc_skb+0x1db/0x200 [<ffffffff82612b5d>] wg_socket_send_buffer_to_peer+0x3d/0xc0 [<ffffffff8260e94a>] wg_packet_send_handshake_initiation+0xfa/0x110 [<ffffffff8260ec81>] wg_packet_handshake_send_worker+0x21/0x30 [<ffffffff8119c558>] process_one_work+0x2e8/0x770 [<ffffffff8119ca2a>] worker_thread+0x4a/0x4b0 [<ffffffff811a88e0>] kthread+0x120/0x160 [<ffffffff8100242f>] ret_from_fork+0x1f/0x30 In function wg_socket_send_buffer_as_reply_to_skb() or wg_socket_send_ buffer_to_peer(), the semantics of send6() is required to free skb. But when CONFIG_IPV6 is disable, kfree_skb() is missing. This patch adds it to fix this bug. Signed-off-by:Wang Hai <wanghai38@huawei.com> Fixes: e7096c13 ("net: WireGuard secure network tunnel") Signed-off-by:
-
Jason A. Donenfeld authored
The seed_rng() function was written to work across lots of old kernels, back when WireGuard used a big compatibility layer. Now that things have evolved, we can vastly simplify this, by just marking the RNG as seeded. Signed-off-by:
-
Jason A. Donenfeld authored
We make too nuanced use of ptr_ring to entirely move to the skb_array wrappers, but we at least should avoid the naughty function pointer cast when cleaning up skbs. Otherwise RAP/CFI will honk at us. This patch uses the __skb_array_destroy_skb wrapper for the cleanup, rather than directly providing kfree_skb, which is what other drivers in the same situation do too. Reported-by:
PaX Team <pageexec@freemail.hu> Fixes: 886fcee9 ("wireguard: receive: use ring buffer for incoming handshakes") Signed-off-by:
-
- 30 Mar, 2022 4 commits
-
-
Martin Habets authored
On such systems cpumask_of_node() returns NULL, which bitmap operations are not happy with. Fixes: c265b569 ("sfc: default config to 1 channel/core in local NUMA node only") Fixes: 09a99ab1 ("sfc: set affinity hints in local NUMA node only") Signed-off-by:
Martin Habets <habetsm.xilinx@gmail.com> Reviewed-by:
Íñigo Huguet <ihuguet@redhat.com> Link: https://lore.kernel.org/r/164857006953.8140.3265568858101821256.stgit@palantir17.mph.netSigned-off-by:
-
Jonathan Lemon authored
nvmem_device_find returns a valid pointer or IS_ERR(). Handle this properly. Fixes: 0cfcdd1e ("ptp: ocp: add nvmem interface for accessing eeprom") Signed-off-by:
Jonathan Lemon <jonathan.lemon@gmail.com> Link: https://lore.kernel.org/r/20220329160354.4035-1-jonathan.lemon@gmail.comSigned-off-by:
-
Zheng Yongjun authored
As the possible failure of the allocation, kzalloc() may return NULL pointer. Therefore, it should be better to check the 'sgi' in order to prevent the dereference of NULL pointer. Fixes: 23ae3a78 ("net: dsa: felix: add stream gate settings for psfp"). Signed-off-by:
Zheng Yongjun <zhengyongjun3@huawei.com> Reviewed-by:
Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://lore.kernel.org/r/20220329090800.130106-1-zhengyongjun3@huawei.comSigned-off-by:
-
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfJakub Kicinski authored
Alexei Starovoitov says: ==================== pull-request: bpf 2022-03-29 We've added 16 non-merge commits during the last 1 day(s) which contain a total of 24 files changed, 354 insertions(+), 187 deletions(-). The main changes are: 1) x86 specific bits of fprobe/rethook, from Masami and Peter. 2) ice/xsk fixes, from Maciej and Magnus. 3) Various small fixes, from Andrii, Yonghong, Geliang and others. * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: selftests/bpf: Fix clang compilation errors ice: xsk: Fix indexing in ice_tx_xsk_pool() ice: xsk: Stop Rx processing when ntc catches ntu ice: xsk: Eliminate unnecessary loop iteration xsk: Do not write NULL in SW ring at allocation failure x86,kprobes: Fix optprobe trampoline to generate complete pt_regs x86,rethook: Fix arch_rethook_trampoline() to generate a complete pt_regs x86,rethook,kprobes: Replace kretprobe with rethook on x86 kprobes: Use rethook for kretprobe if possible bpftool: Fix generated code in codegen_asserts selftests/bpf: fix selftest after random: Urandom_read tracepoint removal bpf: Fix maximum permitted number of arguments check bpf: Sync comments for bpf_get_stack fprobe: Fix sparse warning for acccessing __rcu ftrace_hash fprobe: Fix smatch type mismatch warning bpf/bpftool: Add unprivileged_bpf_disabled check against value of 2 ==================== Link: https://lore.kernel.org/r/20220329234924.39053-1-alexei.starovoitov@gmail.comSigned-off-by:
-
