- 07 May, 2021 6 commits
-
-
Mateusz Palczewski authored
Unlike other supported adapters, 2.5G and 5G use different PHY type identifiers for reading/writing PHY settings and for reading link status. This commit introduces separate PHY identifiers for these two operation types. Fixes: 2e45d3f4 ("i40e: Add support for X710 B/P & SFP+ cards") Signed-off-by:
Dawid Lukwinski <dawid.lukwinski@intel.com> Signed-off-by:
Mateusz Palczewski <mateusz.palczewski@intel.com> Reviewed-by:
Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by:
Dave Switzer <david.switzer@intel.com> Signed-off-by:
Tony Nguyen <anthony.l.nguyen@intel.com>
-
Jaroslaw Gawin authored
When FEC mode was changed the link didn't know it because the link was not reset and new parameters were not negotiated. Set a flag 'I40E_AQ_PHY_ENABLE_ATOMIC_LINK' in 'abilities' to restart the link and make it run with the new settings. Fixes: 1d963401 ("i40e: Add support FEC configuration for Fortville 25G") Signed-off-by:
Jaroslaw Gawin <jaroslawx.gawin@intel.com> Signed-off-by:
-
Yunjian Wang authored
Currently the call to i40e_client_del_instance frees the object pf->cinst, however pf->cinst->lan_info is being accessed after the free. Fix this by adding the missing return. Addresses-Coverity: ("Read from pointer after free") Fixes: 7b0b1a6d ("i40e: Disable iWARP VSI PETCP_ENA flag on netdev down events") Signed-off-by:Yunjian Wang <wangyunjian@huawei.com> Signed-off-by:
-
Magnus Karlsson authored
Commit 12738ac4 ("i40e: Fix sparse errors in i40e_txrx.c") broke XDP support in the i40e driver. That commit was fixing a sparse error in the code by introducing a new variable xdp_res instead of overloading this into the skb pointer. The problem is that the code later uses the skb pointer in if statements and these where not extended to also test for the new xdp_res variable. Fix this by adding the correct tests for xdp_res in these places. The skb pointer was used to store the result of the XDP program by overloading the results in the error pointer ERR_PTR(-result). Therefore, the allocation failure test that used to only test for !skb now need to be extended to also consider !xdp_res. i40e_cleanup_headers() had a check that based on the skb value being an error pointer, i.e. a result from the XDP program != XDP_PASS, and if so start to process a new packet immediately, instead of populating skb fields and sending the skb to the stack. This check is not needed anymore, since we have added an explicit test for xdp_res being set and if so just do continue to pick the next packet from the NIC. Fixes: 12738ac4 ("i40e: Fix sparse errors in i40e_txrx.c") Acked-by:
Jesper Dangaard Brouer <brouer@redhat.com> Tested-by:
Maciej Fijalkowski <maciej.fijalkowski@intel.com> Signed-off-by:
Magnus Karlsson <magnus.karlsson@intel.com> Signed-off-by:
-
Arjun Roy authored
A prior change (1f466e1f) introduces separate handling for ->msg_control depending on whether the pointer is a kernel or user pointer. However, while tcp receive zerocopy is using this field, it is not properly annotating that the buffer in this case is a user pointer. This can cause faults when the improper mechanism is used within put_cmsg(). This patch simply annotates tcp receive zerocopy's use as explicitly being a user pointer. Fixes: 7eeba170 ("tcp: Add receive timestamp support for receive zerocopy.") Signed-off-by:
Arjun Roy <arjunroy@google.com> Acked-by:
Soheil Hassas Yeganeh <soheil@google.com> Reviewed-by:
Eric Dumazet <edumazet@google.com> Link: https://lore.kernel.org/r/20210506223530.2266456-1-arjunroy.kdev@gmail.comSigned-off-by:
Jakub Kicinski <kuba@kernel.org>
-
Ido Schimmel authored
Each multicast route that is forwarding packets (as opposed to trapping them) points to a list of egress router interfaces (RIFs) through which packets are replicated. A route's action can transition from trap to forward when a RIF is created for one of the route's egress virtual interfaces (eVIF). When this happens, the route's action is first updated and only later the list of egress RIFs is committed to the device. This results in the route pointing to an invalid list. In case the list pointer is out of range (due to uninitialized memory), the device will complain: mlxsw_spectrum2 0000:06:00.0: EMAD reg access failed (tid=5733bf490000905c,reg_id=300f(pefa),type=write,status=7(bad parameter)) Fix this by first committing the list of egress RIFs to the device and only later update the route's action. Note that a fix is not needed in the reverse function (i.e., mlxsw_sp_mr_route_evif_unresolve()), as there the route's action is first updated and only later the RIF is removed from the list. Cc: stable@vger.kernel.org Fixes: c011ec1b ("mlxsw: spectrum: Add the multicast routing offloading logic") Signed-off-by:
Ido Schimmel <idosch@nvidia.com> Reviewed-by:
Petr Machata <petrm@nvidia.com> Link: https://lore.kernel.org/r/20210506072308.3834303-1-idosch@idosch.orgSigned-off-by:
-
- 06 May, 2021 6 commits
-
-
Alex Elder authored
In gsi_irq_setup(), two registers are written with the intention of disabling inter-EE channel and event IRQs. But the wrong registers are used (and defined); the ones used are read-only registers that indicate whether the interrupt condition is present. Define the mask registers instead of the status registers, and use them to disable the inter-EE interrupt types. Fixes: 46f748cc ("net: ipa: explicitly disallow inter-EE interrupts") Signed-off-by:
Alex Elder <elder@linaro.org> Link: https://lore.kernel.org/r/20210505223636.232527-1-elder@linaro.orgSigned-off-by:
-
Jakub Kicinski authored
Merge tag 'linux-can-fixes-for-5.13-20210506' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can Marc Kleine-Budde says: ==================== pull-request: can 2021-05-06 The first two patches target the mcp251xfd driver. Dan Carpenter's patch fixes a NULL pointer dereference in the probe function's error path. A patch by me adds the missing can_rx_offload_del() in error path of the probe function. Frieder Schrempf contributes a patch for the mcp251x driver, the patch fixes the resume from sleep before interface was brought up. The last patch is by me and fixes a race condition in the TX path of the m_can driver for peripheral (SPI) based m_can cores. * tag 'linux-can-fixes-for-5.13-20210506' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can: can: m_can: m_can_tx_work_queue(): fix tx_skb race condition can: mcp251x: fix resume from sleep before interface was brought up can: mcp251xfd: mcp251xfd_probe(): add missing can_rx_offload_del() in error path can: mcp251xfd: mcp251xfd_probe(): fix an error pointer dereference in probe ==================== Link: https://lore.kernel.org/r/20210506074015.1300591-1-mkl@pengutronix.deSigned-off-by:
-
Marc Kleine-Budde authored
The m_can_start_xmit() function checks if the cdev->tx_skb is NULL and returns with NETDEV_TX_BUSY in case tx_sbk is not NULL. There is a race condition in the m_can_tx_work_queue(), where first the skb is send to the driver and then the case tx_sbk is set to NULL. A TX complete IRQ might come in between and wake the queue, which results in tx_skb not being cleared yet. Fixes: f524f829 ("can: m_can: Create a m_can platform framework") Tested-by:
Torin Cooper-Bennun <torin@maxiluxsystems.com> Signed-off-by:
Marc Kleine-Budde <mkl@pengutronix.de>
-
Frieder Schrempf authored
Since 8ce8c0ab the driver queues work via priv->restart_work when resuming after suspend, even when the interface was not previously enabled. This causes a null dereference error as the workqueue is only allocated and initialized in mcp251x_open(). To fix this we move the workqueue init to mcp251x_can_probe() as there is no reason to do it later and repeat it whenever mcp251x_open() is called. Fixes: 8ce8c0ab ("can: mcp251x: only reset hardware as required") Link: https://lore.kernel.org/r/17d5d714-b468-482f-f37a-482e3d6df84e@kontron.deSigned-off-by:
Frieder Schrempf <frieder.schrempf@kontron.de> Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> [mkl: fix error handling in mcp251x_stop()] Signed-off-by:
-
Marc Kleine-Budde authored
This patch adds the missing can_rx_offload_del(), that must be called if mcp251xfd_register() fails. Fixes: 55e5b97f ("can: mcp25xxfd: add driver for Microchip MCP25xxFD SPI CAN") Link: https://lore.kernel.org/r/20210504091838.1109047-1-mkl@pengutronix.deSigned-off-by:
-
Dan Carpenter authored
When we converted this code to use dev_err_probe() we accidentally removed a return. It means that if devm_clk_get() it will lead to an Oops when we call clk_get_rate() on the next line. Fixes: cf8ee6de ("can: mcp251xfd: mcp251xfd_probe(): use dev_err_probe() to simplify error handling") Link: https://lore.kernel.org/r/YJANZf13Qxd5Mhr1@mwandaSigned-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Manivannan Sadhasivam <mani@kernel.org> Signed-off-by:
-
- 05 May, 2021 5 commits
-
-
Cong Wang authored
syzbot is able to setup kTLS on an SMC socket which coincidentally uses sk_user_data too. Later, kTLS treats it as psock so triggers a refcnt warning. The root cause is that smc_setsockopt() simply calls TCP setsockopt() which includes TCP_ULP. I do not think it makes sense to setup kTLS on top of SMC sockets, so we should just disallow this setup. It is hard to find a commit to blame, but we can apply this patch since the beginning of TCP_ULP. Reported-and-tested-by: syzbot+b54a1ce86ba4a623b7f0@syzkaller.appspotmail.com Fixes: 734942cc ("tcp: ULP infrastructure") Cc: John Fastabend <john.fastabend@gmail.com> Signed-off-by:
Karsten Graul <kgraul@linux.ibm.com> Signed-off-by:
Cong Wang <cong.wang@bytedance.com> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Maciej Żenczykowski authored
Android userspace has been using TCA_KIND with a char[IFNAMESIZ] many-null-terminated buffer containing the string 'bpf'. This works on 4.19 and ceases to work on 5.10. I'm not entirely sure what fixes tag to use, but I think the issue was likely introduced in the below mentioned 5.4 commit. Reported-by:
Nucca Chen <nuccachen@google.com> Cc: Cong Wang <xiyou.wangcong@gmail.com> Cc: David Ahern <dsahern@gmail.com> Cc: David S. Miller <davem@davemloft.net> Cc: Jakub Kicinski <jakub.kicinski@netronome.com> Cc: Jamal Hadi Salim <jhs@mojatatu.com> Cc: Jiri Pirko <jiri@mellanox.com> Cc: Jiri Pirko <jiri@resnulli.us> Fixes: 62794fc4 ("net_sched: add max len check for TCA_KIND") Change-Id: I66dc281f165a2858fc29a44869a270a2d698a82b Signed-off-by:
-
Íñigo Huguet authored
An sk_buff is allocated to send a flow control message, but it's not sent in all cases: in case the state is not appropiate to send it or if it can't be enqueued. In the first of these 2 cases, the sk_buff was discarded but not freed, producing a memory leak. Signed-off-by:
Íñigo Huguet <ihuguet@redhat.com> Signed-off-by:
-
Sean Gloumeau authored
Spelling error "eleminate" amended to "eliminate". Signed-off-by:
Sean Gloumeau <sajgloumeau@gmail.com> Reviewed-by:
Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Signed-off-by:
-
Fernando Fernandez Mancera authored
When dumping the ethtool information from all the interfaces, the netlink reply should contain the NLM_F_MULTI flag. This flag allows userspace tools to identify that multiple messages are expected. Link: https://bugzilla.redhat.com/1953847 Fixes: 365f9ae4 ("ethtool: fix genlmsg_put() failure handling in ethnl_default_dumpit()") Signed-off-by:
Fernando Fernandez Mancera <ffmancera@riseup.net> Signed-off-by:
-
- 04 May, 2021 4 commits
-
-
Ramesh Babu B authored
In promiscuous mode Receive All bit is set in GMAC packet filter register, but outside promiscuous mode Receive All bit is not cleared, which resulted in all network packets are received when toggle (ON/OFF) the promiscuous mode. Fixes: e0f9956a ("net: stmmac: Add option for VLAN filter fail queue enable") Signed-off-by:
Ramesh Babu B <ramesh.babu.b@intel.com> Signed-off-by:
-
Or Cohen authored
Commits 8a4cd82d ("nfc: fix refcount leak in llcp_sock_connect()") and c33b1cc6 ("nfc: fix refcount leak in llcp_sock_bind()") fixed a refcount leak bug in bind/connect but introduced a use-after-free if the same local is assigned to 2 different sockets. This can be triggered by the following simple program: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) ); addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) close(sock1); close(sock2); Fix this by assigning NULL to llcp_sock->local after calling nfc_llcp_local_put. This addresses CVE-2021-23134. Reported-by:
Or Cohen <orcohen@paloaltonetworks.com> Reported-by:
Nadav Markus <nmarkus@paloaltonetworks.com> Fixes: c33b1cc6 ("nfc: fix refcount leak in llcp_sock_bind()") Signed-off-by:
-
Jonathon Reinhart authored
tcp_set_default_congestion_control() is netns-safe in that it writes to &net->ipv4.tcp_congestion_control, but it also sets ca->flags |= TCP_CONG_NON_RESTRICTED which is not namespaced. This has the unintended side-effect of changing the global net.ipv4.tcp_allowed_congestion_control sysctl, despite the fact that it is read-only: 97684f09 ("net: Make tcp_allowed_congestion_control readonly in non-init netns") Resolve this netns "leak" by only allowing the init netns to set the default algorithm to one that is restricted. This restriction could be removed if tcp_allowed_congestion_control were namespace-ified in the future. This bug was uncovered with https://github.com/JonathonReinhart/linux-netns-sysctl-verify Fixes: 6670e152 ("tcp: Namespace-ify sysctl_tcp_default_congestion_control") Signed-off-by:
Jonathon Reinhart <jonathon.reinhart@gmail.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-05-04 The following pull-request contains BPF updates for your *net* tree. We've added 5 non-merge commits during the last 4 day(s) which contain a total of 6 files changed, 52 insertions(+), 30 deletions(-). The main changes are: 1) Fix libbpf overflow when processing BPF ring buffer in case of extreme application behavior, from Brendan Jackman. 2) Fix potential data leakage of uninitialized BPF stack under speculative execution, from Daniel Borkmann. 3) Fix off-by-one when validating xsk pool chunks, from Xuan Zhuo. 4) Fix snprintf BPF selftest with a pid filter to avoid racing its output test buffer, from Florent Revest. ==================== Signed-off-by:
-
- 03 May, 2021 15 commits
-
-
Xuan Zhuo authored
When desc->len is equal to chunk_size, it is legal. But when the xp_aligned_validate_desc() got chunk_end from desc->addr + desc->len pointing to the next chunk during the check, it caused the check to fail. This problem was first introduced in bbff2f32 ("xsk: new descriptor addressing scheme"). Later in 2b43470a ("xsk: Introduce AF_XDP buffer allocation API") this piece of code was moved into the new function called xp_aligned_validate_desc(). This function was then moved into xsk_queue.h via 26062b18 ("xsk: Explicitly inline functions and move definitions"). Fixes: bbff2f32 ("xsk: new descriptor addressing scheme") Signed-off-by:
Xuan Zhuo <xuanzhuo@linux.alibaba.com> Signed-off-by:
Daniel Borkmann <daniel@iogearbox.net> Acked-by:
-
Daniele Palmas authored
Add documentation for /sys/class/net/<iface>/qmi/pass_through Signed-off-by:
Daniele Palmas <dnlplm@gmail.com> Signed-off-by:
-
Xie He authored
This reverts commit 1b479fb8 ("drivers/net/wan/hdlc_fr: Fix a double free in pvc_xmit"). 1. This commit is incorrect. "__skb_pad" will NOT free the skb on failure when its "free_on_error" parameter is "false". 2. This commit claims to fix my commit. But it didn't CC me?? Fixes: 1b479fb8 ("drivers/net/wan/hdlc_fr: Fix a double free in pvc_xmit") Cc: Lv Yunlong <lyl2019@mail.ustc.edu.cn> Signed-off-by:
Xie He <xie.he.0141@gmail.com> Signed-off-by:
-
David S. Miller authored
Xin Long says: ==================== sctp: fix the race condition in sctp_destroy_sock in a proper way The original fix introduced a dead lock, and has to be removed in Patch 1/2, and we will get a proper way to fix it in Patch 2/2. ==================== Signed-off-by: -
Xin Long authored
As Or Cohen described: If sctp_destroy_sock is called without sock_net(sk)->sctp.addr_wq_lock held and sp->do_auto_asconf is true, then an element is removed from the auto_asconf_splist without any proper locking. This can happen in the following functions: 1. In sctp_accept, if sctp_sock_migrate fails. 2. In inet_create or inet6_create, if there is a bpf program attached to BPF_CGROUP_INET_SOCK_CREATE which denies creation of the sctp socket. This patch is to fix it by moving the auto_asconf init out of sctp_init_sock(), by which inet_create()/inet6_create() won't need to operate it in sctp_destroy_sock() when calling sk_common_release(). It also makes more sense to do auto_asconf init while binding the first addr, as auto_asconf actually requires an ANY addr bind, see it in sctp_addr_wq_timeout_handler(). This addresses CVE-2021-23133. Fixes: 61023658 ("bpf: Add new cgroup attach type to enable sock modifications") Reported-by:Xin Long <lucien.xin@gmail.com> Signed-off-by:
-
Xin Long authored
This reverts commit b166a20b. This one has to be reverted as it introduced a dead lock, as syzbot reported: CPU0 CPU1 ---- ---- lock(&net->sctp.addr_wq_lock); lock(slock-AF_INET6); lock(&net->sctp.addr_wq_lock); lock(slock-AF_INET6); CPU0 is the thread of sctp_addr_wq_timeout_handler(), and CPU1 is that of sctp_close(). The original issue this commit fixed will be fixed in the next patch. Reported-by: syzbot+959223586843e69a2674@syzkaller.appspotmail.com Signed-off-by:
-
Phillip Potter authored
Check at start of fill_frame_info that the MAC header in the supplied skb is large enough to fit a struct hsr_ethhdr, as otherwise this is not a valid HSR frame. If it is too small, return an error which will then cause the callers to clean up the skb. Fixes a KMSAN-found uninit-value bug reported by syzbot at: https://syzkaller.appspot.com/bug?id=f7e9b601f1414f814f7602a82b6619a8d80bce3f Reported-by: syzbot+e267bed19bfc5478fb33@syzkaller.appspotmail.com Signed-off-by:
Phillip Potter <phil@philpotter.co.uk> Signed-off-by:
-
Xin Long authored
Normally SCTP_MIB_CURRESTAB is always incremented once asoc enter into ESTABLISHED from the state < ESTABLISHED and decremented when the asoc is being deleted. However, in sctp_sf_do_dupcook_b(), the asoc's state can be changed to ESTABLISHED from the state >= ESTABLISHED where it shouldn't increment SCTP_MIB_CURRESTAB. Otherwise, one asoc may increment MIB_CURRESTAB multiple times but only decrement once at the end. I was able to reproduce it by using scapy to do the 4-way shakehands, after that I replayed the COOKIE-ECHO chunk with 'peer_vtag' field changed to different values, and SCTP_MIB_CURRESTAB was incremented multiple times and never went back to 0 even when the asoc was freed. This patch is to fix it by only incrementing SCTP_MIB_CURRESTAB when the state < ESTABLISHED in sctp_sf_do_dupcook_b(). Fixes: 1da177e4 ("Linux-2.6.12-rc2") Reported-by:
Marcelo Ricardo Leitner <marcelo.leitner@gmail.com> Signed-off-by:
-
David S. Miller authored
Xin Long says: ==================== sctp: fix the incorrect revert commit 35b4f244 ("sctp: do asoc update earlier in sctp_sf_do_dupcook_a") only keeps the SHUTDOWN and COOKIE-ACK with the same asoc, not transport. So instead of revert commit 145cb2f7 ("sctp: Fix bundling of SHUTDOWN with COOKIE-ACK"), we should revert 12dfd78e ("sctp: Fix SHUTDOWN CTSN Ack in the peer restart case"). ==================== Signed-off-by:
-
Xin Long authored
This reverts commit 12dfd78e. This can be reverted as shutdown and cookie_ack chunk are using the same asoc since commit 35b4f244 ("sctp: do asoc update earlier in sctp_sf_do_dupcook_a"). Reported-by:
Jere Leppänen <jere.leppanen@nokia.com> Signed-off-by:
-
Xin Long authored
This reverts commit 7e9269a5. As Jere notice, commit 35b4f244 ("sctp: do asoc update earlier in sctp_sf_do_dupcook_a") only keeps the SHUTDOWN and COOKIE-ACK with the same asoc, not transport. So we have to bring this patch back. Reported-by:
-
Lv Yunlong authored
In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside enic_queue_wq_skb, if some error happens, the skb will be freed by dev_kfree_skb(skb). But the freed skb is still used in skb_tx_timestamp(skb). My patch makes enic_queue_wq_skb() return error and goto spin_unlock() incase of error. The solution is provided by Govind. See https://lkml.org/lkml/2021/4/30/961. Fixes: fb7516d4 ("enic: add sw timestamp support") Signed-off-by:
Lv Yunlong <lyl2019@mail.ustc.edu.cn> Acked-by:
Govindarajulu Varadarajan <gvaradar@cisco.com> Signed-off-by:
-
Brendan Jackman authored
One of our benchmarks running in (Google-internal) CI pushes data through the ringbuf faster htan than userspace is able to consume it. In this case it seems we're actually able to get >INT_MAX entries in a single ring_buffer__consume() call. ASAN detected that cnt overflows in this case. Fix by using 64-bit counter internally and then capping the result to INT_MAX before converting to the int return type. Do the same for the ring_buffer__poll(). Fixes: bf99c936 (libbpf: Add BPF ring buffer support) Signed-off-by:
Brendan Jackman <jackmanb@google.com> Signed-off-by:
Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20210429130510.1621665-1-jackmanb@google.com
-
Daniel Borkmann authored
The current implemented mechanisms to mitigate data disclosure under speculation mainly address stack and map value oob access from the speculative domain. However, Piotr discovered that uninitialized BPF stack is not protected yet, and thus old data from the kernel stack, potentially including addresses of kernel structures, could still be extracted from that 512 bytes large window. The BPF stack is special compared to map values since it's not zero initialized for every program invocation, whereas map values /are/ zero initialized upon their initial allocation and thus cannot leak any prior data in either domain. In the non-speculative domain, the verifier ensures that every stack slot read must have a prior stack slot write by the BPF program to avoid such data leaking issue. However, this is not enough: for example, when the pointer arithmetic operation moves the stack pointer from the last valid stack offset to the first valid offset, the sanitation logic allows for any intermediate offsets during speculative execution, which could then be used to extract any restricted stack content via side-channel. Given for unprivileged stack pointer arithmetic the use of unknown but bounded scalars is generally forbidden, we can simply turn the register-based arithmetic operation into an immediate-based arithmetic operation without the need for masking. This also gives the benefit of reducing the needed instructions for the operation. Given after the work in 7fedb63a ("bpf: Tighten speculative pointer arithmetic mask"), the aux->alu_limit already holds the final immediate value for the offset register with the known scalar. Thus, a simple mov of the immediate to AX register with using AX as the source for the original instruction is sufficient and possible now in this case. Reported-by:
Piotr Krysiuk <piotras@gmail.com> Signed-off-by:
John Fastabend <john.fastabend@gmail.com> Acked-by:
Alexei Starovoitov <ast@kernel.org>
-
Daniel Borkmann authored
The negation logic for the case where the off_reg is sitting in the dst register is not correct given then we cannot just invert the add to a sub or vice versa. As a fix, perform the final bitwise and-op unconditionally into AX from the off_reg, then move the pointer from the src to dst and finally use AX as the source for the original pointer arithmetic operation such that the inversion yields a correct result. The single non-AX mov in between is possible given constant blinding is retaining it as it's not an immediate based operation. Fixes: 979d63d5 ("bpf: prevent out of bounds speculation on pointer arithmetic") Signed-off-by:
-
- 30 Apr, 2021 4 commits
-
-
Wan Jiabing authored
In commit f4da5652 ("net: stmmac: Add support for external trigger timestamping"), struct stmmac_priv was declared at line 507 which caused duplicate struct declarations. Remove later duplicate declaration here. Signed-off-by:
Wan Jiabing <wanjiabing@vivo.com> Reviewed-by:
Wong Vee Khee <vee.khee.wong@linux.intel.com> Signed-off-by:
-
Maxim Kochetkov authored
A number of PHYs support the PHY tunable to set and get downshift. However, only 88E1116R enables downshift by default. Extend this default enabled to all the PHYs that support the downshift tunable. Signed-off-by:
Maxim Kochetkov <fido_max@inbox.ru> Reviewed-by:
Andrew Lunn <andrew@lunn.ch> Signed-off-by:
-
David S. Miller authored
Xin Long says: ==================== sctp: always send a chunk with the asoc that it belongs to Currently when processing a duplicate COOKIE-ECHO chunk, a new temp asoc would be created, then it creates the chunks with the new asoc. However, later on it uses the old asoc to send these chunks, which has caused quite a few issues. This patchset is to fix this and make sure that the COOKIE-ACK and SHUTDOWN chunks are created with the same asoc that will be used to send them out. v1->v2: - see Patch 3/3. ==================== Acked-by:
-
Xin Long authored
The same thing should be done for sctp_sf_do_dupcook_b(). Meanwhile, SCTP_CMD_UPDATE_ASSOC cmd can be removed. v1->v2: - Fix the return value in sctp_sf_do_assoc_update(). Signed-off-by:
-
