- 23 Jun, 2022 9 commits
-
-
Rosemarie O'Riorden authored
When a packet enters the OVS datapath and does not match any existing flows installed in the kernel flow cache, the packet will be sent to userspace to be parsed, and a new flow will be created. The kernel and OVS rely on each other to parse packet fields in the same way so that packets will be handled properly. As per the design document linked below, OVS expects all later IPv6 fragments to have nw_proto=44 in the flow key, so they can be correctly matched on OpenFlow rules. OpenFlow controllers create pipelines based on this design. This behavior was changed by the commit in the Fixes tag so that nw_proto equals the next_header field of the last extension header. However, there is no counterpart for this change in OVS userspace, meaning that this field is parsed differently between OVS and the kernel. This is a problem because OVS creates actions based on what is parsed in userspace, but the kernel-provided flow key is used as a match criteria, as described in Documentation/networking/openvswitch.rst. This leads to issues such as packets incorrectly matching on a flow and thus the wrong list of actions being applied to the packet. Such changes in packet parsing cannot be implemented without breaking the userspace. The offending commit is partially reverted to restore the expected behavior. The change technically made sense and there is a good reason that it was implemented, but it does not comply with the original design of OVS. If in the future someone wants to implement such a change, then it must be user-configurable and disabled by default to preserve backwards compatibility with existing OVS versions. Cc: stable@vger.kernel.org Fixes: fa642f08 ("openvswitch: Derive IP protocol number for IPv6 later frags") Link: https://docs.openvswitch.org/en/latest/topics/design/#fragmentsSigned-off-by:
Rosemarie O'Riorden <roriorden@redhat.com> Acked-by:
Eelco Chaudron <echaudro@redhat.com> Link: https://lore.kernel.org/r/20220621204845.9721-1-roriorden@redhat.comSigned-off-by:
Paolo Abeni <pabeni@redhat.com>
-
Jakub Kicinski authored
Commit 8a59f9d1 ("sock: Introduce sk->sk_prot->psock_update_sk_prot()") has moved the inet_csk_has_ulp(sk) check from sk_psock_init() to the new tcp_bpf_update_proto() function. I'm guessing that this was done to allow creating psocks for non-inet sockets. Unfortunately the destruction path for psock includes the ULP unwind, so we need to fail the sk_psock_init() itself. Otherwise if ULP is already present we'll notice that later, and call tcp_update_ulp() with the sk_proto of the ULP itself, which will most likely result in the ULP looping its callbacks. Fixes: 8a59f9d1 ("sock: Introduce sk->sk_prot->psock_update_sk_prot()") Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Reviewed-by:
John Fastabend <john.fastabend@gmail.com> Reviewed-by:
Jakub Sitnicki <jakub@cloudflare.com> Tested-by:
-
Jakub Kicinski authored
This reverts commit 69135c57. This commit was just papering over the issue, ULP should not get ->update() called with its own sk_prot. Each ULP would need to add this check. Fixes: 69135c57 ("net/tls: fix tls_sk_proto_close executed repeatedly") Signed-off-by:
-
Stephan Gerhold authored
The following sequence currently causes a driver bug warning when using virtio_net: # ip link set eth0 up # echo mem > /sys/power/state (or e.g. # rtcwake -s 10 -m mem) <resume> # ip link set eth0 down Missing register, driver bug WARNING: CPU: 0 PID: 375 at net/core/xdp.c:138 xdp_rxq_info_unreg+0x58/0x60 Call trace: xdp_rxq_info_unreg+0x58/0x60 virtnet_close+0x58/0xac __dev_close_many+0xac/0x140 __dev_change_flags+0xd8/0x210 dev_change_flags+0x24/0x64 do_setlink+0x230/0xdd0 ... This happens because virtnet_freeze() frees the receive_queue completely (including struct xdp_rxq_info) but does not call xdp_rxq_info_unreg(). Similarly, virtnet_restore() sets up the receive_queue again but does not call xdp_rxq_info_reg(). Actually, parts of virtnet_freeze_down() and virtnet_restore_up() are almost identical to virtnet_close() and virtnet_open(): only the calls to xdp_rxq_info_(un)reg() are missing. This means that we can fix this easily and avoid such problems in the future by just calling virtnet_close()/open() from the freeze/restore handlers. Aside from adding the missing xdp_rxq_info calls the only difference is that the refill work is only cancelled if netif_running(). However, this should not make any functional difference since the refill work should only be active if the network interface is actually up. Fixes: 754b8a21 ("virtio_net: setup xdp_rxq_info") Signed-off-by:
Stephan Gerhold <stephan.gerhold@kernkonzept.com> Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Acked-by:
Jason Wang <jasowang@redhat.com> Link: https://lore.kernel.org/r/20220621114845.3650258-1-stephan.gerhold@kernkonzept.comSigned-off-by:
-
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queueJakub Kicinski authored
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2022-06-21 This series contains updates to ice driver only. Marcin fixes GTP filters by allowing ignoring of the inner ethertype field. Wojciech adds VSI handle tracking in order to properly distinguish similar filters for removal. Anatolii removes ability to set 1000baseT and 1000baseX fields concurrently which caused link issues. He also disallows setting channels to less than the number of Traffic Classes which would cause NULL pointer dereference. * '100GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: ice: ethtool: Prohibit improper channel config for DCB ice: ethtool: advertise 1000M speeds properly ice: Fix switchdev rules book keeping ice: ignore protocol field in GTP offload ==================== Link: https://lore.kernel.org/r/20220621224756.631765-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Kai-Heng Feng authored
Intel I210 on some Intel Alder Lake platforms can only achieve ~750Mbps Tx speed via iperf. The RR2DCDELAY shows around 0x2xxx DMA delay, which will be significantly lower when 1) ASPM is disabled or 2) SoC package c-state stays above PC3. When the RR2DCDELAY is around 0x1xxx the Tx speed can reach to ~950Mbps. According to the I210 datasheet "8.26.1 PCIe Misc. Register - PCIEMISC", "DMA Idle Indication" doesn't seem to tie to DMA coalesce anymore, so set it to 1b for "DMA is considered idle when there is no Rx or Tx AND when there are no TLPs indicating that CPU is active detected on the PCIe link (such as the host executes CSR or Configuration register read or write operation)" and performing Tx should also fall under "active CPU on PCIe link" case. In addition to that, commit b6e0c419 ("igb: Move DMA Coalescing init code to separate function.") seems to wrongly changed from enabling E1000_PCIEMISC_LX_DECISION to disabling it, also fix that. Fixes: b6e0c419 ("igb: Move DMA Coalescing init code to separate function.") Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://lore.kernel.org/r/20220621221056.604304-1-anthony.l.nguyen@intel.comSigned-off-by:
-
Christian Marangi authored
The current mgmt ethernet timeout is set to 100ms. This value is too big and would slow down any mdio command in case the mgmt ethernet packet have some problems on the receiving part. Reduce it to just 5ms to handle case when some operation are done on the master port that would cause the mgmt ethernet to not work temporarily. Fixes: 5950c7c0 ("net: dsa: qca8k: add support for mgmt read/write in Ethernet packet") Signed-off-by:
Christian Marangi <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20220621151633.11741-1-ansuelsmth@gmail.comSigned-off-by:
-
Christian Marangi authored
It was discovered that the Documentation lacks of a fundamental detail on how to correctly change the MAX_FRAME_SIZE of the switch. In fact if the MAX_FRAME_SIZE is changed while the cpu port is on, the switch panics and cease to send any packet. This cause the mgmt ethernet system to not receive any packet (the slow fallback still works) and makes the device not reachable. To recover from this a switch reset is required. To correctly handle this, turn off the cpu ports before changing the MAX_FRAME_SIZE and turn on again after the value is applied. Fixes: f58d2598 ("net: dsa: qca8k: implement the port MTU callbacks") Cc: stable@vger.kernel.org Signed-off-by:
-
Vadim Fedorenko authored
I've been contributing and reviewing patches for ptp_ocp driver for some time and I'm taking care of it's github mirror. On Jakub's suggestion, I would like to step forward and become a maintainer for this driver. This patch adds a dedicated entry to MAINTAINERS. Signed-off-by:
Vadim Fedorenko <vadfed@fb.com> Acked-by:
Jonathan Lemon <jonathan.lemon@gmail.com> Link: https://lore.kernel.org/r/20220621233131.21240-1-vfedorenko@novek.ruSigned-off-by:
-
- 22 Jun, 2022 4 commits
-
-
Kees Cook authored
Under CONFIG_FORTIFY_SOURCE=y and CONFIG_UBSAN_BOUNDS=y, Clang is bugged here for calculating the size of the destination buffer (0x10 instead of 0x14). This copy is a fixed size (sizeof(struct fw_section_info_st)), with the source and dest being struct fw_section_info_st, so the memcpy should be safe, assuming the index is within bounds, which is UBSAN_BOUNDS's responsibility to figure out. Avoid the whole thing and just do a direct assignment. This results in no change to the executable code. [This is a duplicate of commit 2c0ab32b ("hinic: Replace memcpy() with direct assignment") which was applied to net-next.] Cc: Nick Desaulniers <ndesaulniers@google.com> Cc: Tom Rix <trix@redhat.com> Cc: llvm@lists.linux.dev Link: https://github.com/ClangBuiltLinux/linux/issues/1592Signed-off-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> # build Link: https://lore.kernel.org/r/20220616052312.292861-1-keescook@chromium.orgSigned-off-by:
-
Jakub Kicinski authored
This reverts commit 8fc74d18. BAR0 is the main (only?) register bank for this device. We most obviously can't unmap it before the netdev is unregistered. This was pointed out in review but the patch got reposted and merged, anyway. The author of the patch was only testing it with a QEMU model, which I presume does not emulate enough for the netdev to be brought up (author's replies are not visible in lore because they kept sending their emails in HTML). Link: https://lore.kernel.org/all/20220616085059.680dc215@kernel.org/ Fixes: 8fc74d18 ("drivers/net/ethernet/neterion/vxge: Fix a use-after-free bug in vxge-main.c") Signed-off-by:
David S. Miller <davem@davemloft.net>
-
git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nfJakub Kicinski authored
Pablo Neira Ayuso says: ==================== Netfilter fixes for net 1) Use get_random_u32() instead of prandom_u32_state() in nft_meta and nft_numgen, from Florian Westphal. 2) Incorrect list head in nfnetlink_cttimeout in recent update coming from previous development cycle. Also from Florian. 3) Incorrect path to pktgen scripts for nft_concat_range.sh selftest. From Jie2x Zhou. 4) Two fixes for the for nft_fwd and nft_dup egress support, from Florian. * git://git.kernel.org/pub/scm/linux/kernel/git/netfilter/nf: netfilter: nf_dup_netdev: add and use recursion counter netfilter: nf_dup_netdev: do not push mac header a second time selftests: netfilter: correct PKTGEN_SCRIPT_PATHS in nft_concat_range.sh netfilter: cttimeout: fix slab-out-of-bounds read typo in cttimeout_net_exit netfilter: use get_random_u32 instead of prandom ==================== Link: https://lore.kernel.org/r/20220621085618.3975-1-pablo@netfilter.orgSigned-off-by:
-
Lukas Wunner authored
Simon reports that if two LAN9514 USB adapters are directly connected without an intermediate switch, the link fails to come up and link LEDs remain dark. The issue was introduced by commit 1ce8b372 ("usbnet: smsc95xx: Forward PHY interrupts to PHY driver to avoid polling"). The PHY suffers from a known erratum wherein link detection becomes unreliable if Energy Detect Power-Down is used. In poll mode, the driver works around the erratum by briefly disabling EDPD for 640 msec to detect a neighbor, then re-enabling it to save power. In interrupt mode, no interrupt is signaled if EDPD is used by both link partners, so it must not be enabled at all. We'll recoup the power savings by enabling SUSPEND1 mode on affected LAN95xx chips in a forthcoming commit. Fixes: 1ce8b372 ("usbnet: smsc95xx: Forward PHY interrupts to PHY driver to avoid polling") Reported-by:
Simon Han <z.han@kunbus.com> Signed-off-by:
Lukas Wunner <lukas@wunner.de> Link: https://lore.kernel.org/r/439a3f3168c2f9d44b5fd9bb8d2b551711316be6.1655714438.git.lukas@wunner.deSigned-off-by:
-
- 21 Jun, 2022 7 commits
-
-
Anatolii Gerasymenko authored
Do not allow setting less channels, than Traffic Classes there are via ethtool. There must be at least one channel per Traffic Class. If you set less channels, than Traffic Classes there are, then during ice_vsi_rebuild there would be allocated only the requested amount of tx/rx rings in ice_vsi_alloc_arrays. But later in ice_vsi_setup_q_map there would be requested at least one channel per Traffic Class. This results in setting num_rxq > alloc_rxq and num_txq > alloc_txq. Later, there would be a NULL pointer dereference in ice_vsi_map_rings_to_vectors, because we go beyond of rx_rings or tx_rings arrays. Change ice_set_channels() to return error if you try to allocate less channels, than Traffic Classes there are. Change ice_vsi_setup_q_map() and ice_vsi_setup_q_map_mqprio() to return status code instead of void. Add error handling for ice_vsi_setup_q_map() and ice_vsi_setup_q_map_mqprio() in ice_vsi_init() and ice_vsi_cfg_tc(). [53753.889983] INFO: Flow control is disabled for this traffic class (0) on this vsi. [53763.984862] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028 [53763.992915] PGD 14b45f5067 P4D 0 [53763.996444] Oops: 0002 [#1] SMP NOPTI [53764.000312] CPU: 12 PID: 30661 Comm: ethtool Kdump: loaded Tainted: GOE --------- - - 4.18.0-240.el8.x86_64 #1 [53764.011825] Hardware name: Intel Corporation WilsonCity/WilsonCity, BIOS WLYDCRB1.SYS.0020.P21.2012150710 12/15/2020 [53764.022584] RIP: 0010:ice_vsi_map_rings_to_vectors+0x7e/0x120 [ice] [53764.029089] Code: 41 0d 0f b7 b7 12 05 00 00 0f b6 d0 44 29 de 44 0f b7 c6 44 01 c2 41 39 d0 7d 2d 4c 8b 47 28 44 0f b7 ce 83 c6 01 4f 8b 04 c8 <49> 89 48 28 4 c 8b 89 b8 01 00 00 4d 89 08 4c 89 81 b8 01 00 00 44 [53764.048379] RSP: 0018:ff550dd88ea47b20 EFLAGS: 00010206 [53764.053884] RAX: 0000000000000002 RBX: 0000000000000004 RCX: ff385ea42fa4a018 [53764.061301] RDX: 0000000000000006 RSI: 0000000000000005 RDI: ff385e9baeedd018 [53764.068717] RBP: 0000000000000010 R08: 0000000000000000 R09: 0000000000000004 [53764.076133] R10: 0000000000000002 R11: 0000000000000004 R12: 0000000000000000 [53764.083553] R13: 0000000000000000 R14: ff385e658fdd9000 R15: ff385e9baeedd018 [53764.090976] FS: 000014872c5b5740(0000) GS:ff385e847f100000(0000) knlGS:0000000000000000 [53764.099362] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [53764.105409] CR2: 0000000000000028 CR3: 0000000a820fa002 CR4: 0000000000761ee0 [53764.112851] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [53764.120301] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [53764.127747] PKRU: 55555554 [53764.130781] Call Trace: [53764.133564] ice_vsi_rebuild+0x611/0x870 [ice] [53764.138341] ice_vsi_recfg_qs+0x94/0x100 [ice] [53764.143116] ice_set_channels+0x1a8/0x3e0 [ice] [53764.147975] ethtool_set_channels+0x14e/0x240 [53764.152667] dev_ethtool+0xd74/0x2a10 [53764.156665] ? __mod_lruvec_state+0x44/0x110 [53764.161280] ? __mod_lruvec_state+0x44/0x110 [53764.165893] ? page_add_file_rmap+0x15/0x170 [53764.170518] ? inet_ioctl+0xd1/0x220 [53764.174445] ? netdev_run_todo+0x5e/0x290 [53764.178808] dev_ioctl+0xb5/0x550 [53764.182485] sock_do_ioctl+0xa0/0x140 [53764.186512] sock_ioctl+0x1a8/0x300 [53764.190367] ? selinux_file_ioctl+0x161/0x200 [53764.195090] do_vfs_ioctl+0xa4/0x640 [53764.199035] ksys_ioctl+0x60/0x90 [53764.202722] __x64_sys_ioctl+0x16/0x20 [53764.206845] do_syscall_64+0x5b/0x1a0 [53764.210887] entry_SYSCALL_64_after_hwframe+0x65/0xca Fixes: 87324e74 ("ice: Implement ethtool ops for channels") Signed-off-by:
Anatolii Gerasymenko <anatolii.gerasymenko@intel.com> Tested-by: Gurucharan <gurucharanx.g@intel.com> (A Contingent worker at Intel) Signed-off-by:
-
Anatolii Gerasymenko authored
In current implementation ice_update_phy_type enables all link modes for selected speed. This approach doesn't work for 1000M speeds, because both copper (1000baseT) and optical (1000baseX) standards cannot be enabled at once. Fix this, by adding the function `ice_set_phy_type_from_speed()` for 1000M speeds. Fixes: 48cb27f2 ("ice: Implement handlers for ethtool PHY/link operations") Signed-off-by:
-
Wojciech Drewek authored
Adding two filters with same matching criteria ends up with one rule in hardware with act = ICE_FWD_TO_VSI_LIST. In order to remove them properly we have to keep the information about vsi handle which is used in VSI bitmap (ice_adv_fltr_mgmt_list_entry::vsi_list_info::vsi_map). Fixes: 0d08a441 ("ice: ndo_setup_tc implementation for PF") Reported-by:
Sridhar Samudrala <sridhar.samudrala@intel.com> Signed-off-by:
Wojciech Drewek <wojciech.drewek@intel.com> Tested-by:
Sandeep Penigalapati <sandeep.penigalapati@intel.com> Signed-off-by:
-
Marcin Szycik authored
Commit 34a89775 ("ice: Add support for inner etype in switchdev") added the ability to match on inner ethertype. A side effect of that change is that it is now impossible to add some filters for protocols which do not contain inner ethtype field. tc requires the protocol field to be specified when providing certain other options, e.g. src_ip. This is a problem in case of GTP - when user wants to specify e.g. src_ip, they also need to specify protocol in tc command (otherwise tc fails with: Illegal "src_ip"). Because GTP is a tunnel, the protocol field is treated as inner protocol. GTP does not contain inner ethtype field and the filter cannot be added. To fix this, ignore the ethertype field in case of GTP filters. Fixes: 9a225f81 ("ice: Support GTP-U and GTP-C offload in switchdev") Signed-off-by:
Marcin Szycik <marcin.szycik@linux.intel.com> Tested-by:
-
Florian Westphal authored
Now that the egress function can be called from egress hook, we need to avoid recursive calls into the nf_tables traverser, else crash. Fixes: f87b9464 ("netfilter: nft_fwd_netdev: Support egress hook") Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
Pablo Neira Ayuso <pablo@netfilter.org>
-
Florian Westphal authored
Eric reports skb_under_panic when using dup/fwd via bond+egress hook. Before pushing mac header, we should make sure that we're called from ingress to put back what was pulled earlier. In egress case, the MAC header is already there; we should leave skb alone. While at it be more careful here: skb might have been altered and headroom reduced, so add a skb_cow() before so that headroom is increased if necessary. nf_do_netdev_egress() assumes skb ownership (it normally ends with a call to dev_queue_xmit), so we must free the packet on error. Fixes: f87b9464 ("netfilter: nft_fwd_netdev: Support egress hook") Reported-by:
Eric Garver <eric@garver.life> Signed-off-by:
-
Jie2x Zhou authored
Before change: make -C netfilter TEST: performance net,port [SKIP] perf not supported port,net [SKIP] perf not supported net6,port [SKIP] perf not supported port,proto [SKIP] perf not supported net6,port,mac [SKIP] perf not supported net6,port,mac,proto [SKIP] perf not supported net,mac [SKIP] perf not supported After change: net,mac [ OK ] baseline (drop from netdev hook): 2061098pps baseline hash (non-ranged entries): 1606741pps baseline rbtree (match on first field only): 1191607pps set with 1000 full, ranged entries: 1639119pps ok 8 selftests: netfilter: nft_concat_range.sh Fixes: 611973c1 ("selftests: netfilter: Introduce tests for sets with range concatenation") Reported-by:kernel test robot <lkp@intel.com> Signed-off-by:
Jie2x Zhou <jie2x.zhou@intel.com> Signed-off-by:
-
- 20 Jun, 2022 3 commits
-
-
Ziyang Xuan authored
After setting the sock ktls, update ctx->sk_proto to sock->sk_prot by tls_update(), so now ctx->sk_proto->close is tls_sk_proto_close(). When close the sock, tls_sk_proto_close() is called for sock->sk_prot->close is tls_sk_proto_close(). But ctx->sk_proto->close() will be executed later in tls_sk_proto_close(). Thus tls_sk_proto_close() executed repeatedly occurred. That will trigger the following bug. ================================================================= KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] RIP: 0010:tls_sk_proto_close+0xd8/0xaf0 net/tls/tls_main.c:306 Call Trace: <TASK> tls_sk_proto_close+0x356/0xaf0 net/tls/tls_main.c:329 inet_release+0x12e/0x280 net/ipv4/af_inet.c:428 __sock_release+0xcd/0x280 net/socket.c:650 sock_close+0x18/0x20 net/socket.c:1365 Updating a proto which is same with sock->sk_prot is incorrect. Add proto and sock->sk_prot equality check at the head of tls_update() to fix it. Fixes: 95fa1454 ("bpf: sockmap/tls, close can race with map free") Reported-by: syzbot+29c3c12f3214b85ad081@syzkaller.appspotmail.com Signed-off-by:
Ziyang Xuan <william.xuanziyang@huawei.com> Signed-off-by:
-
Eric Dumazet authored
Rewrite tests in ip6erspan_tunnel_xmit() and erspan_fb_xmit() to not assume transport header is set. syzbot reported: WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 skb_transport_header include/linux/skbuff.h:2911 [inline] WARNING: CPU: 0 PID: 1350 at include/linux/skbuff.h:2911 ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963 Modules linked in: CPU: 0 PID: 1350 Comm: aoe_tx0 Not tainted 5.19.0-rc2-syzkaller-00160-g274295c6 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014 RIP: 0010:skb_transport_header include/linux/skbuff.h:2911 [inline] RIP: 0010:ip6erspan_tunnel_xmit+0x15af/0x2eb0 net/ipv6/ip6_gre.c:963 Code: 0f 47 f0 40 88 b5 7f fe ff ff e8 8c 16 4b f9 89 de bf ff ff ff ff e8 a0 12 4b f9 66 83 fb ff 0f 85 1d f1 ff ff e8 71 16 4b f9 <0f> 0b e9 43 f0 ff ff e8 65 16 4b f9 48 8d 85 30 ff ff ff ba 60 00 RSP: 0018:ffffc90005daf910 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000 RDX: ffff88801f032100 RSI: ffffffff882e8d3f RDI: 0000000000000003 RBP: ffffc90005dafab8 R08: 0000000000000003 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000000 R12: ffff888024f21d40 R13: 000000000000a288 R14: 00000000000000b0 R15: ffff888025a2e000 FS: 0000000000000000(0000) GS:ffff88802c800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000001b2e425000 CR3: 000000006d099000 CR4: 0000000000152ef0 Call Trace: <TASK> __netdev_start_xmit include/linux/netdevice.h:4805 [inline] netdev_start_xmit include/linux/netdevice.h:4819 [inline] xmit_one net/core/dev.c:3588 [inline] dev_hard_start_xmit+0x188/0x880 net/core/dev.c:3604 sch_direct_xmit+0x19f/0xbe0 net/sched/sch_generic.c:342 __dev_xmit_skb net/core/dev.c:3815 [inline] __dev_queue_xmit+0x14a1/0x3900 net/core/dev.c:4219 dev_queue_xmit include/linux/netdevice.h:2994 [inline] tx+0x6a/0xc0 drivers/block/aoe/aoenet.c:63 kthread+0x1e7/0x3b0 drivers/block/aoe/aoecmd.c:1229 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:302 </TASK> Fixes: d5db21a3 ("erspan: auto detect truncated ipv6 packets.") Reported-by:
syzbot <syzkaller@googlegroups.com> Signed-off-by:
Eric Dumazet <edumazet@google.com> Cc: William Tu <u9012063@gmail.com> Signed-off-by:
-
Riccardo Paolo Bestetti authored
Commit 8ff978b8 ("ipv4/raw: support binding to nonlocal addresses") introduces support for binding to nonlocal addresses, as well as some basic test coverage for some of the related cases. Commit b4a028c4 ("ipv4: ping: fix bind address validity check") fixes a regression which incorrectly removed some checks for bind address validation. In addition, it introduces regression tests for those specific checks. However, those regression tests are defective, in that they perform the tests using an incorrect combination of bind flags. As a result, those tests fail when they should succeed. This commit introduces additional regression tests for nonlocal binding and fixes the defective regression tests. It also introduces new set_sysctl calls for the ipv4_bind test group, as to perform the ICMP binding tests it is necessary to allow ICMP socket creation by setting the net.ipv4.ping_group_range knob. Fixes: b4a028c4 ("ipv4: ping: fix bind address validity check") Reported-by:
Riccardo Paolo Bestetti <pbl@bestov.io> Signed-off-by:
-
- 19 Jun, 2022 2 commits
-
-
Oleksij Rempel authored
Latest kernel will explode on the PHY interrupt config, since it depends now on allocated priv. So, run probe to allocate priv to fix it. ar9331_switch ethernet.1:10 lan0 (uninitialized): PHY [!ahb!ethernet@1a000000!mdio!switch@10:00] driver [Qualcomm Atheros AR9331 built-in PHY] (irq=13) CPU 0 Unable to handle kernel paging request at virtual address 0000000a, epc == 8050e8a8, ra == 80504b34 ... Call Trace: [<8050e8a8>] at803x_config_intr+0x5c/0xd0 [<80504b34>] phy_request_interrupt+0xa8/0xd0 [<8050289c>] phylink_bringup_phy+0x2d8/0x3ac [<80502b68>] phylink_fwnode_phy_connect+0x118/0x130 [<8074d8ec>] dsa_slave_create+0x270/0x420 [<80743b04>] dsa_port_setup+0x12c/0x148 [<8074580c>] dsa_register_switch+0xaf0/0xcc0 [<80511344>] ar9331_sw_probe+0x370/0x388 [<8050cb78>] mdio_probe+0x44/0x70 [<804df300>] really_probe+0x200/0x424 [<804df7b4>] __driver_probe_device+0x290/0x298 [<804df810>] driver_probe_device+0x54/0xe4 [<804dfd50>] __device_attach_driver+0xe4/0x130 [<804dcb00>] bus_for_each_drv+0xb4/0xd8 [<804dfac4>] __device_attach+0x104/0x1a4 [<804ddd24>] bus_probe_device+0x48/0xc4 [<804deb44>] deferred_probe_work_func+0xf0/0x10c [<800a0ffc>] process_one_work+0x314/0x4d4 [<800a17fc>] worker_thread+0x2a4/0x354 [<800a9a54>] kthread+0x134/0x13c [<8006306c>] ret_from_kernel_thread+0x14/0x1c Same Issue would affect some other PHYs (QCA8081, QCA9561), so fix it too. Fixes: 3265f421 ("net: phy: at803x: add fiber support") Signed-off-by:Oleksij Rempel <o.rempel@pengutronix.de> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
Wentao_Liang authored
The pointer vdev points to a memory region adjacent to a net_device structure ndev, which is a field of hldev. At line 4740, the invocation to vxge_device_unregister unregisters device hldev, and it also releases the memory region pointed by vdev->bar0. At line 4743, the freed memory region is referenced (i.e., iounmap(vdev->bar0)), resulting in a use-after-free vulnerability. We can fix the bug by calling iounmap before vxge_device_unregister. 4721. static void vxge_remove(struct pci_dev *pdev) 4722. { 4723. struct __vxge_hw_device *hldev; 4724. struct vxgedev *vdev; … 4731. vdev = netdev_priv(hldev->ndev); … 4740. vxge_device_unregister(hldev); 4741. /* Do not call pci_disable_sriov here, as it will break child devices */ 4742. vxge_hw_device_terminate(hldev); 4743. iounmap(vdev->bar0); … 4749 vxge_debug_init(vdev->level_trace, "%s:%d Device unregistered", 4750 __func__, __LINE__); 4751 vxge_debug_entryexit(vdev->level_trace, "%s:%d Exiting...", __func__, 4752 __LINE__); 4753. } This is the screenshot when the vulnerability is triggered by using KASAN. We can see that there is a use-after-free reported by KASAN. /***************************start**************************/ root@kernel:~# echo 1 > /sys/bus/pci/devices/0000:00:03.0/remove [ 178.296316] vxge_remove [ 182.057081] ================================================================== [ 182.057548] BUG: KASAN: use-after-free in vxge_remove+0xe0/0x15c [ 182.057760] Read of size 8 at addr ffff888006c76598 by task bash/119 [ 182.057983] [ 182.058747] CPU: 0 PID: 119 Comm: bash Not tainted 5.18.0 #5 [ 182.058919] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 182.059463] Call Trace: [ 182.059726] <TASK> [ 182.060017] dump_stack_lvl+0x34/0x44 [ 182.060316] print_report.cold+0xb2/0x6b7 [ 182.060401] ? kfree+0x89/0x290 [ 182.060478] ? vxge_remove+0xe0/0x15c [ 182.060545] kasan_report+0xa9/0x120 [ 182.060629] ? vxge_remove+0xe0/0x15c [ 182.060706] vxge_remove+0xe0/0x15c [ 182.060793] pci_device_remove+0x5d/0xe0 [ 182.060968] device_release_driver_internal+0xf1/0x180 [ 182.061063] pci_stop_bus_device+0xae/0xe0 [ 182.061150] pci_stop_and_remove_bus_device_locked+0x11/0x20 [ 182.061236] remove_store+0xc6/0xe0 [ 182.061297] ? subordinate_bus_number_show+0xc0/0xc0 [ 182.061359] ? __mutex_lock_slowpath+0x10/0x10 [ 182.061438] ? sysfs_kf_write+0x6d/0xa0 [ 182.061525] kernfs_fop_write_iter+0x1b0/0x260 [ 182.061610] ? sysfs_kf_bin_read+0xf0/0xf0 [ 182.061695] new_sync_write+0x209/0x310 [ 182.061789] ? new_sync_read+0x310/0x310 [ 182.061865] ? cgroup_rstat_updated+0x5c/0x170 [ 182.061937] ? preempt_count_sub+0xf/0xb0 [ 182.061995] ? pick_next_entity+0x13a/0x220 [ 182.062063] ? __inode_security_revalidate+0x44/0x80 [ 182.062155] ? security_file_permission+0x46/0x2a0 [ 182.062230] vfs_write+0x33f/0x3e0 [ 182.062303] ksys_write+0xb4/0x150 [ 182.062369] ? __ia32_sys_read+0x40/0x40 [ 182.062451] do_syscall_64+0x3b/0x90 [ 182.062531] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 182.062894] RIP: 0033:0x7f3f37d17274 [ 182.063558] Code: 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 48 8d 05 89 54 0d 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 41 54 49 89 d4 55 48 89 f5 53 [ 182.063797] RSP: 002b:00007ffd5ba9e178 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ 182.064117] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f3f37d17274 [ 182.064219] RDX: 0000000000000002 RSI: 000055bbec327180 RDI: 0000000000000001 [ 182.064315] RBP: 000055bbec327180 R08: 000000000000000a R09: 00007f3f37de7cf0 [ 182.064414] R10: 000000000000000a R11: 0000000000000246 R12: 00007f3f37de8760 [ 182.064513] R13: 0000000000000002 R14: 00007f3f37de3760 R15: 0000000000000002 [ 182.064691] </TASK> [ 182.064916] [ 182.065224] The buggy address belongs to the physical page: [ 182.065804] page:00000000ef31e4f4 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x6c76 [ 182.067419] flags: 0x100000000000000(node=0|zone=1) [ 182.068997] raw: 0100000000000000 0000000000000000 ffffea00001b1d88 0000000000000000 [ 182.069118] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 182.069294] page dumped because: kasan: bad access detected [ 182.069331] [ 182.069360] Memory state around the buggy address: [ 182.070006] ffff888006c76480: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 182.070136] ffff888006c76500: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 182.070230] >ffff888006c76580: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 182.070305] ^ [ 182.070456] ffff888006c76600: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 182.070505] ffff888006c76680: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 182.070606] ================================================================== [ 182.071374] Disabling lock debugging due to kernel taint /*****************************end*****************************/ After fixing the bug as done in the patch, we can find KASAN do not report the bug and the device(00:03.0) has been successfully removed. /*****************************start***************************/ root@kernel:~# echo 1 > /sys/bus/pci/devices/0000:00:03.0/remove root@kernel:~# /******************************end****************************/ Signed-off-by:Wentao_Liang <Wentao_Liang_g@163.com> Signed-off-by:
-
- 18 Jun, 2022 5 commits
-
-
Peilin Ye authored
As reported by Yuming, currently tc always show a latency of UINT_MAX for netem Qdisc's on 32-bit platforms: $ tc qdisc add dev dummy0 root netem latency 100ms $ tc qdisc show dev dummy0 qdisc netem 8001: root refcnt 2 limit 1000 delay 275s 275s ^^^^^^^^^^^^^^^^ Let us take a closer look at netem_dump(): qopt.latency = min_t(psched_tdiff_t, PSCHED_NS2TICKS(q->latency, UINT_MAX); qopt.latency is __u32, psched_tdiff_t is signed long, (psched_tdiff_t)(UINT_MAX) is negative for 32-bit platforms, so qopt.latency is always UINT_MAX. Fix it by using psched_time_t (u64) instead. Note: confusingly, users have two ways to specify 'latency': 1. normally, via '__u32 latency' in struct tc_netem_qopt; 2. via the TCA_NETEM_LATENCY64 attribute, which is s64. For the second case, theoretically 'latency' could be negative. This patch ignores that corner case, since it is broken (i.e. assigning a negative s64 to __u32) anyways, and should be handled separately. Thanks Ted Lin for the analysis [1] . [1] https://github.com/raspberrypi/linux/issues/3512Reported-by:Yuming Chen <chenyuming.junnan@bytedance.com> Fixes: 112f9cb6 ("netem: convert to qdisc_watchdog_schedule_ns") Reviewed-by:
Cong Wang <cong.wang@bytedance.com> Signed-off-by:
Peilin Ye <peilin.ye@bytedance.com> Acked-by:
Stephen Hemminger <stephen@networkplumber.org> Link: https://lore.kernel.org/r/20220616234336.2443-1-yepeilin.cs@gmail.comSigned-off-by:
-
Ivan Vecera authored
Function fallback_set_params() checks if the module type returned by a driver is ETH_MODULE_SFF_8079 and in this case it assumes that buffer returns a concatenated content of page A0h and A2h. The check is wrong because the correct type is ETH_MODULE_SFF_8472. Fixes: 96d971e3 ("ethtool: Add fallback to get_module_eeprom from netlink command") Signed-off-by:
Ivan Vecera <ivecera@redhat.com> Reviewed-by:
Ido Schimmel <idosch@nvidia.com> Link: https://lore.kernel.org/r/20220616160856.3623273-1-ivecera@redhat.comSigned-off-by:
-
Jay Vosburgh authored
The bonding ARP monitor fails to decrement send_peer_notif, the number of peer notifications (gratuitous ARP or ND) to be sent. This results in a continuous series of notifications. Correct this by decrementing the counter for each notification. Reported-by:
Jonathan Toppins <jtoppins@redhat.com> Signed-off-by:
Jay Vosburgh <jay.vosburgh@canonical.com> Fixes: b0929915 ("bonding: Fix RTNL: assertion failed at net/core/rtnetlink.c for ab arp monitor") Link: https://lore.kernel.org/netdev/b2fd4147-8f50-bebd-963a-1a3e8d1d9715@redhat.com/Tested-by:
-
Lorenzo Bianconi authored
Fix the following use-after-free bug in igb_clean_tx_ring routine when the NIC is running in XDP mode. The issue can be triggered redirecting traffic into the igb NIC and then closing the device while the traffic is flowing. [ 73.322719] CPU: 1 PID: 487 Comm: xdp_redirect Not tainted 5.18.3-apu2 #9 [ 73.330639] Hardware name: PC Engines APU2/APU2, BIOS 4.0.7 02/28/2017 [ 73.337434] RIP: 0010:refcount_warn_saturate+0xa7/0xf0 [ 73.362283] RSP: 0018:ffffc9000081f798 EFLAGS: 00010282 [ 73.367761] RAX: 0000000000000000 RBX: ffffc90000420f80 RCX: 0000000000000000 [ 73.375200] RDX: ffff88811ad22d00 RSI: ffff88811ad171e0 RDI: ffff88811ad171e0 [ 73.382590] RBP: 0000000000000900 R08: ffffffff82298f28 R09: 0000000000000058 [ 73.390008] R10: 0000000000000219 R11: ffffffff82280f40 R12: 0000000000000090 [ 73.397356] R13: ffff888102343a40 R14: ffff88810359e0e4 R15: 0000000000000000 [ 73.404806] FS: 00007ff38d31d740(0000) GS:ffff88811ad00000(0000) knlGS:0000000000000000 [ 73.413129] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 73.419096] CR2: 000055cff35f13f8 CR3: 0000000106391000 CR4: 00000000000406e0 [ 73.426565] Call Trace: [ 73.429087] <TASK> [ 73.431314] igb_clean_tx_ring+0x43/0x140 [igb] [ 73.436002] igb_down+0x1d7/0x220 [igb] [ 73.439974] __igb_close+0x3c/0x120 [igb] [ 73.444118] igb_xdp+0x10c/0x150 [igb] [ 73.447983] ? igb_pci_sriov_configure+0x70/0x70 [igb] [ 73.453362] dev_xdp_install+0xda/0x110 [ 73.457371] dev_xdp_attach+0x1da/0x550 [ 73.461369] do_setlink+0xfd0/0x10f0 [ 73.465166] ? __nla_validate_parse+0x89/0xc70 [ 73.469714] rtnl_setlink+0x11a/0x1e0 [ 73.473547] rtnetlink_rcv_msg+0x145/0x3d0 [ 73.477709] ? rtnl_calcit.isra.0+0x130/0x130 [ 73.482258] netlink_rcv_skb+0x8d/0x110 [ 73.486229] netlink_unicast+0x230/0x340 [ 73.490317] netlink_sendmsg+0x215/0x470 [ 73.494395] __sys_sendto+0x179/0x190 [ 73.498268] ? move_addr_to_user+0x37/0x70 [ 73.502547] ? __sys_getsockname+0x84/0xe0 [ 73.506853] ? netlink_setsockopt+0x1c1/0x4a0 [ 73.511349] ? __sys_setsockopt+0xc8/0x1d0 [ 73.515636] __x64_sys_sendto+0x20/0x30 [ 73.519603] do_syscall_64+0x3b/0x80 [ 73.523399] entry_SYSCALL_64_after_hwframe+0x44/0xae [ 73.528712] RIP: 0033:0x7ff38d41f20c [ 73.551866] RSP: 002b:00007fff3b945a68 EFLAGS: 00000246 ORIG_RAX: 000000000000002c [ 73.559640] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff38d41f20c [ 73.567066] RDX: 0000000000000034 RSI: 00007fff3b945b30 RDI: 0000000000000003 [ 73.574457] RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 [ 73.581852] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff3b945ab0 [ 73.589179] R13: 0000000000000000 R14: 0000000000000003 R15: 00007fff3b945b30 [ 73.596545] </TASK> [ 73.598842] ---[ end trace 0000000000000000 ]--- Fixes: 9cbc948b ("igb: add XDP support") Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by:
Jesse Brandeburg <jesse.brandeburg@intel.com> Acked-by:
-
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpfJakub Kicinski authored
Daniel Borkmann says: ==================== pull-request: bpf 2022-06-17 We've added 12 non-merge commits during the last 4 day(s) which contain a total of 14 files changed, 305 insertions(+), 107 deletions(-). The main changes are: 1) Fix x86 JIT tailcall count offset on BPF-2-BPF call, from Jakub Sitnicki. 2) Fix a kprobe_multi link bug which misplaces BPF cookies, from Jiri Olsa. 3) Fix an infinite loop when processing a module's BTF, from Kumar Kartikeya Dwivedi. 4) Fix getting a rethook only in RCU available context, from Masami Hiramatsu. 5) Fix request socket refcount leak in sk lookup helpers, from Jon Maxwell. 6) Fix xsk xmit behavior which wrongly adds skb to already full cq, from Ciara Loftus. * https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf: rethook: Reject getting a rethook if RCU is not watching fprobe, samples: Add use_trace option and show hit/missed counter bpf, docs: Update some of the JIT/maintenance entries selftest/bpf: Fix kprobe_multi bench test bpf: Force cookies array to follow symbols sorting ftrace: Keep address offset in ftrace_lookup_symbols selftests/bpf: Shuffle cookies symbols in kprobe multi test selftests/bpf: Test tail call counting with bpf2bpf and data on stack bpf, x86: Fix tail call count offset calculation on bpf2bpf call bpf: Limit maximum modifier chain length in btf_check_type_tags bpf: Fix request_sock leak in sk lookup helpers xsk: Fix generic transmit when completion queue reservation fails ==================== Link: https://lore.kernel.org/r/20220617202119.2421-1-daniel@iogearbox.netSigned-off-by:
-
- 17 Jun, 2022 10 commits
-
-
Florian Westphal authored
syzbot reports: BUG: KASAN: slab-out-of-bounds in __list_del_entry_valid+0xcc/0xf0 lib/list_debug.c:42 [..] list_del include/linux/list.h:148 [inline] cttimeout_net_exit+0x211/0x540 net/netfilter/nfnetlink_cttimeout.c:617 Problem is the wrong name of the list member, so container_of() result is wrong. Reported-by: <syzbot+92968395eedbdbd3617d@syzkaller.appspotmail.com> Fixes: 78222bac ("netfilter: cttimeout: decouple unlink and free on netns destruction") Signed-off-by:
-
Masami Hiramatsu (Google) authored
Since the rethook_recycle() will involve the call_rcu() for reclaiming the rethook_instance, the rethook must be set up at the RCU available context (non idle). This rethook_recycle() in the rethook trampoline handler is inevitable, thus the RCU available check must be done before setting the rethook trampoline. This adds a rcu_is_watching() check in the rethook_try_get() so that it will return NULL if it is called when !rcu_is_watching(). Fixes: 54ecbe6f ("rethook: Add a generic return hook") Signed-off-by:
Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
Steven Rostedt (Google) <rostedt@goodmis.org> Acked-by:
Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/bpf/165461827269.280167.7379263615545598958.stgit@devnote2
-
Masami Hiramatsu (Google) authored
Add use_trace option to use trace_printk() instead of pr_info() so that the handler doesn't involve the RCU operations. And show the hit and missed counter so that the user can check how many times the probe handler hit and missed. Signed-off-by:
-
Daniel Borkmann authored
Various minor updates around some of the BPF-related entries: JITs for ARM32/NFP/SPARC/X86-32 haven't seen updates in quite a while, thus for now, mark them as 'Odd Fixes' until they become more actively developed. JITs for POWERPC/S390 are in good shape and receive active development and review, thus bump to 'Supported' similar as we have with X86-64/ARM64. JITs for MIPS/RISC-V are in similar good shape as the ones mentioned above, but looked after mostly in spare time, thus leave for now in 'Maintained' state. Add Michael to PPC JIT given he's picking up the patches there, so it better reflects today's state. Also, I haven't done much reviewing around BPF sockmap/kTLS after John and I did the big rework back in the days to integrate sockmap with kTLS. These days, most of this is taken care by John, Jakub {Sitnicki,Kicinski} and others in the community, so remove myself from these two. Lastly, move all BPF-related entries into one place, that is, move the sockmap one over near rest of BPF. Signed-off-by:Andrii Nakryiko <andrii@kernel.org> Acked-by:
Alexei Starovoitov <ast@kernel.org> Acked-by:
-
Riccardo Paolo Bestetti authored
Commit 8ff978b8 ("ipv4/raw: support binding to nonlocal addresses") introduced a helper function to fold duplicated validity checks of bind addresses into inet_addr_valid_or_nonlocal(). However, this caused an unintended regression in ping_check_bind_addr(), which previously would reject binding to multicast and broadcast addresses, but now these are both incorrectly allowed as reported in [1]. This patch restores the original check. A simple reordering is done to improve readability and make it evident that multicast and broadcast addresses should not be allowed. Also, add an early exit for INADDR_ANY which replaces lost behavior added by commit 0ce779a9 ("net: Avoid unnecessary inet_addr_type() call when addr is INADDR_ANY"). Furthermore, this patch introduces regression selftests to catch these specific cases. [1] https://lore.kernel.org/netdev/CANP3RGdkAcDyAZoT1h8Gtuu0saq+eOrrTiWbxnOs+5zn+cpyKg@mail.gmail.com/ Fixes: 8ff978b8 ("ipv4/raw: support binding to nonlocal addresses") Cc: Miaohe Lin <linmiaohe@huawei.com> Reported-by:
Maciej Żenczykowski <maze@google.com> Signed-off-by:
Carlos Llamas <cmllamas@google.com> Signed-off-by:
-
Xu Jia authored
Hulk Robot reports incorrect sp->rx_count_cooked value in decode_std_command(). This should be caused by the subtracting from sp->rx_count_cooked before. It seems that sp->rx_count_cooked value is changed to 0, which bypassed the previous judgment. The situation is shown below: (Thread 1) | (Thread 2) decode_std_command() | resync_tnc() ... | if (rest == 2) | sp->rx_count_cooked -= 2; | else if (rest == 3) | ... | sp->rx_count_cooked = 0; sp->rx_count_cooked -= 1; | for (i = 0; i < sp->rx_count_cooked; i++) // report error checksum += sp->cooked_buf[i]; sp->rx_count_cooked is a shared variable but is not protected by a lock. The same applies to sp->rx_count. This patch adds a lock to fix the bug. The fail log is shown below: ======================================================================= UBSAN: array-index-out-of-bounds in drivers/net/hamradio/6pack.c:925:31 index 400 is out of range for type 'unsigned char [400]' CPU: 3 PID: 7433 Comm: kworker/u10:1 Not tainted 5.18.0-rc5-00163-g4b97bac0 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 Workqueue: events_unbound flush_to_ldisc Call Trace: <TASK> dump_stack_lvl+0xcd/0x134 ubsan_epilogue+0xb/0x50 __ubsan_handle_out_of_bounds.cold+0x62/0x6c sixpack_receive_buf+0xfda/0x1330 tty_ldisc_receive_buf+0x13e/0x180 tty_port_default_receive_buf+0x6d/0xa0 flush_to_ldisc+0x213/0x3f0 process_one_work+0x98f/0x1620 worker_thread+0x665/0x1080 kthread+0x2e9/0x3a0 ret_from_fork+0x1f/0x30 ... Reported-by:Hulk Robot <hulkci@huawei.com> Signed-off-by:
Xu Jia <xujia39@huawei.com> Signed-off-by:
-
Hoang Le authored
syzbot found the following issue on: ================================================================== BUG: KASAN: use-after-free in tipc_named_reinit+0x94f/0x9b0 net/tipc/name_distr.c:413 Read of size 8 at addr ffff88805299a000 by task kworker/1:9/23764 CPU: 1 PID: 23764 Comm: kworker/1:9 Not tainted 5.18.0-rc4-syzkaller-00878-g17d49e6e #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events tipc_net_finalize_work Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106 print_address_description.constprop.0.cold+0xeb/0x495 mm/kasan/report.c:313 print_report mm/kasan/report.c:429 [inline] kasan_report.cold+0xf4/0x1c6 mm/kasan/report.c:491 tipc_named_reinit+0x94f/0x9b0 net/tipc/name_distr.c:413 tipc_net_finalize+0x234/0x3d0 net/tipc/net.c:138 process_one_work+0x996/0x1610 kernel/workqueue.c:2289 worker_thread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e9/0x3a0 kernel/kthread.c:376 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298 </TASK> [...] ================================================================== In the commit d966ddcc ("tipc: fix a deadlock when flushing scheduled work"), the cancel_work_sync() function just to make sure ONLY the work tipc_net_finalize_work() is executing/pending on any CPU completed before tipc namespace is destroyed through tipc_exit_net(). But this function is not guaranteed the work is the last queued. So, the destroyed instance may be accessed in the work which will try to enqueue later. In order to completely fix, we re-order the calling of cancel_work_sync() to make sure the work tipc_net_finalize_work() was last queued and it must be completed by calling cancel_work_sync(). Reported-by: syzbot+47af19f3307fc9c5c82e@syzkaller.appspotmail.com Fixes: d966ddcc ("tipc: fix a deadlock when flushing scheduled work") Acked-by:
Jon Maloy <jmaloy@redhat.com> Signed-off-by:
Ying Xue <ying.xue@windriver.com> Signed-off-by:
Hoang Le <hoang.h.le@dektech.com.au> Signed-off-by:
-
Jay Vosburgh authored
Since commit 21a75f09 ("bonding: Fix ARP monitor validation"), the bonding ARP / ND link monitors depend on the trans_start time to determine link availability. NETIF_F_LLTX drivers must update trans_start directly, which veth does not do. This prevents use of the ARP or ND link monitors with veth interfaces in a bond. Resolve this by having veth_xmit update the trans_start time. Reported-by:
-
Eric Dumazet authored
dev_isalive() is called under RTNL or dev_base_lock protection. This means that changes to dev->reg_state should be done with both locks held. syzbot reported: BUG: KCSAN: data-race in register_netdevice / type_show write to 0xffff888144ecf518 of 1 bytes by task 20886 on cpu 0: register_netdevice+0xb9f/0xdf0 net/core/dev.c:10050 lapbeth_new_device drivers/net/wan/lapbether.c:414 [inline] lapbeth_device_event+0x4a0/0x6c0 drivers/net/wan/lapbether.c:456 notifier_call_chain kernel/notifier.c:87 [inline] raw_notifier_call_chain+0x53/0xb0 kernel/notifier.c:455 __dev_notify_flags+0x1d6/0x3a0 dev_change_flags+0xa2/0xc0 net/core/dev.c:8607 do_setlink+0x778/0x2230 net/core/rtnetlink.c:2780 __rtnl_newlink net/core/rtnetlink.c:3546 [inline] rtnl_newlink+0x114c/0x16a0 net/core/rtnetlink.c:3593 rtnetlink_rcv_msg+0x811/0x8c0 net/core/rtnetlink.c:6089 netlink_rcv_skb+0x13e/0x240 net/netlink/af_netlink.c:2501 rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6107 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x58a/0x660 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x661/0x750 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg net/socket.c:734 [inline] __sys_sendto+0x21e/0x2c0 net/socket.c:2119 __do_sys_sendto net/socket.c:2131 [inline] __se_sys_sendto net/socket.c:2127 [inline] __x64_sys_sendto+0x74/0x90 net/socket.c:2127 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 read to 0xffff888144ecf518 of 1 bytes by task 20423 on cpu 1: dev_isalive net/core/net-sysfs.c:38 [inline] netdev_show net/core/net-sysfs.c:50 [inline] type_show+0x24/0x90 net/core/net-sysfs.c:112 dev_attr_show+0x35/0x90 drivers/base/core.c:2095 sysfs_kf_seq_show+0x175/0x240 fs/sysfs/file.c:59 kernfs_seq_show+0x75/0x80 fs/kernfs/file.c:162 seq_read_iter+0x2c3/0x8e0 fs/seq_file.c:230 kernfs_fop_read_iter+0xd1/0x2f0 fs/kernfs/file.c:235 call_read_iter include/linux/fs.h:2052 [inline] new_sync_read fs/read_write.c:401 [inline] vfs_read+0x5a5/0x6a0 fs/read_write.c:482 ksys_read+0xe8/0x1a0 fs/read_write.c:620 __do_sys_read fs/read_write.c:630 [inline] __se_sys_read fs/read_write.c:628 [inline] __x64_sys_read+0x3e/0x50 fs/read_write.c:628 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 value changed: 0x00 -> 0x01 Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 20423 Comm: udevd Tainted: G W 5.19.0-rc2-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Claudiu Manoil authored
Even when the eth port is resticted to work with speeds not higher than 1G, and so the eth driver is requesting the phy (via phylink) to advertise up to 1000BASET support, the aquantia phy device is still advertising for 2.5G and 5G speeds. Clear these advertising defaults when requested. Cc: Ondrej Spacek <ondrej.spacek@nxp.com> Fixes: 09c4c57f ("net: phy: aquantia: add support for auto-negotiation configuration") Signed-off-by:
Claudiu Manoil <claudiu.manoil@nxp.com> Link: https://lore.kernel.org/r/20220610084037.7625-1-claudiu.manoil@nxp.comSigned-off-by:
-
