- 03 6月, 2021 40 次提交
-
-
由 Sean Christopherson 提交于
stable inclusion from stable-5.10.37 commit 8fcdfa71ba6a1baa7bff73353b914df2a15b1bb8 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit dbdd096a ] Disable pass-through of the FS and GS base MSRs for 32-bit KVM. Intel's SDM unequivocally states that the MSRs exist if and only if the CPU supports x86-64. FS_BASE and GS_BASE are mostly a non-issue; a clever guest could opportunistically use the MSRs without issue. KERNEL_GS_BASE is a bigger problem, as a clever guest would subtly be broken if it were migrated, as KVM disallows software access to the MSRs, and unlike the direct variants, KERNEL_GS_BASE needs to be explicitly migrated as it's not captured in the VMCS. Fixes: 25c5f225 ("KVM: VMX: Enable MSR Bitmap feature") Signed-off-by: NSean Christopherson <seanjc@google.com> Message-Id: <20210422023831.3473491-1-seanjc@google.com> [*NOT* for stable kernels. - Paolo] Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Michael Chan 提交于
stable inclusion from stable-5.10.37 commit 4fcaad2b7dac3f16704f8118c7e481024ddbd3ed bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit bbd6f0a9 ] In bnxt_rx_pkt(), the RX buffers are expected to complete in order. If the RX consumer index indicates an out of order buffer completion, it means we are hitting a hardware bug and the driver will abort all remaining RX packets and reset the RX ring. The RX consumer index that we pass to bnxt_discard_rx() is not correct. We should be passing the current index (tmp_raw_cons) instead of the old index (raw_cons). This bug can cause us to be at the wrong index when trying to abort the next RX packet. It can crash like this: #0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007 #1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232 #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e #3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978 #4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0 #5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24 #7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e #8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12 #9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5 [exception RIP: bnxt_rx_pkt+237] RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213 RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000 RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000 RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0 R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 Fixes: a1b0e4e6 ("bnxt_en: Improve RX consumer index validity check.") Reviewed-by: NPavan Chebbi <pavan.chebbi@broadcom.com> Reviewed-by: NAndy Gospodarek <gospo@broadcom.com> Signed-off-by: NMichael Chan <michael.chan@broadcom.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Danielle Ratson 提交于
stable inclusion from stable-5.10.37 commit 1625872f012c8ccdcbd77ed14102f9f4cb6ed907 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 1f1c9213 ] Currently, the error return code of the failure condition is lost after using an if statement, so the test doesn't fail when it should. Remove the if statement that separates the condition and the error code check, so the test won't always pass. Fixes: abfce9e0 ("selftests: mlxsw: Reduce running time using offload indication") Reported-by: NIdo Schimmel <idosch@nvidia.com> Signed-off-by: NDanielle Ratson <danieller@nvidia.com> Reviewed-by: NPetr Machata <petrm@nvidia.com> Signed-off-by: NPetr Machata <petrm@nvidia.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Petr Machata 提交于
stable inclusion from stable-5.10.37 commit 8ebdce8fe0b0da1ac6147c945c1c42ba2f772e24 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit c8d0260c ] The FDB roaming test installs a destination MAC address on the wrong interface of an FDB database and tests whether the mirroring fails, because packets are sent to the wrong port. The test by mistake installs the FDB entry as local. This worked previously, because drivers were notified of local FDB entries in the same way as of static entries. However that has been fixed in the commit 6ab4c311 ("net: bridge: don't notify switchdev for local FDB addresses"), and local entries are not notified anymore. As a result, the HW is not reconfigured for the FDB roam, and mirroring keeps working, failing the test. To fix the issue, mark the FDB entry as static. Fixes: 9c7c8a82 ("selftests: forwarding: mirror_gre_vlan_bridge_1q: Add more tests") Signed-off-by: NPetr Machata <petrm@nvidia.com> Reviewed-by: NIdo Schimmel <idosch@nvidia.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Phillip Potter 提交于
stable inclusion from stable-5.10.37 commit 71ad9260c001b217d704cda88ecea251b2d367da bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit d13f048d ] Modify the header size check in geneve6_xmit_skb and geneve_xmit_skb to use pskb_inet_may_pull rather than pskb_network_may_pull. This fixes two kernel selftest failures introduced by the commit introducing the checks: IPv4 over geneve6: PMTU exceptions IPv4 over geneve6: PMTU exceptions - nexthop objects It does this by correctly accounting for the fact that IPv4 packets may transit over geneve IPv6 tunnels (and vice versa), and still fixes the uninit-value bug fixed by the original commit. Reported-by: Nkernel test robot <oliver.sang@intel.com> Fixes: 6628ddfe ("net: geneve: check skb is large enough for IPv4/IPv6 header") Suggested-by: NSabrina Dubroca <sd@queasysnail.net> Signed-off-by: NPhillip Potter <phil@philpotter.co.uk> Acked-by: NSabrina Dubroca <sd@queasysnail.net> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Kunihiko Hayashi 提交于
stable inclusion from stable-5.10.37 commit 1fc61844b6a2011627cfa58a82c6f5fed208b084 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit dcabb06b ] UniPhier LD20 and PXs3 boards have RTL8211E ethernet phy, and the phy have the RX/TX delays of RGMII interface using pull-ups on the RXDLY and TXDLY pins. After the commit bbc4d71d ("net: phy: realtek: fix rtl8211e rx/tx delay config"), the delays are working correctly, however, "rgmii" means no delay and the phy doesn't work. So need to set the phy-mode to "rgmii-id" to show that RX/TX delays are enabled. Fixes: c73730ee ("arm64: dts: uniphier: add AVE ethernet node") Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Kunihiko Hayashi 提交于
stable inclusion from stable-5.10.37 commit 0ae610556f238df7a36e4ffb0066ef0b6c71aecc bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 9ba585cc ] UniPhier PXs2 boards have RTL8211E ethernet phy, and the phy have the RX/TX delays of RGMII interface using pull-ups on the RXDLY and TXDLY pins. After the commit bbc4d71d ("net: phy: realtek: fix rtl8211e rx/tx delay config"), the delays are working correctly, however, "rgmii" means no delay and the phy doesn't work. So need to set the phy-mode to "rgmii-id" to show that RX/TX delays are enabled. Fixes: e3cc9319 ("ARM: dts: uniphier: add AVE ethernet node") Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Dan Carpenter 提交于
stable inclusion from stable-5.10.37 commit 66b1cfc0cd87a3c087fed66c24a3c7422d33dffe bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 27537929 ] The problem is that bnxt_show_temp() returns long but "rc" is an int and "len" is a u32. With ternary operations the type promotion is quite tricky. The negative "rc" is first promoted to u32 and then to long so it ends up being a high positive value instead of a a negative as we intended. Fix this by removing the ternary. Fixes: d69753fa ("bnxt_en: return proper error codes in bnxt_show_temp") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Arnd Bergmann 提交于
stable inclusion from stable-5.10.37 commit 9f722ef596fefec48cd7105025bd5ff4a29cc968 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 74c97ea3 ] A link time bug that I had fixed before has come back now that another sub-module was added to the enetc driver: ERROR: modpost: "enetc_ierb_register_pf" [drivers/net/ethernet/freescale/enetc/fsl-enetc.ko] undefined! The problem is that the enetc Makefile is not actually used for the ierb module if that is the only built-in driver in there and everything else is a loadable module. Fix it by always entering the directory this time, regardless of which symbols are configured. This should reliably fix the problem and prevent it from coming back another time. Fixes: 112463dd ("net: dsa: felix: fix link error") Fixes: e7d48e5f ("net: enetc: add a mini driver for the Integrated Endpoint Register Block") Signed-off-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NVladimir Oltean <vladimir.oltean@nxp.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Maxim Kochetkov 提交于
stable inclusion from stable-5.10.37 commit bfcb5a8cc7b669a30e3950fc9c2a421e3244dbc8 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit e7679c55 ] Changing downshift params without software reset has no effect, so call genphy_soft_reset() after change downshift params. As the datasheet says: Changes to these bits are disruptive to the normal operation therefore, any changes to these registers must be followed by software reset to take effect. Fixes: 5c6bc519 ("net: phy: marvell: add downshift support for M88E1111") Signed-off-by: NMaxim Kochetkov <fido_max@inbox.ru> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Maxim Kochetkov 提交于
stable inclusion from stable-5.10.37 commit 1157d01e04d90dde889b6bd5342df33b5db39949 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 990875b2 ] Changing downshift params without software reset has no effect, so call genphy_soft_reset() after change downshift params. As the datasheet says: Changes to these bits are disruptive to the normal operation therefore, any changes to these registers must be followed by software reset to take effect. Fixes: 911af5e1 ("net: phy: marvell: fix downshift function naming") Signed-off-by: NMaxim Kochetkov <fido_max@inbox.ru> Reviewed-by: NAndrew Lunn <andrew@lunn.ch> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Christophe Leroy 提交于
stable inclusion from stable-5.10.37 commit be631825652f1731e291a3aab3c56dc00bb3b91c bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 8a87a507 ] AS arch/powerpc/platforms/52xx/lite5200_sleep.o arch/powerpc/platforms/52xx/lite5200_sleep.S: Assembler messages: arch/powerpc/platforms/52xx/lite5200_sleep.S:184: Warning: invalid register expression In the following code, 'addi' is wrong, has to be 'add' /* local udelay in sram is needed */ udelay: /* r11 - tb_ticks_per_usec, r12 - usecs, overwrites r13 */ mullw r12, r12, r11 mftb r13 /* start */ addi r12, r13, r12 /* end */ Fixes: ee983079 ("[POWERPC] MPC5200 low power mode") Signed-off-by: NChristophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/cb4cec9131c8577803367f1699209a7e104cec2a.1619025821.git.christophe.leroy@csgroup.euSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Athira Rajeev 提交于
stable inclusion from stable-5.10.37 commit e06a532f31c4c435153d24f2279825a4684e3f1c bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 66d9b749 ] Memory events (mem-loads and mem-stores) currently use the threshold event selection as issue to finish. Power10 supports issue to complete as part of thresholding which is more appropriate for mem-loads and mem-stores. Hence fix the event code for memory events to use issue to complete. Fixes: a64e697c ("powerpc/perf: power10 Performance Monitoring support") Signed-off-by: NAthira Rajeev <atrajeev@linux.vnet.ibm.com> Reviewed-by: NMadhavan Srinivasan <maddy@linux.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/1614840015-1535-1-git-send-email-atrajeev@linux.vnet.ibm.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Colin Ian King 提交于
stable inclusion from stable-5.10.37 commit b6b894e7a27e52a9032a7eaace538538830d4b9e bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit a9a4c080 ] The size of the buffer than can be written to is currently incorrect, it is always the size of the entire buffer even though the snprintf is writing as position pos into the buffer. Fix this by setting the buffer size to be the number of bytes left in the buffer, namely sizeof(buf) - pos. Addresses-Coverity: ("Out-of-bounds access") Fixes: 7b0e2c4f ("wlcore: fix overlapping snprintf arguments in debugfs") Signed-off-by: NColin Ian King <colin.king@canonical.com> Reviewed-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210419141405.180582-1-colin.king@canonical.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Shuah Khan 提交于
stable inclusion from stable-5.10.37 commit 1cce33fe59f095c6198de32e5fcda36e703dfddb bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit eaaf52e4 ] ath10k_wmi_tlv_op_pull_peer_stats_info() could try to unlock RCU lock winthout locking it first when peer reason doesn't match the valid cases for this function. Add a default case to return without unlocking. Fixes: 09078368 ("ath10k: hold RCU lock when calling ieee80211_find_sta_by_ifaddr()") Reported-by: NPavel Machek <pavel@ucw.cz> Signed-off-by: NShuah Khan <skhan@linuxfoundation.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210406230228.31301-1-skhan@linuxfoundation.orgSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Lv Yunlong 提交于
stable inclusion from stable-5.10.37 commit 8bb054fb336f4250002fff4e0b075221c05c3c65 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 8392df5d ] In ath10k_htc_send_bundle, the bundle_skb could be freed by dev_kfree_skb_any(bundle_skb). But the bundle_skb is used later by bundle_skb->len. As skb_len = bundle_skb->len, my patch replaces bundle_skb->len to skb_len after the bundle_skb was freed. Fixes: c8334512 ("ath10k: add htt TX bundle for sdio") Signed-off-by: NLv Yunlong <lyl2019@mail.ustc.edu.cn> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210329120154.8963-1-lyl2019@mail.ustc.edu.cnSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Toke Høiland-Jørgensen 提交于
stable inclusion from stable-5.10.37 commit 0f98e1ea970cdb7395f4d4964ac7d19955268006 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 7dd9a40f ] When the error check in ath9k_hw_read_revisions() was added, it checked for -EIO which is what ath9k_regread() in the ath9k_htc driver uses. However, for plain ath9k, the register read function uses ioread32(), which just returns -1 on error. So if such a read fails, it still gets passed through and ends up as a weird mac revision in the log output. Fix this by changing ath9k_regread() to return -1 on error like ioread32() does, and fix the error check to look for that instead of -EIO. Fixes: 2f90c7e5 ("ath9k: Check for errors when reading SREV register") Signed-off-by: NToke Høiland-Jørgensen <toke@redhat.com> Reviewed-by: NLorenzo Bianconi <lorenzo@kernel.org> Signed-off-by: NKalle Valo <kvalo@codeaurora.org> Link: https://lore.kernel.org/r/20210326180819.142480-1-toke@redhat.comSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Christophe Leroy 提交于
stable inclusion from stable-5.10.37 commit 4b9fb2c9039a206d37f215936a4d5bee7b1bf9cd bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 9ccba66d ] At the time being, the fixmap area is defined at the top of the address space or just below KASAN. This definition is not valid for PPC64. For PPC64, use the top of the I/O space. Because of circular dependencies, it is not possible to include asm/fixmap.h in asm/book3s/64/pgtable.h , so define a fixed size AREA at the top of the I/O space for fixmap and ensure during build that the size is big enough. Fixes: 265c3491 ("powerpc: Add support for GENERIC_EARLY_IOREMAP") Signed-off-by: NChristophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/0d51620eacf036d683d1a3c41328f69adb601dc0.1618925560.git.christophe.leroy@csgroup.euSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Shay Drory 提交于
stable inclusion from stable-5.10.37 commit c5ebaca402f5c5bd61ac8316feb2aa3a0be4d4a8 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit cb5cd0ea ] The device attach triggers addition of CM_ID to the restrack DB. However, when error occurs, we releasing this device, but defer CM_ID release. This causes to the situation where restrack sees CM_ID that is not valid anymore. As a solution, add the CM_ID to the resource tracking DB only after the attachment is finished. Found by syzcaller: infiniband syz0: added syz_tun rdma_rxe: ignoring netdev event = 10 for syz_tun infiniband syz0: set down infiniband syz0: ib_query_port failed (-19) restrack: ------------[ cut here ]------------ infiniband syz0: BUG: RESTRACK detected leak of resources restrack: User CM_ID object allocated by syz-executor716 is not freed restrack: ------------[ cut here ]------------ Fixes: b09c4d70 ("RDMA/restrack: Improve readability in task name management") Link: https://lore.kernel.org/r/ab93e56ba831eac65c322b3256796fa1589ec0bb.1618753862.git.leonro@nvidia.comSigned-off-by: NShay Drory <shayd@nvidia.com> Signed-off-by: NLeon Romanovsky <leonro@nvidia.com> Signed-off-by: NJason Gunthorpe <jgg@nvidia.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Bob Pearson 提交于
stable inclusion from stable-5.10.37 commit 63c61d26e3fbee4d4f7a420f3cc5b93f52c3459f bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 45062f44 ] Fix a bug in rxe_fill_ip_info() which was attempting to convert from RDMA_NETWORK_XXX to RXE_NETWORK_XXX. .._IPV6 should have mapped to .._IPV6 not .._IPV4. Fixes: edebc840 ("RDMA/rxe: Fix small problem in network_type patch") Link: https://lore.kernel.org/r/20210421035952.4892-1-rpearson@hpe.comSuggested-by: NFrank Zago <frank.zago@hpe.com> Signed-off-by: NBob Pearson <rpearson@hpe.com> Acked-by: NZhu Yanjun <zyjzyj2000@gmail.com> Signed-off-by: NJason Gunthorpe <jgg@nvidia.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Martin Schiller 提交于
stable inclusion from stable-5.10.37 commit 7fe12d6db3f04b4c95a24532046a115443e70f5a bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 357a07c2 ] The Intel xway phys offer the possibility to deactivate the integrated LED function and to control the LEDs manually. If this was set by the bootloader, it must be ensured that the integrated LED function is enabled for all LEDs when loading the driver. Before commit 6e2d85ec ("net: phy: Stop with excessive soft reset") the LEDs were enabled by a soft-reset of the PHY (using genphy_soft_reset). Initialize the XWAY_MDIO_LED with it's default value (which is applied during a soft reset) instead of adding back the soft reset. This brings back the default LED configuration while still preventing an excessive amount of soft resets. Fixes: 6e2d85ec ("net: phy: Stop with excessive soft reset") Signed-off-by: NMartin Schiller <ms@dev.tdt.de> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yoshihiro Shimoda 提交于
stable inclusion from stable-5.10.37 commit cf49a91faa7db78ab156b784ec44a74cb3a210d7 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 5718458b ] When a lot of frames were received in the short term, the driver caused a stuck of receiving until a new frame was received. For example, the following command from other device could cause this issue. $ sudo ping -f -l 1000 -c 1000 <this driver's ipaddress> The previous code always cleared the interrupt flag of RX but checks the interrupt flags in ravb_poll(). So, ravb_poll() could not call ravb_rx() in the next time until a new RX frame was received if ravb_rx() returned true. To fix the issue, always calls ravb_rx() regardless the interrupt flags condition. Fixes: c156633f ("Renesas Ethernet AVB driver proper") Signed-off-by: NYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ong Boon Leong 提交于
stable inclusion from stable-5.10.37 commit 01dab91200dc6edda96d9694a4ff7afb025f9590 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 5e6038b8 ] TSO and TBS cannot co-exist and current implementation requires two fixes: 1) stmmac_open() does not need to call stmmac_enable_tbs() because the MAC is reset in stmmac_init_dma_engine() anyway. 2) Inside stmmac_hw_setup(), we should call stmmac_enable_tso() for TX Q that is _not_ configured for TBS. Fixes: 579a25a8 ("net: stmmac: Initial support for TBS") Signed-off-by: NOng Boon Leong <boon.leong.ong@intel.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Yinjun Zhang 提交于
stable inclusion from stable-5.10.37 commit 64753ac1e43e3a1d1e0a467b2d51f18956f71be7 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 90b669d6 ] The number of lanes of devlink port should be correctly initialized when registering the port, so that the input check when running "devlink port split <port> count <N>" can pass. Fixes: a21cf0a8 ("devlink: Add a new devlink port lanes attribute and pass to netlink") Signed-off-by: NYinjun Zhang <yinjun.zhang@corigine.com> Signed-off-by: NLouis Peens <louis.peens@corigine.com> Signed-off-by: NSimon Horman <simon.horman@netronome.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Sean Christopherson 提交于
stable inclusion from stable-5.10.37 commit e606073b77a3c4a6f3f6b013deef36f75aef5737 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 74c1f136 ] Explicitly reject using pointers that are not virt_to_phys() friendly as the source for SEV commands that are sent to the PSP. The PSP works with physical addresses, and __pa()/virt_to_phys() will not return the correct address in these cases, e.g. for a vmalloc'd pointer. At best, the bogus address will cause the command to fail, and at worst lead to system instability. While it's unlikely that callers will deliberately use a bad pointer for SEV buffers, a caller can easily use a vmalloc'd pointer unknowingly when running with CONFIG_VMAP_STACK=y as it's not obvious that putting the command buffers on the stack would be bad. The command buffers are relative small and easily fit on the stack, and the APIs to do not document that the incoming pointer must be a physically contiguous, __pa() friendly pointer. Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Borislav Petkov <bp@suse.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Fixes: 200664d5 ("crypto: ccp: Add Secure Encrypted Virtualization (SEV) command support") Signed-off-by: NSean Christopherson <seanjc@google.com> Message-Id: <20210406224952.4177376-3-seanjc@google.com> Reviewed-by: NBrijesh Singh <brijesh.singh@amd.com> Acked-by: NTom Lendacky <thomas.lendacky@amd.com> Signed-off-by: NPaolo Bonzini <pbonzini@redhat.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Ryder Lee 提交于
stable inclusion from stable-5.10.37 commit 4fa28c807da54c1d720b3cc12e48eb9bea1e2c8f bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 8ab31da7 ] mt7615_tx_token_put() should get call before mt76_free_pending_txwi(). Fixes: a6275e93 ("mt76: mt7615: reset token when mac_reset happens") Signed-off-by: NRyder Lee <ryder.lee@mediatek.com> Signed-off-by: NFelix Fietkau <nbd@nbd.name> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Colin Ian King 提交于
stable inclusion from stable-5.10.37 commit 9ed951f416435c9bc1293c8f08b6d625cc334860 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit d83b8aa5 ] The bit-masks used for the TXERRCH and RXERRCH (tx and rx error channels) are incorrect and always lead to a zero result. The mask values are currently the incorrect post-right shifted values, fix this by setting them to the currect values. (I double checked these against the TMS320TCI6482 data sheet, section 5.30, page 127 to ensure I had the correct mask values for the TXERRCH and RXERRCH fields in the MACSTATUS register). Addresses-Coverity: ("Operands don't affect result") Fixes: a6286ee6 ("net: Add TI DaVinci EMAC driver") Signed-off-by: NColin Ian King <colin.king@canonical.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Vadym Kochan 提交于
stable inclusion from stable-5.10.37 commit 0ce6052802be2cb61a57b753e41301339c88c839 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 33398048 ] For some reason there might be a crash during ports creation if port events are handling at the same time because fw may send initial port event with down state. The crash points to cancel_delayed_work() which is called when port went is down. Currently I did not find out the real cause of the issue, so fixed it by cancel port stats work only if previous port's state was up & runnig. The following is the crash which can be triggered: [ 28.311104] Unable to handle kernel paging request at virtual address 000071775f776600 [ 28.319097] Mem abort info: [ 28.321914] ESR = 0x96000004 [ 28.324996] EC = 0x25: DABT (current EL), IL = 32 bits [ 28.330350] SET = 0, FnV = 0 [ 28.333430] EA = 0, S1PTW = 0 [ 28.336597] Data abort info: [ 28.339499] ISV = 0, ISS = 0x00000004 [ 28.343362] CM = 0, WnR = 0 [ 28.346354] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000100bf7000 [ 28.352842] [000071775f776600] pgd=0000000000000000, p4d=0000000000000000 [ 28.359695] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 28.365310] Modules linked in: prestera_pci(+) prestera uio_pdrv_genirq [ 28.372005] CPU: 0 PID: 1291 Comm: kworker/0:1H Not tainted 5.11.0-rc4 #1 [ 28.378846] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 28.384283] Workqueue: prestera_fw_wq prestera_fw_evt_work_fn [prestera_pci] [ 28.391413] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--) [ 28.397468] pc : get_work_pool+0x48/0x60 [ 28.401442] lr : try_to_grab_pending+0x6c/0x1b0 [ 28.406018] sp : ffff80001391bc60 [ 28.409358] x29: ffff80001391bc60 x28: 0000000000000000 [ 28.414725] x27: ffff000104fc8b40 x26: ffff80001127de88 [ 28.420089] x25: 0000000000000000 x24: ffff000106119760 [ 28.425452] x23: ffff00010775dd60 x22: ffff00010567e000 [ 28.430814] x21: 0000000000000000 x20: ffff80001391bcb0 [ 28.436175] x19: ffff00010775deb8 x18: 00000000000000c0 [ 28.441537] x17: 0000000000000000 x16: 000000008d9b0e88 [ 28.446898] x15: 0000000000000001 x14: 00000000000002ba [ 28.452261] x13: 80a3002c00000002 x12: 00000000000005f4 [ 28.457622] x11: 0000000000000030 x10: 000000000000000c [ 28.462985] x9 : 000000000000000c x8 : 0000000000000030 [ 28.468346] x7 : ffff800014400000 x6 : ffff000106119758 [ 28.473708] x5 : 0000000000000003 x4 : ffff00010775dc60 [ 28.479068] x3 : 0000000000000000 x2 : 0000000000000060 [ 28.484429] x1 : 000071775f776600 x0 : ffff00010775deb8 [ 28.489791] Call trace: [ 28.492259] get_work_pool+0x48/0x60 [ 28.495874] cancel_delayed_work+0x38/0xb0 [ 28.500011] prestera_port_handle_event+0x90/0xa0 [prestera] [ 28.505743] prestera_evt_recv+0x98/0xe0 [prestera] [ 28.510683] prestera_fw_evt_work_fn+0x180/0x228 [prestera_pci] [ 28.516660] process_one_work+0x1e8/0x360 [ 28.520710] worker_thread+0x44/0x480 [ 28.524412] kthread+0x154/0x160 [ 28.527670] ret_from_fork+0x10/0x38 [ 28.531290] Code: a8c17bfd d50323bf d65f03c0 9278dc21 (f9400020) [ 28.537429] ---[ end trace 5eced933df3a080b ]--- Fixes: 501ef306 ("net: marvell: prestera: Add driver for Prestera family ASIC devices") Signed-off-by: NVadym Kochan <vkochan@marvell.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Stefano Garzarella 提交于
stable inclusion from stable-5.10.37 commit b605673b523fe33abeafb2136759bcbc9c1e6ebf bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 8432b811 ] As reported by syzbot [1], there is a memory leak while closing the socket. We partially solved this issue with commit ac03046e ("vsock/virtio: free packets during the socket release"), but we forgot to drain the RX queue when the socket is definitely closed by the scheduled work. To avoid future issues, let's use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock(). [1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9 Fixes: ac03046e ("vsock/virtio: free packets during the socket release") Reported-and-tested-by: syzbot+24452624fc4c571eedd9@syzkaller.appspotmail.com Signed-off-by: NStefano Garzarella <sgarzare@redhat.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Edward Cree 提交于
stable inclusion from stable-5.10.37 commit 5231d17eb9d004f5721358c11cac01244c5c9c88 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 172e269e ] We're starting from a TXQ label, not a TXQ type, so efx_channel_get_tx_queue() is inappropriate. This worked by chance, because labels and types currently match on EF10, but we shouldn't rely on that. Fixes: 12804793 ("sfc: decouple TXQ type from label") Signed-off-by: NEdward Cree <ecree.xilinx@gmail.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Colin Ian King 提交于
stable inclusion from stable-5.10.37 commit 7459bb5943285b025bc1d16ea7c57bb5a09e1b8e bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit cfd577ac ] Currently when the call to usb_urb_ep_type_check fails (returning -EINVAL) the error return path returns -ENOMEM via the exit label "error". Other uses of the same error exit label set the err variable to -ENOMEM but this is not being used. I believe the original intent was for the error exit path to return the value in err rather than the hard coded -ENOMEM, so return this rather than the hard coded -ENOMEM. Addresses-Coverity: ("Unused value") Fixes: 738d9edc ("ALSA: usb-audio: Add sanity checks for invalid EPs") Signed-off-by: NColin Ian King <colin.king@canonical.com> Link: https://lore.kernel.org/r/20210420134719.381409-1-colin.king@canonical.comSigned-off-by: NTakashi Iwai <tiwai@suse.de> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Sindhu Devale 提交于
stable inclusion from stable-5.10.37 commit 312c5ce349426ad4771571ce0442f31a4045184d bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 783a11bf ] When i40iw_hmc_sd_one fails, chunk is freed without the deletion of chunk entry in the PBLE info list. Fix it by adding the chunk entry to the PBLE info list only after successful addition of SD in i40iw_hmc_sd_one. This fixes a static checker warning reported here: https://lore.kernel.org/linux-rdma/YHV4CFXzqTm23AOZ@mwanda/ Fixes: 97158301 ("i40iw: add pble resource files") Link: https://lore.kernel.org/r/20210416002104.323-1-shiraz.saleem@intel.comReported-by: NDan Carpenter <dan.carpenter@oracle.com> Signed-off-by: NSindhu Devale <sindhu.devale@intel.com> Signed-off-by: NShiraz Saleem <shiraz.saleem@intel.com> Signed-off-by: NJason Gunthorpe <jgg@nvidia.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Potnuri Bharat Teja 提交于
stable inclusion from stable-5.10.37 commit 45b84abb47a9c7d05d046e93e8a3769ebee25dfa bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 3a668438 ] missing qpid increment leads to skipping few qpids while allocating QP. This eventually leads to adapter running out of qpids after establishing fewer connections than it actually supports. Current patch increments the qpid correctly. Fixes: cfdda9d7 ("RDMA/cxgb4: Add driver for Chelsio T4 RNIC") Link: https://lore.kernel.org/r/20210415151422.9139-1-bharat@chelsio.comSigned-off-by: NPotnuri Bharat Teja <bharat@chelsio.com> Signed-off-by: NJason Gunthorpe <jgg@nvidia.com> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Alexander Lobakin 提交于
stable inclusion from stable-5.10.37 commit da54cc2549399072b95926dbe9dc44546c297e75 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 7ad18ff6 ] Commit 38ec4944 ("gro: ensure frag0 meets IP header alignment") did the right thing, but missed the fact that napi_gro_frags() logics calls for skb_gro_reset_offset() *before* pulling Ethernet header to the skb linear space. That said, the introduced check for frag0 address being aligned to 4 always fails for it as Ethernet header is obviously 14 bytes long, and in case with NET_IP_ALIGN its start is not aligned to 4. Fix this by adding @nhoff argument to skb_gro_reset_offset() which tells if an IP header is placed right at the start of frag0 or not. This restores Fast GRO for napi_gro_frags() that became very slow after the mentioned commit, and preserves the introduced check to avoid silent unaligned accesses. From v1 [0]: - inline tiny skb_gro_reset_offset() to let the code be optimized more efficively (esp. for the !NET_IP_ALIGN case) (Eric); - pull in Reviewed-by from Eric. [0] https://lore.kernel.org/netdev/20210418114200.5839-1-alobakin@pm.me Fixes: 38ec4944 ("gro: ensure frag0 meets IP header alignment") Reviewed-by: NEric Dumazet <edumazet@google.com> Signed-off-by: NAlexander Lobakin <alobakin@pm.me> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Linus Walleij 提交于
stable inclusion from stable-5.10.37 commit 257f38e78aa3545a1c4637e0cd942d39b486e71f bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 8d892d60 ] The former fix only papered over the actual problem: the ethernet core expects the netdev .dev member to have the proper DMA masks set, or there will be BUG_ON() triggered in kernel/dma/mapping.c. Fix this by simply copying dma_mask and dma_mask_coherent from the parent device. Fixes: e45d0fad ("net: ethernet: ixp4xx: Use parent dev for DMA pool") Signed-off-by: NLinus Walleij <linus.walleij@linaro.org> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Florent Revest 提交于
stable inclusion from stable-5.10.37 commit 78d8b34751cf3c61b8dcd6ac40b0fc453de3c6a3 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 83cd92b4 ] When initializing the __param array with a one liner, if all args are const, the initial array value will be placed in the rodata section but because libbpf does not support relocation in the rodata section, any pointer in this array will stay NULL. Fixes: c09add2f ("tools/libbpf: Add bpf_iter support") Signed-off-by: NFlorent Revest <revest@chromium.org> Signed-off-by: NAlexei Starovoitov <ast@kernel.org> Acked-by: NAndrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20210419155243.1632274-5-revest@chromium.orgSigned-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Stefano Garzarella 提交于
stable inclusion from stable-5.10.37 commit b9e719698fc498551e7a580fea45dde07eb96f58 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit e16edc99 ] VMCI feature is not supported in conjunction with the vSphere Fault Tolerance (FT) feature. VMware Tools can repeatedly try to create a vsock connection. If FT is enabled the kernel logs is flooded with the following messages: qp_alloc_hypercall result = -20 Could not attach to queue pair with -20 "qp_alloc_hypercall result = -20" was hidden by commit e8266c4c ("VMCI: Stop log spew when qp allocation isn't possible"), but "Could not attach to queue pair with -20" is still there flooding the log. Since the error message can be useful in some cases, print it only once. Fixes: d021c344 ("VSOCK: Introduce VM Sockets") Signed-off-by: NStefano Garzarella <sgarzare@redhat.com> Reviewed-by: NJorgen Hansen <jhansen@vmware.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Pablo Neira Ayuso 提交于
stable inclusion from stable-5.10.37 commit bc2e5321d7f11b9a972110b303ea7172959b9def bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 783003f3 ] The nftables offload parser sets FLOW_DISSECTOR_KEY_BASIC .n_proto to the ethertype field in the ethertype frame. However: - FLOW_DISSECTOR_KEY_BASIC .n_proto field always stores either IPv4 or IPv6 ethertypes. - FLOW_DISSECTOR_KEY_VLAN .vlan_tpid stores either the 802.1q and 802.1ad ethertypes. Same as for FLOW_DISSECTOR_KEY_CVLAN. This function adjusts the flow dissector to handle two scenarios: 1) FLOW_DISSECTOR_KEY_VLAN .vlan_tpid is set to 802.1q or 802.1ad. Then, transfer: - the .n_proto field to FLOW_DISSECTOR_KEY_VLAN .tpid. - the original FLOW_DISSECTOR_KEY_VLAN .tpid to the FLOW_DISSECTOR_KEY_CVLAN .tpid - the original FLOW_DISSECTOR_KEY_CVLAN .tpid to the .n_proto field. 2) .n_proto is set to 802.1q or 802.1ad. Then, transfer: - the .n_proto field to FLOW_DISSECTOR_KEY_VLAN .tpid. - the original FLOW_DISSECTOR_KEY_VLAN .tpid to the .n_proto field. Fixes: a82055af ("netfilter: nft_payload: add VLAN offload support") Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Pablo Neira Ayuso 提交于
stable inclusion from stable-5.10.37 commit a7eb38aacc81623f338d6c6f19604ace2fe4ec15 bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit ff4d90a8 ] The flow dissector representation expects the VLAN id in host byteorder. Add the NFT_OFFLOAD_F_NETWORK2HOST flag to swap the bytes from nft_cmp. Fixes: a82055af ("netfilter: nft_payload: add VLAN offload support") Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-
由 Pablo Neira Ayuso 提交于
stable inclusion from stable-5.10.37 commit cf2de861b2794f98363072e078ac9375d8e8f83e bugzilla: 51868 CVE: NA -------------------------------- [ Upstream commit 14c20643 ] - add another struct flow_dissector_key_vlan for C-VLAN - update layer 3 dependency to allow to match on IPv4/IPv6 Fixes: 89d8fd44 ("netfilter: nft_payload: add C-VLAN offload support") Signed-off-by: NPablo Neira Ayuso <pablo@netfilter.org> Signed-off-by: NSasha Levin <sashal@kernel.org> Signed-off-by: NChen Jun <chenjun102@huawei.com> Acked-by: NWeilong Chen <chenweilong@huawei.com> Signed-off-by: NZheng Zengkai <zhengzengkai@huawei.com>
-