From: Sasha Levin Date: Sun, 26 Mar 2023 23:04:15 +0000 (-0400) Subject: Fixes for 5.4 X-Git-Tag: v5.15.105~72 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=e1a37be162910a863c93a482254fff401c0b0e9b;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.4 Signed-off-by: Sasha Levin --- diff --git a/queue-5.4/atm-idt77252-fix-kmemleak-when-rmmod-idt77252.patch b/queue-5.4/atm-idt77252-fix-kmemleak-when-rmmod-idt77252.patch new file mode 100644 index 00000000000..e9c7201d2a3 --- /dev/null +++ b/queue-5.4/atm-idt77252-fix-kmemleak-when-rmmod-idt77252.patch @@ -0,0 +1,92 @@ +From 55c27c6e93c240bc8e9c8485c02cbe5caeb65e2a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 20 Mar 2023 14:33:18 +0000 +Subject: atm: idt77252: fix kmemleak when rmmod idt77252 + +From: Li Zetao + +[ Upstream commit 4fe3c88552a3fbe1944426a4506a18cdeb457b5a ] + +There are memory leaks reported by kmemleak: + + unreferenced object 0xffff888106500800 (size 128): + comm "modprobe", pid 1017, jiffies 4297787785 (age 67.152s) + hex dump (first 32 bytes): + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ + backtrace: + [<00000000970ce626>] __kmem_cache_alloc_node+0x20c/0x380 + [<00000000fb5f78d9>] kmalloc_trace+0x2f/0xb0 + [<000000000e947e2a>] idt77252_init_one+0x2847/0x3c90 [idt77252] + [<000000006efb048e>] local_pci_probe+0xeb/0x1a0 + ... + + unreferenced object 0xffff888106500b00 (size 128): + comm "modprobe", pid 1017, jiffies 4297787785 (age 67.152s) + hex dump (first 32 bytes): + 00 20 3d 01 80 88 ff ff 00 20 3d 01 80 88 ff ff . =...... =..... + f0 23 3d 01 80 88 ff ff 00 20 3d 01 00 00 00 00 .#=...... =..... + backtrace: + [<00000000970ce626>] __kmem_cache_alloc_node+0x20c/0x380 + [<00000000fb5f78d9>] kmalloc_trace+0x2f/0xb0 + [<00000000f451c5be>] alloc_scq.constprop.0+0x4a/0x400 [idt77252] + [<00000000e6313849>] idt77252_init_one+0x28cf/0x3c90 [idt77252] + +The root cause is traced to the vc_maps which alloced in open_card_oam() +are not freed in close_card_oam(). The vc_maps are used to record +open connections, so when close a vc_map in close_card_oam(), the memory +should be freed. Moreover, the ubr0 is not closed when close a idt77252 +device, leading to the memory leak of vc_map and scq_info. + +Fix them by adding kfree in close_card_oam() and implementing new +close_card_ubr0() to close ubr0. + +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Signed-off-by: Li Zetao +Reviewed-by: Francois Romieu +Link: https://lore.kernel.org/r/20230320143318.2644630-1-lizetao1@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/atm/idt77252.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +diff --git a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c +index a95a9448984fe..c60611196786f 100644 +--- a/drivers/atm/idt77252.c ++++ b/drivers/atm/idt77252.c +@@ -2914,6 +2914,7 @@ close_card_oam(struct idt77252_dev *card) + + recycle_rx_pool_skb(card, &vc->rcv.rx_pool); + } ++ kfree(vc); + } + } + } +@@ -2957,6 +2958,15 @@ open_card_ubr0(struct idt77252_dev *card) + return 0; + } + ++static void ++close_card_ubr0(struct idt77252_dev *card) ++{ ++ struct vc_map *vc = card->vcs[0]; ++ ++ free_scq(card, vc->scq); ++ kfree(vc); ++} ++ + static int + idt77252_dev_open(struct idt77252_dev *card) + { +@@ -3006,6 +3016,7 @@ static void idt77252_dev_close(struct atm_dev *dev) + struct idt77252_dev *card = dev->dev_data; + u32 conf; + ++ close_card_ubr0(card); + close_card_oam(card); + + conf = SAR_CFG_RXPTH | /* enable receive path */ +-- +2.39.2 + diff --git a/queue-5.4/bluetooth-btqcomsmd-fix-command-timeout-after-settin.patch b/queue-5.4/bluetooth-btqcomsmd-fix-command-timeout-after-settin.patch new file mode 100644 index 00000000000..52847447faf --- /dev/null +++ b/queue-5.4/bluetooth-btqcomsmd-fix-command-timeout-after-settin.patch @@ -0,0 +1,74 @@ +From 3aed8d0fcfd353cd199db65d5245788c24a5332e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 8 Mar 2023 14:31:55 +0100 +Subject: Bluetooth: btqcomsmd: Fix command timeout after setting BD address + +From: Stephan Gerhold + +[ Upstream commit 5d44ab9e204200a78ad55cdf185aa2bb109b5950 ] + +On most devices using the btqcomsmd driver (e.g. the DragonBoard 410c +and other devices based on the Qualcomm MSM8916/MSM8909/... SoCs) +the Bluetooth firmware seems to become unresponsive for a while after +setting the BD address. On recent kernel versions (at least 5.17+) +this often causes timeouts for subsequent commands, e.g. the HCI reset +sent by the Bluetooth core during initialization: + + Bluetooth: hci0: Opcode 0x c03 failed: -110 + +Unfortunately this behavior does not seem to be documented anywhere. +Experimentation suggests that the minimum necessary delay to avoid +the problem is ~150us. However, to be sure add a sleep for > 1ms +in case it is a bit longer on other firmware versions. + +Older kernel versions are likely also affected, although perhaps with +slightly different errors or less probability. Side effects can easily +hide the issue in most cases, e.g. unrelated incoming interrupts that +cause the necessary delay. + +Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver") +Signed-off-by: Stephan Gerhold +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + drivers/bluetooth/btqcomsmd.c | 17 ++++++++++++++++- + 1 file changed, 16 insertions(+), 1 deletion(-) + +diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c +index 2acb719e596f5..11c7e04bf3947 100644 +--- a/drivers/bluetooth/btqcomsmd.c ++++ b/drivers/bluetooth/btqcomsmd.c +@@ -122,6 +122,21 @@ static int btqcomsmd_setup(struct hci_dev *hdev) + return 0; + } + ++static int btqcomsmd_set_bdaddr(struct hci_dev *hdev, const bdaddr_t *bdaddr) ++{ ++ int ret; ++ ++ ret = qca_set_bdaddr_rome(hdev, bdaddr); ++ if (ret) ++ return ret; ++ ++ /* The firmware stops responding for a while after setting the bdaddr, ++ * causing timeouts for subsequent commands. Sleep a bit to avoid this. ++ */ ++ usleep_range(1000, 10000); ++ return 0; ++} ++ + static int btqcomsmd_probe(struct platform_device *pdev) + { + struct btqcomsmd *btq; +@@ -162,7 +177,7 @@ static int btqcomsmd_probe(struct platform_device *pdev) + hdev->close = btqcomsmd_close; + hdev->send = btqcomsmd_send; + hdev->setup = btqcomsmd_setup; +- hdev->set_bdaddr = qca_set_bdaddr_rome; ++ hdev->set_bdaddr = btqcomsmd_set_bdaddr; + + ret = hci_register_dev(hdev); + if (ret < 0) +-- +2.39.2 + diff --git a/queue-5.4/bluetooth-btsdio-fix-use-after-free-bug-in-btsdio_re.patch b/queue-5.4/bluetooth-btsdio-fix-use-after-free-bug-in-btsdio_re.patch new file mode 100644 index 00000000000..2703ea688d4 --- /dev/null +++ b/queue-5.4/bluetooth-btsdio-fix-use-after-free-bug-in-btsdio_re.patch @@ -0,0 +1,39 @@ +From 477a67435a45811becb54ca5b7fa53c8686592b8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 9 Mar 2023 16:07:39 +0800 +Subject: Bluetooth: btsdio: fix use after free bug in btsdio_remove due to + unfinished work + +From: Zheng Wang + +[ Upstream commit 1e9ac114c4428fdb7ff4635b45d4f46017e8916f ] + +In btsdio_probe, &data->work was bound with btsdio_work.In +btsdio_send_frame, it was started by schedule_work. + +If we call btsdio_remove with an unfinished job, there may +be a race condition and cause UAF bug on hdev. + +Fixes: ddbaf13e3609 ("[Bluetooth] Add generic driver for Bluetooth SDIO devices") +Signed-off-by: Zheng Wang +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + drivers/bluetooth/btsdio.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/bluetooth/btsdio.c b/drivers/bluetooth/btsdio.c +index fd9571d5fdac9..81125fb180351 100644 +--- a/drivers/bluetooth/btsdio.c ++++ b/drivers/bluetooth/btsdio.c +@@ -343,6 +343,7 @@ static void btsdio_remove(struct sdio_func *func) + + BT_DBG("func %p", func); + ++ cancel_work_sync(&data->work); + if (!data) + return; + +-- +2.39.2 + diff --git a/queue-5.4/bpf-adjust-insufficient-default-bpf_jit_limit.patch b/queue-5.4/bpf-adjust-insufficient-default-bpf_jit_limit.patch new file mode 100644 index 00000000000..32c40901c69 --- /dev/null +++ b/queue-5.4/bpf-adjust-insufficient-default-bpf_jit_limit.patch @@ -0,0 +1,78 @@ +From edc71662a7f78f6df2da9f0594d19541e0b01c04 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 20 Mar 2023 15:37:25 +0100 +Subject: bpf: Adjust insufficient default bpf_jit_limit + +From: Daniel Borkmann + +[ Upstream commit 10ec8ca8ec1a2f04c4ed90897225231c58c124a7 ] + +We've seen recent AWS EKS (Kubernetes) user reports like the following: + + After upgrading EKS nodes from v20230203 to v20230217 on our 1.24 EKS + clusters after a few days a number of the nodes have containers stuck + in ContainerCreating state or liveness/readiness probes reporting the + following error: + + Readiness probe errored: rpc error: code = Unknown desc = failed to + exec in container: failed to start exec "4a11039f730203ffc003b7[...]": + OCI runtime exec failed: exec failed: unable to start container process: + unable to init seccomp: error loading seccomp filter into kernel: + error loading seccomp filter: errno 524: unknown + + However, we had not been seeing this issue on previous AMIs and it only + started to occur on v20230217 (following the upgrade from kernel 5.4 to + 5.10) with no other changes to the underlying cluster or workloads. + + We tried the suggestions from that issue (sysctl net.core.bpf_jit_limit=452534528) + which helped to immediately allow containers to be created and probes to + execute but after approximately a day the issue returned and the value + returned by cat /proc/vmallocinfo | grep bpf_jit | awk '{s+=$2} END {print s}' + was steadily increasing. + +I tested bpf tree to observe bpf_jit_charge_modmem, bpf_jit_uncharge_modmem +their sizes passed in as well as bpf_jit_current under tcpdump BPF filter, +seccomp BPF and native (e)BPF programs, and the behavior all looks sane +and expected, that is nothing "leaking" from an upstream perspective. + +The bpf_jit_limit knob was originally added in order to avoid a situation +where unprivileged applications loading BPF programs (e.g. seccomp BPF +policies) consuming all the module memory space via BPF JIT such that loading +of kernel modules would be prevented. The default limit was defined back in +2018 and while good enough back then, we are generally seeing far more BPF +consumers today. + +Adjust the limit for the BPF JIT pool from originally 1/4 to now 1/2 of the +module memory space to better reflect today's needs and avoid more users +running into potentially hard to debug issues. + +Fixes: fdadd04931c2 ("bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K") +Reported-by: Stephen Haynes +Reported-by: Lefteris Alexakis +Signed-off-by: Daniel Borkmann +Link: https://github.com/awslabs/amazon-eks-ami/issues/1179 +Link: https://github.com/awslabs/amazon-eks-ami/issues/1219 +Reviewed-by: Kuniyuki Iwashima +Link: https://lore.kernel.org/r/20230320143725.8394-1-daniel@iogearbox.net +Signed-off-by: Alexei Starovoitov +Signed-off-by: Sasha Levin +--- + kernel/bpf/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c +index 11f24421ad3a0..dde21d23f2202 100644 +--- a/kernel/bpf/core.c ++++ b/kernel/bpf/core.c +@@ -764,7 +764,7 @@ static int __init bpf_jit_charge_init(void) + { + /* Only used as heuristic here to derive limit. */ + bpf_jit_limit_max = bpf_jit_alloc_exec_limit(); +- bpf_jit_limit = min_t(u64, round_up(bpf_jit_limit_max >> 2, ++ bpf_jit_limit = min_t(u64, round_up(bpf_jit_limit_max >> 1, + PAGE_SIZE), LONG_MAX); + return 0; + } +-- +2.39.2 + diff --git a/queue-5.4/erspan-do-not-use-skb_mac_header-in-ndo_start_xmit.patch b/queue-5.4/erspan-do-not-use-skb_mac_header-in-ndo_start_xmit.patch new file mode 100644 index 00000000000..cf494ee0978 --- /dev/null +++ b/queue-5.4/erspan-do-not-use-skb_mac_header-in-ndo_start_xmit.patch @@ -0,0 +1,122 @@ +From 83c663690a308311c9f7cd966ae2c362e4373dcb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 20 Mar 2023 16:34:27 +0000 +Subject: erspan: do not use skb_mac_header() in ndo_start_xmit() + +From: Eric Dumazet + +[ Upstream commit 8e50ed774554f93d55426039b27b1e38d7fa64d8 ] + +Drivers should not assume skb_mac_header(skb) == skb->data in their +ndo_start_xmit(). + +Use skb_network_offset() and skb_transport_offset() which +better describe what is needed in erspan_fb_xmit() and +ip6erspan_tunnel_xmit() + +syzbot reported: +WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 skb_mac_header include/linux/skbuff.h:2873 [inline] +WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962 +Modules linked in: +CPU: 0 PID: 5083 Comm: syz-executor406 Not tainted 6.3.0-rc2-syzkaller-00866-gd4671cb96fa3 #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 +RIP: 0010:skb_mac_header include/linux/skbuff.h:2873 [inline] +RIP: 0010:ip6erspan_tunnel_xmit+0x1d9c/0x2d90 net/ipv6/ip6_gre.c:962 +Code: 04 02 41 01 de 84 c0 74 08 3c 03 0f 8e 1c 0a 00 00 45 89 b4 24 c8 00 00 00 c6 85 77 fe ff ff 01 e9 33 e7 ff ff e8 b4 27 a1 f8 <0f> 0b e9 b6 e7 ff ff e8 a8 27 a1 f8 49 8d bf f0 0c 00 00 48 b8 00 +RSP: 0018:ffffc90003b2f830 EFLAGS: 00010293 +RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000 +RDX: ffff888021273a80 RSI: ffffffff88e1bd4c RDI: 0000000000000003 +RBP: ffffc90003b2f9d8 R08: 0000000000000003 R09: 000000000000ffff +R10: 000000000000ffff R11: 0000000000000000 R12: ffff88802b28da00 +R13: 00000000000000d0 R14: ffff88807e25b6d0 R15: ffff888023408000 +FS: 0000555556a61300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: 000055e5b11eb6e8 CR3: 0000000027c1b000 CR4: 00000000003506f0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 +Call Trace: + +__netdev_start_xmit include/linux/netdevice.h:4900 [inline] +netdev_start_xmit include/linux/netdevice.h:4914 [inline] +__dev_direct_xmit+0x504/0x730 net/core/dev.c:4300 +dev_direct_xmit include/linux/netdevice.h:3088 [inline] +packet_xmit+0x20a/0x390 net/packet/af_packet.c:285 +packet_snd net/packet/af_packet.c:3075 [inline] +packet_sendmsg+0x31a0/0x5150 net/packet/af_packet.c:3107 +sock_sendmsg_nosec net/socket.c:724 [inline] +sock_sendmsg+0xde/0x190 net/socket.c:747 +__sys_sendto+0x23a/0x340 net/socket.c:2142 +__do_sys_sendto net/socket.c:2154 [inline] +__se_sys_sendto net/socket.c:2150 [inline] +__x64_sys_sendto+0xe1/0x1b0 net/socket.c:2150 +do_syscall_x64 arch/x86/entry/common.c:50 [inline] +do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80 +entry_SYSCALL_64_after_hwframe+0x63/0xcd +RIP: 0033:0x7f123aaa1039 +Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 +RSP: 002b:00007ffc15d12058 EFLAGS: 00000246 ORIG_RAX: 000000000000002c +RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f123aaa1039 +RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 +RBP: 0000000000000000 R08: 0000000020000040 R09: 0000000000000014 +R10: 0000000000000000 R11: 0000000000000246 R12: 00007f123aa648c0 +R13: 431bde82d7b634db R14: 0000000000000000 R15: 0000000000000000 + +Fixes: 1baf5ebf8954 ("erspan: auto detect truncated packets.") +Reported-by: syzbot +Signed-off-by: Eric Dumazet +Reviewed-by: Simon Horman +Link: https://lore.kernel.org/r/20230320163427.8096-1-edumazet@google.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/ipv4/ip_gre.c | 4 ++-- + net/ipv6/ip6_gre.c | 4 ++-- + 2 files changed, 4 insertions(+), 4 deletions(-) + +diff --git a/net/ipv4/ip_gre.c b/net/ipv4/ip_gre.c +index 52dbffb7bc2fd..317fdb9f47e88 100644 +--- a/net/ipv4/ip_gre.c ++++ b/net/ipv4/ip_gre.c +@@ -525,7 +525,7 @@ static void erspan_fb_xmit(struct sk_buff *skb, struct net_device *dev) + truncate = true; + } + +- nhoff = skb_network_header(skb) - skb_mac_header(skb); ++ nhoff = skb_network_offset(skb); + if (skb->protocol == htons(ETH_P_IP) && + (ntohs(ip_hdr(skb)->tot_len) > skb->len - nhoff)) + truncate = true; +@@ -534,7 +534,7 @@ static void erspan_fb_xmit(struct sk_buff *skb, struct net_device *dev) + int thoff; + + if (skb_transport_header_was_set(skb)) +- thoff = skb_transport_header(skb) - skb_mac_header(skb); ++ thoff = skb_transport_offset(skb); + else + thoff = nhoff + sizeof(struct ipv6hdr); + if (ntohs(ipv6_hdr(skb)->payload_len) > skb->len - thoff) +diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c +index fd4da1019e44c..85ec466b5735e 100644 +--- a/net/ipv6/ip6_gre.c ++++ b/net/ipv6/ip6_gre.c +@@ -942,7 +942,7 @@ static netdev_tx_t ip6erspan_tunnel_xmit(struct sk_buff *skb, + truncate = true; + } + +- nhoff = skb_network_header(skb) - skb_mac_header(skb); ++ nhoff = skb_network_offset(skb); + if (skb->protocol == htons(ETH_P_IP) && + (ntohs(ip_hdr(skb)->tot_len) > skb->len - nhoff)) + truncate = true; +@@ -951,7 +951,7 @@ static netdev_tx_t ip6erspan_tunnel_xmit(struct sk_buff *skb, + int thoff; + + if (skb_transport_header_was_set(skb)) +- thoff = skb_transport_header(skb) - skb_mac_header(skb); ++ thoff = skb_transport_offset(skb); + else + thoff = nhoff + sizeof(struct ipv6hdr); + if (ntohs(ipv6_hdr(skb)->payload_len) > skb->len - thoff) +-- +2.39.2 + diff --git a/queue-5.4/hvc-xen-prevent-concurrent-accesses-to-the-shared-ri.patch b/queue-5.4/hvc-xen-prevent-concurrent-accesses-to-the-shared-ri.patch new file mode 100644 index 00000000000..bb05f7ee2d3 --- /dev/null +++ b/queue-5.4/hvc-xen-prevent-concurrent-accesses-to-the-shared-ri.patch @@ -0,0 +1,147 @@ +From d1911f0e07f979c6c3d6df39dcd65c0e99f67b71 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 30 Nov 2022 16:09:11 +0100 +Subject: hvc/xen: prevent concurrent accesses to the shared ring +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Roger Pau Monne + +[ Upstream commit 6214894f49a967c749ee6c07cb00f9cede748df4 ] + +The hvc machinery registers both a console and a tty device based on +the hv ops provided by the specific implementation. Those two +interfaces however have different locks, and there's no single locks +that's shared between the tty and the console implementations, hence +the driver needs to protect itself against concurrent accesses. +Otherwise concurrent calls using the split interfaces are likely to +corrupt the ring indexes, leaving the console unusable. + +Introduce a lock to xencons_info to serialize accesses to the shared +ring. This is only required when using the shared memory console, +concurrent accesses to the hypercall based console implementation are +not an issue. + +Note the conditional logic in domU_read_console() is slightly modified +so the notify_daemon() call can be done outside of the locked region: +it's an hypercall and there's no need for it to be done with the lock +held. + +Fixes: b536b4b96230 ('xen: use the hvc console infrastructure for Xen console') +Signed-off-by: Roger Pau Monné +Reviewed-by: Juergen Gross +Link: https://lore.kernel.org/r/20221130150919.13935-1-roger.pau@citrix.com +Signed-off-by: Juergen Gross +Signed-off-by: Sasha Levin +--- + drivers/tty/hvc/hvc_xen.c | 19 +++++++++++++++++-- + 1 file changed, 17 insertions(+), 2 deletions(-) + +diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c +index 7dd11b62a196e..bf8bb9ce4fab9 100644 +--- a/drivers/tty/hvc/hvc_xen.c ++++ b/drivers/tty/hvc/hvc_xen.c +@@ -43,6 +43,7 @@ struct xencons_info { + int irq; + int vtermno; + grant_ref_t gntref; ++ spinlock_t ring_lock; + }; + + static LIST_HEAD(xenconsoles); +@@ -89,12 +90,15 @@ static int __write_console(struct xencons_info *xencons, + XENCONS_RING_IDX cons, prod; + struct xencons_interface *intf = xencons->intf; + int sent = 0; ++ unsigned long flags; + ++ spin_lock_irqsave(&xencons->ring_lock, flags); + cons = intf->out_cons; + prod = intf->out_prod; + mb(); /* update queue values before going on */ + + if ((prod - cons) > sizeof(intf->out)) { ++ spin_unlock_irqrestore(&xencons->ring_lock, flags); + pr_err_once("xencons: Illegal ring page indices"); + return -EINVAL; + } +@@ -104,6 +108,7 @@ static int __write_console(struct xencons_info *xencons, + + wmb(); /* write ring before updating pointer */ + intf->out_prod = prod; ++ spin_unlock_irqrestore(&xencons->ring_lock, flags); + + if (sent) + notify_daemon(xencons); +@@ -146,16 +151,19 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len) + int recv = 0; + struct xencons_info *xencons = vtermno_to_xencons(vtermno); + unsigned int eoiflag = 0; ++ unsigned long flags; + + if (xencons == NULL) + return -EINVAL; + intf = xencons->intf; + ++ spin_lock_irqsave(&xencons->ring_lock, flags); + cons = intf->in_cons; + prod = intf->in_prod; + mb(); /* get pointers before reading ring */ + + if ((prod - cons) > sizeof(intf->in)) { ++ spin_unlock_irqrestore(&xencons->ring_lock, flags); + pr_err_once("xencons: Illegal ring page indices"); + return -EINVAL; + } +@@ -179,10 +187,13 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len) + xencons->out_cons = intf->out_cons; + xencons->out_cons_same = 0; + } ++ if (!recv && xencons->out_cons_same++ > 1) { ++ eoiflag = XEN_EOI_FLAG_SPURIOUS; ++ } ++ spin_unlock_irqrestore(&xencons->ring_lock, flags); ++ + if (recv) { + notify_daemon(xencons); +- } else if (xencons->out_cons_same++ > 1) { +- eoiflag = XEN_EOI_FLAG_SPURIOUS; + } + + xen_irq_lateeoi(xencons->irq, eoiflag); +@@ -239,6 +250,7 @@ static int xen_hvm_console_init(void) + info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL); + if (!info) + return -ENOMEM; ++ spin_lock_init(&info->ring_lock); + } else if (info->intf != NULL) { + /* already configured */ + return 0; +@@ -275,6 +287,7 @@ static int xen_hvm_console_init(void) + + static int xencons_info_pv_init(struct xencons_info *info, int vtermno) + { ++ spin_lock_init(&info->ring_lock); + info->evtchn = xen_start_info->console.domU.evtchn; + /* GFN == MFN for PV guest */ + info->intf = gfn_to_virt(xen_start_info->console.domU.mfn); +@@ -325,6 +338,7 @@ static int xen_initial_domain_console_init(void) + info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL); + if (!info) + return -ENOMEM; ++ spin_lock_init(&info->ring_lock); + } + + info->irq = bind_virq_to_irq(VIRQ_CONSOLE, 0, false); +@@ -482,6 +496,7 @@ static int xencons_probe(struct xenbus_device *dev, + info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL); + if (!info) + return -ENOMEM; ++ spin_lock_init(&info->ring_lock); + dev_set_drvdata(&dev->dev, info); + info->xbdev = dev; + info->vtermno = xenbus_devid_to_vtermno(devid); +-- +2.39.2 + diff --git a/queue-5.4/i2c-imx-lpi2c-check-only-for-enabled-interrupt-flags.patch b/queue-5.4/i2c-imx-lpi2c-check-only-for-enabled-interrupt-flags.patch new file mode 100644 index 00000000000..64c2cb7a64f --- /dev/null +++ b/queue-5.4/i2c-imx-lpi2c-check-only-for-enabled-interrupt-flags.patch @@ -0,0 +1,47 @@ +From 65009463a0cb0ec4265ffae7f0d113c2a6873e06 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 30 Jan 2023 16:32:47 +0100 +Subject: i2c: imx-lpi2c: check only for enabled interrupt flags + +From: Alexander Stein + +[ Upstream commit 1c7885004567e8951d65a983be095f254dd20bef ] + +When reading from I2C, the Tx watermark is set to 0. Unfortunately the +TDF (transmit data flag) is enabled when Tx FIFO entries is equal or less +than watermark. So it is set in every case, hence the reset default of 1. +This results in the MSR_RDF _and_ MSR_TDF flags to be set thus trying +to send Tx data on a read message. +Mask the IRQ status to filter for wanted flags only. + +Fixes: a55fa9d0e42e ("i2c: imx-lpi2c: add low power i2c bus driver") +Signed-off-by: Alexander Stein +Tested-by: Emanuele Ghidoli +Signed-off-by: Wolfram Sang +Signed-off-by: Sasha Levin +--- + drivers/i2c/busses/i2c-imx-lpi2c.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c +index a0d045c1bc9e6..13c17afe7102e 100644 +--- a/drivers/i2c/busses/i2c-imx-lpi2c.c ++++ b/drivers/i2c/busses/i2c-imx-lpi2c.c +@@ -508,10 +508,14 @@ static int lpi2c_imx_xfer(struct i2c_adapter *adapter, + static irqreturn_t lpi2c_imx_isr(int irq, void *dev_id) + { + struct lpi2c_imx_struct *lpi2c_imx = dev_id; ++ unsigned int enabled; + unsigned int temp; + ++ enabled = readl(lpi2c_imx->base + LPI2C_MIER); ++ + lpi2c_imx_intctrl(lpi2c_imx, 0); + temp = readl(lpi2c_imx->base + LPI2C_MSR); ++ temp &= enabled; + + if (temp & MSR_RDF) + lpi2c_imx_read_rxfifo(lpi2c_imx); +-- +2.39.2 + diff --git a/queue-5.4/iavf-fix-inverted-rx-hash-condition-leading-to-disab.patch b/queue-5.4/iavf-fix-inverted-rx-hash-condition-leading-to-disab.patch new file mode 100644 index 00000000000..877088f8ff8 --- /dev/null +++ b/queue-5.4/iavf-fix-inverted-rx-hash-condition-leading-to-disab.patch @@ -0,0 +1,44 @@ +From 28fce5439cb00281dc5885a8c14a0672cd75571d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 1 Mar 2023 12:59:07 +0100 +Subject: iavf: fix inverted Rx hash condition leading to disabled hash + +From: Alexander Lobakin + +[ Upstream commit 32d57f667f871bc5a8babbe27ea4c5e668ee0ea8 ] + +Condition, which checks whether the netdev has hashing enabled is +inverted. Basically, the tagged commit effectively disabled passing flow +hash from descriptor to skb, unless user *disables* it via Ethtool. +Commit a876c3ba59a6 ("i40e/i40evf: properly report Rx packet hash") +fixed this problem, but only for i40e. +Invert the condition now in iavf and unblock passing hash to skbs again. + +Fixes: 857942fd1aa1 ("i40e: Fix Rx hash reported to the stack by our driver") +Reviewed-by: Larysa Zaremba +Reviewed-by: Michal Kubiak +Signed-off-by: Alexander Lobakin +Tested-by: Rafal Romanowski +Reviewed-by: Leon Romanovsky +Signed-off-by: Tony Nguyen +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/intel/iavf/iavf_txrx.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/net/ethernet/intel/iavf/iavf_txrx.c b/drivers/net/ethernet/intel/iavf/iavf_txrx.c +index 1f7b842c67638..7a1812912d6c1 100644 +--- a/drivers/net/ethernet/intel/iavf/iavf_txrx.c ++++ b/drivers/net/ethernet/intel/iavf/iavf_txrx.c +@@ -1061,7 +1061,7 @@ static inline void iavf_rx_hash(struct iavf_ring *ring, + cpu_to_le64((u64)IAVF_RX_DESC_FLTSTAT_RSS_HASH << + IAVF_RX_DESC_STATUS_FLTSTAT_SHIFT); + +- if (ring->netdev->features & NETIF_F_RXHASH) ++ if (!(ring->netdev->features & NETIF_F_RXHASH)) + return; + + if ((rx_desc->wb.qword1.status_error_len & rss_mask) == rss_mask) { +-- +2.39.2 + diff --git a/queue-5.4/iavf-fix-non-tunneled-ipv6-udp-packet-type-and-hashi.patch b/queue-5.4/iavf-fix-non-tunneled-ipv6-udp-packet-type-and-hashi.patch new file mode 100644 index 00000000000..3d13b69261a --- /dev/null +++ b/queue-5.4/iavf-fix-non-tunneled-ipv6-udp-packet-type-and-hashi.patch @@ -0,0 +1,48 @@ +From 31bed641518fdf32065007d83f3eeac88be9c674 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 1 Mar 2023 12:59:08 +0100 +Subject: iavf: fix non-tunneled IPv6 UDP packet type and hashing + +From: Alexander Lobakin + +[ Upstream commit de58647b4301fe181f9c38e8b46f7021584ae427 ] + +Currently, IAVF's decode_rx_desc_ptype() correctly reports payload type +of L4 for IPv4 UDP packets and IPv{4,6} TCP, but only L3 for IPv6 UDP. +Originally, i40e, ice and iavf were affected. +Commit 73df8c9e3e3d ("i40e: Correct UDP packet header for non_tunnel-ipv6") +fixed that in i40e, then +commit 638a0c8c8861 ("ice: fix incorrect payload indicator on PTYPE") +fixed that for ice. +IPv6 UDP is L4 obviously. Fix it and make iavf report correct L4 hash +type for such packets, so that the stack won't calculate it on CPU when +needs it. + +Fixes: 206812b5fccb ("i40e/i40evf: i40e implementation for skb_set_hash") +Reviewed-by: Larysa Zaremba +Reviewed-by: Michal Kubiak +Signed-off-by: Alexander Lobakin +Tested-by: Rafal Romanowski +Reviewed-by: Leon Romanovsky +Signed-off-by: Tony Nguyen +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/intel/iavf/iavf_common.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/net/ethernet/intel/iavf/iavf_common.c b/drivers/net/ethernet/intel/iavf/iavf_common.c +index 8547fc8fdfd60..78423ca401b24 100644 +--- a/drivers/net/ethernet/intel/iavf/iavf_common.c ++++ b/drivers/net/ethernet/intel/iavf/iavf_common.c +@@ -662,7 +662,7 @@ struct iavf_rx_ptype_decoded iavf_ptype_lookup[] = { + /* Non Tunneled IPv6 */ + IAVF_PTT(88, IP, IPV6, FRG, NONE, NONE, NOF, NONE, PAY3), + IAVF_PTT(89, IP, IPV6, NOF, NONE, NONE, NOF, NONE, PAY3), +- IAVF_PTT(90, IP, IPV6, NOF, NONE, NONE, NOF, UDP, PAY3), ++ IAVF_PTT(90, IP, IPV6, NOF, NONE, NONE, NOF, UDP, PAY4), + IAVF_PTT_UNUSED_ENTRY(91), + IAVF_PTT(92, IP, IPV6, NOF, NONE, NONE, NOF, TCP, PAY4), + IAVF_PTT(93, IP, IPV6, NOF, NONE, NONE, NOF, SCTP, PAY4), +-- +2.39.2 + diff --git a/queue-5.4/igbvf-regard-vf-reset-nack-as-success.patch b/queue-5.4/igbvf-regard-vf-reset-nack-as-success.patch new file mode 100644 index 00000000000..ecb9b640bbd --- /dev/null +++ b/queue-5.4/igbvf-regard-vf-reset-nack-as-success.patch @@ -0,0 +1,62 @@ +From e49e9fd5d08cb9f3eb5e10d23de0c898d4af529b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 1 Dec 2022 19:20:03 +0900 +Subject: igbvf: Regard vf reset nack as success + +From: Akihiko Odaki + +[ Upstream commit 02c83791ef969c6a8a150b4927193d0d0e50fb23 ] + +vf reset nack actually represents the reset operation itself is +performed but no address is assigned. Therefore, e1000_reset_hw_vf +should fill the "perm_addr" with the zero address and return success on +such an occasion. This prevents its callers in netdev.c from saying PF +still resetting, and instead allows them to correctly report that no +address is assigned. + +Fixes: 6ddbc4cf1f4d ("igb: Indicate failure on vf reset for empty mac address") +Signed-off-by: Akihiko Odaki +Reviewed-by: Leon Romanovsky +Tested-by: Marek Szlosek +Signed-off-by: Tony Nguyen +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/intel/igbvf/vf.c | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +diff --git a/drivers/net/ethernet/intel/igbvf/vf.c b/drivers/net/ethernet/intel/igbvf/vf.c +index b8ba3f94c3632..a47a2e3e548cf 100644 +--- a/drivers/net/ethernet/intel/igbvf/vf.c ++++ b/drivers/net/ethernet/intel/igbvf/vf.c +@@ -1,6 +1,8 @@ + // SPDX-License-Identifier: GPL-2.0 + /* Copyright(c) 2009 - 2018 Intel Corporation. */ + ++#include ++ + #include "vf.h" + + static s32 e1000_check_for_link_vf(struct e1000_hw *hw); +@@ -131,11 +133,16 @@ static s32 e1000_reset_hw_vf(struct e1000_hw *hw) + /* set our "perm_addr" based on info provided by PF */ + ret_val = mbx->ops.read_posted(hw, msgbuf, 3); + if (!ret_val) { +- if (msgbuf[0] == (E1000_VF_RESET | +- E1000_VT_MSGTYPE_ACK)) ++ switch (msgbuf[0]) { ++ case E1000_VF_RESET | E1000_VT_MSGTYPE_ACK: + memcpy(hw->mac.perm_addr, addr, ETH_ALEN); +- else ++ break; ++ case E1000_VF_RESET | E1000_VT_MSGTYPE_NACK: ++ eth_zero_addr(hw->mac.perm_addr); ++ break; ++ default: + ret_val = -E1000_ERR_MAC_INIT; ++ } + } + } + +-- +2.39.2 + diff --git a/queue-5.4/intel-igbvf-free-irq-on-the-error-path-in-igbvf_requ.patch b/queue-5.4/intel-igbvf-free-irq-on-the-error-path-in-igbvf_requ.patch new file mode 100644 index 00000000000..61803608a7b --- /dev/null +++ b/queue-5.4/intel-igbvf-free-irq-on-the-error-path-in-igbvf_requ.patch @@ -0,0 +1,54 @@ +From 526c07aa2d2b744fab43beb2972563692aca060a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 22 Nov 2022 10:28:52 +0800 +Subject: intel/igbvf: free irq on the error path in igbvf_request_msix() + +From: Gaosheng Cui + +[ Upstream commit 85eb39bb39cbb5c086df1e19ba67cc1366693a77 ] + +In igbvf_request_msix(), irqs have not been freed on the err path, +we need to free it. Fix it. + +Fixes: d4e0fe01a38a ("igbvf: add new driver to support 82576 virtual functions") +Signed-off-by: Gaosheng Cui +Reviewed-by: Maciej Fijalkowski +Tested-by: Marek Szlosek +Signed-off-by: Tony Nguyen +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/intel/igbvf/netdev.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c +index 1082e49ea0560..5bf1c9d847271 100644 +--- a/drivers/net/ethernet/intel/igbvf/netdev.c ++++ b/drivers/net/ethernet/intel/igbvf/netdev.c +@@ -1070,7 +1070,7 @@ static int igbvf_request_msix(struct igbvf_adapter *adapter) + igbvf_intr_msix_rx, 0, adapter->rx_ring->name, + netdev); + if (err) +- goto out; ++ goto free_irq_tx; + + adapter->rx_ring->itr_register = E1000_EITR(vector); + adapter->rx_ring->itr_val = adapter->current_itr; +@@ -1079,10 +1079,14 @@ static int igbvf_request_msix(struct igbvf_adapter *adapter) + err = request_irq(adapter->msix_entries[vector].vector, + igbvf_msix_other, 0, netdev->name, netdev); + if (err) +- goto out; ++ goto free_irq_rx; + + igbvf_configure_msix(adapter); + return 0; ++free_irq_rx: ++ free_irq(adapter->msix_entries[--vector].vector, netdev); ++free_irq_tx: ++ free_irq(adapter->msix_entries[--vector].vector, netdev); + out: + return err; + } +-- +2.39.2 + diff --git a/queue-5.4/keys-do-not-cache-key-in-task-struct-if-key-is-reque.patch b/queue-5.4/keys-do-not-cache-key-in-task-struct-if-key-is-reque.patch new file mode 100644 index 00000000000..dd1628ee6af --- /dev/null +++ b/queue-5.4/keys-do-not-cache-key-in-task-struct-if-key-is-reque.patch @@ -0,0 +1,64 @@ +From 13abcad0eba8c549536ac2794d48835a7be5cfab Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 14 Mar 2023 15:15:18 +0000 +Subject: keys: Do not cache key in task struct if key is requested from kernel + thread + +From: David Howells + +[ Upstream commit 47f9e4c924025c5be87959d3335e66fcbb7f6b5c ] + +The key which gets cached in task structure from a kernel thread does not +get invalidated even after expiry. Due to which, a new key request from +kernel thread will be served with the cached key if it's present in task +struct irrespective of the key validity. The change is to not cache key in +task_struct when key requested from kernel thread so that kernel thread +gets a valid key on every key request. + +The problem has been seen with the cifs module doing DNS lookups from a +kernel thread and the results getting pinned by being attached to that +kernel thread's cache - and thus not something that can be easily got rid +of. The cache would ordinarily be cleared by notify-resume, but kernel +threads don't do that. + +This isn't seen with AFS because AFS is doing request_key() within the +kernel half of a user thread - which will do notify-resume. + +Fixes: 7743c48e54ee ("keys: Cache result of request_key*() temporarily in task_struct") +Signed-off-by: Bharath SM +Signed-off-by: David Howells +Reviewed-by: Jarkko Sakkinen +cc: Shyam Prasad N +cc: Steve French +cc: keyrings@vger.kernel.org +cc: linux-cifs@vger.kernel.org +cc: linux-fsdevel@vger.kernel.org +Link: https://lore.kernel.org/r/CAGypqWw951d=zYRbdgNR4snUDvJhWL=q3=WOyh7HhSJupjz2vA@mail.gmail.com/ +Signed-off-by: Sasha Levin +--- + security/keys/request_key.c | 9 ++++++--- + 1 file changed, 6 insertions(+), 3 deletions(-) + +diff --git a/security/keys/request_key.c b/security/keys/request_key.c +index 957b9e3e14924..17c9c0cfb6f59 100644 +--- a/security/keys/request_key.c ++++ b/security/keys/request_key.c +@@ -38,9 +38,12 @@ static void cache_requested_key(struct key *key) + #ifdef CONFIG_KEYS_REQUEST_CACHE + struct task_struct *t = current; + +- key_put(t->cached_requested_key); +- t->cached_requested_key = key_get(key); +- set_tsk_thread_flag(t, TIF_NOTIFY_RESUME); ++ /* Do not cache key if it is a kernel thread */ ++ if (!(t->flags & PF_KTHREAD)) { ++ key_put(t->cached_requested_key); ++ t->cached_requested_key = key_get(key); ++ set_tsk_thread_flag(t, TIF_NOTIFY_RESUME); ++ } + #endif + } + +-- +2.39.2 + diff --git a/queue-5.4/net-dsa-mt7530-move-setting-ssc_delta-to-phy_interfa.patch b/queue-5.4/net-dsa-mt7530-move-setting-ssc_delta-to-phy_interfa.patch new file mode 100644 index 00000000000..59667aca2e7 --- /dev/null +++ b/queue-5.4/net-dsa-mt7530-move-setting-ssc_delta-to-phy_interfa.patch @@ -0,0 +1,55 @@ +From 35b6a1d7f4572ada18248b0852d00c254d13181f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 20 Mar 2023 22:05:20 +0300 +Subject: net: dsa: mt7530: move setting ssc_delta to PHY_INTERFACE_MODE_TRGMII + case +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Arınç ÜNAL + +[ Upstream commit 407b508bdd70b6848993843d96ed49ac4108fb52 ] + +Move setting the ssc_delta variable to under the PHY_INTERFACE_MODE_TRGMII +case as it's only needed when trgmii is used. + +Fixes: b8f126a8d543 ("net-next: dsa: add dsa support for Mediatek MT7530 switch") +Signed-off-by: Arınç ÜNAL +Link: https://lore.kernel.org/r/20230320190520.124513-3-arinc.unal@arinc9.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/dsa/mt7530.c | 9 ++++----- + 1 file changed, 4 insertions(+), 5 deletions(-) + +diff --git a/drivers/net/dsa/mt7530.c b/drivers/net/dsa/mt7530.c +index 2d8382eb9add3..5bd282cb3d9f2 100644 +--- a/drivers/net/dsa/mt7530.c ++++ b/drivers/net/dsa/mt7530.c +@@ -396,6 +396,10 @@ mt7530_pad_clk_setup(struct dsa_switch *ds, int mode) + break; + case PHY_INTERFACE_MODE_TRGMII: + trgint = 1; ++ if (xtal == HWTRAP_XTAL_25MHZ) ++ ssc_delta = 0x57; ++ else ++ ssc_delta = 0x87; + if (priv->id == ID_MT7621) { + /* PLL frequency: 150MHz: 1.2GBit */ + if (xtal == HWTRAP_XTAL_40MHZ) +@@ -414,11 +418,6 @@ mt7530_pad_clk_setup(struct dsa_switch *ds, int mode) + return -EINVAL; + } + +- if (xtal == HWTRAP_XTAL_25MHZ) +- ssc_delta = 0x57; +- else +- ssc_delta = 0x87; +- + mt7530_rmw(priv, MT7530_P6ECR, P6_INTF_MODE_MASK, + P6_INTF_MODE(trgint)); + +-- +2.39.2 + diff --git a/queue-5.4/net-mdio-thunder-add-missing-fwnode_handle_put.patch b/queue-5.4/net-mdio-thunder-add-missing-fwnode_handle_put.patch new file mode 100644 index 00000000000..18b14e80186 --- /dev/null +++ b/queue-5.4/net-mdio-thunder-add-missing-fwnode_handle_put.patch @@ -0,0 +1,36 @@ +From d987cd5c6a04bf971e077bf6fc34439ec830a93d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 22 Mar 2023 14:20:57 +0800 +Subject: net: mdio: thunder: Add missing fwnode_handle_put() + +From: Liang He + +[ Upstream commit b1de5c78ebe9858ccec9d49af2f76724f1d47e3e ] + +In device_for_each_child_node(), we should add fwnode_handle_put() +when break out of the iteration device_for_each_child_node() +as it will automatically increase and decrease the refcounter. + +Fixes: 379d7ac7ca31 ("phy: mdio-thunder: Add driver for Cavium Thunder SoC MDIO buses.") +Signed-off-by: Liang He +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/phy/mdio-thunder.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/net/phy/mdio-thunder.c b/drivers/net/phy/mdio-thunder.c +index 1e2f57ed1ef75..31ca0361a11e0 100644 +--- a/drivers/net/phy/mdio-thunder.c ++++ b/drivers/net/phy/mdio-thunder.c +@@ -104,6 +104,7 @@ static int thunder_mdiobus_pci_probe(struct pci_dev *pdev, + if (i >= ARRAY_SIZE(nexus->buses)) + break; + } ++ fwnode_handle_put(fwn); + return 0; + + err_release_regions: +-- +2.39.2 + diff --git a/queue-5.4/net-mlx5-read-the-tc-mapping-of-all-priorities-on-et.patch b/queue-5.4/net-mlx5-read-the-tc-mapping-of-all-priorities-on-et.patch new file mode 100644 index 00000000000..130678ee5c5 --- /dev/null +++ b/queue-5.4/net-mlx5-read-the-tc-mapping-of-all-priorities-on-et.patch @@ -0,0 +1,51 @@ +From 40a05fe01189fe8be0c3296a9a064ca8a00b5ee5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 15 Mar 2023 11:04:38 +0200 +Subject: net/mlx5: Read the TC mapping of all priorities on ETS query + +From: Maher Sanalla + +[ Upstream commit 44d553188c38ac74b799dfdcebafef2f7bb70942 ] + +When ETS configurations are queried by the user to get the mapping +assignment between packet priority and traffic class, only priorities up +to maximum TCs are queried from QTCT register in FW to retrieve their +assigned TC, leaving the rest of the priorities mapped to the default +TC #0 which might be misleading. + +Fix by querying the TC mapping of all priorities on each ETS query, +regardless of the maximum number of TCs configured in FW. + +Fixes: 820c2c5e773d ("net/mlx5e: Read ETS settings directly from firmware") +Signed-off-by: Maher Sanalla +Reviewed-by: Moshe Shemesh +Signed-off-by: Saeed Mahameed +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c +index 01f2918063af0..f1952e14c8042 100644 +--- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c ++++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c +@@ -109,12 +109,14 @@ static int mlx5e_dcbnl_ieee_getets(struct net_device *netdev, + if (!MLX5_CAP_GEN(priv->mdev, ets)) + return -EOPNOTSUPP; + +- ets->ets_cap = mlx5_max_tc(priv->mdev) + 1; +- for (i = 0; i < ets->ets_cap; i++) { ++ for (i = 0; i < IEEE_8021QAZ_MAX_TCS; i++) { + err = mlx5_query_port_prio_tc(mdev, i, &ets->prio_tc[i]); + if (err) + return err; ++ } + ++ ets->ets_cap = mlx5_max_tc(priv->mdev) + 1; ++ for (i = 0; i < ets->ets_cap; i++) { + err = mlx5_query_port_tc_group(mdev, i, &tc_group[i]); + if (err) + return err; +-- +2.39.2 + diff --git a/queue-5.4/net-ps3_gelic_net-fix-rx-sk_buff-length.patch b/queue-5.4/net-ps3_gelic_net-fix-rx-sk_buff-length.patch new file mode 100644 index 00000000000..497ca009e08 --- /dev/null +++ b/queue-5.4/net-ps3_gelic_net-fix-rx-sk_buff-length.patch @@ -0,0 +1,108 @@ +From ea503b374c3c51e51e5c863dced3a3b3c6a28931 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 18 Mar 2023 17:39:16 +0000 +Subject: net/ps3_gelic_net: Fix RX sk_buff length + +From: Geoff Levand + +[ Upstream commit 19b3bb51c3bc288b3f2c6f8c4450b0f548320625 ] + +The Gelic Ethernet device needs to have the RX sk_buffs aligned to +GELIC_NET_RXBUF_ALIGN, and also the length of the RX sk_buffs must +be a multiple of GELIC_NET_RXBUF_ALIGN. + +The current Gelic Ethernet driver was not allocating sk_buffs large +enough to allow for this alignment. + +Also, correct the maximum and minimum MTU sizes, and add a new +preprocessor macro for the maximum frame size, GELIC_NET_MAX_FRAME. + +Fixes various randomly occurring runtime network errors. + +Fixes: 02c1889166b4 ("ps3: gigabit ethernet driver for PS3, take3") +Signed-off-by: Geoff Levand +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/toshiba/ps3_gelic_net.c | 19 ++++++++++--------- + drivers/net/ethernet/toshiba/ps3_gelic_net.h | 5 +++-- + 2 files changed, 13 insertions(+), 11 deletions(-) + +diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c b/drivers/net/ethernet/toshiba/ps3_gelic_net.c +index 9d9f8acb7ee33..c3e3477081e48 100644 +--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c ++++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c +@@ -365,28 +365,29 @@ static int gelic_card_init_chain(struct gelic_card *card, + * + * allocates a new rx skb, iommu-maps it and attaches it to the descriptor. + * Activate the descriptor state-wise ++ * ++ * Gelic RX sk_buffs must be aligned to GELIC_NET_RXBUF_ALIGN and the length ++ * must be a multiple of GELIC_NET_RXBUF_ALIGN. + */ + static int gelic_descr_prepare_rx(struct gelic_card *card, + struct gelic_descr *descr) + { ++ static const unsigned int rx_skb_size = ++ ALIGN(GELIC_NET_MAX_FRAME, GELIC_NET_RXBUF_ALIGN) + ++ GELIC_NET_RXBUF_ALIGN - 1; + int offset; +- unsigned int bufsize; + + if (gelic_descr_get_status(descr) != GELIC_DESCR_DMA_NOT_IN_USE) + dev_info(ctodev(card), "%s: ERROR status\n", __func__); +- /* we need to round up the buffer size to a multiple of 128 */ +- bufsize = ALIGN(GELIC_NET_MAX_MTU, GELIC_NET_RXBUF_ALIGN); + +- /* and we need to have it 128 byte aligned, therefore we allocate a +- * bit more */ +- descr->skb = dev_alloc_skb(bufsize + GELIC_NET_RXBUF_ALIGN - 1); ++ descr->skb = netdev_alloc_skb(*card->netdev, rx_skb_size); + if (!descr->skb) { + descr->buf_addr = 0; /* tell DMAC don't touch memory */ + dev_info(ctodev(card), + "%s:allocate skb failed !!\n", __func__); + return -ENOMEM; + } +- descr->buf_size = cpu_to_be32(bufsize); ++ descr->buf_size = cpu_to_be32(rx_skb_size); + descr->dmac_cmd_status = 0; + descr->result_size = 0; + descr->valid_size = 0; +@@ -399,7 +400,7 @@ static int gelic_descr_prepare_rx(struct gelic_card *card, + /* io-mmu-map the skb */ + descr->buf_addr = cpu_to_be32(dma_map_single(ctodev(card), + descr->skb->data, +- GELIC_NET_MAX_MTU, ++ GELIC_NET_MAX_FRAME, + DMA_FROM_DEVICE)); + if (!descr->buf_addr) { + dev_kfree_skb_any(descr->skb); +@@ -917,7 +918,7 @@ static void gelic_net_pass_skb_up(struct gelic_descr *descr, + data_error = be32_to_cpu(descr->data_error); + /* unmap skb buffer */ + dma_unmap_single(ctodev(card), be32_to_cpu(descr->buf_addr), +- GELIC_NET_MAX_MTU, ++ GELIC_NET_MAX_FRAME, + DMA_FROM_DEVICE); + + skb_put(skb, be32_to_cpu(descr->valid_size)? +diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.h b/drivers/net/ethernet/toshiba/ps3_gelic_net.h +index 051033580f0a6..7624c68c95cbf 100644 +--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.h ++++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.h +@@ -19,8 +19,9 @@ + #define GELIC_NET_RX_DESCRIPTORS 128 /* num of descriptors */ + #define GELIC_NET_TX_DESCRIPTORS 128 /* num of descriptors */ + +-#define GELIC_NET_MAX_MTU VLAN_ETH_FRAME_LEN +-#define GELIC_NET_MIN_MTU VLAN_ETH_ZLEN ++#define GELIC_NET_MAX_FRAME 2312 ++#define GELIC_NET_MAX_MTU 2294 ++#define GELIC_NET_MIN_MTU 64 + #define GELIC_NET_RXBUF_ALIGN 128 + #define GELIC_CARD_RX_CSUM_DEFAULT 1 /* hw chksum */ + #define GELIC_NET_WATCHDOG_TIMEOUT 5*HZ +-- +2.39.2 + diff --git a/queue-5.4/net-ps3_gelic_net-use-dma_mapping_error.patch b/queue-5.4/net-ps3_gelic_net-use-dma_mapping_error.patch new file mode 100644 index 00000000000..5d0f0cc0539 --- /dev/null +++ b/queue-5.4/net-ps3_gelic_net-use-dma_mapping_error.patch @@ -0,0 +1,89 @@ +From 10a129ec979c4af4d76eba4505898e44c4af6562 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 18 Mar 2023 17:39:16 +0000 +Subject: net/ps3_gelic_net: Use dma_mapping_error + +From: Geoff Levand + +[ Upstream commit bebe933d35a63d4f042fbf4dce4f22e689ba0fcd ] + +The current Gelic Etherenet driver was checking the return value of its +dma_map_single call, and not using the dma_mapping_error() routine. + +Fixes runtime problems like these: + + DMA-API: ps3_gelic_driver sb_05: device driver failed to check map error + WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:1027 .check_unmap+0x888/0x8dc + +Fixes: 02c1889166b4 ("ps3: gigabit ethernet driver for PS3, take3") +Reviewed-by: Alexander Duyck +Signed-off-by: Geoff Levand +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/toshiba/ps3_gelic_net.c | 24 +++++++++++--------- + 1 file changed, 13 insertions(+), 11 deletions(-) + +diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c b/drivers/net/ethernet/toshiba/ps3_gelic_net.c +index c3e3477081e48..4e6c71da9f21f 100644 +--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c ++++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c +@@ -317,15 +317,17 @@ static int gelic_card_init_chain(struct gelic_card *card, + + /* set up the hardware pointers in each descriptor */ + for (i = 0; i < no; i++, descr++) { ++ dma_addr_t cpu_addr; ++ + gelic_descr_set_status(descr, GELIC_DESCR_DMA_NOT_IN_USE); +- descr->bus_addr = +- dma_map_single(ctodev(card), descr, +- GELIC_DESCR_SIZE, +- DMA_BIDIRECTIONAL); + +- if (!descr->bus_addr) ++ cpu_addr = dma_map_single(ctodev(card), descr, ++ GELIC_DESCR_SIZE, DMA_BIDIRECTIONAL); ++ ++ if (dma_mapping_error(ctodev(card), cpu_addr)) + goto iommu_error; + ++ descr->bus_addr = cpu_to_be32(cpu_addr); + descr->next = descr + 1; + descr->prev = descr - 1; + } +@@ -375,6 +377,7 @@ static int gelic_descr_prepare_rx(struct gelic_card *card, + static const unsigned int rx_skb_size = + ALIGN(GELIC_NET_MAX_FRAME, GELIC_NET_RXBUF_ALIGN) + + GELIC_NET_RXBUF_ALIGN - 1; ++ dma_addr_t cpu_addr; + int offset; + + if (gelic_descr_get_status(descr) != GELIC_DESCR_DMA_NOT_IN_USE) +@@ -398,11 +401,10 @@ static int gelic_descr_prepare_rx(struct gelic_card *card, + if (offset) + skb_reserve(descr->skb, GELIC_NET_RXBUF_ALIGN - offset); + /* io-mmu-map the skb */ +- descr->buf_addr = cpu_to_be32(dma_map_single(ctodev(card), +- descr->skb->data, +- GELIC_NET_MAX_FRAME, +- DMA_FROM_DEVICE)); +- if (!descr->buf_addr) { ++ cpu_addr = dma_map_single(ctodev(card), descr->skb->data, ++ GELIC_NET_MAX_FRAME, DMA_FROM_DEVICE); ++ descr->buf_addr = cpu_to_be32(cpu_addr); ++ if (dma_mapping_error(ctodev(card), cpu_addr)) { + dev_kfree_skb_any(descr->skb); + descr->skb = NULL; + dev_info(ctodev(card), +@@ -782,7 +784,7 @@ static int gelic_descr_prepare_tx(struct gelic_card *card, + + buf = dma_map_single(ctodev(card), skb->data, skb->len, DMA_TO_DEVICE); + +- if (!buf) { ++ if (dma_mapping_error(ctodev(card), buf)) { + dev_err(ctodev(card), + "dma map 2 failed (%p, %i). Dropping packet\n", + skb->data, skb->len); +-- +2.39.2 + diff --git a/queue-5.4/net-qcom-emac-fix-use-after-free-bug-in-emac_remove-.patch b/queue-5.4/net-qcom-emac-fix-use-after-free-bug-in-emac_remove-.patch new file mode 100644 index 00000000000..907bd191f60 --- /dev/null +++ b/queue-5.4/net-qcom-emac-fix-use-after-free-bug-in-emac_remove-.patch @@ -0,0 +1,63 @@ +From 5ebcf32100a6e340044f75ef31b8abeb26b526a2 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 18 Mar 2023 16:05:26 +0800 +Subject: net: qcom/emac: Fix use after free bug in emac_remove due to race + condition + +From: Zheng Wang + +[ Upstream commit 6b6bc5b8bd2d4ca9e1efa9ae0f98a0b0687ace75 ] + +In emac_probe, &adpt->work_thread is bound with +emac_work_thread. Then it will be started by timeout +handler emac_tx_timeout or a IRQ handler emac_isr. + +If we remove the driver which will call emac_remove + to make cleanup, there may be a unfinished work. + +The possible sequence is as follows: + +Fix it by finishing the work before cleanup in the emac_remove +and disable timeout response. + +CPU0 CPU1 + + |emac_work_thread +emac_remove | +free_netdev | +kfree(netdev); | + |emac_reinit_locked + |emac_mac_down + |//use netdev +Fixes: b9b17debc69d ("net: emac: emac gigabit ethernet controller driver") +Signed-off-by: Zheng Wang + +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/qualcomm/emac/emac.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c b/drivers/net/ethernet/qualcomm/emac/emac.c +index 5c199d2516d47..5fe28dec60c1d 100644 +--- a/drivers/net/ethernet/qualcomm/emac/emac.c ++++ b/drivers/net/ethernet/qualcomm/emac/emac.c +@@ -738,9 +738,15 @@ static int emac_remove(struct platform_device *pdev) + struct net_device *netdev = dev_get_drvdata(&pdev->dev); + struct emac_adapter *adpt = netdev_priv(netdev); + ++ netif_carrier_off(netdev); ++ netif_tx_disable(netdev); ++ + unregister_netdev(netdev); + netif_napi_del(&adpt->rx_q.napi); + ++ free_irq(adpt->irq.irq, &adpt->irq); ++ cancel_work_sync(&adpt->work_thread); ++ + emac_clks_teardown(adpt); + + put_device(&adpt->phydev->mdio.dev); +-- +2.39.2 + diff --git a/queue-5.4/net-sonic-use-dma_mapping_error-for-error-check.patch b/queue-5.4/net-sonic-use-dma_mapping_error-for-error-check.patch new file mode 100644 index 00000000000..22506ee7343 --- /dev/null +++ b/queue-5.4/net-sonic-use-dma_mapping_error-for-error-check.patch @@ -0,0 +1,49 @@ +From f9c4c7eb7090a962713c98a8ee7631762e4d90be Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 21 Mar 2023 14:45:43 +1100 +Subject: net/sonic: use dma_mapping_error() for error check + +From: Zhang Changzhong + +[ Upstream commit 4107b8746d93ace135b8c4da4f19bbae81db785f ] + +The DMA address returned by dma_map_single() should be checked with +dma_mapping_error(). Fix it accordingly. + +Fixes: efcce839360f ("[PATCH] macsonic/jazzsonic network drivers update") +Signed-off-by: Zhang Changzhong +Tested-by: Stan Johnson +Signed-off-by: Finn Thain +Reviewed-by: Leon Romanovsky +Link: https://lore.kernel.org/r/6645a4b5c1e364312103f48b7b36783b94e197a2.1679370343.git.fthain@linux-m68k.org +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/natsemi/sonic.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/net/ethernet/natsemi/sonic.c b/drivers/net/ethernet/natsemi/sonic.c +index 05e760444a92c..953708e2ab4b4 100644 +--- a/drivers/net/ethernet/natsemi/sonic.c ++++ b/drivers/net/ethernet/natsemi/sonic.c +@@ -256,7 +256,7 @@ static int sonic_send_packet(struct sk_buff *skb, struct net_device *dev) + */ + + laddr = dma_map_single(lp->device, skb->data, length, DMA_TO_DEVICE); +- if (!laddr) { ++ if (dma_mapping_error(lp->device, laddr)) { + pr_err_ratelimited("%s: failed to map tx DMA buffer.\n", dev->name); + dev_kfree_skb_any(skb); + return NETDEV_TX_OK; +@@ -474,7 +474,7 @@ static bool sonic_alloc_rb(struct net_device *dev, struct sonic_local *lp, + + *new_addr = dma_map_single(lp->device, skb_put(*new_skb, SONIC_RBSIZE), + SONIC_RBSIZE, DMA_FROM_DEVICE); +- if (!*new_addr) { ++ if (dma_mapping_error(lp->device, *new_addr)) { + dev_kfree_skb(*new_skb); + *new_skb = NULL; + return false; +-- +2.39.2 + diff --git a/queue-5.4/net-usb-smsc95xx-limit-packet-length-to-skb-len.patch b/queue-5.4/net-usb-smsc95xx-limit-packet-length-to-skb-len.patch new file mode 100644 index 00000000000..159d275ad2f --- /dev/null +++ b/queue-5.4/net-usb-smsc95xx-limit-packet-length-to-skb-len.patch @@ -0,0 +1,43 @@ +From d24826875af9f9cd61b4909ed66be20e5a4c0a21 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 16 Mar 2023 11:19:54 +0100 +Subject: net: usb: smsc95xx: Limit packet length to skb->len + +From: Szymon Heidrich + +[ Upstream commit ff821092cf02a70c2bccd2d19269f01e29aa52cf ] + +Packet length retrieved from descriptor may be larger than +the actual socket buffer length. In such case the cloned +skb passed up the network stack will leak kernel memory contents. + +Fixes: 2f7ca802bdae ("net: Add SMSC LAN9500 USB2.0 10/100 ethernet adapter driver") +Signed-off-by: Szymon Heidrich +Reviewed-by: Jakub Kicinski +Link: https://lore.kernel.org/r/20230316101954.75836-1-szymon.heidrich@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/usb/smsc95xx.c | 6 ++++++ + 1 file changed, 6 insertions(+) + +diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c +index bb4ccbda031ab..9a770f7fa5b02 100644 +--- a/drivers/net/usb/smsc95xx.c ++++ b/drivers/net/usb/smsc95xx.c +@@ -1935,6 +1935,12 @@ static int smsc95xx_rx_fixup(struct usbnet *dev, struct sk_buff *skb) + size = (u16)((header & RX_STS_FL_) >> 16); + align_count = (4 - ((size + NET_IP_ALIGN) % 4)) % 4; + ++ if (unlikely(size > skb->len)) { ++ netif_dbg(dev, rx_err, dev->net, ++ "size err header=0x%08x\n", header); ++ return 0; ++ } ++ + if (unlikely(header & RX_STS_ES_)) { + netif_dbg(dev, rx_err, dev->net, + "Error header=0x%08x\n", header); +-- +2.39.2 + diff --git a/queue-5.4/nvme-tcp-fix-nvme_tcp_term_pdu-to-match-spec.patch b/queue-5.4/nvme-tcp-fix-nvme_tcp_term_pdu-to-match-spec.patch new file mode 100644 index 00000000000..57df5fcc4a3 --- /dev/null +++ b/queue-5.4/nvme-tcp-fix-nvme_tcp_term_pdu-to-match-spec.patch @@ -0,0 +1,44 @@ +From 39925a1604e652f412a71d6b4116bdd0d6be53ff Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 20 Mar 2023 09:57:36 -0600 +Subject: nvme-tcp: fix nvme_tcp_term_pdu to match spec + +From: Caleb Sander + +[ Upstream commit aa01c67de5926fdb276793180564f172c55fb0d7 ] + +The FEI field of C2HTermReq/H2CTermReq is 4 bytes but not 4-byte-aligned +in the NVMe/TCP specification (it is located at offset 10 in the PDU). +Split it into two 16-bit integers in struct nvme_tcp_term_pdu +so no padding is inserted. There should also be 10 reserved bytes after. +There are currently no users of this type. + +Fixes: fc221d05447aa6db ("nvme-tcp: Add protocol header") +Reported-by: Geert Uytterhoeven +Signed-off-by: Caleb Sander +Reviewed-by: Sagi Grimberg +Signed-off-by: Christoph Hellwig +Signed-off-by: Sasha Levin +--- + include/linux/nvme-tcp.h | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +diff --git a/include/linux/nvme-tcp.h b/include/linux/nvme-tcp.h +index 959e0bd9a913e..73364ae916890 100644 +--- a/include/linux/nvme-tcp.h ++++ b/include/linux/nvme-tcp.h +@@ -114,8 +114,9 @@ struct nvme_tcp_icresp_pdu { + struct nvme_tcp_term_pdu { + struct nvme_tcp_hdr hdr; + __le16 fes; +- __le32 fei; +- __u8 rsvd[8]; ++ __le16 feil; ++ __le16 feiu; ++ __u8 rsvd[10]; + }; + + /** +-- +2.39.2 + diff --git a/queue-5.4/platform-chrome-cros_ec_chardev-fix-kernel-data-leak.patch b/queue-5.4/platform-chrome-cros_ec_chardev-fix-kernel-data-leak.patch new file mode 100644 index 00000000000..f99dd4048c9 --- /dev/null +++ b/queue-5.4/platform-chrome-cros_ec_chardev-fix-kernel-data-leak.patch @@ -0,0 +1,41 @@ +From 3be9eb4450579f7e131db7d9b2e3ccdec0e69495 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 24 Mar 2023 09:06:58 +0800 +Subject: platform/chrome: cros_ec_chardev: fix kernel data leak from ioctl + +From: Tzung-Bi Shih + +[ Upstream commit b20cf3f89c56b5f6a38b7f76a8128bf9f291bbd3 ] + +It is possible to peep kernel page's data by providing larger `insize` +in struct cros_ec_command[1] when invoking EC host commands. + +Fix it by using zeroed memory. + +[1]: https://elixir.bootlin.com/linux/v6.2/source/include/linux/platform_data/cros_ec_proto.h#L74 + +Fixes: eda2e30c6684 ("mfd / platform: cros_ec: Miscellaneous character device to talk with the EC") +Signed-off-by: Tzung-Bi Shih +Reviewed-by: Guenter Roeck +Link: https://lore.kernel.org/r/20230324010658.1082361-1-tzungbi@kernel.org +Signed-off-by: Sasha Levin +--- + drivers/platform/chrome/cros_ec_chardev.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/platform/chrome/cros_ec_chardev.c b/drivers/platform/chrome/cros_ec_chardev.c +index 1f5f4a46ab748..4791b62c2923f 100644 +--- a/drivers/platform/chrome/cros_ec_chardev.c ++++ b/drivers/platform/chrome/cros_ec_chardev.c +@@ -285,7 +285,7 @@ static long cros_ec_chardev_ioctl_xcmd(struct cros_ec_dev *ec, void __user *arg) + u_cmd.insize > EC_MAX_MSG_BYTES) + return -EINVAL; + +- s_cmd = kmalloc(sizeof(*s_cmd) + max(u_cmd.outsize, u_cmd.insize), ++ s_cmd = kzalloc(sizeof(*s_cmd) + max(u_cmd.outsize, u_cmd.insize), + GFP_KERNEL); + if (!s_cmd) + return -ENOMEM; +-- +2.39.2 + diff --git a/queue-5.4/power-supply-da9150-fix-use-after-free-bug-in-da9150.patch b/queue-5.4/power-supply-da9150-fix-use-after-free-bug-in-da9150.patch new file mode 100644 index 00000000000..471294150ec --- /dev/null +++ b/queue-5.4/power-supply-da9150-fix-use-after-free-bug-in-da9150.patch @@ -0,0 +1,55 @@ +From 9faebfd26084f21bd594748c4aef287981ce50e6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 12 Mar 2023 01:46:50 +0800 +Subject: power: supply: da9150: Fix use after free bug in + da9150_charger_remove due to race condition + +From: Zheng Wang + +[ Upstream commit 06615d11cc78162dfd5116efb71f29eb29502d37 ] + +In da9150_charger_probe, &charger->otg_work is bound with +da9150_charger_otg_work. da9150_charger_otg_ncb may be +called to start the work. + +If we remove the module which will call da9150_charger_remove +to make cleanup, there may be a unfinished work. The possible +sequence is as follows: + +Fix it by canceling the work before cleanup in the da9150_charger_remove + +CPU0 CPUc1 + + |da9150_charger_otg_work +da9150_charger_remove | +power_supply_unregister | +device_unregister | +power_supply_dev_release| +kfree(psy) | + | + | power_supply_changed(charger->usb); + | //use + +Fixes: c1a281e34dae ("power: Add support for DA9150 Charger") +Signed-off-by: Zheng Wang +Signed-off-by: Sebastian Reichel +Signed-off-by: Sasha Levin +--- + drivers/power/supply/da9150-charger.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/power/supply/da9150-charger.c b/drivers/power/supply/da9150-charger.c +index f9314cc0cd75f..6b987da586556 100644 +--- a/drivers/power/supply/da9150-charger.c ++++ b/drivers/power/supply/da9150-charger.c +@@ -662,6 +662,7 @@ static int da9150_charger_remove(struct platform_device *pdev) + + if (!IS_ERR_OR_NULL(charger->usb_phy)) + usb_unregister_notifier(charger->usb_phy, &charger->otg_nb); ++ cancel_work_sync(&charger->otg_work); + + power_supply_unregister(charger->battery); + power_supply_unregister(charger->usb); +-- +2.39.2 + diff --git a/queue-5.4/qed-qed_sriov-guard-against-null-derefs-from-qed_iov.patch b/queue-5.4/qed-qed_sriov-guard-against-null-derefs-from-qed_iov.patch new file mode 100644 index 00000000000..c3f103fdf4f --- /dev/null +++ b/queue-5.4/qed-qed_sriov-guard-against-null-derefs-from-qed_iov.patch @@ -0,0 +1,51 @@ +From 007af75377887c69ed8a50cd0f848f10ebd23dc5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 16 Mar 2023 13:29:21 +0300 +Subject: qed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info + +From: Daniil Tatianin + +[ Upstream commit 25143b6a01d0cc5319edd3de22ffa2578b045550 ] + +We have to make sure that the info returned by the helper is valid +before using it. + +Found by Linux Verification Center (linuxtesting.org) with the SVACE +static analysis tool. + +Fixes: f990c82c385b ("qed*: Add support for ndo_set_vf_trust") +Fixes: 733def6a04bf ("qed*: IOV link control") +Signed-off-by: Daniil Tatianin +Reviewed-by: Michal Swiatkowski +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/qlogic/qed/qed_sriov.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c b/drivers/net/ethernet/qlogic/qed/qed_sriov.c +index 20f840ea05030..caa0468df4b53 100644 +--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c ++++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c +@@ -4404,6 +4404,9 @@ qed_iov_configure_min_tx_rate(struct qed_dev *cdev, int vfid, u32 rate) + } + + vf = qed_iov_get_vf_info(QED_LEADING_HWFN(cdev), (u16)vfid, true); ++ if (!vf) ++ return -EINVAL; ++ + vport_id = vf->vport_id; + + return qed_configure_vport_wfq(cdev, vport_id, rate); +@@ -5150,7 +5153,7 @@ static void qed_iov_handle_trust_change(struct qed_hwfn *hwfn) + + /* Validate that the VF has a configured vport */ + vf = qed_iov_get_vf_info(hwfn, i, true); +- if (!vf->vport_instance) ++ if (!vf || !vf->vport_instance) + continue; + + memset(¶ms, 0, sizeof(params)); +-- +2.39.2 + diff --git a/queue-5.4/scsi-scsi_dh_alua-fix-memleak-for-qdata-in-alua_acti.patch b/queue-5.4/scsi-scsi_dh_alua-fix-memleak-for-qdata-in-alua_acti.patch new file mode 100644 index 00000000000..e87f89fc6aa --- /dev/null +++ b/queue-5.4/scsi-scsi_dh_alua-fix-memleak-for-qdata-in-alua_acti.patch @@ -0,0 +1,61 @@ +From ed0afe431939fb788412bf17c3b454d56f296669 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 15 Mar 2023 14:21:54 +0800 +Subject: scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate() + +From: Yu Kuai + +[ Upstream commit a13faca032acbf2699293587085293bdfaafc8ae ] + +If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not +freed, which will cause following memleak: + +unreferenced object 0xffff88810b2c6980 (size 32): + comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s) + hex dump (first 32 bytes): + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ + 40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$............. + backtrace: + [<0000000098f3a26d>] alua_activate+0xb0/0x320 + [<000000003b529641>] scsi_dh_activate+0xb2/0x140 + [<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath] + [<000000007adc9ace>] process_one_work+0x3c5/0x730 + [<00000000c457a985>] worker_thread+0x93/0x650 + [<00000000cb80e628>] kthread+0x1ba/0x210 + [<00000000a1e61077>] ret_from_fork+0x22/0x30 + +Fix the problem by freeing 'qdata' in error path. + +Fixes: 625fe857e4fa ("scsi: scsi_dh_alua: Check scsi_device_get() return value") +Signed-off-by: Yu Kuai +Link: https://lore.kernel.org/r/20230315062154.668812-1-yukuai1@huaweicloud.com +Reviewed-by: Benjamin Block +Reviewed-by: Bart Van Assche +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/device_handler/scsi_dh_alua.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c b/drivers/scsi/device_handler/scsi_dh_alua.c +index fe8a5e5c0df84..bf0b3178f84d0 100644 +--- a/drivers/scsi/device_handler/scsi_dh_alua.c ++++ b/drivers/scsi/device_handler/scsi_dh_alua.c +@@ -1036,10 +1036,12 @@ static int alua_activate(struct scsi_device *sdev, + rcu_read_unlock(); + mutex_unlock(&h->init_mutex); + +- if (alua_rtpg_queue(pg, sdev, qdata, true)) ++ if (alua_rtpg_queue(pg, sdev, qdata, true)) { + fn = NULL; +- else ++ } else { ++ kfree(qdata); + err = SCSI_DH_DEV_OFFLINED; ++ } + kref_put(&pg->kref, release_port_group); + out: + if (fn) +-- +2.39.2 + diff --git a/queue-5.4/series b/queue-5.4/series index 9ab4e5e2a1b..1435e58c25c 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -1 +1,27 @@ net-tls-fix-possible-race-condition-between-do_tls_g.patch +power-supply-da9150-fix-use-after-free-bug-in-da9150.patch +iavf-fix-inverted-rx-hash-condition-leading-to-disab.patch +iavf-fix-non-tunneled-ipv6-udp-packet-type-and-hashi.patch +intel-igbvf-free-irq-on-the-error-path-in-igbvf_requ.patch +igbvf-regard-vf-reset-nack-as-success.patch +i2c-imx-lpi2c-check-only-for-enabled-interrupt-flags.patch +scsi-scsi_dh_alua-fix-memleak-for-qdata-in-alua_acti.patch +net-usb-smsc95xx-limit-packet-length-to-skb-len.patch +qed-qed_sriov-guard-against-null-derefs-from-qed_iov.patch +xirc2ps_cs-fix-use-after-free-bug-in-xirc2ps_detach.patch +net-qcom-emac-fix-use-after-free-bug-in-emac_remove-.patch +net-ps3_gelic_net-fix-rx-sk_buff-length.patch +net-ps3_gelic_net-use-dma_mapping_error.patch +keys-do-not-cache-key-in-task-struct-if-key-is-reque.patch +bpf-adjust-insufficient-default-bpf_jit_limit.patch +net-mlx5-read-the-tc-mapping-of-all-priorities-on-et.patch +atm-idt77252-fix-kmemleak-when-rmmod-idt77252.patch +erspan-do-not-use-skb_mac_header-in-ndo_start_xmit.patch +net-sonic-use-dma_mapping_error-for-error-check.patch +nvme-tcp-fix-nvme_tcp_term_pdu-to-match-spec.patch +hvc-xen-prevent-concurrent-accesses-to-the-shared-ri.patch +net-dsa-mt7530-move-setting-ssc_delta-to-phy_interfa.patch +net-mdio-thunder-add-missing-fwnode_handle_put.patch +bluetooth-btqcomsmd-fix-command-timeout-after-settin.patch +bluetooth-btsdio-fix-use-after-free-bug-in-btsdio_re.patch +platform-chrome-cros_ec_chardev-fix-kernel-data-leak.patch diff --git a/queue-5.4/xirc2ps_cs-fix-use-after-free-bug-in-xirc2ps_detach.patch b/queue-5.4/xirc2ps_cs-fix-use-after-free-bug-in-xirc2ps_detach.patch new file mode 100644 index 00000000000..afaae080561 --- /dev/null +++ b/queue-5.4/xirc2ps_cs-fix-use-after-free-bug-in-xirc2ps_detach.patch @@ -0,0 +1,58 @@ +From 80d19816f148fb405f1ffe1fb5948b1ec40260ba Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 17 Mar 2023 00:15:26 +0800 +Subject: xirc2ps_cs: Fix use after free bug in xirc2ps_detach + +From: Zheng Wang + +[ Upstream commit e8d20c3ded59a092532513c9bd030d1ea66f5f44 ] + +In xirc2ps_probe, the local->tx_timeout_task was bounded +with xirc2ps_tx_timeout_task. When timeout occurs, +it will call xirc_tx_timeout->schedule_work to start the +work. + +When we call xirc2ps_detach to remove the driver, there +may be a sequence as follows: + +Stop responding to timeout tasks and complete scheduled +tasks before cleanup in xirc2ps_detach, which will fix +the problem. + +CPU0 CPU1 + + |xirc2ps_tx_timeout_task +xirc2ps_detach | + free_netdev | + kfree(dev); | + | + | do_reset + | //use dev + +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Signed-off-by: Zheng Wang +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/xircom/xirc2ps_cs.c | 5 +++++ + 1 file changed, 5 insertions(+) + +diff --git a/drivers/net/ethernet/xircom/xirc2ps_cs.c b/drivers/net/ethernet/xircom/xirc2ps_cs.c +index fd5288ff53b53..e3438cef5f9c6 100644 +--- a/drivers/net/ethernet/xircom/xirc2ps_cs.c ++++ b/drivers/net/ethernet/xircom/xirc2ps_cs.c +@@ -503,6 +503,11 @@ static void + xirc2ps_detach(struct pcmcia_device *link) + { + struct net_device *dev = link->priv; ++ struct local_info *local = netdev_priv(dev); ++ ++ netif_carrier_off(dev); ++ netif_tx_disable(dev); ++ cancel_work_sync(&local->tx_timeout_task); + + dev_dbg(&link->dev, "detach\n"); + +-- +2.39.2 +