From: Sasha Levin Date: Sat, 5 Nov 2022 13:27:08 +0000 (-0400) Subject: Fixes for 6.0 X-Git-Tag: v4.9.333~91 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=25c3ed2a21dbd9cefa3d2a34ed761a337a3365a9;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 6.0 Signed-off-by: Sasha Levin --- diff --git a/queue-6.0/ata-palmld-fix-return-value-check-in-palmld_pata_pro.patch b/queue-6.0/ata-palmld-fix-return-value-check-in-palmld_pata_pro.patch new file mode 100644 index 00000000000..62435a98ddd --- /dev/null +++ b/queue-6.0/ata-palmld-fix-return-value-check-in-palmld_pata_pro.patch @@ -0,0 +1,39 @@ +From 2a35ded6721c557ca64441079e058fc487ae41ab Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 29 Oct 2022 15:49:31 +0800 +Subject: ata: palmld: fix return value check in palmld_pata_probe() + +From: Yang Yingliang + +[ Upstream commit 015618c3ec19584c83ff179fa631be8cec906aaf ] + +If devm_platform_ioremap_resource() fails, it never return +NULL pointer, replace the check with IS_ERR(). + +Fixes: 57bf0f5a162d ("ARM: pxa: use pdev resource for palmld mmio") +Signed-off-by: Yang Yingliang +Reviewed-by: Sergey Shtylyov +Signed-off-by: Damien Le Moal +Signed-off-by: Sasha Levin +--- + drivers/ata/pata_palmld.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/ata/pata_palmld.c b/drivers/ata/pata_palmld.c +index 400e65190904..51caa2a427dd 100644 +--- a/drivers/ata/pata_palmld.c ++++ b/drivers/ata/pata_palmld.c +@@ -63,8 +63,8 @@ static int palmld_pata_probe(struct platform_device *pdev) + + /* remap drive's physical memory address */ + mem = devm_platform_ioremap_resource(pdev, 0); +- if (!mem) +- return -ENOMEM; ++ if (IS_ERR(mem)) ++ return PTR_ERR(mem); + + /* request and activate power and reset GPIOs */ + lda->power = devm_gpiod_get(dev, "power", GPIOD_OUT_HIGH); +-- +2.35.1 + diff --git a/queue-6.0/ata-pata_legacy-fix-pdc20230_set_piomode.patch b/queue-6.0/ata-pata_legacy-fix-pdc20230_set_piomode.patch new file mode 100644 index 00000000000..8435da006df --- /dev/null +++ b/queue-6.0/ata-pata_legacy-fix-pdc20230_set_piomode.patch @@ -0,0 +1,45 @@ +From 3b9688e04db7d057a92caf7f138db646a47ecf45 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 29 Oct 2022 00:07:06 +0300 +Subject: ata: pata_legacy: fix pdc20230_set_piomode() + +From: Sergey Shtylyov + +[ Upstream commit 171a93182eccd6e6835d2c86b40787f9f832efaa ] + +Clang gives a warning when compiling pata_legacy.c with 'make W=1' about +the 'rt' local variable in pdc20230_set_piomode() being set but unused. +Quite obviously, there is an outb() call missing to write back the updated +variable. Moreover, checking the docs by Petr Soucek revealed that bitwise +AND should have been done with a negated timing mask and the master/slave +timing masks were swapped while updating... + +Fixes: 669a5db411d8 ("[libata] Add a bunch of PATA drivers.") +Reported-by: Damien Le Moal +Signed-off-by: Sergey Shtylyov +Signed-off-by: Damien Le Moal +Signed-off-by: Sasha Levin +--- + drivers/ata/pata_legacy.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +diff --git a/drivers/ata/pata_legacy.c b/drivers/ata/pata_legacy.c +index 0a8bf09a5c19..03c580625c2c 100644 +--- a/drivers/ata/pata_legacy.c ++++ b/drivers/ata/pata_legacy.c +@@ -315,9 +315,10 @@ static void pdc20230_set_piomode(struct ata_port *ap, struct ata_device *adev) + outb(inb(0x1F4) & 0x07, 0x1F4); + + rt = inb(0x1F3); +- rt &= 0x07 << (3 * adev->devno); ++ rt &= ~(0x07 << (3 * !adev->devno)); + if (pio) +- rt |= (1 + 3 * pio) << (3 * adev->devno); ++ rt |= (1 + 3 * pio) << (3 * !adev->devno); ++ outb(rt, 0x1F3); + + udelay(100); + outb(inb(0x1F2) | 0x01, 0x1F2); +-- +2.35.1 + diff --git a/queue-6.0/bluetooth-hci_conn-fix-cis-connection-dst_type-handl.patch b/queue-6.0/bluetooth-hci_conn-fix-cis-connection-dst_type-handl.patch new file mode 100644 index 00000000000..0434b13d387 --- /dev/null +++ b/queue-6.0/bluetooth-hci_conn-fix-cis-connection-dst_type-handl.patch @@ -0,0 +1,95 @@ +From fa332c117942ca5b0e3e3712354f313bf027ebec Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 11 Oct 2022 22:25:33 +0300 +Subject: Bluetooth: hci_conn: Fix CIS connection dst_type handling + +From: Pauli Virtanen + +[ Upstream commit b36a234dc438cb6b76fc929a8df9a0e59c8acf23 ] + +hci_connect_cis and iso_connect_cis call hci_bind_cis inconsistently +with dst_type being either ISO socket address type or the HCI type, but +these values cannot be mixed like this. Fix this by using only the HCI +type. + +CIS connection dst_type was also not initialized in hci_bind_cis, even +though it is used in hci_conn_hash_lookup_cis to find existing +connections. Set the value in hci_bind_cis, so that existing CIS +connections are found e.g. when doing deferred socket connections, also +when dst_type is not 0 (ADDR_LE_DEV_PUBLIC). + +Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") +Signed-off-by: Pauli Virtanen +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + net/bluetooth/hci_conn.c | 7 +------ + net/bluetooth/iso.c | 14 ++++++++++++-- + 2 files changed, 13 insertions(+), 8 deletions(-) + +diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c +index 9777e7b109ee..f1263cdd71dd 100644 +--- a/net/bluetooth/hci_conn.c ++++ b/net/bluetooth/hci_conn.c +@@ -1697,6 +1697,7 @@ struct hci_conn *hci_bind_cis(struct hci_dev *hdev, bdaddr_t *dst, + if (!cis) + return ERR_PTR(-ENOMEM); + cis->cleanup = cis_cleanup; ++ cis->dst_type = dst_type; + } + + if (cis->state == BT_CONNECTED) +@@ -2076,12 +2077,6 @@ struct hci_conn *hci_connect_cis(struct hci_dev *hdev, bdaddr_t *dst, + struct hci_conn *le; + struct hci_conn *cis; + +- /* Convert from ISO socket address type to HCI address type */ +- if (dst_type == BDADDR_LE_PUBLIC) +- dst_type = ADDR_LE_DEV_PUBLIC; +- else +- dst_type = ADDR_LE_DEV_RANDOM; +- + if (hci_dev_test_flag(hdev, HCI_ADVERTISING)) + le = hci_connect_le(hdev, dst, dst_type, false, + BT_SECURITY_LOW, +diff --git a/net/bluetooth/iso.c b/net/bluetooth/iso.c +index 613039ba5dbf..f825857db6d0 100644 +--- a/net/bluetooth/iso.c ++++ b/net/bluetooth/iso.c +@@ -235,6 +235,14 @@ static int iso_chan_add(struct iso_conn *conn, struct sock *sk, + return err; + } + ++static inline u8 le_addr_type(u8 bdaddr_type) ++{ ++ if (bdaddr_type == BDADDR_LE_PUBLIC) ++ return ADDR_LE_DEV_PUBLIC; ++ else ++ return ADDR_LE_DEV_RANDOM; ++} ++ + static int iso_connect_bis(struct sock *sk) + { + struct iso_conn *conn; +@@ -328,14 +336,16 @@ static int iso_connect_cis(struct sock *sk) + /* Just bind if DEFER_SETUP has been set */ + if (test_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags)) { + hcon = hci_bind_cis(hdev, &iso_pi(sk)->dst, +- iso_pi(sk)->dst_type, &iso_pi(sk)->qos); ++ le_addr_type(iso_pi(sk)->dst_type), ++ &iso_pi(sk)->qos); + if (IS_ERR(hcon)) { + err = PTR_ERR(hcon); + goto done; + } + } else { + hcon = hci_connect_cis(hdev, &iso_pi(sk)->dst, +- iso_pi(sk)->dst_type, &iso_pi(sk)->qos); ++ le_addr_type(iso_pi(sk)->dst_type), ++ &iso_pi(sk)->qos); + if (IS_ERR(hcon)) { + err = PTR_ERR(hcon); + goto done; +-- +2.35.1 + diff --git a/queue-6.0/bluetooth-hci_conn-fix-not-restoring-iso-buffer-coun.patch b/queue-6.0/bluetooth-hci_conn-fix-not-restoring-iso-buffer-coun.patch new file mode 100644 index 00000000000..4edb2531900 --- /dev/null +++ b/queue-6.0/bluetooth-hci_conn-fix-not-restoring-iso-buffer-coun.patch @@ -0,0 +1,54 @@ +From ad6268f0a5c666e60979d4cf66b369e1c87daa20 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 17 Oct 2022 15:36:23 -0700 +Subject: Bluetooth: hci_conn: Fix not restoring ISO buffer count on disconnect +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Luiz Augusto von Dentz + +[ Upstream commit 5638d9ea9c01c77fc11693d48cf719bc7e88f224 ] + +When disconnecting an ISO link the controller may not generate +HCI_EV_NUM_COMP_PKTS for unacked packets which needs to be restored in +hci_conn_del otherwise the host would assume they are still in use and +would not be able to use all the buffers available. + +Fixes: 26afbd826ee3 ("Bluetooth: Add initial implementation of CIS connections") +Signed-off-by: Luiz Augusto von Dentz +Tested-by: Frédéric Danis +Signed-off-by: Sasha Levin +--- + net/bluetooth/hci_conn.c | 11 +++++++++++ + 1 file changed, 11 insertions(+) + +diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c +index f1263cdd71dd..f26ed278d9e3 100644 +--- a/net/bluetooth/hci_conn.c ++++ b/net/bluetooth/hci_conn.c +@@ -1003,10 +1003,21 @@ int hci_conn_del(struct hci_conn *conn) + hdev->acl_cnt += conn->sent; + } else { + struct hci_conn *acl = conn->link; ++ + if (acl) { + acl->link = NULL; + hci_conn_drop(acl); + } ++ ++ /* Unacked ISO frames */ ++ if (conn->type == ISO_LINK) { ++ if (hdev->iso_pkts) ++ hdev->iso_cnt += conn->sent; ++ else if (hdev->le_pkts) ++ hdev->le_cnt += conn->sent; ++ else ++ hdev->acl_cnt += conn->sent; ++ } + } + + if (conn->amp_mgr) +-- +2.35.1 + diff --git a/queue-6.0/bluetooth-l2cap-fix-memory-leak-in-vhci_write.patch b/queue-6.0/bluetooth-l2cap-fix-memory-leak-in-vhci_write.patch new file mode 100644 index 00000000000..6cd4df20473 --- /dev/null +++ b/queue-6.0/bluetooth-l2cap-fix-memory-leak-in-vhci_write.patch @@ -0,0 +1,82 @@ +From 6a7440be8612430732655a7ab1cda49ac2a9aec7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 18 Oct 2022 10:18:51 +0800 +Subject: Bluetooth: L2CAP: Fix memory leak in vhci_write + +From: Hawkins Jiawei + +[ Upstream commit 7c9524d929648935bac2bbb4c20437df8f9c3f42 ] + +Syzkaller reports a memory leak as follows: +==================================== +BUG: memory leak +unreferenced object 0xffff88810d81ac00 (size 240): + [...] + 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: + [] __alloc_skb+0x1f9/0x270 net/core/skbuff.c:418 + [] alloc_skb include/linux/skbuff.h:1257 [inline] + [] bt_skb_alloc include/net/bluetooth/bluetooth.h:469 [inline] + [] vhci_get_user drivers/bluetooth/hci_vhci.c:391 [inline] + [] vhci_write+0x5f/0x230 drivers/bluetooth/hci_vhci.c:511 + [] call_write_iter include/linux/fs.h:2192 [inline] + [] new_sync_write fs/read_write.c:491 [inline] + [] vfs_write+0x42d/0x540 fs/read_write.c:578 + [] ksys_write+0x9d/0x160 fs/read_write.c:631 + [] do_syscall_x64 arch/x86/entry/common.c:50 [inline] + [] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80 + [] entry_SYSCALL_64_after_hwframe+0x63/0xcd +==================================== + +HCI core will uses hci_rx_work() to process frame, which is queued to +the hdev->rx_q tail in hci_recv_frame() by HCI driver. + +Yet the problem is that, HCI core may not free the skb after handling +ACL data packets. To be more specific, when start fragment does not +contain the L2CAP length, HCI core just copies skb into conn->rx_skb and +finishes frame process in l2cap_recv_acldata(), without freeing the skb, +which triggers the above memory leak. + +This patch solves it by releasing the relative skb, after processing +the above case in l2cap_recv_acldata(). + +Fixes: 4d7ea8ee90e4 ("Bluetooth: L2CAP: Fix handling fragmented length") +Link: https://lore.kernel.org/all/0000000000000d0b1905e6aaef64@google.com/ +Reported-and-tested-by: syzbot+8f819e36e01022991cfa@syzkaller.appspotmail.com +Signed-off-by: Hawkins Jiawei +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + net/bluetooth/l2cap_core.c | 7 +++---- + 1 file changed, 3 insertions(+), 4 deletions(-) + +diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c +index 9a32ce634919..1fbe087d6ae4 100644 +--- a/net/bluetooth/l2cap_core.c ++++ b/net/bluetooth/l2cap_core.c +@@ -8461,9 +8461,8 @@ void l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 flags) + * expected length. + */ + if (skb->len < L2CAP_LEN_SIZE) { +- if (l2cap_recv_frag(conn, skb, conn->mtu) < 0) +- goto drop; +- return; ++ l2cap_recv_frag(conn, skb, conn->mtu); ++ break; + } + + len = get_unaligned_le16(skb->data) + L2CAP_HDR_SIZE; +@@ -8507,7 +8506,7 @@ void l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 flags) + + /* Header still could not be read just continue */ + if (conn->rx_skb->len < L2CAP_LEN_SIZE) +- return; ++ break; + } + + if (skb->len > conn->rx_len) { +-- +2.35.1 + diff --git a/queue-6.0/bluetooth-l2cap-fix-use-after-free-caused-by-l2cap_r.patch b/queue-6.0/bluetooth-l2cap-fix-use-after-free-caused-by-l2cap_r.patch new file mode 100644 index 00000000000..7e8eed40a41 --- /dev/null +++ b/queue-6.0/bluetooth-l2cap-fix-use-after-free-caused-by-l2cap_r.patch @@ -0,0 +1,175 @@ +From d23e2c358dfbbadefeefbc737c3d1422284f049b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 5 Oct 2022 00:27:18 +0300 +Subject: Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu + +From: Maxim Mikityanskiy + +[ Upstream commit 3aff8aaca4e36dc8b17eaa011684881a80238966 ] + +Fix the race condition between the following two flows that run in +parallel: + +1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) -> + __sock_queue_rcv_skb. + +2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram. + +An SKB can be queued by the first flow and immediately dequeued and +freed by the second flow, therefore the callers of l2cap_reassemble_sdu +can't use the SKB after that function returns. However, some places +continue accessing struct l2cap_ctrl that resides in the SKB's CB for a +short time after l2cap_reassemble_sdu returns, leading to a +use-after-free condition (the stack trace is below, line numbers for +kernel 5.19.8). + +Fix it by keeping a local copy of struct l2cap_ctrl. + +BUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth +Read of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169 + +Workqueue: hci0 hci_rx_work [bluetooth] +Call Trace: + + dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4)) + print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429) + ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth + kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493) + ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth + l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth + l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth + ret_from_fork (arch/x86/entry/entry_64.S:306) + + +Allocated by task 43169: + kasan_save_stack (mm/kasan/common.c:39) + __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469) + kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293) + __alloc_skb (net/core/skbuff.c:414) + l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth + l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth + hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth + process_one_work (kernel/workqueue.c:2289) + worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437) + kthread (kernel/kthread.c:376) + ret_from_fork (arch/x86/entry/entry_64.S:306) + +Freed by task 27920: + kasan_save_stack (mm/kasan/common.c:39) + kasan_set_track (mm/kasan/common.c:45) + kasan_set_free_info (mm/kasan/generic.c:372) + ____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328) + slab_free_freelist_hook (mm/slub.c:1780) + kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553) + skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323) + bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth + l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth + sock_read_iter (net/socket.c:1087) + new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401) + vfs_read (fs/read_write.c:482) + ksys_read (fs/read_write.c:620) + do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) + entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120) + +Link: https://lore.kernel.org/linux-bluetooth/CAKErNvoqga1WcmoR3-0875esY6TVWFQDandbVZncSiuGPBQXLA@mail.gmail.com/T/#u +Fixes: d2a7ac5d5d3a ("Bluetooth: Add the ERTM receive state machine") +Fixes: 4b51dae96731 ("Bluetooth: Add streaming mode receive and incoming packet classifier") +Signed-off-by: Maxim Mikityanskiy +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + net/bluetooth/l2cap_core.c | 48 ++++++++++++++++++++++++++++++++------ + 1 file changed, 41 insertions(+), 7 deletions(-) + +diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c +index 1f34b82ca0ec..2283871d3f01 100644 +--- a/net/bluetooth/l2cap_core.c ++++ b/net/bluetooth/l2cap_core.c +@@ -6885,6 +6885,7 @@ static int l2cap_rx_state_recv(struct l2cap_chan *chan, + struct l2cap_ctrl *control, + struct sk_buff *skb, u8 event) + { ++ struct l2cap_ctrl local_control; + int err = 0; + bool skb_in_use = false; + +@@ -6909,15 +6910,32 @@ static int l2cap_rx_state_recv(struct l2cap_chan *chan, + chan->buffer_seq = chan->expected_tx_seq; + skb_in_use = true; + ++ /* l2cap_reassemble_sdu may free skb, hence invalidate ++ * control, so make a copy in advance to use it after ++ * l2cap_reassemble_sdu returns and to avoid the race ++ * condition, for example: ++ * ++ * The current thread calls: ++ * l2cap_reassemble_sdu ++ * chan->ops->recv == l2cap_sock_recv_cb ++ * __sock_queue_rcv_skb ++ * Another thread calls: ++ * bt_sock_recvmsg ++ * skb_recv_datagram ++ * skb_free_datagram ++ * Then the current thread tries to access control, but ++ * it was freed by skb_free_datagram. ++ */ ++ local_control = *control; + err = l2cap_reassemble_sdu(chan, skb, control); + if (err) + break; + +- if (control->final) { ++ if (local_control.final) { + if (!test_and_clear_bit(CONN_REJ_ACT, + &chan->conn_state)) { +- control->final = 0; +- l2cap_retransmit_all(chan, control); ++ local_control.final = 0; ++ l2cap_retransmit_all(chan, &local_control); + l2cap_ertm_send(chan); + } + } +@@ -7297,11 +7315,27 @@ static int l2cap_rx(struct l2cap_chan *chan, struct l2cap_ctrl *control, + static int l2cap_stream_rx(struct l2cap_chan *chan, struct l2cap_ctrl *control, + struct sk_buff *skb) + { ++ /* l2cap_reassemble_sdu may free skb, hence invalidate control, so store ++ * the txseq field in advance to use it after l2cap_reassemble_sdu ++ * returns and to avoid the race condition, for example: ++ * ++ * The current thread calls: ++ * l2cap_reassemble_sdu ++ * chan->ops->recv == l2cap_sock_recv_cb ++ * __sock_queue_rcv_skb ++ * Another thread calls: ++ * bt_sock_recvmsg ++ * skb_recv_datagram ++ * skb_free_datagram ++ * Then the current thread tries to access control, but it was freed by ++ * skb_free_datagram. ++ */ ++ u16 txseq = control->txseq; ++ + BT_DBG("chan %p, control %p, skb %p, state %d", chan, control, skb, + chan->rx_state); + +- if (l2cap_classify_txseq(chan, control->txseq) == +- L2CAP_TXSEQ_EXPECTED) { ++ if (l2cap_classify_txseq(chan, txseq) == L2CAP_TXSEQ_EXPECTED) { + l2cap_pass_to_tx(chan, control); + + BT_DBG("buffer_seq %u->%u", chan->buffer_seq, +@@ -7324,8 +7358,8 @@ static int l2cap_stream_rx(struct l2cap_chan *chan, struct l2cap_ctrl *control, + } + } + +- chan->last_acked_seq = control->txseq; +- chan->expected_tx_seq = __next_seq(chan, control->txseq); ++ chan->last_acked_seq = txseq; ++ chan->expected_tx_seq = __next_seq(chan, txseq); + + return 0; + } +-- +2.35.1 + diff --git a/queue-6.0/bluetooth-l2cap-fix-use-after-free-in-l2cap_conn_del.patch b/queue-6.0/bluetooth-l2cap-fix-use-after-free-in-l2cap_conn_del.patch new file mode 100644 index 00000000000..bc2f88b1f7a --- /dev/null +++ b/queue-6.0/bluetooth-l2cap-fix-use-after-free-in-l2cap_conn_del.patch @@ -0,0 +1,141 @@ +From ec533fb857684251b2e1d8a0af3404c1bb1dd668 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 17 Oct 2022 15:58:13 +0800 +Subject: Bluetooth: L2CAP: fix use-after-free in l2cap_conn_del() + +From: Zhengchao Shao + +[ Upstream commit 0d0e2d032811280b927650ff3c15fe5020e82533 ] + +When l2cap_recv_frame() is invoked to receive data, and the cid is +L2CAP_CID_A2MP, if the channel does not exist, it will create a channel. +However, after a channel is created, the hold operation of the channel +is not performed. In this case, the value of channel reference counting +is 1. As a result, after hci_error_reset() is triggered, l2cap_conn_del() +invokes the close hook function of A2MP to release the channel. Then + l2cap_chan_unlock(chan) will trigger UAF issue. + +The process is as follows: +Receive data: +l2cap_data_channel() + a2mp_channel_create() --->channel ref is 2 + l2cap_chan_put() --->channel ref is 1 + +Triger event: + hci_error_reset() + hci_dev_do_close() + ... + l2cap_disconn_cfm() + l2cap_conn_del() + l2cap_chan_hold() --->channel ref is 2 + l2cap_chan_del() --->channel ref is 1 + a2mp_chan_close_cb() --->channel ref is 0, release channel + l2cap_chan_unlock() --->UAF of channel + +The detailed Call Trace is as follows: +BUG: KASAN: use-after-free in __mutex_unlock_slowpath+0xa6/0x5e0 +Read of size 8 at addr ffff8880160664b8 by task kworker/u11:1/7593 +Workqueue: hci0 hci_error_reset +Call Trace: + + dump_stack_lvl+0xcd/0x134 + print_report.cold+0x2ba/0x719 + kasan_report+0xb1/0x1e0 + kasan_check_range+0x140/0x190 + __mutex_unlock_slowpath+0xa6/0x5e0 + l2cap_conn_del+0x404/0x7b0 + l2cap_disconn_cfm+0x8c/0xc0 + hci_conn_hash_flush+0x11f/0x260 + hci_dev_close_sync+0x5f5/0x11f0 + hci_dev_do_close+0x2d/0x70 + hci_error_reset+0x9e/0x140 + process_one_work+0x98a/0x1620 + worker_thread+0x665/0x1080 + kthread+0x2e4/0x3a0 + ret_from_fork+0x1f/0x30 + + +Allocated by task 7593: + kasan_save_stack+0x1e/0x40 + __kasan_kmalloc+0xa9/0xd0 + l2cap_chan_create+0x40/0x930 + amp_mgr_create+0x96/0x990 + a2mp_channel_create+0x7d/0x150 + l2cap_recv_frame+0x51b8/0x9a70 + l2cap_recv_acldata+0xaa3/0xc00 + hci_rx_work+0x702/0x1220 + process_one_work+0x98a/0x1620 + worker_thread+0x665/0x1080 + kthread+0x2e4/0x3a0 + ret_from_fork+0x1f/0x30 + +Freed by task 7593: + kasan_save_stack+0x1e/0x40 + kasan_set_track+0x21/0x30 + kasan_set_free_info+0x20/0x30 + ____kasan_slab_free+0x167/0x1c0 + slab_free_freelist_hook+0x89/0x1c0 + kfree+0xe2/0x580 + l2cap_chan_put+0x22a/0x2d0 + l2cap_conn_del+0x3fc/0x7b0 + l2cap_disconn_cfm+0x8c/0xc0 + hci_conn_hash_flush+0x11f/0x260 + hci_dev_close_sync+0x5f5/0x11f0 + hci_dev_do_close+0x2d/0x70 + hci_error_reset+0x9e/0x140 + process_one_work+0x98a/0x1620 + worker_thread+0x665/0x1080 + kthread+0x2e4/0x3a0 + ret_from_fork+0x1f/0x30 + +Last potentially related work creation: + kasan_save_stack+0x1e/0x40 + __kasan_record_aux_stack+0xbe/0xd0 + call_rcu+0x99/0x740 + netlink_release+0xe6a/0x1cf0 + __sock_release+0xcd/0x280 + sock_close+0x18/0x20 + __fput+0x27c/0xa90 + task_work_run+0xdd/0x1a0 + exit_to_user_mode_prepare+0x23c/0x250 + syscall_exit_to_user_mode+0x19/0x50 + do_syscall_64+0x42/0x80 + entry_SYSCALL_64_after_hwframe+0x63/0xcd + +Second to last potentially related work creation: + kasan_save_stack+0x1e/0x40 + __kasan_record_aux_stack+0xbe/0xd0 + call_rcu+0x99/0x740 + netlink_release+0xe6a/0x1cf0 + __sock_release+0xcd/0x280 + sock_close+0x18/0x20 + __fput+0x27c/0xa90 + task_work_run+0xdd/0x1a0 + exit_to_user_mode_prepare+0x23c/0x250 + syscall_exit_to_user_mode+0x19/0x50 + do_syscall_64+0x42/0x80 + entry_SYSCALL_64_after_hwframe+0x63/0xcd + +Fixes: d0be8347c623 ("Bluetooth: L2CAP: Fix use-after-free caused by l2cap_chan_put") +Signed-off-by: Zhengchao Shao +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + net/bluetooth/l2cap_core.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c +index 2283871d3f01..9a32ce634919 100644 +--- a/net/bluetooth/l2cap_core.c ++++ b/net/bluetooth/l2cap_core.c +@@ -7615,6 +7615,7 @@ static void l2cap_data_channel(struct l2cap_conn *conn, u16 cid, + return; + } + ++ l2cap_chan_hold(chan); + l2cap_chan_lock(chan); + } else { + BT_DBG("unknown cid 0x%4.4x", cid); +-- +2.35.1 + diff --git a/queue-6.0/bluetooth-virtio_bt-use-skb_put-to-set-length.patch b/queue-6.0/bluetooth-virtio_bt-use-skb_put-to-set-length.patch new file mode 100644 index 00000000000..197349adff3 --- /dev/null +++ b/queue-6.0/bluetooth-virtio_bt-use-skb_put-to-set-length.patch @@ -0,0 +1,43 @@ +From 8b871df9725d37f038009542a053f1fcc75f974a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 12 Oct 2022 09:45:06 +0200 +Subject: Bluetooth: virtio_bt: Use skb_put to set length + +From: Soenke Huster + +[ Upstream commit 160fbcf3bfb93c3c086427f9f4c8bc70f217e9be ] + +By using skb_put we ensure that skb->tail is set +correctly. Currently, skb->tail is always zero, which +leads to errors, such as the following page fault in +rfcomm_recv_frame: + + BUG: unable to handle page fault for address: ffffed1021de29ff + #PF: supervisor read access in kernel mode + #PF: error_code(0x0000) - not-present page + RIP: 0010:rfcomm_run+0x831/0x4040 (net/bluetooth/rfcomm/core.c:1751) + +Fixes: afd2daa26c7a ("Bluetooth: Add support for virtio transport driver") +Signed-off-by: Soenke Huster +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Sasha Levin +--- + drivers/bluetooth/virtio_bt.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/bluetooth/virtio_bt.c b/drivers/bluetooth/virtio_bt.c +index 67c21263f9e0..fd281d439505 100644 +--- a/drivers/bluetooth/virtio_bt.c ++++ b/drivers/bluetooth/virtio_bt.c +@@ -219,7 +219,7 @@ static void virtbt_rx_work(struct work_struct *work) + if (!skb) + return; + +- skb->len = len; ++ skb_put(skb, len); + virtbt_rx_handle(vbt, skb); + + if (virtbt_add_inbuf(vbt) < 0) +-- +2.35.1 + diff --git a/queue-6.0/bridge-fix-flushing-of-dynamic-fdb-entries.patch b/queue-6.0/bridge-fix-flushing-of-dynamic-fdb-entries.patch new file mode 100644 index 00000000000..2359fda976f --- /dev/null +++ b/queue-6.0/bridge-fix-flushing-of-dynamic-fdb-entries.patch @@ -0,0 +1,75 @@ +From 486e4dcf04744bc4a1d5fbf7316140d95ac49ae9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 1 Nov 2022 20:57:53 +0200 +Subject: bridge: Fix flushing of dynamic FDB entries + +From: Ido Schimmel + +[ Upstream commit 628ac04a75ed5ff13647e725f40192da22ef2be8 ] + +The following commands should result in all the dynamic FDB entries +being flushed, but instead all the non-local (non-permanent) entries are +flushed: + + # bridge fdb add 00:aa:bb:cc:dd:ee dev dummy1 master static + # bridge fdb add 00:11:22:33:44:55 dev dummy1 master dynamic + # ip link set dev br0 type bridge fdb_flush + # bridge fdb show brport dummy1 + 00:00:00:00:00:01 master br0 permanent + 33:33:00:00:00:01 self permanent + 01:00:5e:00:00:01 self permanent + +This is because br_fdb_flush() works with FDB flags and not the +corresponding enumerator values. Fix by passing the FDB flag instead. + +After the fix: + + # bridge fdb add 00:aa:bb:cc:dd:ee dev dummy1 master static + # bridge fdb add 00:11:22:33:44:55 dev dummy1 master dynamic + # ip link set dev br0 type bridge fdb_flush + # bridge fdb show brport dummy1 + 00:aa:bb:cc:dd:ee master br0 static + 00:00:00:00:00:01 master br0 permanent + 33:33:00:00:00:01 self permanent + 01:00:5e:00:00:01 self permanent + +Fixes: 1f78ee14eeac ("net: bridge: fdb: add support for fine-grained flushing") +Signed-off-by: Ido Schimmel +Acked-by: Nikolay Aleksandrov +Link: https://lore.kernel.org/r/20221101185753.2120691-1-idosch@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/bridge/br_netlink.c | 2 +- + net/bridge/br_sysfs_br.c | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c +index 5aeb3646e74c..d087fd4c784a 100644 +--- a/net/bridge/br_netlink.c ++++ b/net/bridge/br_netlink.c +@@ -1332,7 +1332,7 @@ static int br_changelink(struct net_device *brdev, struct nlattr *tb[], + + if (data[IFLA_BR_FDB_FLUSH]) { + struct net_bridge_fdb_flush_desc desc = { +- .flags_mask = BR_FDB_STATIC ++ .flags_mask = BIT(BR_FDB_STATIC) + }; + + br_fdb_flush(br, &desc); +diff --git a/net/bridge/br_sysfs_br.c b/net/bridge/br_sysfs_br.c +index 612e367fff20..ea733542244c 100644 +--- a/net/bridge/br_sysfs_br.c ++++ b/net/bridge/br_sysfs_br.c +@@ -345,7 +345,7 @@ static int set_flush(struct net_bridge *br, unsigned long val, + struct netlink_ext_ack *extack) + { + struct net_bridge_fdb_flush_desc desc = { +- .flags_mask = BR_FDB_STATIC ++ .flags_mask = BIT(BR_FDB_STATIC) + }; + + br_fdb_flush(br, &desc); +-- +2.35.1 + diff --git a/queue-6.0/btrfs-fix-inode-list-leak-during-backref-walking-at-.patch b/queue-6.0/btrfs-fix-inode-list-leak-during-backref-walking-at-.patch new file mode 100644 index 00000000000..2c76d4aad3f --- /dev/null +++ b/queue-6.0/btrfs-fix-inode-list-leak-during-backref-walking-at-.patch @@ -0,0 +1,94 @@ +From 2de33bdbe6912904a20b338d0ebf0e7804c13b53 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 1 Nov 2022 16:15:37 +0000 +Subject: btrfs: fix inode list leak during backref walking at + resolve_indirect_refs() + +From: Filipe Manana + +[ Upstream commit 5614dc3a47e3310fbc77ea3b67eaadd1c6417bf1 ] + +During backref walking, at resolve_indirect_refs(), if we get an error +we jump to the 'out' label and call ulist_free() on the 'parents' ulist, +which frees all the elements in the ulist - however that does not free +any inode lists that may be attached to elements, through the 'aux' field +of a ulist node, so we end up leaking lists if we have any attached to +the unodes. + +Fix this by calling free_leaf_list() instead of ulist_free() when we exit +from resolve_indirect_refs(). The static function free_leaf_list() is +moved up for this to be possible and it's slightly simplified by removing +unnecessary code. + +Fixes: 3301958b7c1d ("Btrfs: add inodes before dropping the extent lock in find_all_leafs") +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Sasha Levin +--- + fs/btrfs/backref.c | 36 +++++++++++++++++------------------- + 1 file changed, 17 insertions(+), 19 deletions(-) + +diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c +index ccc818b40977..90702a74f90c 100644 +--- a/fs/btrfs/backref.c ++++ b/fs/btrfs/backref.c +@@ -648,6 +648,18 @@ unode_aux_to_inode_list(struct ulist_node *node) + return (struct extent_inode_elem *)(uintptr_t)node->aux; + } + ++static void free_leaf_list(struct ulist *ulist) ++{ ++ struct ulist_node *node; ++ struct ulist_iterator uiter; ++ ++ ULIST_ITER_INIT(&uiter); ++ while ((node = ulist_next(ulist, &uiter))) ++ free_inode_elem_list(unode_aux_to_inode_list(node)); ++ ++ ulist_free(ulist); ++} ++ + /* + * We maintain three separate rbtrees: one for direct refs, one for + * indirect refs which have a key, and one for indirect refs which do not +@@ -762,7 +774,11 @@ static int resolve_indirect_refs(struct btrfs_fs_info *fs_info, + cond_resched(); + } + out: +- ulist_free(parents); ++ /* ++ * We may have inode lists attached to refs in the parents ulist, so we ++ * must free them before freeing the ulist and its refs. ++ */ ++ free_leaf_list(parents); + return ret; + } + +@@ -1409,24 +1425,6 @@ static int find_parent_nodes(struct btrfs_trans_handle *trans, + return ret; + } + +-static void free_leaf_list(struct ulist *blocks) +-{ +- struct ulist_node *node = NULL; +- struct extent_inode_elem *eie; +- struct ulist_iterator uiter; +- +- ULIST_ITER_INIT(&uiter); +- while ((node = ulist_next(blocks, &uiter))) { +- if (!node->aux) +- continue; +- eie = unode_aux_to_inode_list(node); +- free_inode_elem_list(eie); +- node->aux = 0; +- } +- +- ulist_free(blocks); +-} +- + /* + * Finds all leafs with a reference to the specified combination of bytenr and + * offset. key_list_head will point to a list of corresponding keys (caller must +-- +2.35.1 + diff --git a/queue-6.0/btrfs-fix-inode-list-leak-during-backref-walking-at-.patch-31031 b/queue-6.0/btrfs-fix-inode-list-leak-during-backref-walking-at-.patch-31031 new file mode 100644 index 00000000000..8700f5e86dd --- /dev/null +++ b/queue-6.0/btrfs-fix-inode-list-leak-during-backref-walking-at-.patch-31031 @@ -0,0 +1,81 @@ +From 173b6de7b17548c748eb14986c80f23cbf43e5c9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 1 Nov 2022 16:15:38 +0000 +Subject: btrfs: fix inode list leak during backref walking at + find_parent_nodes() + +From: Filipe Manana + +[ Upstream commit 92876eec382a0f19f33d09d2c939e9ca49038ae5 ] + +During backref walking, at find_parent_nodes(), if we are dealing with a +data extent and we get an error while resolving the indirect backrefs, at +resolve_indirect_refs(), or in the while loop that iterates over the refs +in the direct refs rbtree, we end up leaking the inode lists attached to +the direct refs we have in the direct refs rbtree that were not yet added +to the refs ulist passed as argument to find_parent_nodes(). Since they +were not yet added to the refs ulist and prelim_release() does not free +the lists, on error the caller can only free the lists attached to the +refs that were added to the refs ulist, all the remaining refs get their +inode lists never freed, therefore leaking their memory. + +Fix this by having prelim_release() always free any attached inode list +to each ref found in the rbtree, and have find_parent_nodes() set the +ref's inode list to NULL once it transfers ownership of the inode list +to a ref added to the refs ulist passed to find_parent_nodes(). + +Fixes: 86d5f9944252 ("btrfs: convert prelimary reference tracking to use rbtrees") +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Sasha Levin +--- + fs/btrfs/backref.c | 18 +++++++++++++++++- + 1 file changed, 17 insertions(+), 1 deletion(-) + +diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c +index 90702a74f90c..21c478df6aef 100644 +--- a/fs/btrfs/backref.c ++++ b/fs/btrfs/backref.c +@@ -289,8 +289,10 @@ static void prelim_release(struct preftree *preftree) + struct prelim_ref *ref, *next_ref; + + rbtree_postorder_for_each_entry_safe(ref, next_ref, +- &preftree->root.rb_root, rbnode) ++ &preftree->root.rb_root, rbnode) { ++ free_inode_elem_list(ref->inode_list); + free_pref(ref); ++ } + + preftree->root = RB_ROOT_CACHED; + preftree->count = 0; +@@ -1384,6 +1386,12 @@ static int find_parent_nodes(struct btrfs_trans_handle *trans, + if (ret < 0) + goto out; + ref->inode_list = eie; ++ /* ++ * We transferred the list ownership to the ref, ++ * so set to NULL to avoid a double free in case ++ * an error happens after this. ++ */ ++ eie = NULL; + } + ret = ulist_add_merge_ptr(refs, ref->parent, + ref->inode_list, +@@ -1409,6 +1417,14 @@ static int find_parent_nodes(struct btrfs_trans_handle *trans, + eie->next = ref->inode_list; + } + eie = NULL; ++ /* ++ * We have transferred the inode list ownership from ++ * this ref to the ref we added to the 'refs' ulist. ++ * So set this ref's inode list to NULL to avoid ++ * use-after-free when our caller uses it or double ++ * frees in case an error happens before we return. ++ */ ++ ref->inode_list = NULL; + } + cond_resched(); + } +-- +2.35.1 + diff --git a/queue-6.0/btrfs-fix-ulist-leaks-in-error-paths-of-qgroup-self-.patch b/queue-6.0/btrfs-fix-ulist-leaks-in-error-paths-of-qgroup-self-.patch new file mode 100644 index 00000000000..3bb71c35d15 --- /dev/null +++ b/queue-6.0/btrfs-fix-ulist-leaks-in-error-paths-of-qgroup-self-.patch @@ -0,0 +1,90 @@ +From f27946c4bdca73f5c35318dfa54b629216bd1187 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 1 Nov 2022 16:15:39 +0000 +Subject: btrfs: fix ulist leaks in error paths of qgroup self tests + +From: Filipe Manana + +[ Upstream commit d37de92b38932d40e4a251e876cc388f9aee5f42 ] + +In the test_no_shared_qgroup() and test_multiple_refs() qgroup self tests, +if we fail to add the tree ref, remove the extent item or remove the +extent ref, we are returning from the test function without freeing the +"old_roots" ulist that was allocated by the previous calls to +btrfs_find_all_roots(). Fix that by calling ulist_free() before returning. + +Fixes: 442244c96332 ("btrfs: qgroup: Switch self test to extent-oriented qgroup mechanism.") +Signed-off-by: Filipe Manana +Signed-off-by: David Sterba +Signed-off-by: Sasha Levin +--- + fs/btrfs/tests/qgroup-tests.c | 20 +++++++++++++++----- + 1 file changed, 15 insertions(+), 5 deletions(-) + +diff --git a/fs/btrfs/tests/qgroup-tests.c b/fs/btrfs/tests/qgroup-tests.c +index eee1e4459541..843dd3d3adbe 100644 +--- a/fs/btrfs/tests/qgroup-tests.c ++++ b/fs/btrfs/tests/qgroup-tests.c +@@ -232,8 +232,10 @@ static int test_no_shared_qgroup(struct btrfs_root *root, + + ret = insert_normal_tree_ref(root, nodesize, nodesize, 0, + BTRFS_FS_TREE_OBJECTID); +- if (ret) ++ if (ret) { ++ ulist_free(old_roots); + return ret; ++ } + + ret = btrfs_find_all_roots(&trans, fs_info, nodesize, 0, &new_roots, false); + if (ret) { +@@ -266,8 +268,10 @@ static int test_no_shared_qgroup(struct btrfs_root *root, + } + + ret = remove_extent_item(root, nodesize, nodesize); +- if (ret) ++ if (ret) { ++ ulist_free(old_roots); + return -EINVAL; ++ } + + ret = btrfs_find_all_roots(&trans, fs_info, nodesize, 0, &new_roots, false); + if (ret) { +@@ -329,8 +333,10 @@ static int test_multiple_refs(struct btrfs_root *root, + + ret = insert_normal_tree_ref(root, nodesize, nodesize, 0, + BTRFS_FS_TREE_OBJECTID); +- if (ret) ++ if (ret) { ++ ulist_free(old_roots); + return ret; ++ } + + ret = btrfs_find_all_roots(&trans, fs_info, nodesize, 0, &new_roots, false); + if (ret) { +@@ -362,8 +368,10 @@ static int test_multiple_refs(struct btrfs_root *root, + + ret = add_tree_ref(root, nodesize, nodesize, 0, + BTRFS_FIRST_FREE_OBJECTID); +- if (ret) ++ if (ret) { ++ ulist_free(old_roots); + return ret; ++ } + + ret = btrfs_find_all_roots(&trans, fs_info, nodesize, 0, &new_roots, false); + if (ret) { +@@ -401,8 +409,10 @@ static int test_multiple_refs(struct btrfs_root *root, + + ret = remove_extent_ref(root, nodesize, nodesize, 0, + BTRFS_FIRST_FREE_OBJECTID); +- if (ret) ++ if (ret) { ++ ulist_free(old_roots); + return ret; ++ } + + ret = btrfs_find_all_roots(&trans, fs_info, nodesize, 0, &new_roots, false); + if (ret) { +-- +2.35.1 + diff --git a/queue-6.0/docs-process-howto-replace-c89-with-c11.patch b/queue-6.0/docs-process-howto-replace-c89-with-c11.patch new file mode 100644 index 00000000000..4959ec5c947 --- /dev/null +++ b/queue-6.0/docs-process-howto-replace-c89-with-c11.patch @@ -0,0 +1,115 @@ +From 782909305abe2e501dabbd32011d43cd6e84e9ba Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 15 Oct 2022 18:22:01 +0900 +Subject: docs/process/howto: Replace C89 with C11 + +From: Akira Yokosawa + +[ Upstream commit 2f3f53d62307262f0086804ea7cea99b0e085450 ] + +Commit e8c07082a810 ("Kbuild: move to -std=gnu11") updated +process/programming-language.rst, but failed to update +process/howto.rst. + +Update howto.rst and resolve the inconsistency. + +Fixes: e8c07082a810 ("Kbuild: move to -std=gnu11") +Signed-off-by: Akira Yokosawa +Cc: Arnd Bergmann +Cc: Federico Vaga +Cc: Alex Shi +Cc: Hu Haowen +Cc: Tsugikazu Shibata +Link: https://lore.kernel.org/r/20221015092201.32099-1-akiyks@gmail.com +Signed-off-by: Jonathan Corbet +Signed-off-by: Sasha Levin +--- + Documentation/process/howto.rst | 2 +- + Documentation/translations/it_IT/process/howto.rst | 2 +- + Documentation/translations/ja_JP/howto.rst | 2 +- + Documentation/translations/ko_KR/howto.rst | 2 +- + Documentation/translations/zh_CN/process/howto.rst | 2 +- + Documentation/translations/zh_TW/process/howto.rst | 2 +- + 6 files changed, 6 insertions(+), 6 deletions(-) + +diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst +index cd6997a9d203..8fc5398c732b 100644 +--- a/Documentation/process/howto.rst ++++ b/Documentation/process/howto.rst +@@ -36,7 +36,7 @@ experience, the following books are good for, if anything, reference: + - "C: A Reference Manual" by Harbison and Steele [Prentice Hall] + + The kernel is written using GNU C and the GNU toolchain. While it +-adheres to the ISO C89 standard, it uses a number of extensions that are ++adheres to the ISO C11 standard, it uses a number of extensions that are + not featured in the standard. The kernel is a freestanding C + environment, with no reliance on the standard C library, so some + portions of the C standard are not supported. Arbitrary long long +diff --git a/Documentation/translations/it_IT/process/howto.rst b/Documentation/translations/it_IT/process/howto.rst +index 16ad5622d549..67b84f015da8 100644 +--- a/Documentation/translations/it_IT/process/howto.rst ++++ b/Documentation/translations/it_IT/process/howto.rst +@@ -44,7 +44,7 @@ altro, utili riferimenti: + - "C: A Reference Manual" di Harbison and Steele [Prentice Hall] + + Il kernel è stato scritto usando GNU C e la toolchain GNU. +-Sebbene si attenga allo standard ISO C89, esso utilizza una serie di ++Sebbene si attenga allo standard ISO C11, esso utilizza una serie di + estensioni che non sono previste in questo standard. Il kernel è un + ambiente C indipendente, che non ha alcuna dipendenza dalle librerie + C standard, così alcune parti del C standard non sono supportate. +diff --git a/Documentation/translations/ja_JP/howto.rst b/Documentation/translations/ja_JP/howto.rst +index 649e2ff2a407..e2e946a4298a 100644 +--- a/Documentation/translations/ja_JP/howto.rst ++++ b/Documentation/translations/ja_JP/howto.rst +@@ -65,7 +65,7 @@ Linux カーネル開発のやり方 + - 『新・詳説 C 言語 H&S リファレンス』 (サミュエル P ハービソン/ガイ L スティール共著 斉藤 信男監訳)[ソフトバンク] + + カーネルは GNU C と GNU ツールチェインを使って書かれています。カーネル +-は ISO C89 仕様に準拠して書く一方で、標準には無い言語拡張を多く使って ++は ISO C11 仕様に準拠して書く一方で、標準には無い言語拡張を多く使って + います。カーネルは標準 C ライブラリに依存しない、C 言語非依存環境です。 + そのため、C の標準の中で使えないものもあります。特に任意の long long + の除算や浮動小数点は使えません。カーネルがツールチェインや C 言語拡張 +diff --git a/Documentation/translations/ko_KR/howto.rst b/Documentation/translations/ko_KR/howto.rst +index e43970584ca4..2a7ab4257e44 100644 +--- a/Documentation/translations/ko_KR/howto.rst ++++ b/Documentation/translations/ko_KR/howto.rst +@@ -62,7 +62,7 @@ Documentation/process/howto.rst + - "Practical C Programming" by Steve Oualline [O'Reilly] + - "C: A Reference Manual" by Harbison and Steele [Prentice Hall] + +-커널은 GNU C와 GNU 툴체인을 사용하여 작성되었다. 이 툴들은 ISO C89 표준을 ++커널은 GNU C와 GNU 툴체인을 사용하여 작성되었다. 이 툴들은 ISO C11 표준을 + 따르는 반면 표준에 있지 않은 많은 확장기능도 가지고 있다. 커널은 표준 C + 라이브러리와는 관계없이 freestanding C 환경이어서 C 표준의 일부는 + 지원되지 않는다. 임의의 long long 나누기나 floating point는 지원되지 않는다. +diff --git a/Documentation/translations/zh_CN/process/howto.rst b/Documentation/translations/zh_CN/process/howto.rst +index 1455190dc087..e7e4bb000b8a 100644 +--- a/Documentation/translations/zh_CN/process/howto.rst ++++ b/Documentation/translations/zh_CN/process/howto.rst +@@ -45,7 +45,7 @@ Linux内核大部分是由C语言写成的，一些体系结构相关的代码 + - "C: A Reference Manual" by Harbison and Steele [Prentice Hall] + 《C语言参考手册（原书第5版）》（邱仲潘 等译）[机械工业出版社] + +-Linux内核使用GNU C和GNU工具链开发。虽然它遵循ISO C89标准，但也用到了一些 ++Linux内核使用GNU C和GNU工具链开发。虽然它遵循ISO C11标准，但也用到了一些 + 标准中没有定义的扩展。内核是自给自足的C环境，不依赖于标准C库的支持，所以 + 并不支持C标准中的部分定义。比如long long类型的大数除法和浮点运算就不允许 + 使用。有时候确实很难弄清楚内核对工具链的要求和它所使用的扩展，不幸的是目 +diff --git a/Documentation/translations/zh_TW/process/howto.rst b/Documentation/translations/zh_TW/process/howto.rst +index 68ae4411285b..e335789d7e26 100644 +--- a/Documentation/translations/zh_TW/process/howto.rst ++++ b/Documentation/translations/zh_TW/process/howto.rst +@@ -48,7 +48,7 @@ Linux內核大部分是由C語言寫成的，一些體系結構相關的代碼 + - "C: A Reference Manual" by Harbison and Steele [Prentice Hall] + 《C語言參考手冊（原書第5版）》（邱仲潘 等譯）[機械工業出版社] + +-Linux內核使用GNU C和GNU工具鏈開發。雖然它遵循ISO C89標準，但也用到了一些 ++Linux內核使用GNU C和GNU工具鏈開發。雖然它遵循ISO C11標準，但也用到了一些 + 標準中沒有定義的擴展。內核是自給自足的C環境，不依賴於標準C庫的支持，所以 + 並不支持C標準中的部分定義。比如long long類型的大數除法和浮點運算就不允許 + 使用。有時候確實很難弄清楚內核對工具鏈的要求和它所使用的擴展，不幸的是目 +-- +2.35.1 + diff --git a/queue-6.0/ib-hfi1-correctly-move-list-in-sc_disable.patch b/queue-6.0/ib-hfi1-correctly-move-list-in-sc_disable.patch new file mode 100644 index 00000000000..e64de701a43 --- /dev/null +++ b/queue-6.0/ib-hfi1-correctly-move-list-in-sc_disable.patch @@ -0,0 +1,59 @@ +From a2bb2dff0179d0eee5137886330092b93d761576 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 18 Oct 2022 10:27:50 -0400 +Subject: IB/hfi1: Correctly move list in sc_disable() + +From: Dean Luick + +[ Upstream commit 1afac08b39d85437187bb2a92d89a741b1078f55 ] + +Commit 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()") +incorrectly tries to move a list from one list head to another. The +result is a kernel crash. + +The crash is triggered when a link goes down and there are waiters for a +send to complete. The following signature is seen: + + BUG: kernel NULL pointer dereference, address: 0000000000000030 + [...] + Call Trace: + sc_disable+0x1ba/0x240 [hfi1] + pio_freeze+0x3d/0x60 [hfi1] + handle_freeze+0x27/0x1b0 [hfi1] + process_one_work+0x1b0/0x380 + ? process_one_work+0x380/0x380 + worker_thread+0x30/0x360 + ? process_one_work+0x380/0x380 + kthread+0xd7/0x100 + ? kthread_complete_and_exit+0x20/0x20 + ret_from_fork+0x1f/0x30 + +The fix is to use the correct call to move the list. + +Fixes: 13bac861952a ("IB/hfi1: Fix abba locking issue with sc_disable()") +Signed-off-by: Dean Luick +Signed-off-by: Dennis Dalessandro +Link: https://lore.kernel.org/r/166610327042.674422.6146908799669288976.stgit@awfm-02.cornelisnetworks.com +Signed-off-by: Leon Romanovsky +Signed-off-by: Sasha Levin +--- + drivers/infiniband/hw/hfi1/pio.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/drivers/infiniband/hw/hfi1/pio.c b/drivers/infiniband/hw/hfi1/pio.c +index 3d42bd2b36bd..51ae58c02b15 100644 +--- a/drivers/infiniband/hw/hfi1/pio.c ++++ b/drivers/infiniband/hw/hfi1/pio.c +@@ -913,8 +913,7 @@ void sc_disable(struct send_context *sc) + spin_unlock(&sc->release_lock); + + write_seqlock(&sc->waitlock); +- if (!list_empty(&sc->piowait)) +- list_move(&sc->piowait, &wake_list); ++ list_splice_init(&sc->piowait, &wake_list); + write_sequnlock(&sc->waitlock); + while (!list_empty(&wake_list)) { + struct iowait *wait; +-- +2.35.1 + diff --git a/queue-6.0/ibmvnic-free-rwi-on-reset-success.patch b/queue-6.0/ibmvnic-free-rwi-on-reset-success.patch new file mode 100644 index 00000000000..62c8fef1334 --- /dev/null +++ b/queue-6.0/ibmvnic-free-rwi-on-reset-success.patch @@ -0,0 +1,59 @@ +From 90c7fbc08f47dde3a3524d5aa6d17cad961559c3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 31 Oct 2022 10:06:42 -0500 +Subject: ibmvnic: Free rwi on reset success + +From: Nick Child + +[ Upstream commit d6dd2fe71153f0ff748bf188bd4af076fe09a0a6 ] + +Free the rwi structure in the event that the last rwi in the list +processed successfully. The logic in commit 4f408e1fa6e1 ("ibmvnic: +retry reset if there are no other resets") introduces an issue that +results in a 32 byte memory leak whenever the last rwi in the list +gets processed. + +Fixes: 4f408e1fa6e1 ("ibmvnic: retry reset if there are no other resets") +Signed-off-by: Nick Child +Link: https://lore.kernel.org/r/20221031150642.13356-1-nnac123@linux.ibm.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/ibm/ibmvnic.c | 16 ++++++++-------- + 1 file changed, 8 insertions(+), 8 deletions(-) + +diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c +index 5ab7c0f81e9a..e6b141536879 100644 +--- a/drivers/net/ethernet/ibm/ibmvnic.c ++++ b/drivers/net/ethernet/ibm/ibmvnic.c +@@ -3007,19 +3007,19 @@ static void __ibmvnic_reset(struct work_struct *work) + rwi = get_next_rwi(adapter); + + /* +- * If there is another reset queued, free the previous rwi +- * and process the new reset even if previous reset failed +- * (the previous reset could have failed because of a fail +- * over for instance, so process the fail over). +- * + * If there are no resets queued and the previous reset failed, + * the adapter would be in an undefined state. So retry the + * previous reset as a hard reset. ++ * ++ * Else, free the previous rwi and, if there is another reset ++ * queued, process the new reset even if previous reset failed ++ * (the previous reset could have failed because of a fail ++ * over for instance, so process the fail over). + */ +- if (rwi) +- kfree(tmprwi); +- else if (rc) ++ if (!rwi && rc) + rwi = tmprwi; ++ else ++ kfree(tmprwi); + + if (rwi && (rwi->reset_reason == VNIC_RESET_FAILOVER || + rwi->reset_reason == VNIC_RESET_MOBILITY || rc)) +-- +2.35.1 + diff --git a/queue-6.0/ipv6-fix-warning-in-ip6_route_net_exit_late.patch b/queue-6.0/ipv6-fix-warning-in-ip6_route_net_exit_late.patch new file mode 100644 index 00000000000..23ff8318f4d --- /dev/null +++ b/queue-6.0/ipv6-fix-warning-in-ip6_route_net_exit_late.patch @@ -0,0 +1,70 @@ +From 45a5bc030779c702ec72271e846bc1e7e1100a43 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 2 Nov 2022 10:06:10 +0800 +Subject: ipv6: fix WARNING in ip6_route_net_exit_late() + +From: Zhengchao Shao + +[ Upstream commit 768b3c745fe5789f2430bdab02f35a9ad1148d97 ] + +During the initialization of ip6_route_net_init_late(), if file +ipv6_route or rt6_stats fails to be created, the initialization is +successful by default. Therefore, the ipv6_route or rt6_stats file +doesn't be found during the remove in ip6_route_net_exit_late(). It +will cause WRNING. + +The following is the stack information: +name 'rt6_stats' +WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460 +Modules linked in: +Workqueue: netns cleanup_net +RIP: 0010:remove_proc_entry+0x389/0x460 +PKRU: 55555554 +Call Trace: + +ops_exit_list+0xb0/0x170 +cleanup_net+0x4ea/0xb00 +process_one_work+0x9bf/0x1710 +worker_thread+0x665/0x1080 +kthread+0x2e4/0x3a0 +ret_from_fork+0x1f/0x30 + + +Fixes: cdb1876192db ("[NETNS][IPV6] route6 - create route6 proc files for the namespace") +Signed-off-by: Zhengchao Shao +Reviewed-by: Eric Dumazet +Link: https://lore.kernel.org/r/20221102020610.351330-1-shaozhengchao@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/ipv6/route.c | 14 ++++++++++---- + 1 file changed, 10 insertions(+), 4 deletions(-) + +diff --git a/net/ipv6/route.c b/net/ipv6/route.c +index 69252eb462b2..2f355f0ec32a 100644 +--- a/net/ipv6/route.c ++++ b/net/ipv6/route.c +@@ -6555,10 +6555,16 @@ static void __net_exit ip6_route_net_exit(struct net *net) + static int __net_init ip6_route_net_init_late(struct net *net) + { + #ifdef CONFIG_PROC_FS +- proc_create_net("ipv6_route", 0, net->proc_net, &ipv6_route_seq_ops, +- sizeof(struct ipv6_route_iter)); +- proc_create_net_single("rt6_stats", 0444, net->proc_net, +- rt6_stats_seq_show, NULL); ++ if (!proc_create_net("ipv6_route", 0, net->proc_net, ++ &ipv6_route_seq_ops, ++ sizeof(struct ipv6_route_iter))) ++ return -ENOMEM; ++ ++ if (!proc_create_net_single("rt6_stats", 0444, net->proc_net, ++ rt6_stats_seq_show, NULL)) { ++ remove_proc_entry("ipv6_route", net->proc_net); ++ return -ENOMEM; ++ } + #endif + return 0; + } +-- +2.35.1 + diff --git a/queue-6.0/ipvs-fix-warning-in-__ip_vs_cleanup_batch.patch b/queue-6.0/ipvs-fix-warning-in-__ip_vs_cleanup_batch.patch new file mode 100644 index 00000000000..e4315a37e7b --- /dev/null +++ b/queue-6.0/ipvs-fix-warning-in-__ip_vs_cleanup_batch.patch @@ -0,0 +1,90 @@ +From ab5b8289e39716336ae639f5ba576f6b50074abf Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 31 Oct 2022 20:07:04 +0800 +Subject: ipvs: fix WARNING in __ip_vs_cleanup_batch() + +From: Zhengchao Shao + +[ Upstream commit 3d00c6a0da8ddcf75213e004765e4a42acc71d5d ] + +During the initialization of ip_vs_conn_net_init(), if file ip_vs_conn +or ip_vs_conn_sync fails to be created, the initialization is successful +by default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn't +be found during the remove. + +The following is the stack information: +name 'ip_vs_conn_sync' +WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712 +remove_proc_entry+0x389/0x460 +Modules linked in: +Workqueue: netns cleanup_net +RIP: 0010:remove_proc_entry+0x389/0x460 +Call Trace: + +__ip_vs_cleanup_batch+0x7d/0x120 +ops_exit_list+0x125/0x170 +cleanup_net+0x4ea/0xb00 +process_one_work+0x9bf/0x1710 +worker_thread+0x665/0x1080 +kthread+0x2e4/0x3a0 +ret_from_fork+0x1f/0x30 + + +Fixes: 61b1ab4583e2 ("IPVS: netns, add basic init per netns.") +Signed-off-by: Zhengchao Shao +Acked-by: Julian Anastasov +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Sasha Levin +--- + net/netfilter/ipvs/ip_vs_conn.c | 26 +++++++++++++++++++++----- + 1 file changed, 21 insertions(+), 5 deletions(-) + +diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c +index db13288fddfa..cb6d68220c26 100644 +--- a/net/netfilter/ipvs/ip_vs_conn.c ++++ b/net/netfilter/ipvs/ip_vs_conn.c +@@ -1447,20 +1447,36 @@ int __net_init ip_vs_conn_net_init(struct netns_ipvs *ipvs) + { + atomic_set(&ipvs->conn_count, 0); + +- proc_create_net("ip_vs_conn", 0, ipvs->net->proc_net, +- &ip_vs_conn_seq_ops, sizeof(struct ip_vs_iter_state)); +- proc_create_net("ip_vs_conn_sync", 0, ipvs->net->proc_net, +- &ip_vs_conn_sync_seq_ops, +- sizeof(struct ip_vs_iter_state)); ++#ifdef CONFIG_PROC_FS ++ if (!proc_create_net("ip_vs_conn", 0, ipvs->net->proc_net, ++ &ip_vs_conn_seq_ops, ++ sizeof(struct ip_vs_iter_state))) ++ goto err_conn; ++ ++ if (!proc_create_net("ip_vs_conn_sync", 0, ipvs->net->proc_net, ++ &ip_vs_conn_sync_seq_ops, ++ sizeof(struct ip_vs_iter_state))) ++ goto err_conn_sync; ++#endif ++ + return 0; ++ ++#ifdef CONFIG_PROC_FS ++err_conn_sync: ++ remove_proc_entry("ip_vs_conn", ipvs->net->proc_net); ++err_conn: ++ return -ENOMEM; ++#endif + } + + void __net_exit ip_vs_conn_net_cleanup(struct netns_ipvs *ipvs) + { + /* flush all the connection entries first */ + ip_vs_conn_flush(ipvs); ++#ifdef CONFIG_PROC_FS + remove_proc_entry("ip_vs_conn", ipvs->net->proc_net); + remove_proc_entry("ip_vs_conn_sync", ipvs->net->proc_net); ++#endif + } + + int __init ip_vs_conn_init(void) +-- +2.35.1 + diff --git a/queue-6.0/ipvs-fix-warning-in-ip_vs_app_net_cleanup.patch b/queue-6.0/ipvs-fix-warning-in-ip_vs_app_net_cleanup.patch new file mode 100644 index 00000000000..c4795ef262d --- /dev/null +++ b/queue-6.0/ipvs-fix-warning-in-ip_vs_app_net_cleanup.patch @@ -0,0 +1,68 @@ +From 0fc75485e760af5c9b8e5cd2cca03075117a108a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 31 Oct 2022 20:07:05 +0800 +Subject: ipvs: fix WARNING in ip_vs_app_net_cleanup() + +From: Zhengchao Shao + +[ Upstream commit 5663ed63adb9619c98ab7479aa4606fa9b7a548c ] + +During the initialization of ip_vs_app_net_init(), if file ip_vs_app +fails to be created, the initialization is successful by default. +Therefore, the ip_vs_app file doesn't be found during the remove in +ip_vs_app_net_cleanup(). It will cause WRNING. + +The following is the stack information: +name 'ip_vs_app' +WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460 +Modules linked in: +Workqueue: netns cleanup_net +RIP: 0010:remove_proc_entry+0x389/0x460 +Call Trace: + +ops_exit_list+0x125/0x170 +cleanup_net+0x4ea/0xb00 +process_one_work+0x9bf/0x1710 +worker_thread+0x665/0x1080 +kthread+0x2e4/0x3a0 +ret_from_fork+0x1f/0x30 + + +Fixes: 457c4cbc5a3d ("[NET]: Make /proc/net per network namespace") +Signed-off-by: Zhengchao Shao +Acked-by: Julian Anastasov +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Sasha Levin +--- + net/netfilter/ipvs/ip_vs_app.c | 10 ++++++++-- + 1 file changed, 8 insertions(+), 2 deletions(-) + +diff --git a/net/netfilter/ipvs/ip_vs_app.c b/net/netfilter/ipvs/ip_vs_app.c +index f9b16f2b2219..fdacbc3c15be 100644 +--- a/net/netfilter/ipvs/ip_vs_app.c ++++ b/net/netfilter/ipvs/ip_vs_app.c +@@ -599,13 +599,19 @@ static const struct seq_operations ip_vs_app_seq_ops = { + int __net_init ip_vs_app_net_init(struct netns_ipvs *ipvs) + { + INIT_LIST_HEAD(&ipvs->app_list); +- proc_create_net("ip_vs_app", 0, ipvs->net->proc_net, &ip_vs_app_seq_ops, +- sizeof(struct seq_net_private)); ++#ifdef CONFIG_PROC_FS ++ if (!proc_create_net("ip_vs_app", 0, ipvs->net->proc_net, ++ &ip_vs_app_seq_ops, ++ sizeof(struct seq_net_private))) ++ return -ENOMEM; ++#endif + return 0; + } + + void __net_exit ip_vs_app_net_cleanup(struct netns_ipvs *ipvs) + { + unregister_ip_vs_app(ipvs, NULL /* all */); ++#ifdef CONFIG_PROC_FS + remove_proc_entry("ip_vs_app", ipvs->net->proc_net); ++#endif + } +-- +2.35.1 + diff --git a/queue-6.0/ipvs-use-explicitly-signed-chars.patch b/queue-6.0/ipvs-use-explicitly-signed-chars.patch new file mode 100644 index 00000000000..b49544fee2a --- /dev/null +++ b/queue-6.0/ipvs-use-explicitly-signed-chars.patch @@ -0,0 +1,41 @@ +From 4f7c3666110e11e944d0f3677a6d76ad064a4c47 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 26 Oct 2022 14:32:16 +0200 +Subject: ipvs: use explicitly signed chars + +From: Jason A. Donenfeld + +[ Upstream commit 5c26159c97b324dc5174a5713eafb8c855cf8106 ] + +The `char` type with no explicit sign is sometimes signed and sometimes +unsigned. This code will break on platforms such as arm, where char is +unsigned. So mark it here as explicitly signed, so that the +todrop_counter decrement and subsequent comparison is correct. + +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Signed-off-by: Jason A. Donenfeld +Acked-by: Julian Anastasov +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Sasha Levin +--- + net/netfilter/ipvs/ip_vs_conn.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/net/netfilter/ipvs/ip_vs_conn.c b/net/netfilter/ipvs/ip_vs_conn.c +index fb67f1ca2495..db13288fddfa 100644 +--- a/net/netfilter/ipvs/ip_vs_conn.c ++++ b/net/netfilter/ipvs/ip_vs_conn.c +@@ -1265,8 +1265,8 @@ static inline int todrop_entry(struct ip_vs_conn *cp) + * The drop rate array needs tuning for real environments. + * Called from timer bh only => no locking + */ +- static const char todrop_rate[9] = {0, 1, 2, 3, 4, 5, 6, 7, 8}; +- static char todrop_counter[9] = {0}; ++ static const signed char todrop_rate[9] = {0, 1, 2, 3, 4, 5, 6, 7, 8}; ++ static signed char todrop_counter[9] = {0}; + int i; + + /* if the conn entry hasn't lasted for 60 seconds, don't drop it. +-- +2.35.1 + diff --git a/queue-6.0/isdn-misdn-netjet-fix-wrong-check-of-device-registra.patch b/queue-6.0/isdn-misdn-netjet-fix-wrong-check-of-device-registra.patch new file mode 100644 index 00000000000..fe5af98657b --- /dev/null +++ b/queue-6.0/isdn-misdn-netjet-fix-wrong-check-of-device-registra.patch @@ -0,0 +1,37 @@ +From 8ecaa223fa41376598b4167456299543913895e5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 31 Oct 2022 20:13:41 +0800 +Subject: isdn: mISDN: netjet: fix wrong check of device registration + +From: Yang Yingliang + +[ Upstream commit bf00f5426074249058a106a6edbb89e4b25a4d79 ] + +The class is set in mISDN_register_device(), but if device_add() returns +error, it will lead to delete a device without added, fix this by using +device_is_registered() to check if the device is registered. + +Fixes: a900845e5661 ("mISDN: Add support for Traverse Technologies NETJet PCI cards") +Signed-off-by: Yang Yingliang +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/isdn/hardware/mISDN/netjet.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/isdn/hardware/mISDN/netjet.c b/drivers/isdn/hardware/mISDN/netjet.c +index a52f275f8263..f8447135a902 100644 +--- a/drivers/isdn/hardware/mISDN/netjet.c ++++ b/drivers/isdn/hardware/mISDN/netjet.c +@@ -956,7 +956,7 @@ nj_release(struct tiger_hw *card) + } + if (card->irq > 0) + free_irq(card->irq, card); +- if (card->isac.dch.dev.dev.class) ++ if (device_is_registered(&card->isac.dch.dev.dev)) + mISDN_unregister_device(&card->isac.dch.dev); + + for (i = 0; i < 2; i++) { +-- +2.35.1 + diff --git a/queue-6.0/misdn-fix-possible-memory-leak-in-misdn_register_dev.patch b/queue-6.0/misdn-fix-possible-memory-leak-in-misdn_register_dev.patch new file mode 100644 index 00000000000..fac1a560cd3 --- /dev/null +++ b/queue-6.0/misdn-fix-possible-memory-leak-in-misdn_register_dev.patch @@ -0,0 +1,56 @@ +From 43a46d4834de681c2bd14db4be9bcec98c746234 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 31 Oct 2022 20:13:40 +0800 +Subject: mISDN: fix possible memory leak in mISDN_register_device() + +From: Yang Yingliang + +[ Upstream commit e7d1d4d9ac0dfa40be4c2c8abd0731659869b297 ] + +Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's +bus_id string array"), the name of device is allocated dynamically, +add put_device() to give up the reference, so that the name can be +freed in kobject_cleanup() when the refcount is 0. + +Set device class before put_device() to avoid null release() function +WARN message in device_release(). + +Fixes: 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array") +Signed-off-by: Yang Yingliang +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/isdn/mISDN/core.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +diff --git a/drivers/isdn/mISDN/core.c b/drivers/isdn/mISDN/core.c +index a41b4b264594..7ea0100f218a 100644 +--- a/drivers/isdn/mISDN/core.c ++++ b/drivers/isdn/mISDN/core.c +@@ -233,11 +233,12 @@ mISDN_register_device(struct mISDNdevice *dev, + if (debug & DEBUG_CORE) + printk(KERN_DEBUG "mISDN_register %s %d\n", + dev_name(&dev->dev), dev->id); ++ dev->dev.class = &mISDN_class; ++ + err = create_stack(dev); + if (err) + goto error1; + +- dev->dev.class = &mISDN_class; + dev->dev.platform_data = dev; + dev->dev.parent = parent; + dev_set_drvdata(&dev->dev, dev); +@@ -249,8 +250,8 @@ mISDN_register_device(struct mISDNdevice *dev, + + error3: + delete_stack(dev); +- return err; + error1: ++ put_device(&dev->dev); + return err; + + } +-- +2.35.1 + diff --git a/queue-6.0/net-dsa-fall-back-to-default-tagger-if-we-can-t-load.patch b/queue-6.0/net-dsa-fall-back-to-default-tagger-if-we-can-t-load.patch new file mode 100644 index 00000000000..dd356e37632 --- /dev/null +++ b/queue-6.0/net-dsa-fall-back-to-default-tagger-if-we-can-t-load.patch @@ -0,0 +1,95 @@ +From 0ee13cd5dc554e3297cf5bc8017a61d9ff9a5ba1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 27 Oct 2022 17:54:39 +0300 +Subject: net: dsa: fall back to default tagger if we can't load the one from + DT + +From: Vladimir Oltean + +[ Upstream commit a2c65a9d0568b6737c02b54f00b80716a53fac61 ] + +DSA tagging protocol drivers can be changed at runtime through sysfs and +at probe time through the device tree (support for the latter was added +later). + +When changing through sysfs, it is assumed that the module for the new +tagging protocol was already loaded into the kernel (in fact this is +only a concern for Ocelot/Felix switches, where we have tag_ocelot.ko +and tag_ocelot_8021q.ko; for every other switch, the default and +alternative protocols are compiled within the same .ko, so there is +nothing for the user to load). + +The kernel cannot currently call request_module(), because it has no way +of constructing the modalias name of the tagging protocol driver +("dsa_tag-%d", where the number is one of DSA_TAG_PROTO_*_VALUE). +The device tree only contains the string name of the tagging protocol +("ocelot-8021q"), and the only mapping between the string and the +DSA_TAG_PROTO_OCELOT_8021Q_VALUE is present in tag_ocelot_8021q.ko. +So this is a chicken-and-egg situation and dsa_core.ko has nothing based +on which it can automatically request the insertion of the module. + +As a consequence, if CONFIG_NET_DSA_TAG_OCELOT_8021Q is built as module, +the switch will forever defer probing. + +The long-term solution is to make DSA call request_module() somehow, +but that probably needs some refactoring. + +What we can do to keep operating with existing device tree blobs is to +cancel the attempt to change the tagging protocol with the one specified +there, and to remain operating with the default one. Depending on the +situation, the default protocol might still allow some functionality +(in the case of ocelot, it does), and it's better to have that than to +fail to probe. + +Fixes: deff710703d8 ("net: dsa: Allow default tag protocol to be overridden from DT") +Link: https://lore.kernel.org/lkml/20221027113248.420216-1-michael@walle.cc/ +Reported-by: Heiko Thiery +Reported-by: Michael Walle +Signed-off-by: Vladimir Oltean +Tested-by: Michael Walle +Reviewed-by: Florian Fainelli +Link: https://lore.kernel.org/r/20221027145439.3086017-1-vladimir.oltean@nxp.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/dsa/dsa2.c | 13 ++++++++++--- + 1 file changed, 10 insertions(+), 3 deletions(-) + +diff --git a/net/dsa/dsa2.c b/net/dsa/dsa2.c +index cac48a741f27..e537655e442b 100644 +--- a/net/dsa/dsa2.c ++++ b/net/dsa/dsa2.c +@@ -1407,9 +1407,9 @@ static enum dsa_tag_protocol dsa_get_tag_protocol(struct dsa_port *dp, + static int dsa_port_parse_cpu(struct dsa_port *dp, struct net_device *master, + const char *user_protocol) + { ++ const struct dsa_device_ops *tag_ops = NULL; + struct dsa_switch *ds = dp->ds; + struct dsa_switch_tree *dst = ds->dst; +- const struct dsa_device_ops *tag_ops; + enum dsa_tag_protocol default_proto; + + /* Find out which protocol the switch would prefer. */ +@@ -1432,10 +1432,17 @@ static int dsa_port_parse_cpu(struct dsa_port *dp, struct net_device *master, + } + + tag_ops = dsa_find_tagger_by_name(user_protocol); +- } else { +- tag_ops = dsa_tag_driver_get(default_proto); ++ if (IS_ERR(tag_ops)) { ++ dev_warn(ds->dev, ++ "Failed to find a tagging driver for protocol %s, using default\n", ++ user_protocol); ++ tag_ops = NULL; ++ } + } + ++ if (!tag_ops) ++ tag_ops = dsa_tag_driver_get(default_proto); ++ + if (IS_ERR(tag_ops)) { + if (PTR_ERR(tag_ops) == -ENOPROTOOPT) + return -EPROBE_DEFER; +-- +2.35.1 + diff --git a/queue-6.0/net-dsa-fix-possible-memory-leaks-in-dsa_loop_init.patch b/queue-6.0/net-dsa-fix-possible-memory-leaks-in-dsa_loop_init.patch new file mode 100644 index 00000000000..920b0be1b39 --- /dev/null +++ b/queue-6.0/net-dsa-fix-possible-memory-leaks-in-dsa_loop_init.patch @@ -0,0 +1,108 @@ +From d97fa3abc9993fd86f9cbb1c87173f07a9dddf0a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 26 Oct 2022 10:03:21 +0800 +Subject: net: dsa: Fix possible memory leaks in dsa_loop_init() + +From: Chen Zhongjin + +[ Upstream commit 633efc8b3dc96f56f5a57f2a49764853a2fa3f50 ] + +kmemleak reported memory leaks in dsa_loop_init(): + +kmemleak: 12 new suspected memory leaks + +unreferenced object 0xffff8880138ce000 (size 2048): + comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s) + backtrace: + [<000000006a94f1d5>] kmalloc_trace+0x26/0x60 + [<00000000a9c44622>] phy_device_create+0x5d/0x970 + [<00000000d0ee2afc>] get_phy_device+0xf3/0x2b0 + [<00000000dca0c71f>] __fixed_phy_register.part.0+0x92/0x4e0 + [<000000008a834798>] fixed_phy_register+0x84/0xb0 + [<0000000055223fcb>] dsa_loop_init+0xa9/0x116 [dsa_loop] + ... + +There are two reasons for memleak in dsa_loop_init(). + +First, fixed_phy_register() create and register phy_device: + +fixed_phy_register() + get_phy_device() + phy_device_create() # freed by phy_device_free() + phy_device_register() # freed by phy_device_remove() + +But fixed_phy_unregister() only calls phy_device_remove(). +So the memory allocated in phy_device_create() is leaked. + +Second, when mdio_driver_register() fail in dsa_loop_init(), +it just returns and there is no cleanup for phydevs. + +Fix the problems by catching the error of mdio_driver_register() +in dsa_loop_init(), then calling both fixed_phy_unregister() and +phy_device_free() to release phydevs. +Also add a function for phydevs cleanup to avoid duplacate. + +Fixes: 98cd1552ea27 ("net: dsa: Mock-up driver") +Signed-off-by: Chen Zhongjin +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/dsa/dsa_loop.c | 25 ++++++++++++++++++------- + 1 file changed, 18 insertions(+), 7 deletions(-) + +diff --git a/drivers/net/dsa/dsa_loop.c b/drivers/net/dsa/dsa_loop.c +index 263e41191c29..0d20ebafbd03 100644 +--- a/drivers/net/dsa/dsa_loop.c ++++ b/drivers/net/dsa/dsa_loop.c +@@ -378,6 +378,17 @@ static struct mdio_driver dsa_loop_drv = { + + #define NUM_FIXED_PHYS (DSA_LOOP_NUM_PORTS - 2) + ++static void dsa_loop_phydevs_unregister(void) ++{ ++ unsigned int i; ++ ++ for (i = 0; i < NUM_FIXED_PHYS; i++) ++ if (!IS_ERR(phydevs[i])) { ++ fixed_phy_unregister(phydevs[i]); ++ phy_device_free(phydevs[i]); ++ } ++} ++ + static int __init dsa_loop_init(void) + { + struct fixed_phy_status status = { +@@ -385,23 +396,23 @@ static int __init dsa_loop_init(void) + .speed = SPEED_100, + .duplex = DUPLEX_FULL, + }; +- unsigned int i; ++ unsigned int i, ret; + + for (i = 0; i < NUM_FIXED_PHYS; i++) + phydevs[i] = fixed_phy_register(PHY_POLL, &status, NULL); + +- return mdio_driver_register(&dsa_loop_drv); ++ ret = mdio_driver_register(&dsa_loop_drv); ++ if (ret) ++ dsa_loop_phydevs_unregister(); ++ ++ return ret; + } + module_init(dsa_loop_init); + + static void __exit dsa_loop_exit(void) + { +- unsigned int i; +- + mdio_driver_unregister(&dsa_loop_drv); +- for (i = 0; i < NUM_FIXED_PHYS; i++) +- if (!IS_ERR(phydevs[i])) +- fixed_phy_unregister(phydevs[i]); ++ dsa_loop_phydevs_unregister(); + } + module_exit(dsa_loop_exit); + +-- +2.35.1 + diff --git a/queue-6.0/net-fec-fix-improper-use-of-netdev_tx_busy.patch b/queue-6.0/net-fec-fix-improper-use-of-netdev_tx_busy.patch new file mode 100644 index 00000000000..b7316811503 --- /dev/null +++ b/queue-6.0/net-fec-fix-improper-use-of-netdev_tx_busy.patch @@ -0,0 +1,47 @@ +From 7c17f26bcaf2848ef9fb03142772bbeaae5349b4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 28 Oct 2022 10:09:11 +0800 +Subject: net: fec: fix improper use of NETDEV_TX_BUSY + +From: Zhang Changzhong + +[ Upstream commit 06a4df5863f73af193a4ff7abf7cb04058584f06 ] + +The ndo_start_xmit() method must not free skb when returning +NETDEV_TX_BUSY, since caller is going to requeue freed skb. + +Fix it by returning NETDEV_TX_OK in case of dma_map_single() fails. + +Fixes: 79f339125ea3 ("net: fec: Add software TSO support") +Signed-off-by: Zhang Changzhong +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/freescale/fec_main.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/net/ethernet/freescale/fec_main.c b/drivers/net/ethernet/freescale/fec_main.c +index a486435ceee2..5aa254eaa8d0 100644 +--- a/drivers/net/ethernet/freescale/fec_main.c ++++ b/drivers/net/ethernet/freescale/fec_main.c +@@ -657,7 +657,7 @@ fec_enet_txq_put_data_tso(struct fec_enet_priv_tx_q *txq, struct sk_buff *skb, + dev_kfree_skb_any(skb); + if (net_ratelimit()) + netdev_err(ndev, "Tx DMA memory map failed\n"); +- return NETDEV_TX_BUSY; ++ return NETDEV_TX_OK; + } + + bdp->cbd_datlen = cpu_to_fec16(size); +@@ -719,7 +719,7 @@ fec_enet_txq_put_hdr_tso(struct fec_enet_priv_tx_q *txq, + dev_kfree_skb_any(skb); + if (net_ratelimit()) + netdev_err(ndev, "Tx DMA memory map failed\n"); +- return NETDEV_TX_BUSY; ++ return NETDEV_TX_OK; + } + } + +-- +2.35.1 + diff --git a/queue-6.0/net-lan966x-adjust-maximum-frame-size-when-vlan-is-e.patch b/queue-6.0/net-lan966x-adjust-maximum-frame-size-when-vlan-is-e.patch new file mode 100644 index 00000000000..1513d60df91 --- /dev/null +++ b/queue-6.0/net-lan966x-adjust-maximum-frame-size-when-vlan-is-e.patch @@ -0,0 +1,71 @@ +From 616622763803f218f1f7e8988fe11db54f5e1fb3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 30 Oct 2022 22:36:35 +0100 +Subject: net: lan966x: Adjust maximum frame size when vlan is enabled/disabled + +From: Horatiu Vultur + +[ Upstream commit 25f28bb1b4a7717a9df3aa574d210374ebb6bb23 ] + +When vlan filtering is enabled/disabled, it is required to adjust the +maximum received frame size that it can received. When vlan filtering is +enabled, it would all to receive extra 4 bytes, that are the vlan tag. +So the maximum frame size would be 1522 with a vlan tag. If vlan +filtering is disabled then the maximum frame size would be 1518 +regardless if there is or not a vlan tag. + +Fixes: 6d2c186afa5d ("net: lan966x: Add vlan support.") +Signed-off-by: Horatiu Vultur +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + .../net/ethernet/microchip/lan966x/lan966x_regs.h | 15 +++++++++++++++ + .../net/ethernet/microchip/lan966x/lan966x_vlan.c | 6 ++++++ + 2 files changed, 21 insertions(+) + +diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_regs.h b/drivers/net/ethernet/microchip/lan966x/lan966x_regs.h +index 8265ad89f0bc..357ecc2f1089 100644 +--- a/drivers/net/ethernet/microchip/lan966x/lan966x_regs.h ++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_regs.h +@@ -444,6 +444,21 @@ enum lan966x_target { + #define DEV_MAC_MAXLEN_CFG_MAX_LEN_GET(x)\ + FIELD_GET(DEV_MAC_MAXLEN_CFG_MAX_LEN, x) + ++/* DEV:MAC_CFG_STATUS:MAC_TAGS_CFG */ ++#define DEV_MAC_TAGS_CFG(t) __REG(TARGET_DEV, t, 8, 28, 0, 1, 44, 12, 0, 1, 4) ++ ++#define DEV_MAC_TAGS_CFG_VLAN_DBL_AWR_ENA BIT(1) ++#define DEV_MAC_TAGS_CFG_VLAN_DBL_AWR_ENA_SET(x)\ ++ FIELD_PREP(DEV_MAC_TAGS_CFG_VLAN_DBL_AWR_ENA, x) ++#define DEV_MAC_TAGS_CFG_VLAN_DBL_AWR_ENA_GET(x)\ ++ FIELD_GET(DEV_MAC_TAGS_CFG_VLAN_DBL_AWR_ENA, x) ++ ++#define DEV_MAC_TAGS_CFG_VLAN_AWR_ENA BIT(0) ++#define DEV_MAC_TAGS_CFG_VLAN_AWR_ENA_SET(x)\ ++ FIELD_PREP(DEV_MAC_TAGS_CFG_VLAN_AWR_ENA, x) ++#define DEV_MAC_TAGS_CFG_VLAN_AWR_ENA_GET(x)\ ++ FIELD_GET(DEV_MAC_TAGS_CFG_VLAN_AWR_ENA, x) ++ + /* DEV:MAC_CFG_STATUS:MAC_IFG_CFG */ + #define DEV_MAC_IFG_CFG(t) __REG(TARGET_DEV, t, 8, 28, 0, 1, 44, 20, 0, 1, 4) + +diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_vlan.c b/drivers/net/ethernet/microchip/lan966x/lan966x_vlan.c +index 8d7260cd7da9..3c44660128da 100644 +--- a/drivers/net/ethernet/microchip/lan966x/lan966x_vlan.c ++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_vlan.c +@@ -169,6 +169,12 @@ void lan966x_vlan_port_apply(struct lan966x_port *port) + ANA_VLAN_CFG_VLAN_POP_CNT, + lan966x, ANA_VLAN_CFG(port->chip_port)); + ++ lan_rmw(DEV_MAC_TAGS_CFG_VLAN_AWR_ENA_SET(port->vlan_aware) | ++ DEV_MAC_TAGS_CFG_VLAN_DBL_AWR_ENA_SET(port->vlan_aware), ++ DEV_MAC_TAGS_CFG_VLAN_AWR_ENA | ++ DEV_MAC_TAGS_CFG_VLAN_DBL_AWR_ENA, ++ lan966x, DEV_MAC_TAGS_CFG(port->chip_port)); ++ + /* Drop frames with multicast source address */ + val = ANA_DROP_CFG_DROP_MC_SMAC_ENA_SET(1); + if (port->vlan_aware && !pvid) +-- +2.35.1 + diff --git a/queue-6.0/net-lan966x-fix-fdma-when-mtu-is-changed.patch b/queue-6.0/net-lan966x-fix-fdma-when-mtu-is-changed.patch new file mode 100644 index 00000000000..ec0fa02c31d --- /dev/null +++ b/queue-6.0/net-lan966x-fix-fdma-when-mtu-is-changed.patch @@ -0,0 +1,76 @@ +From 42e88d53d65f698a00175c5f02166900713aa704 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 30 Oct 2022 22:36:36 +0100 +Subject: net: lan966x: Fix FDMA when MTU is changed + +From: Horatiu Vultur + +[ Upstream commit 872ad758f9b7fb4eb42aebaf64e50c5b29b7ffe5 ] + +When MTU is changed, FDMA is required to calculate what is the maximum +size of the frame that it can received. So it can calculate what is the +page order needed to allocate for the received frames. +The first problem was that, when the max MTU was calculated it was +reading the value from dev and not from HW, so in this way it was +missing L2 header + the FCS. +The other problem was that once the skb is created using +__build_skb_around, it would reserve some space for skb_shared_info. +So if we received a frame which size is at the limit of the page order +then the creating will failed because it would not have space to put all +the data. + +Fixes: 2ea1cbac267e ("net: lan966x: Update FDMA to change MTU.") +Signed-off-by: Horatiu Vultur +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c | 8 ++++++-- + drivers/net/ethernet/microchip/lan966x/lan966x_main.c | 2 +- + 2 files changed, 7 insertions(+), 3 deletions(-) + +diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c +index 69f741db25b1..407a6c125515 100644 +--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c ++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c +@@ -668,12 +668,14 @@ static int lan966x_fdma_get_max_mtu(struct lan966x *lan966x) + int i; + + for (i = 0; i < lan966x->num_phys_ports; ++i) { ++ struct lan966x_port *port; + int mtu; + +- if (!lan966x->ports[i]) ++ port = lan966x->ports[i]; ++ if (!port) + continue; + +- mtu = lan966x->ports[i]->dev->mtu; ++ mtu = lan_rd(lan966x, DEV_MAC_MAXLEN_CFG(port->chip_port)); + if (mtu > max_mtu) + max_mtu = mtu; + } +@@ -733,6 +735,8 @@ int lan966x_fdma_change_mtu(struct lan966x *lan966x) + + max_mtu = lan966x_fdma_get_max_mtu(lan966x); + max_mtu += IFH_LEN * sizeof(u32); ++ max_mtu += SKB_DATA_ALIGN(sizeof(struct skb_shared_info)); ++ max_mtu += VLAN_HLEN * 2; + + if (round_up(max_mtu, PAGE_SIZE) / PAGE_SIZE - 1 == + lan966x->rx.page_order) +diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c +index 989e5f045d7e..4a3cb7579420 100644 +--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c ++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c +@@ -394,7 +394,7 @@ static int lan966x_port_change_mtu(struct net_device *dev, int new_mtu) + + err = lan966x_fdma_change_mtu(lan966x); + if (err) { +- lan_wr(DEV_MAC_MAXLEN_CFG_MAX_LEN_SET(old_mtu), ++ lan_wr(DEV_MAC_MAXLEN_CFG_MAX_LEN_SET(LAN966X_HW_MTU(old_mtu)), + lan966x, DEV_MAC_MAXLEN_CFG(port->chip_port)); + dev->mtu = old_mtu; + } +-- +2.35.1 + diff --git a/queue-6.0/net-lan966x-fix-the-mtu-calculation.patch b/queue-6.0/net-lan966x-fix-the-mtu-calculation.patch new file mode 100644 index 00000000000..4752784f33a --- /dev/null +++ b/queue-6.0/net-lan966x-fix-the-mtu-calculation.patch @@ -0,0 +1,55 @@ +From 416215f65dc7a593ebbfd6c2b15da7a6ccaf9158 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 30 Oct 2022 22:36:34 +0100 +Subject: net: lan966x: Fix the MTU calculation + +From: Horatiu Vultur + +[ Upstream commit 486c292230166c2d61701d3c984bf9143588ea28 ] + +When the MTU was changed, the lan966x didn't take in consideration +the L2 header and the FCS. So the HW was configured with a smaller +value than what was desired. Therefore the correct value to configure +the HW would be new_mtu + ETH_HLEN + ETH_FCS_LEN. +The vlan tag is not considered here, because at the time when the +blamed commit was added, there was no vlan filtering support. The +vlan fix will be part of the next patch. + +Fixes: d28d6d2e37d1 ("net: lan966x: add port module support") +Signed-off-by: Horatiu Vultur +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/microchip/lan966x/lan966x_main.c | 2 +- + drivers/net/ethernet/microchip/lan966x/lan966x_main.h | 2 ++ + 2 files changed, 3 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c +index d928b75f3780..989e5f045d7e 100644 +--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.c ++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.c +@@ -385,7 +385,7 @@ static int lan966x_port_change_mtu(struct net_device *dev, int new_mtu) + int old_mtu = dev->mtu; + int err; + +- lan_wr(DEV_MAC_MAXLEN_CFG_MAX_LEN_SET(new_mtu), ++ lan_wr(DEV_MAC_MAXLEN_CFG_MAX_LEN_SET(LAN966X_HW_MTU(new_mtu)), + lan966x, DEV_MAC_MAXLEN_CFG(port->chip_port)); + dev->mtu = new_mtu; + +diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h +index 2787055c1847..e316bfe186d7 100644 +--- a/drivers/net/ethernet/microchip/lan966x/lan966x_main.h ++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_main.h +@@ -24,6 +24,8 @@ + #define LAN966X_BUFFER_MEMORY (160 * 1024) + #define LAN966X_BUFFER_MIN_SZ 60 + ++#define LAN966X_HW_MTU(mtu) ((mtu) + ETH_HLEN + ETH_FCS_LEN) ++ + #define PGID_AGGR 64 + #define PGID_SRC 80 + #define PGID_ENTRIES 89 +-- +2.35.1 + diff --git a/queue-6.0/net-lan966x-fix-unmapping-of-received-frames-using-f.patch b/queue-6.0/net-lan966x-fix-unmapping-of-received-frames-using-f.patch new file mode 100644 index 00000000000..a45b2dee870 --- /dev/null +++ b/queue-6.0/net-lan966x-fix-unmapping-of-received-frames-using-f.patch @@ -0,0 +1,79 @@ +From 56aca823041ec4ca097620b521ae0ade4e8f4f5d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 31 Oct 2022 14:34:21 +0100 +Subject: net: lan966x: Fix unmapping of received frames using FDMA + +From: Horatiu Vultur + +[ Upstream commit fc57062f98b0b0ae52bc584d8fd5ac77c50df607 ] + +When lan966x was receiving a frame, then it was building the skb and +after that it was calling dma_unmap_single with frame size as the +length. This actually has 2 issues: +1. It is using a length to map and a different length to unmap. +2. When the unmap was happening, the data was sync for cpu but it could + be that this will overwrite what build_skb was initializing. + +The fix for these two problems is to change the order of operations. +First to sync the frame for cpu, then to build the skb and in the end to +unmap using the correct size but without sync the frame again for cpu. + +Fixes: c8349639324a ("net: lan966x: Add FDMA functionality") +Signed-off-by: Horatiu Vultur +Link: https://lore.kernel.org/r/20221031133421.1283196-1-horatiu.vultur@microchip.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + .../ethernet/microchip/lan966x/lan966x_fdma.c | 18 ++++++++++++------ + 1 file changed, 12 insertions(+), 6 deletions(-) + +diff --git a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c +index 407a6c125515..3a1a0f9178c0 100644 +--- a/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c ++++ b/drivers/net/ethernet/microchip/lan966x/lan966x_fdma.c +@@ -414,13 +414,15 @@ static struct sk_buff *lan966x_fdma_rx_get_frame(struct lan966x_rx *rx) + /* Get the received frame and unmap it */ + db = &rx->dcbs[rx->dcb_index].db[rx->db_index]; + page = rx->page[rx->dcb_index][rx->db_index]; ++ ++ dma_sync_single_for_cpu(lan966x->dev, (dma_addr_t)db->dataptr, ++ FDMA_DCB_STATUS_BLOCKL(db->status), ++ DMA_FROM_DEVICE); ++ + skb = build_skb(page_address(page), PAGE_SIZE << rx->page_order); + if (unlikely(!skb)) + goto unmap_page; + +- dma_unmap_single(lan966x->dev, (dma_addr_t)db->dataptr, +- FDMA_DCB_STATUS_BLOCKL(db->status), +- DMA_FROM_DEVICE); + skb_put(skb, FDMA_DCB_STATUS_BLOCKL(db->status)); + + lan966x_ifh_get_src_port(skb->data, &src_port); +@@ -429,6 +431,10 @@ static struct sk_buff *lan966x_fdma_rx_get_frame(struct lan966x_rx *rx) + if (WARN_ON(src_port >= lan966x->num_phys_ports)) + goto free_skb; + ++ dma_unmap_single_attrs(lan966x->dev, (dma_addr_t)db->dataptr, ++ PAGE_SIZE << rx->page_order, DMA_FROM_DEVICE, ++ DMA_ATTR_SKIP_CPU_SYNC); ++ + skb->dev = lan966x->ports[src_port]->dev; + skb_pull(skb, IFH_LEN * sizeof(u32)); + +@@ -454,9 +460,9 @@ static struct sk_buff *lan966x_fdma_rx_get_frame(struct lan966x_rx *rx) + free_skb: + kfree_skb(skb); + unmap_page: +- dma_unmap_page(lan966x->dev, (dma_addr_t)db->dataptr, +- FDMA_DCB_STATUS_BLOCKL(db->status), +- DMA_FROM_DEVICE); ++ dma_unmap_single_attrs(lan966x->dev, (dma_addr_t)db->dataptr, ++ PAGE_SIZE << rx->page_order, DMA_FROM_DEVICE, ++ DMA_ATTR_SKIP_CPU_SYNC); + __free_pages(page, rx->page_order); + + return NULL; +-- +2.35.1 + diff --git a/queue-6.0/net-mdio-fix-undefined-behavior-in-bit-shift-for-__m.patch b/queue-6.0/net-mdio-fix-undefined-behavior-in-bit-shift-for-__m.patch new file mode 100644 index 00000000000..022490f7d7a --- /dev/null +++ b/queue-6.0/net-mdio-fix-undefined-behavior-in-bit-shift-for-__m.patch @@ -0,0 +1,54 @@ +From 50c53cb091abc72bfcadd3be8b46732b401f19bf Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 31 Oct 2022 21:26:45 +0800 +Subject: net: mdio: fix undefined behavior in bit shift for __mdiobus_register + +From: Gaosheng Cui + +[ Upstream commit 40e4eb324c59e11fcb927aa46742d28aba6ecb8a ] + +Shifting signed 32-bit value by 31 bits is undefined, so changing +significant bit to unsigned. The UBSAN warning calltrace like below: + +UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27 +left shift of 1 by 31 places cannot be represented in type 'int' +Call Trace: + + dump_stack_lvl+0x7d/0xa5 + dump_stack+0x15/0x1b + ubsan_epilogue+0xe/0x4e + __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c + __mdiobus_register+0x49d/0x4e0 + fixed_mdio_bus_init+0xd8/0x12d + do_one_initcall+0x76/0x430 + kernel_init_freeable+0x3b3/0x422 + kernel_init+0x24/0x1e0 + ret_from_fork+0x1f/0x30 + + +Fixes: 4fd5f812c23c ("phylib: allow incremental scanning of an mii bus") +Signed-off-by: Gaosheng Cui +Reviewed-by: Andrew Lunn +Link: https://lore.kernel.org/r/20221031132645.168421-1-cuigaosheng1@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/phy/mdio_bus.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c +index 8a2dbe849866..1bc988d9f2e8 100644 +--- a/drivers/net/phy/mdio_bus.c ++++ b/drivers/net/phy/mdio_bus.c +@@ -583,7 +583,7 @@ int __mdiobus_register(struct mii_bus *bus, struct module *owner) + } + + for (i = 0; i < PHY_MAX_ADDR; i++) { +- if ((bus->phy_mask & (1 << i)) == 0) { ++ if ((bus->phy_mask & BIT(i)) == 0) { + struct phy_device *phydev; + + phydev = mdiobus_scan(bus, i); +-- +2.35.1 + diff --git a/queue-6.0/net-neigh-fix-null-ptr-deref-in-neigh_table_clear.patch b/queue-6.0/net-neigh-fix-null-ptr-deref-in-neigh_table_clear.patch new file mode 100644 index 00000000000..6693f981ef7 --- /dev/null +++ b/queue-6.0/net-neigh-fix-null-ptr-deref-in-neigh_table_clear.patch @@ -0,0 +1,65 @@ +From c7b867cca0f7028f73af9efac0270682a6b1a3f1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 1 Nov 2022 20:15:52 +0800 +Subject: net, neigh: Fix null-ptr-deref in neigh_table_clear() + +From: Chen Zhongjin + +[ Upstream commit f8017317cb0b279b8ab98b0f3901a2e0ac880dad ] + +When IPv6 module gets initialized but hits an error in the middle, +kenel panic with: + +KASAN: null-ptr-deref in range [0x0000000000000598-0x000000000000059f] +CPU: 1 PID: 361 Comm: insmod +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) +RIP: 0010:__neigh_ifdown.isra.0+0x24b/0x370 +RSP: 0018:ffff888012677908 EFLAGS: 00000202 +... +Call Trace: + + neigh_table_clear+0x94/0x2d0 + ndisc_cleanup+0x27/0x40 [ipv6] + inet6_init+0x21c/0x2cb [ipv6] + do_one_initcall+0xd3/0x4d0 + do_init_module+0x1ae/0x670 +... +Kernel panic - not syncing: Fatal exception + +When ipv6 initialization fails, it will try to cleanup and calls: + +neigh_table_clear() + neigh_ifdown(tbl, NULL) + pneigh_queue_purge(&tbl->proxy_queue, dev_net(dev == NULL)) + # dev_net(NULL) triggers null-ptr-deref. + +Fix it by passing NULL to pneigh_queue_purge() in neigh_ifdown() if dev +is NULL, to make kernel not panic immediately. + +Fixes: 66ba215cb513 ("neigh: fix possible DoS due to net iface start/stop loop") +Signed-off-by: Chen Zhongjin +Reviewed-by: Eric Dumazet +Reviewed-by: Denis V. Lunev +Link: https://lore.kernel.org/r/20221101121552.21890-1-chenzhongjin@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/core/neighbour.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/net/core/neighbour.c b/net/core/neighbour.c +index 78cc8fb68814..84755db81e9d 100644 +--- a/net/core/neighbour.c ++++ b/net/core/neighbour.c +@@ -409,7 +409,7 @@ static int __neigh_ifdown(struct neigh_table *tbl, struct net_device *dev, + write_lock_bh(&tbl->lock); + neigh_flush_dev(tbl, dev, skip_perm); + pneigh_ifdown_and_unlock(tbl, dev); +- pneigh_queue_purge(&tbl->proxy_queue, dev_net(dev)); ++ pneigh_queue_purge(&tbl->proxy_queue, dev ? dev_net(dev) : NULL); + if (skb_queue_empty_lockless(&tbl->proxy_queue)) + del_timer_sync(&tbl->proxy_timer); + return 0; +-- +2.35.1 + diff --git a/queue-6.0/net-sched-fix-use-after-free-in-red_enqueue.patch b/queue-6.0/net-sched-fix-use-after-free-in-red_enqueue.patch new file mode 100644 index 00000000000..8a7309e7d58 --- /dev/null +++ b/queue-6.0/net-sched-fix-use-after-free-in-red_enqueue.patch @@ -0,0 +1,49 @@ +From 188843d03e6105b324139179ea6fd3a4758b9b8d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 28 Oct 2022 18:05:00 +0300 +Subject: net: sched: Fix use after free in red_enqueue() + +From: Dan Carpenter + +[ Upstream commit 8bdc2acd420c6f3dd1f1c78750ec989f02a1e2b9 ] + +We can't use "skb" again after passing it to qdisc_enqueue(). This is +basically identical to commit 2f09707d0c97 ("sch_sfb: Also store skb +len before calling child enqueue"). + +Fixes: d7f4f332f082 ("sch_red: update backlog as well") +Signed-off-by: Dan Carpenter +Reviewed-by: Eric Dumazet +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/sched/sch_red.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/net/sched/sch_red.c b/net/sched/sch_red.c +index f1e013e3f04a..935d90874b1b 100644 +--- a/net/sched/sch_red.c ++++ b/net/sched/sch_red.c +@@ -72,6 +72,7 @@ static int red_enqueue(struct sk_buff *skb, struct Qdisc *sch, + { + struct red_sched_data *q = qdisc_priv(sch); + struct Qdisc *child = q->qdisc; ++ unsigned int len; + int ret; + + q->vars.qavg = red_calc_qavg(&q->parms, +@@ -126,9 +127,10 @@ static int red_enqueue(struct sk_buff *skb, struct Qdisc *sch, + break; + } + ++ len = qdisc_pkt_len(skb); + ret = qdisc_enqueue(skb, child, to_free); + if (likely(ret == NET_XMIT_SUCCESS)) { +- qdisc_qstats_backlog_inc(sch, skb); ++ sch->qstats.backlog += len; + sch->q.qlen++; + } else if (net_xmit_drop_count(ret)) { + q->stats.pdrop++; +-- +2.35.1 + diff --git a/queue-6.0/net-smc-fix-possible-leaked-pernet-namespace-in-smc_.patch b/queue-6.0/net-smc-fix-possible-leaked-pernet-namespace-in-smc_.patch new file mode 100644 index 00000000000..835925da4bb --- /dev/null +++ b/queue-6.0/net-smc-fix-possible-leaked-pernet-namespace-in-smc_.patch @@ -0,0 +1,69 @@ +From 0a8b4c10373b50b734c1b32920adcfebf95f632f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 1 Nov 2022 17:37:22 +0800 +Subject: net/smc: Fix possible leaked pernet namespace in smc_init() + +From: Chen Zhongjin + +[ Upstream commit 62ff373da2534534c55debe6c724c7fe14adb97f ] + +In smc_init(), register_pernet_subsys(&smc_net_stat_ops) is called +without any error handling. +If it fails, registering of &smc_net_ops won't be reverted. +And if smc_nl_init() fails, &smc_net_stat_ops itself won't be reverted. + +This leaves wild ops in subsystem linkedlist and when another module +tries to call register_pernet_operations() it triggers page fault: + +BUG: unable to handle page fault for address: fffffbfff81b964c +RIP: 0010:register_pernet_operations+0x1b9/0x5f0 +Call Trace: + + register_pernet_subsys+0x29/0x40 + ebtables_init+0x58/0x1000 [ebtables] + ... + +Fixes: 194730a9beb5 ("net/smc: Make SMC statistics network namespace aware") +Signed-off-by: Chen Zhongjin +Reviewed-by: Tony Lu +Reviewed-by: Wenjia Zhang +Link: https://lore.kernel.org/r/20221101093722.127223-1-chenzhongjin@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/smc/af_smc.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/net/smc/af_smc.c b/net/smc/af_smc.c +index 0939cc3b915a..58ff5f33b370 100644 +--- a/net/smc/af_smc.c ++++ b/net/smc/af_smc.c +@@ -3380,14 +3380,14 @@ static int __init smc_init(void) + + rc = register_pernet_subsys(&smc_net_stat_ops); + if (rc) +- return rc; ++ goto out_pernet_subsys; + + smc_ism_init(); + smc_clc_init(); + + rc = smc_nl_init(); + if (rc) +- goto out_pernet_subsys; ++ goto out_pernet_subsys_stat; + + rc = smc_pnet_init(); + if (rc) +@@ -3480,6 +3480,8 @@ static int __init smc_init(void) + smc_pnet_exit(); + out_nl: + smc_nl_exit(); ++out_pernet_subsys_stat: ++ unregister_pernet_subsys(&smc_net_stat_ops); + out_pernet_subsys: + unregister_pernet_subsys(&smc_net_ops); + +-- +2.35.1 + diff --git a/queue-6.0/net-tun-fix-bugs-for-oversize-packet-when-napi-frags.patch b/queue-6.0/net-tun-fix-bugs-for-oversize-packet-when-napi-frags.patch new file mode 100644 index 00000000000..34d06d09311 --- /dev/null +++ b/queue-6.0/net-tun-fix-bugs-for-oversize-packet-when-napi-frags.patch @@ -0,0 +1,96 @@ +From 72cbbdbd1abea7f44821de79cbaa4be4d1b7279f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 29 Oct 2022 17:41:01 +0800 +Subject: net: tun: fix bugs for oversize packet when napi frags enabled + +From: Ziyang Xuan + +[ Upstream commit 363a5328f4b0517e59572118ccfb7c626d81dca9 ] + +Recently, we got two syzkaller problems because of oversize packet +when napi frags enabled. + +One of the problems is because the first seg size of the iov_iter +from user space is very big, it is 2147479538 which is bigger than +the threshold value for bail out early in __alloc_pages(). And +skb->pfmemalloc is true, __kmalloc_reserve() would use pfmemalloc +reserves without __GFP_NOWARN flag. Thus we got a warning as following: + +======================================================== +WARNING: CPU: 1 PID: 17965 at mm/page_alloc.c:5295 __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295 +... +Call trace: + __alloc_pages+0x1308/0x16c4 mm/page_alloc.c:5295 + __alloc_pages_node include/linux/gfp.h:550 [inline] + alloc_pages_node include/linux/gfp.h:564 [inline] + kmalloc_large_node+0x94/0x350 mm/slub.c:4038 + __kmalloc_node_track_caller+0x620/0x8e4 mm/slub.c:4545 + __kmalloc_reserve.constprop.0+0x1e4/0x2b0 net/core/skbuff.c:151 + pskb_expand_head+0x130/0x8b0 net/core/skbuff.c:1654 + __skb_grow include/linux/skbuff.h:2779 [inline] + tun_napi_alloc_frags+0x144/0x610 drivers/net/tun.c:1477 + tun_get_user+0x31c/0x2010 drivers/net/tun.c:1835 + tun_chr_write_iter+0x98/0x100 drivers/net/tun.c:2036 + +The other problem is because odd IPv6 packets without NEXTHDR_NONE +extension header and have big packet length, it is 2127925 which is +bigger than ETH_MAX_MTU(65535). After ipv6_gso_pull_exthdrs() in +ipv6_gro_receive(), network_header offset and transport_header offset +are all bigger than U16_MAX. That would trigger skb->network_header +and skb->transport_header overflow error, because they are all '__u16' +type. Eventually, it would affect the value for __skb_push(skb, value), +and make it be a big value. After __skb_push() in ipv6_gro_receive(), +skb->data would less than skb->head, an out of bounds memory bug occurred. +That would trigger the problem as following: + +================================================================== +BUG: KASAN: use-after-free in eth_type_trans+0x100/0x260 +... +Call trace: + dump_backtrace+0xd8/0x130 + show_stack+0x1c/0x50 + dump_stack_lvl+0x64/0x7c + print_address_description.constprop.0+0xbc/0x2e8 + print_report+0x100/0x1e4 + kasan_report+0x80/0x120 + __asan_load8+0x78/0xa0 + eth_type_trans+0x100/0x260 + napi_gro_frags+0x164/0x550 + tun_get_user+0xda4/0x1270 + tun_chr_write_iter+0x74/0x130 + do_iter_readv_writev+0x130/0x1ec + do_iter_write+0xbc/0x1e0 + vfs_writev+0x13c/0x26c + +To fix the problems, restrict the packet size less than +(ETH_MAX_MTU - NET_SKB_PAD - NET_IP_ALIGN) which has considered reserved +skb space in napi_alloc_skb() because transport_header is an offset from +skb->head. Add len check in tun_napi_alloc_frags() simply. + +Fixes: 90e33d459407 ("tun: enable napi_gro_frags() for TUN/TAP driver") +Signed-off-by: Ziyang Xuan +Reviewed-by: Eric Dumazet +Link: https://lore.kernel.org/r/20221029094101.1653855-1-william.xuanziyang@huawei.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/tun.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/net/tun.c b/drivers/net/tun.c +index db736b944016..b02bd0a6c0a9 100644 +--- a/drivers/net/tun.c ++++ b/drivers/net/tun.c +@@ -1459,7 +1459,8 @@ static struct sk_buff *tun_napi_alloc_frags(struct tun_file *tfile, + int err; + int i; + +- if (it->nr_segs > MAX_SKB_FRAGS + 1) ++ if (it->nr_segs > MAX_SKB_FRAGS + 1 || ++ len > (ETH_MAX_MTU - NET_SKB_PAD - NET_IP_ALIGN)) + return ERR_PTR(-EMSGSIZE); + + local_bh_disable(); +-- +2.35.1 + diff --git a/queue-6.0/netfilter-ipset-enforce-documented-limit-to-prevent-.patch b/queue-6.0/netfilter-ipset-enforce-documented-limit-to-prevent-.patch new file mode 100644 index 00000000000..7b379871b02 --- /dev/null +++ b/queue-6.0/netfilter-ipset-enforce-documented-limit-to-prevent-.patch @@ -0,0 +1,102 @@ +From 4faab618d92e12b4f868d16f78aba77680d487c8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 2 Nov 2022 10:40:47 +0100 +Subject: netfilter: ipset: enforce documented limit to prevent allocating huge + memory + +From: Jozsef Kadlecsik + +[ Upstream commit 510841da1fcc16f702440ab58ef0b4d82a9056b7 ] + +Daniel Xu reported that the hash:net,iface type of the ipset subsystem does +not limit adding the same network with different interfaces to a set, which +can lead to huge memory usage or allocation failure. + +The quick reproducer is + +$ ipset create ACL.IN.ALL_PERMIT hash:net,iface hashsize 1048576 timeout 0 +$ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALL_PERMIT 0.0.0.0/0,kaf_$i timeout 0 -exist; done + +The backtrace when vmalloc fails: + + [Tue Oct 25 00:13:08 2022] ipset: vmalloc error: size 1073741848, exceeds total pages + <...> + [Tue Oct 25 00:13:08 2022] Call Trace: + [Tue Oct 25 00:13:08 2022] + [Tue Oct 25 00:13:08 2022] dump_stack_lvl+0x48/0x60 + [Tue Oct 25 00:13:08 2022] warn_alloc+0x155/0x180 + [Tue Oct 25 00:13:08 2022] __vmalloc_node_range+0x72a/0x760 + [Tue Oct 25 00:13:08 2022] ? hash_netiface4_add+0x7c0/0xb20 + [Tue Oct 25 00:13:08 2022] ? __kmalloc_large_node+0x4a/0x90 + [Tue Oct 25 00:13:08 2022] kvmalloc_node+0xa6/0xd0 + [Tue Oct 25 00:13:08 2022] ? hash_netiface4_resize+0x99/0x710 + <...> + +The fix is to enforce the limit documented in the ipset(8) manpage: + +> The internal restriction of the hash:net,iface set type is that the same +> network prefix cannot be stored with more than 64 different interfaces +> in a single set. + +Fixes: ccf0a4b7fc68 ("netfilter: ipset: Add bucketsize parameter to all hash types") +Reported-by: Daniel Xu +Signed-off-by: Jozsef Kadlecsik +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Sasha Levin +--- + net/netfilter/ipset/ip_set_hash_gen.h | 30 ++++++--------------------- + 1 file changed, 6 insertions(+), 24 deletions(-) + +diff --git a/net/netfilter/ipset/ip_set_hash_gen.h b/net/netfilter/ipset/ip_set_hash_gen.h +index 6e391308431d..3adc291d9ce1 100644 +--- a/net/netfilter/ipset/ip_set_hash_gen.h ++++ b/net/netfilter/ipset/ip_set_hash_gen.h +@@ -42,31 +42,8 @@ + #define AHASH_MAX_SIZE (6 * AHASH_INIT_SIZE) + /* Max muber of elements in the array block when tuned */ + #define AHASH_MAX_TUNED 64 +- + #define AHASH_MAX(h) ((h)->bucketsize) + +-/* Max number of elements can be tuned */ +-#ifdef IP_SET_HASH_WITH_MULTI +-static u8 +-tune_bucketsize(u8 curr, u32 multi) +-{ +- u32 n; +- +- if (multi < curr) +- return curr; +- +- n = curr + AHASH_INIT_SIZE; +- /* Currently, at listing one hash bucket must fit into a message. +- * Therefore we have a hard limit here. +- */ +- return n > curr && n <= AHASH_MAX_TUNED ? n : curr; +-} +-#define TUNE_BUCKETSIZE(h, multi) \ +- ((h)->bucketsize = tune_bucketsize((h)->bucketsize, multi)) +-#else +-#define TUNE_BUCKETSIZE(h, multi) +-#endif +- + /* A hash bucket */ + struct hbucket { + struct rcu_head rcu; /* for call_rcu */ +@@ -936,7 +913,12 @@ mtype_add(struct ip_set *set, void *value, const struct ip_set_ext *ext, + goto set_full; + /* Create a new slot */ + if (n->pos >= n->size) { +- TUNE_BUCKETSIZE(h, multi); ++#ifdef IP_SET_HASH_WITH_MULTI ++ if (h->bucketsize >= AHASH_MAX_TUNED) ++ goto set_full; ++ else if (h->bucketsize < multi) ++ h->bucketsize += AHASH_INIT_SIZE; ++#endif + if (n->size >= AHASH_MAX(h)) { + /* Trigger rehashing */ + mtype_data_next(&h->next, d); +-- +2.35.1 + diff --git a/queue-6.0/netfilter-nf_tables-netlink-notifier-might-race-to-r.patch b/queue-6.0/netfilter-nf_tables-netlink-notifier-might-race-to-r.patch new file mode 100644 index 00000000000..a778878dda2 --- /dev/null +++ b/queue-6.0/netfilter-nf_tables-netlink-notifier-might-race-to-r.patch @@ -0,0 +1,41 @@ +From 2e20e22894b9ca91f8e4f3b5302b98334da18649 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 26 Oct 2022 09:52:36 +0200 +Subject: netfilter: nf_tables: netlink notifier might race to release objects + +From: Pablo Neira Ayuso + +[ Upstream commit d4bc8271db21ea9f1c86a1ca4d64999f184d4aae ] + +commit release path is invoked via call_rcu and it runs lockless to +release the objects after rcu grace period. The netlink notifier handler +might win race to remove objects that the transaction context is still +referencing from the commit release path. + +Call rcu_barrier() to ensure pending rcu callbacks run to completion +if the list of transactions to be destroyed is not empty. + +Fixes: 6001a930ce03 ("netfilter: nftables: introduce table ownership") +Reported-by: syzbot+8f747f62763bc6c32916@syzkaller.appspotmail.com +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Sasha Levin +--- + net/netfilter/nf_tables_api.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c +index 5897afd12466..cc598504bc10 100644 +--- a/net/netfilter/nf_tables_api.c ++++ b/net/netfilter/nf_tables_api.c +@@ -10030,6 +10030,8 @@ static int nft_rcv_nl_event(struct notifier_block *this, unsigned long event, + nft_net = nft_pernet(net); + deleted = 0; + mutex_lock(&nft_net->commit_mutex); ++ if (!list_empty(&nf_tables_destroy_list)) ++ rcu_barrier(); + again: + list_for_each_entry(table, &nft_net->tables, list) { + if (nft_table_has_owner(table) && +-- +2.35.1 + diff --git a/queue-6.0/netfilter-nf_tables-release-flow-rule-object-from-co.patch b/queue-6.0/netfilter-nf_tables-release-flow-rule-object-from-co.patch new file mode 100644 index 00000000000..03ec350cf87 --- /dev/null +++ b/queue-6.0/netfilter-nf_tables-release-flow-rule-object-from-co.patch @@ -0,0 +1,48 @@ +From 10f5188b3f8660690be88fb9ec220f199d18044c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 26 Oct 2022 09:54:45 +0200 +Subject: netfilter: nf_tables: release flow rule object from commit path + +From: Pablo Neira Ayuso + +[ Upstream commit 26b5934ff4194e13196bedcba373cd4915071d0e ] + +No need to postpone this to the commit release path, since no packets +are walking over this object, this is accessed from control plane only. +This helped uncovered UAF triggered by races with the netlink notifier. + +Fixes: 9dd732e0bdf5 ("netfilter: nf_tables: memleak flow rule from commit path") +Reported-by: syzbot+8f747f62763bc6c32916@syzkaller.appspotmail.com +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Sasha Levin +--- + net/netfilter/nf_tables_api.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/net/netfilter/nf_tables_api.c b/net/netfilter/nf_tables_api.c +index cc598504bc10..879f4a1a27d5 100644 +--- a/net/netfilter/nf_tables_api.c ++++ b/net/netfilter/nf_tables_api.c +@@ -8465,9 +8465,6 @@ static void nft_commit_release(struct nft_trans *trans) + nf_tables_chain_destroy(&trans->ctx); + break; + case NFT_MSG_DELRULE: +- if (trans->ctx.chain->flags & NFT_CHAIN_HW_OFFLOAD) +- nft_flow_rule_destroy(nft_trans_flow_rule(trans)); +- + nf_tables_rule_destroy(&trans->ctx, nft_trans_rule(trans)); + break; + case NFT_MSG_DELSET: +@@ -8973,6 +8970,9 @@ static int nf_tables_commit(struct net *net, struct sk_buff *skb) + nft_rule_expr_deactivate(&trans->ctx, + nft_trans_rule(trans), + NFT_TRANS_COMMIT); ++ ++ if (trans->ctx.chain->flags & NFT_CHAIN_HW_OFFLOAD) ++ nft_flow_rule_destroy(nft_trans_flow_rule(trans)); + break; + case NFT_MSG_NEWSET: + nft_clear(net, nft_trans_set(trans)); +-- +2.35.1 + diff --git a/queue-6.0/nfc-fdp-fix-potential-memory-leak-in-fdp_nci_send.patch b/queue-6.0/nfc-fdp-fix-potential-memory-leak-in-fdp_nci_send.patch new file mode 100644 index 00000000000..2636de1ea56 --- /dev/null +++ b/queue-6.0/nfc-fdp-fix-potential-memory-leak-in-fdp_nci_send.patch @@ -0,0 +1,50 @@ +From 1700a6dadb973a420cf15f564bb76f8678d8ab4c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 27 Oct 2022 22:03:29 +0800 +Subject: nfc: fdp: Fix potential memory leak in fdp_nci_send() + +From: Shang XiaoJing + +[ Upstream commit 8e4aae6b8ca76afb1fb64dcb24be44ba814e7f8a ] + +fdp_nci_send() will call fdp_nci_i2c_write that will not free skb in +the function. As a result, when fdp_nci_i2c_write() finished, the skb +will memleak. fdp_nci_send() should free skb after fdp_nci_i2c_write() +finished. + +Fixes: a06347c04c13 ("NFC: Add Intel Fields Peak NFC solution driver") +Signed-off-by: Shang XiaoJing +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/nfc/fdp/fdp.c | 10 +++++++++- + 1 file changed, 9 insertions(+), 1 deletion(-) + +diff --git a/drivers/nfc/fdp/fdp.c b/drivers/nfc/fdp/fdp.c +index c6b3334f24c9..f12f903a9dd1 100644 +--- a/drivers/nfc/fdp/fdp.c ++++ b/drivers/nfc/fdp/fdp.c +@@ -249,11 +249,19 @@ static int fdp_nci_close(struct nci_dev *ndev) + static int fdp_nci_send(struct nci_dev *ndev, struct sk_buff *skb) + { + struct fdp_nci_info *info = nci_get_drvdata(ndev); ++ int ret; + + if (atomic_dec_and_test(&info->data_pkt_counter)) + info->data_pkt_counter_cb(ndev); + +- return info->phy_ops->write(info->phy, skb); ++ ret = info->phy_ops->write(info->phy, skb); ++ if (ret < 0) { ++ kfree_skb(skb); ++ return ret; ++ } ++ ++ consume_skb(skb); ++ return 0; + } + + static int fdp_nci_request_firmware(struct nci_dev *ndev) +-- +2.35.1 + diff --git a/queue-6.0/nfc-nfcmrvl-fix-potential-memory-leak-in-nfcmrvl_i2c.patch b/queue-6.0/nfc-nfcmrvl-fix-potential-memory-leak-in-nfcmrvl_i2c.patch new file mode 100644 index 00000000000..8828d50a315 --- /dev/null +++ b/queue-6.0/nfc-nfcmrvl-fix-potential-memory-leak-in-nfcmrvl_i2c.patch @@ -0,0 +1,47 @@ +From 7e0dc24aa274b8a5026c95ae54808e5ac2bee454 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 27 Oct 2022 22:03:32 +0800 +Subject: nfc: nfcmrvl: Fix potential memory leak in nfcmrvl_i2c_nci_send() + +From: Shang XiaoJing + +[ Upstream commit 93d904a734a74c54d945a9884b4962977f1176cd ] + +nfcmrvl_i2c_nci_send() will be called by nfcmrvl_nci_send(), and skb +should be freed in nfcmrvl_i2c_nci_send(). However, nfcmrvl_nci_send() +will only free skb when i2c_master_send() return >=0, which means skb +will memleak when i2c_master_send() failed. Free skb no matter whether +i2c_master_send() succeeds. + +Fixes: b5b3e23e4cac ("NFC: nfcmrvl: add i2c driver") +Signed-off-by: Shang XiaoJing +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/nfc/nfcmrvl/i2c.c | 7 ++++++- + 1 file changed, 6 insertions(+), 1 deletion(-) + +diff --git a/drivers/nfc/nfcmrvl/i2c.c b/drivers/nfc/nfcmrvl/i2c.c +index 01329b91d59d..a902720cd849 100644 +--- a/drivers/nfc/nfcmrvl/i2c.c ++++ b/drivers/nfc/nfcmrvl/i2c.c +@@ -132,10 +132,15 @@ static int nfcmrvl_i2c_nci_send(struct nfcmrvl_private *priv, + ret = -EREMOTEIO; + } else + ret = 0; ++ } ++ ++ if (ret) { + kfree_skb(skb); ++ return ret; + } + +- return ret; ++ consume_skb(skb); ++ return 0; + } + + static void nfcmrvl_i2c_nci_update_config(struct nfcmrvl_private *priv, +-- +2.35.1 + diff --git a/queue-6.0/nfc-nxp-nci-fix-potential-memory-leak-in-nxp_nci_sen.patch b/queue-6.0/nfc-nxp-nci-fix-potential-memory-leak-in-nxp_nci_sen.patch new file mode 100644 index 00000000000..b5747ae0997 --- /dev/null +++ b/queue-6.0/nfc-nxp-nci-fix-potential-memory-leak-in-nxp_nci_sen.patch @@ -0,0 +1,46 @@ +From 9ca79d3e0c9ae3aa501d31b2e06a0c6ad3f5c695 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 27 Oct 2022 22:03:30 +0800 +Subject: nfc: nxp-nci: Fix potential memory leak in nxp_nci_send() + +From: Shang XiaoJing + +[ Upstream commit 7bf1ed6aff0f70434bd0cdd45495e83f1dffb551 ] + +nxp_nci_send() will call nxp_nci_i2c_write(), and only free skb when +nxp_nci_i2c_write() failed. However, even if the nxp_nci_i2c_write() +run succeeds, the skb will not be freed in nxp_nci_i2c_write(). As the +result, the skb will memleak. nxp_nci_send() should also free the skb +when nxp_nci_i2c_write() succeeds. + +Fixes: dece45855a8b ("NFC: nxp-nci: Add support for NXP NCI chips") +Signed-off-by: Shang XiaoJing +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/nfc/nxp-nci/core.c | 7 +++++-- + 1 file changed, 5 insertions(+), 2 deletions(-) + +diff --git a/drivers/nfc/nxp-nci/core.c b/drivers/nfc/nxp-nci/core.c +index 7c93d484dc1b..580cb6ecffee 100644 +--- a/drivers/nfc/nxp-nci/core.c ++++ b/drivers/nfc/nxp-nci/core.c +@@ -80,10 +80,13 @@ static int nxp_nci_send(struct nci_dev *ndev, struct sk_buff *skb) + return -EINVAL; + + r = info->phy_ops->write(info->phy_id, skb); +- if (r < 0) ++ if (r < 0) { + kfree_skb(skb); ++ return r; ++ } + +- return r; ++ consume_skb(skb); ++ return 0; + } + + static int nxp_nci_rf_pll_unlocked_ntf(struct nci_dev *ndev, +-- +2.35.1 + diff --git a/queue-6.0/nfc-s3fwrn5-fix-potential-memory-leak-in-s3fwrn5_nci.patch b/queue-6.0/nfc-s3fwrn5-fix-potential-memory-leak-in-s3fwrn5_nci.patch new file mode 100644 index 00000000000..340b106a4d1 --- /dev/null +++ b/queue-6.0/nfc-s3fwrn5-fix-potential-memory-leak-in-s3fwrn5_nci.patch @@ -0,0 +1,48 @@ +From 250b310a5536b3313eae5fcf6a9f8d7f125dc639 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 27 Oct 2022 22:03:31 +0800 +Subject: nfc: s3fwrn5: Fix potential memory leak in s3fwrn5_nci_send() + +From: Shang XiaoJing + +[ Upstream commit 3a146b7e3099dc7cf3114f627d9b79291e2d2203 ] + +s3fwrn5_nci_send() will call s3fwrn5_i2c_write() or s3fwrn82_uart_write(), +and free the skb if write() failed. However, even if the write() run +succeeds, the skb will not be freed in write(). As the result, the skb +will memleak. s3fwrn5_nci_send() should also free the skb when write() +succeeds. + +Fixes: c04c674fadeb ("nfc: s3fwrn5: Add driver for Samsung S3FWRN5 NFC Chip") +Signed-off-by: Shang XiaoJing +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/nfc/s3fwrn5/core.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +diff --git a/drivers/nfc/s3fwrn5/core.c b/drivers/nfc/s3fwrn5/core.c +index 1c412007fabb..0270e05b68df 100644 +--- a/drivers/nfc/s3fwrn5/core.c ++++ b/drivers/nfc/s3fwrn5/core.c +@@ -110,11 +110,15 @@ static int s3fwrn5_nci_send(struct nci_dev *ndev, struct sk_buff *skb) + } + + ret = s3fwrn5_write(info, skb); +- if (ret < 0) ++ if (ret < 0) { + kfree_skb(skb); ++ mutex_unlock(&info->mutex); ++ return ret; ++ } + ++ consume_skb(skb); + mutex_unlock(&info->mutex); +- return ret; ++ return 0; + } + + static int s3fwrn5_nci_post_setup(struct nci_dev *ndev) +-- +2.35.1 + diff --git a/queue-6.0/nfs4-fix-kmemleak-when-allocate-slot-failed.patch b/queue-6.0/nfs4-fix-kmemleak-when-allocate-slot-failed.patch new file mode 100644 index 00000000000..5f4b88cf1ea --- /dev/null +++ b/queue-6.0/nfs4-fix-kmemleak-when-allocate-slot-failed.patch @@ -0,0 +1,54 @@ +From 97c4e0184a4ce630276bb0f131ab7a92a6f77e74 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 20 Oct 2022 11:20:54 +0800 +Subject: nfs4: Fix kmemleak when allocate slot failed + +From: Zhang Xiaoxu + +[ Upstream commit 7e8436728e22181c3f12a5dbabd35ed3a8b8c593 ] + +If one of the slot allocate failed, should cleanup all the other +allocated slots, otherwise, the allocated slots will leak: + + unreferenced object 0xffff8881115aa100 (size 64): + comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s) + hex dump (first 32 bytes): + 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z..... + 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ + backtrace: + [<000000007a4c434a>] nfs4_find_or_create_slot+0x8e/0x130 + [<000000005472a39c>] nfs4_realloc_slot_table+0x23f/0x270 + [<00000000cd8ca0eb>] nfs40_init_client+0x4a/0x90 + [<00000000128486db>] nfs4_init_client+0xce/0x270 + [<000000008d2cacad>] nfs4_set_client+0x1a2/0x2b0 + [<000000000e593b52>] nfs4_create_server+0x300/0x5f0 + [<00000000e4425dd2>] nfs4_try_get_tree+0x65/0x110 + [<00000000d3a6176f>] vfs_get_tree+0x41/0xf0 + [<0000000016b5ad4c>] path_mount+0x9b3/0xdd0 + [<00000000494cae71>] __x64_sys_mount+0x190/0x1d0 + [<000000005d56bdec>] do_syscall_64+0x35/0x80 + [<00000000687c9ae4>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 + +Fixes: abf79bb341bf ("NFS: Add a slot table to struct nfs_client for NFSv4.0 transport blocking") +Signed-off-by: Zhang Xiaoxu +Signed-off-by: Anna Schumaker +Signed-off-by: Sasha Levin +--- + fs/nfs/nfs4client.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c +index 3c5678aec006..8ae2827da28d 100644 +--- a/fs/nfs/nfs4client.c ++++ b/fs/nfs/nfs4client.c +@@ -346,6 +346,7 @@ int nfs40_init_client(struct nfs_client *clp) + ret = nfs4_setup_slot_table(tbl, NFS4_MAX_SLOT_TABLE, + "NFSv4.0 transport Slot table"); + if (ret) { ++ nfs4_shutdown_slot_table(tbl); + kfree(tbl); + return ret; + } +-- +2.35.1 + diff --git a/queue-6.0/nfsd-fix-net-namespace-logic-in-__nfsd_file_cache_pu.patch b/queue-6.0/nfsd-fix-net-namespace-logic-in-__nfsd_file_cache_pu.patch new file mode 100644 index 00000000000..b24d3daf3c1 --- /dev/null +++ b/queue-6.0/nfsd-fix-net-namespace-logic-in-__nfsd_file_cache_pu.patch @@ -0,0 +1,42 @@ +From aabd93fdc6cd0530484a77d4438ee28db19b2aea Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 31 Oct 2022 11:49:21 -0400 +Subject: nfsd: fix net-namespace logic in __nfsd_file_cache_purge + +From: Jeff Layton + +[ Upstream commit d3aefd2b29ff5ffdeb5c06a7d3191a027a18cdb8 ] + +If the namespace doesn't match the one in "net", then we'll continue, +but that doesn't cause another rhashtable_walk_next call, so it will +loop infinitely. + +Fixes: ce502f81ba88 ("NFSD: Convert the filecache to use rhashtable") +Reported-by: Petr Vorel +Link: https://lore.kernel.org/ltp/Y1%2FP8gDAcWC%2F+VR3@pevik/ +Signed-off-by: Jeff Layton +Signed-off-by: Chuck Lever +Signed-off-by: Sasha Levin +--- + fs/nfsd/filecache.c | 5 ++--- + 1 file changed, 2 insertions(+), 3 deletions(-) + +diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c +index 844c41832d50..173b38ffa423 100644 +--- a/fs/nfsd/filecache.c ++++ b/fs/nfsd/filecache.c +@@ -893,9 +893,8 @@ __nfsd_file_cache_purge(struct net *net) + + nf = rhashtable_walk_next(&iter); + while (!IS_ERR_OR_NULL(nf)) { +- if (net && nf->nf_net != net) +- continue; +- nfsd_file_unhash_and_dispose(nf, &dispose); ++ if (!net || nf->nf_net == net) ++ nfsd_file_unhash_and_dispose(nf, &dispose); + nf = rhashtable_walk_next(&iter); + } + +-- +2.35.1 + diff --git a/queue-6.0/nfsd-fix-nfsd_file_unhash_and_dispose.patch b/queue-6.0/nfsd-fix-nfsd_file_unhash_and_dispose.patch new file mode 100644 index 00000000000..40ddba37538 --- /dev/null +++ b/queue-6.0/nfsd-fix-nfsd_file_unhash_and_dispose.patch @@ -0,0 +1,126 @@ +From 1f7fbcae3a01c36ce66e09f845991cbd795db0e8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 30 Sep 2022 16:56:02 -0400 +Subject: nfsd: fix nfsd_file_unhash_and_dispose + +From: Jeff Layton + +[ Upstream commit 8d0d254b15cc5b7d46d85fb7ab8ecede9575e672 ] + +nfsd_file_unhash_and_dispose() is called for two reasons: + +We're either shutting down and purging the filecache, or we've gotten a +notification about a file delete, so we want to go ahead and unhash it +so that it'll get cleaned up when we close. + +We're either walking the hashtable or doing a lookup in it and we +don't take a reference in either case. What we want to do in both cases +is to try and unhash the object and put it on the dispose list if that +was successful. If it's no longer hashed, then we don't want to touch +it, with the assumption being that something else is already cleaning +up the sentinel reference. + +Instead of trying to selectively decrement the refcount in this +function, just unhash it, and if that was successful, move it to the +dispose list. Then, the disposal routine will just clean that up as +usual. + +Also, just make this a void function, drop the WARN_ON_ONCE, and the +comments about deadlocking since the nature of the purported deadlock +is no longer clear. + +Signed-off-by: Jeff Layton +Signed-off-by: Chuck Lever +Stable-dep-of: d3aefd2b29ff ("nfsd: fix net-namespace logic in __nfsd_file_cache_purge") +Signed-off-by: Sasha Levin +--- + fs/nfsd/filecache.c | 36 +++++++----------------------------- + 1 file changed, 7 insertions(+), 29 deletions(-) + +diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c +index eeed4ae5b4ad..844c41832d50 100644 +--- a/fs/nfsd/filecache.c ++++ b/fs/nfsd/filecache.c +@@ -405,22 +405,15 @@ nfsd_file_unhash(struct nfsd_file *nf) + return false; + } + +-/* +- * Return true if the file was unhashed. +- */ +-static bool ++static void + nfsd_file_unhash_and_dispose(struct nfsd_file *nf, struct list_head *dispose) + { + trace_nfsd_file_unhash_and_dispose(nf); +- if (!nfsd_file_unhash(nf)) +- return false; +- /* keep final reference for nfsd_file_lru_dispose */ +- if (refcount_dec_not_one(&nf->nf_ref)) +- return true; +- +- nfsd_file_lru_remove(nf); +- list_add(&nf->nf_lru, dispose); +- return true; ++ if (nfsd_file_unhash(nf)) { ++ /* caller must call nfsd_file_dispose_list() later */ ++ nfsd_file_lru_remove(nf); ++ list_add(&nf->nf_lru, dispose); ++ } + } + + static void +@@ -562,8 +555,6 @@ nfsd_file_dispose_list_delayed(struct list_head *dispose) + * @lock: LRU list lock (unused) + * @arg: dispose list + * +- * Note this can deadlock with nfsd_file_cache_purge. +- * + * Return values: + * %LRU_REMOVED: @item was removed from the LRU + * %LRU_ROTATE: @item is to be moved to the LRU tail +@@ -748,8 +739,6 @@ nfsd_file_close_inode(struct inode *inode) + * + * Walk the LRU list and close any entries that have not been used since + * the last scan. +- * +- * Note this can deadlock with nfsd_file_cache_purge. + */ + static void + nfsd_file_delayed_close(struct work_struct *work) +@@ -891,16 +880,12 @@ nfsd_file_cache_init(void) + goto out; + } + +-/* +- * Note this can deadlock with nfsd_file_lru_cb. +- */ + static void + __nfsd_file_cache_purge(struct net *net) + { + struct rhashtable_iter iter; + struct nfsd_file *nf; + LIST_HEAD(dispose); +- bool del; + + rhashtable_walk_enter(&nfsd_file_rhash_tbl, &iter); + do { +@@ -910,14 +895,7 @@ __nfsd_file_cache_purge(struct net *net) + while (!IS_ERR_OR_NULL(nf)) { + if (net && nf->nf_net != net) + continue; +- del = nfsd_file_unhash_and_dispose(nf, &dispose); +- +- /* +- * Deadlock detected! Something marked this entry as +- * unhased, but hasn't removed it from the hash list. +- */ +- WARN_ON_ONCE(!del); +- ++ nfsd_file_unhash_and_dispose(nf, &dispose); + nf = rhashtable_walk_next(&iter); + } + +-- +2.35.1 + diff --git a/queue-6.0/nfsv4-fix-a-potential-state-reclaim-deadlock.patch b/queue-6.0/nfsv4-fix-a-potential-state-reclaim-deadlock.patch new file mode 100644 index 00000000000..11819b83ba2 --- /dev/null +++ b/queue-6.0/nfsv4-fix-a-potential-state-reclaim-deadlock.patch @@ -0,0 +1,83 @@ +From 1dd18ffadea024c4b5f8d4151827a9d044b1c9d8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 16 Oct 2022 14:44:31 -0400 +Subject: NFSv4: Fix a potential state reclaim deadlock + +From: Trond Myklebust + +[ Upstream commit 1ba04394e028ea8b45d92685cc0d6ab582cf7647 ] + +If the server reboots while we are engaged in a delegation return, and +there is a pNFS layout with return-on-close set, then the current code +can end up deadlocking in pnfs_roc() when nfs_inode_set_delegation() +tries to return the old delegation. +Now that delegreturn actually uses its own copy of the stateid, it +should be safe to just always update the delegation stateid in place. + +Fixes: 078000d02d57 ("pNFS: We want return-on-close to complete when evicting the inode") +Signed-off-by: Trond Myklebust +Signed-off-by: Anna Schumaker +Signed-off-by: Sasha Levin +--- + fs/nfs/delegation.c | 36 +++++++++++++++++------------------- + 1 file changed, 17 insertions(+), 19 deletions(-) + +diff --git a/fs/nfs/delegation.c b/fs/nfs/delegation.c +index 5c97cad741a7..ead8a0e06abf 100644 +--- a/fs/nfs/delegation.c ++++ b/fs/nfs/delegation.c +@@ -228,8 +228,7 @@ static int nfs_delegation_claim_opens(struct inode *inode, + * + */ + void nfs_inode_reclaim_delegation(struct inode *inode, const struct cred *cred, +- fmode_t type, +- const nfs4_stateid *stateid, ++ fmode_t type, const nfs4_stateid *stateid, + unsigned long pagemod_limit) + { + struct nfs_delegation *delegation; +@@ -239,25 +238,24 @@ void nfs_inode_reclaim_delegation(struct inode *inode, const struct cred *cred, + delegation = rcu_dereference(NFS_I(inode)->delegation); + if (delegation != NULL) { + spin_lock(&delegation->lock); +- if (nfs4_is_valid_delegation(delegation, 0)) { +- nfs4_stateid_copy(&delegation->stateid, stateid); +- delegation->type = type; +- delegation->pagemod_limit = pagemod_limit; +- oldcred = delegation->cred; +- delegation->cred = get_cred(cred); +- clear_bit(NFS_DELEGATION_NEED_RECLAIM, +- &delegation->flags); +- spin_unlock(&delegation->lock); +- rcu_read_unlock(); +- put_cred(oldcred); +- trace_nfs4_reclaim_delegation(inode, type); +- return; +- } +- /* We appear to have raced with a delegation return. */ ++ nfs4_stateid_copy(&delegation->stateid, stateid); ++ delegation->type = type; ++ delegation->pagemod_limit = pagemod_limit; ++ oldcred = delegation->cred; ++ delegation->cred = get_cred(cred); ++ clear_bit(NFS_DELEGATION_NEED_RECLAIM, &delegation->flags); ++ if (test_and_clear_bit(NFS_DELEGATION_REVOKED, ++ &delegation->flags)) ++ atomic_long_inc(&nfs_active_delegations); + spin_unlock(&delegation->lock); ++ rcu_read_unlock(); ++ put_cred(oldcred); ++ trace_nfs4_reclaim_delegation(inode, type); ++ } else { ++ rcu_read_unlock(); ++ nfs_inode_set_delegation(inode, cred, type, stateid, ++ pagemod_limit); + } +- rcu_read_unlock(); +- nfs_inode_set_delegation(inode, cred, type, stateid, pagemod_limit); + } + + static int nfs_do_return_delegation(struct inode *inode, struct nfs_delegation *delegation, int issync) +-- +2.35.1 + diff --git a/queue-6.0/nfsv4.1-handle-reclaim_complete-trunking-errors.patch b/queue-6.0/nfsv4.1-handle-reclaim_complete-trunking-errors.patch new file mode 100644 index 00000000000..775cc1295f1 --- /dev/null +++ b/queue-6.0/nfsv4.1-handle-reclaim_complete-trunking-errors.patch @@ -0,0 +1,35 @@ +From 0e5faf3cb1a5594d47bdfdc95dd754ae76c6a4a6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 16 Oct 2022 14:44:32 -0400 +Subject: NFSv4.1: Handle RECLAIM_COMPLETE trunking errors + +From: Trond Myklebust + +[ Upstream commit 5d917cba3201e5c25059df96c29252fd99c4f6a7 ] + +If RECLAIM_COMPLETE sets the NFS4CLNT_BIND_CONN_TO_SESSION flag, then we +need to loop back in order to handle it. + +Fixes: 0048fdd06614 ("NFSv4.1: RECLAIM_COMPLETE must handle NFS4ERR_CONN_NOT_BOUND_TO_SESSION") +Signed-off-by: Trond Myklebust +Signed-off-by: Anna Schumaker +Signed-off-by: Sasha Levin +--- + fs/nfs/nfs4state.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c +index 9bab3e9c702a..0b6bd6336c98 100644 +--- a/fs/nfs/nfs4state.c ++++ b/fs/nfs/nfs4state.c +@@ -2671,6 +2671,7 @@ static void nfs4_state_manager(struct nfs_client *clp) + if (status < 0) + goto out_error; + nfs4_state_end_reclaim_reboot(clp); ++ continue; + } + + /* Detect expired delegations... */ +-- +2.35.1 + diff --git a/queue-6.0/nfsv4.1-we-must-always-send-reclaim_complete-after-a.patch b/queue-6.0/nfsv4.1-we-must-always-send-reclaim_complete-after-a.patch new file mode 100644 index 00000000000..c8329254bf7 --- /dev/null +++ b/queue-6.0/nfsv4.1-we-must-always-send-reclaim_complete-after-a.patch @@ -0,0 +1,36 @@ +From eccb60f57c7c672254086587d82614c74264ab6e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 16 Oct 2022 14:44:33 -0400 +Subject: NFSv4.1: We must always send RECLAIM_COMPLETE after a reboot + +From: Trond Myklebust + +[ Upstream commit e59679f2b7e522ecad99974e5636291ffd47c184 ] + +Currently, we are only guaranteed to send RECLAIM_COMPLETE if we have +open state to recover. Fix the client to always send RECLAIM_COMPLETE +after setting up the lease. + +Fixes: fce5c838e133 ("nfs41: RECLAIM_COMPLETE functionality") +Signed-off-by: Trond Myklebust +Signed-off-by: Anna Schumaker +Signed-off-by: Sasha Levin +--- + fs/nfs/nfs4state.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c +index 0b6bd6336c98..a629d7db9420 100644 +--- a/fs/nfs/nfs4state.c ++++ b/fs/nfs/nfs4state.c +@@ -1787,6 +1787,7 @@ static void nfs4_state_mark_reclaim_helper(struct nfs_client *clp, + + static void nfs4_state_start_reclaim_reboot(struct nfs_client *clp) + { ++ set_bit(NFS4CLNT_RECLAIM_REBOOT, &clp->cl_state); + /* Mark all delegations for reclaim */ + nfs_delegation_mark_reclaim(clp); + nfs4_state_mark_reclaim_helper(clp, nfs4_state_mark_reclaim_reboot); +-- +2.35.1 + diff --git a/queue-6.0/nfsv4.2-fixup-clone-dest-file-size-for-zero-length-c.patch b/queue-6.0/nfsv4.2-fixup-clone-dest-file-size-for-zero-length-c.patch new file mode 100644 index 00000000000..274c08233c5 --- /dev/null +++ b/queue-6.0/nfsv4.2-fixup-clone-dest-file-size-for-zero-length-c.patch @@ -0,0 +1,41 @@ +From 8e7a08a7683e427ce7bcb7dcb5ed47fc78b442b9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 13 Oct 2022 11:58:01 -0400 +Subject: NFSv4.2: Fixup CLONE dest file size for zero-length count + +From: Benjamin Coddington + +[ Upstream commit 038efb6348ce96228f6828354cb809c22a661681 ] + +When holding a delegation, the NFS client optimizes away setting the +attributes of a file from the GETATTR in the compound after CLONE, and for +a zero-length CLONE we will end up setting the inode's size to zero in +nfs42_copy_dest_done(). Handle this case by computing the resulting count +from the server's reported size after CLONE's GETATTR. + +Suggested-by: Trond Myklebust +Signed-off-by: Benjamin Coddington +Fixes: 94d202d5ca39 ("NFSv42: Copy offload should update the file size when appropriate") +Signed-off-by: Anna Schumaker +Signed-off-by: Sasha Levin +--- + fs/nfs/nfs42proc.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/fs/nfs/nfs42proc.c b/fs/nfs/nfs42proc.c +index 6dab9e408372..21c9e97c3ba3 100644 +--- a/fs/nfs/nfs42proc.c ++++ b/fs/nfs/nfs42proc.c +@@ -1093,6 +1093,9 @@ static int _nfs42_proc_clone(struct rpc_message *msg, struct file *src_f, + &args.seq_args, &res.seq_res, 0); + trace_nfs4_clone(src_inode, dst_inode, &args, status); + if (status == 0) { ++ /* a zero-length count means clone to EOF in src */ ++ if (count == 0 && res.dst_fattr->valid & NFS_ATTR_FATTR_SIZE) ++ count = nfs_size_to_loff_t(res.dst_fattr->size) - dst_offset; + nfs42_copy_dest_done(dst_inode, dst_offset, count); + status = nfs_post_op_update_inode(dst_inode, res.dst_fattr); + } +-- +2.35.1 + diff --git a/queue-6.0/rdma-cma-use-output-interface-for-net_dev-check.patch b/queue-6.0/rdma-cma-use-output-interface-for-net_dev-check.patch new file mode 100644 index 00000000000..f27de92015d --- /dev/null +++ b/queue-6.0/rdma-cma-use-output-interface-for-net_dev-check.patch @@ -0,0 +1,49 @@ +From 034930e6e39abdbb8bfaafbf61a8784ee8888378 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 12 Oct 2022 16:15:42 +0200 +Subject: RDMA/cma: Use output interface for net_dev check +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Håkon Bugge + +[ Upstream commit eb83f502adb036cd56c27e13b9ca3b2aabfa790b ] + +Commit 27cfde795a96 ("RDMA/cma: Fix arguments order in net device +validation") swapped the src and dst addresses in the call to +validate_net_dev(). + +As a consequence, the test in validate_ipv4_net_dev() to see if the +net_dev is the right one, is incorrect for port 1 <-> 2 communication when +the ports are on the same sub-net. This is fixed by denoting the +flowi4_oif as the device instead of the incoming one. + +The bug has not been observed using IPv6 addresses. + +Fixes: 27cfde795a96 ("RDMA/cma: Fix arguments order in net device validation") +Signed-off-by: Håkon Bugge +Link: https://lore.kernel.org/r/20221012141542.16925-1-haakon.bugge@oracle.com +Reviewed-by: Leon Romanovsky +Signed-off-by: Leon Romanovsky +Signed-off-by: Sasha Levin +--- + drivers/infiniband/core/cma.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c +index be317f2665a9..ff8821f79fec 100644 +--- a/drivers/infiniband/core/cma.c ++++ b/drivers/infiniband/core/cma.c +@@ -1556,7 +1556,7 @@ static bool validate_ipv4_net_dev(struct net_device *net_dev, + return false; + + memset(&fl4, 0, sizeof(fl4)); +- fl4.flowi4_iif = net_dev->ifindex; ++ fl4.flowi4_oif = net_dev->ifindex; + fl4.daddr = daddr; + fl4.saddr = saddr; + +-- +2.35.1 + diff --git a/queue-6.0/rdma-core-fix-null-ptr-deref-in-ib_core_cleanup.patch b/queue-6.0/rdma-core-fix-null-ptr-deref-in-ib_core_cleanup.patch new file mode 100644 index 00000000000..a5bfc7f7307 --- /dev/null +++ b/queue-6.0/rdma-core-fix-null-ptr-deref-in-ib_core_cleanup.patch @@ -0,0 +1,89 @@ +From c5d120d0e42e8988bd93f550ab1a80c680581199 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 25 Oct 2022 10:41:46 +0800 +Subject: RDMA/core: Fix null-ptr-deref in ib_core_cleanup() + +From: Chen Zhongjin + +[ Upstream commit 07c0d131cc0fe1f3981a42958fc52d573d303d89 ] + +KASAN reported a null-ptr-deref error: + + KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] + CPU: 1 PID: 379 + Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) + RIP: 0010:destroy_workqueue+0x2f/0x740 + RSP: 0018:ffff888016137df8 EFLAGS: 00000202 + ... + Call Trace: + ib_core_cleanup+0xa/0xa1 [ib_core] + __do_sys_delete_module.constprop.0+0x34f/0x5b0 + do_syscall_64+0x3a/0x90 + entry_SYSCALL_64_after_hwframe+0x63/0xcd + RIP: 0033:0x7fa1a0d221b7 + ... + +It is because the fail of roce_gid_mgmt_init() is ignored: + + ib_core_init() + roce_gid_mgmt_init() + gid_cache_wq = alloc_ordered_workqueue # fail + ... + ib_core_cleanup() + roce_gid_mgmt_cleanup() + destroy_workqueue(gid_cache_wq) + # destroy an unallocated wq + +Fix this by catching the fail of roce_gid_mgmt_init() in ib_core_init(). + +Fixes: 03db3a2d81e6 ("IB/core: Add RoCE GID table management") +Signed-off-by: Chen Zhongjin +Link: https://lore.kernel.org/r/20221025024146.109137-1-chenzhongjin@huawei.com +Signed-off-by: Leon Romanovsky +Signed-off-by: Jason Gunthorpe +Signed-off-by: Sasha Levin +--- + drivers/infiniband/core/device.c | 10 +++++++++- + drivers/infiniband/core/nldev.c | 2 +- + 2 files changed, 10 insertions(+), 2 deletions(-) + +diff --git a/drivers/infiniband/core/device.c b/drivers/infiniband/core/device.c +index d275db195f1a..4053a09b8d33 100644 +--- a/drivers/infiniband/core/device.c ++++ b/drivers/infiniband/core/device.c +@@ -2815,10 +2815,18 @@ static int __init ib_core_init(void) + + nldev_init(); + rdma_nl_register(RDMA_NL_LS, ibnl_ls_cb_table); +- roce_gid_mgmt_init(); ++ ret = roce_gid_mgmt_init(); ++ if (ret) { ++ pr_warn("Couldn't init RoCE GID management\n"); ++ goto err_parent; ++ } + + return 0; + ++err_parent: ++ rdma_nl_unregister(RDMA_NL_LS); ++ nldev_exit(); ++ unregister_pernet_device(&rdma_dev_net_ops); + err_compat: + unregister_blocking_lsm_notifier(&ibdev_lsm_nb); + err_sa: +diff --git a/drivers/infiniband/core/nldev.c b/drivers/infiniband/core/nldev.c +index b92358f606d0..12dc97067ed2 100644 +--- a/drivers/infiniband/core/nldev.c ++++ b/drivers/infiniband/core/nldev.c +@@ -2537,7 +2537,7 @@ void __init nldev_init(void) + rdma_nl_register(RDMA_NL_NLDEV, nldev_cb_table); + } + +-void __exit nldev_exit(void) ++void nldev_exit(void) + { + rdma_nl_unregister(RDMA_NL_NLDEV); + } +-- +2.35.1 + diff --git a/queue-6.0/rdma-hns-disable-local-invalidate-operation.patch b/queue-6.0/rdma-hns-disable-local-invalidate-operation.patch new file mode 100644 index 00000000000..47af4e81d11 --- /dev/null +++ b/queue-6.0/rdma-hns-disable-local-invalidate-operation.patch @@ -0,0 +1,152 @@ +From e36ceba12eec88638cf9287195da759c5acd1426 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 24 Oct 2022 16:38:13 +0800 +Subject: RDMA/hns: Disable local invalidate operation + +From: Yangyang Li + +[ Upstream commit 9e272ed69ad6f6952fafd0599d6993575512408e ] + +When function reset and local invalidate are mixed, HNS RoCEE may hang. +Before introducing the cause of the problem, two hardware internal +concepts need to be introduced: + + 1. Execution queue: The queue of hardware execution instructions, + function reset and local invalidate are queued for execution in this + queue. + + 2.Local queue: A queue that stores local operation instructions. The + instructions in the local queue will be sent to the execution queue + for execution. The instructions in the local queue will not be removed + until the execution is completed. + +The reason for the problem is as follows: + + 1. There is a function reset instruction in the execution queue, which + is currently being executed. A necessary condition for the successful + execution of function reset is: the hardware pipeline needs to empty + the instructions that were not completed before; + + 2. A local invalidate instruction at the head of the local queue is + sent to the execution queue. Now there are two instructions in the + execution queue, the first is the function reset instruction, and the + second is the local invalidate instruction, which will be executed in + se quence; + + 3. The user has issued many local invalidate operations, causing the + local queue to be filled up. + + 4. The user still has a new local operation command and is queuing to + enter the local queue. But the local queue is full and cannot receive + new instructions, this instruction is temporarily stored at the + hardware pipeline. + + 5. The function reset has been waiting for the instruction before the + hardware pipeline stage is drained. The hardware pipeline stage also + caches a local invalidate instruction, so the function reset cannot be + completed, and the instructions after it cannot be executed. + +These factors together cause the execution logic deadlock of the hardware, +and the consequence is that RoCEE will not have any response. Considering +that the local operation command may potentially cause RoCEE to hang, this +feature is no longer supported. + +Fixes: e93df0108579 ("RDMA/hns: Support local invalidate for hip08 in kernel space") +Signed-off-by: Yangyang Li +Signed-off-by: Wenpeng Liang +Signed-off-by: Haoyue Xu +Link: https://lore.kernel.org/r/20221024083814.1089722-2-xuhaoyue1@hisilicon.com +Signed-off-by: Leon Romanovsky +Signed-off-by: Sasha Levin +--- + drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 11 ----------- + drivers/infiniband/hw/hns/hns_roce_hw_v2.h | 2 -- + 2 files changed, 13 deletions(-) + +diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c +index c780646bd60a..8507d788cc94 100644 +--- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c ++++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c +@@ -118,7 +118,6 @@ static const u32 hns_roce_op_code[] = { + HR_OPC_MAP(ATOMIC_CMP_AND_SWP, ATOM_CMP_AND_SWAP), + HR_OPC_MAP(ATOMIC_FETCH_AND_ADD, ATOM_FETCH_AND_ADD), + HR_OPC_MAP(SEND_WITH_INV, SEND_WITH_INV), +- HR_OPC_MAP(LOCAL_INV, LOCAL_INV), + HR_OPC_MAP(MASKED_ATOMIC_CMP_AND_SWP, ATOM_MSK_CMP_AND_SWAP), + HR_OPC_MAP(MASKED_ATOMIC_FETCH_AND_ADD, ATOM_MSK_FETCH_AND_ADD), + HR_OPC_MAP(REG_MR, FAST_REG_PMR), +@@ -560,9 +559,6 @@ static int set_rc_opcode(struct hns_roce_dev *hr_dev, + else + ret = -EOPNOTSUPP; + break; +- case IB_WR_LOCAL_INV: +- hr_reg_enable(rc_sq_wqe, RC_SEND_WQE_SO); +- fallthrough; + case IB_WR_SEND_WITH_INV: + rc_sq_wqe->inv_key = cpu_to_le32(wr->ex.invalidate_rkey); + break; +@@ -3226,7 +3222,6 @@ static int hns_roce_v2_write_mtpt(struct hns_roce_dev *hr_dev, + + hr_reg_write(mpt_entry, MPT_ST, V2_MPT_ST_VALID); + hr_reg_write(mpt_entry, MPT_PD, mr->pd); +- hr_reg_enable(mpt_entry, MPT_L_INV_EN); + + hr_reg_write_bool(mpt_entry, MPT_BIND_EN, + mr->access & IB_ACCESS_MW_BIND); +@@ -3317,7 +3312,6 @@ static int hns_roce_v2_frmr_write_mtpt(struct hns_roce_dev *hr_dev, + + hr_reg_enable(mpt_entry, MPT_RA_EN); + hr_reg_enable(mpt_entry, MPT_R_INV_EN); +- hr_reg_enable(mpt_entry, MPT_L_INV_EN); + + hr_reg_enable(mpt_entry, MPT_FRE); + hr_reg_clear(mpt_entry, MPT_MR_MW); +@@ -3349,7 +3343,6 @@ static int hns_roce_v2_mw_write_mtpt(void *mb_buf, struct hns_roce_mw *mw) + hr_reg_write(mpt_entry, MPT_PD, mw->pdn); + + hr_reg_enable(mpt_entry, MPT_R_INV_EN); +- hr_reg_enable(mpt_entry, MPT_L_INV_EN); + hr_reg_enable(mpt_entry, MPT_LW_EN); + + hr_reg_enable(mpt_entry, MPT_MR_MW); +@@ -3798,7 +3791,6 @@ static const u32 wc_send_op_map[] = { + HR_WC_OP_MAP(RDMA_READ, RDMA_READ), + HR_WC_OP_MAP(RDMA_WRITE, RDMA_WRITE), + HR_WC_OP_MAP(RDMA_WRITE_WITH_IMM, RDMA_WRITE), +- HR_WC_OP_MAP(LOCAL_INV, LOCAL_INV), + HR_WC_OP_MAP(ATOM_CMP_AND_SWAP, COMP_SWAP), + HR_WC_OP_MAP(ATOM_FETCH_AND_ADD, FETCH_ADD), + HR_WC_OP_MAP(ATOM_MSK_CMP_AND_SWAP, MASKED_COMP_SWAP), +@@ -3848,9 +3840,6 @@ static void fill_send_wc(struct ib_wc *wc, struct hns_roce_v2_cqe *cqe) + case HNS_ROCE_V2_WQE_OP_RDMA_WRITE_WITH_IMM: + wc->wc_flags |= IB_WC_WITH_IMM; + break; +- case HNS_ROCE_V2_WQE_OP_LOCAL_INV: +- wc->wc_flags |= IB_WC_WITH_INVALIDATE; +- break; + case HNS_ROCE_V2_WQE_OP_ATOM_CMP_AND_SWAP: + case HNS_ROCE_V2_WQE_OP_ATOM_FETCH_AND_ADD: + case HNS_ROCE_V2_WQE_OP_ATOM_MSK_CMP_AND_SWAP: +diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.h b/drivers/infiniband/hw/hns/hns_roce_hw_v2.h +index 64797109bab6..4544a8775ce5 100644 +--- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.h ++++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.h +@@ -182,7 +182,6 @@ enum { + HNS_ROCE_V2_WQE_OP_ATOM_MSK_CMP_AND_SWAP = 0x8, + HNS_ROCE_V2_WQE_OP_ATOM_MSK_FETCH_AND_ADD = 0x9, + HNS_ROCE_V2_WQE_OP_FAST_REG_PMR = 0xa, +- HNS_ROCE_V2_WQE_OP_LOCAL_INV = 0xb, + HNS_ROCE_V2_WQE_OP_BIND_MW = 0xc, + HNS_ROCE_V2_WQE_OP_MASK = 0x1f, + }; +@@ -916,7 +915,6 @@ struct hns_roce_v2_rc_send_wqe { + #define RC_SEND_WQE_OWNER RC_SEND_WQE_FIELD_LOC(7, 7) + #define RC_SEND_WQE_CQE RC_SEND_WQE_FIELD_LOC(8, 8) + #define RC_SEND_WQE_FENCE RC_SEND_WQE_FIELD_LOC(9, 9) +-#define RC_SEND_WQE_SO RC_SEND_WQE_FIELD_LOC(10, 10) + #define RC_SEND_WQE_SE RC_SEND_WQE_FIELD_LOC(11, 11) + #define RC_SEND_WQE_INLINE RC_SEND_WQE_FIELD_LOC(12, 12) + #define RC_SEND_WQE_WQE_INDEX RC_SEND_WQE_FIELD_LOC(30, 15) +-- +2.35.1 + diff --git a/queue-6.0/rdma-hns-fix-null-pointer-problem-in-free_mr_init.patch b/queue-6.0/rdma-hns-fix-null-pointer-problem-in-free_mr_init.patch new file mode 100644 index 00000000000..7e54a441009 --- /dev/null +++ b/queue-6.0/rdma-hns-fix-null-pointer-problem-in-free_mr_init.patch @@ -0,0 +1,65 @@ +From 6026022b596281db988ef794c308fc11721f0d0b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 24 Oct 2022 16:38:14 +0800 +Subject: RDMA/hns: Fix NULL pointer problem in free_mr_init() + +From: Yixing Liu + +[ Upstream commit 12bcaf87d8b66d8cd812479c8a6349dcb245375c ] + +Lock grab occurs in a concurrent scenario, resulting in stepping on a NULL +pointer. It should be init mutex_init() first before use the lock. + + Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 + Call trace: + __mutex_lock.constprop.0+0xd0/0x5c0 + __mutex_lock_slowpath+0x1c/0x2c + mutex_lock+0x44/0x50 + free_mr_send_cmd_to_hw+0x7c/0x1c0 [hns_roce_hw_v2] + hns_roce_v2_dereg_mr+0x30/0x40 [hns_roce_hw_v2] + hns_roce_dereg_mr+0x4c/0x130 [hns_roce_hw_v2] + ib_dereg_mr_user+0x54/0x124 + uverbs_free_mr+0x24/0x30 + destroy_hw_idr_uobject+0x38/0x74 + uverbs_destroy_uobject+0x48/0x1c4 + uobj_destroy+0x74/0xcc + ib_uverbs_cmd_verbs+0x368/0xbb0 + ib_uverbs_ioctl+0xec/0x1a4 + __arm64_sys_ioctl+0xb4/0x100 + invoke_syscall+0x50/0x120 + el0_svc_common.constprop.0+0x58/0x190 + do_el0_svc+0x30/0x90 + el0_svc+0x2c/0xb4 + el0t_64_sync_handler+0x1a4/0x1b0 + el0t_64_sync+0x19c/0x1a0 + +Fixes: 70f92521584f ("RDMA/hns: Use the reserved loopback QPs to free MR before destroying MPT") +Signed-off-by: Yixing Liu +Signed-off-by: Haoyue Xu +Link: https://lore.kernel.org/r/20221024083814.1089722-3-xuhaoyue1@hisilicon.com +Signed-off-by: Leon Romanovsky +Signed-off-by: Sasha Levin +--- + drivers/infiniband/hw/hns/hns_roce_hw_v2.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c +index 8507d788cc94..105888c6ccb7 100644 +--- a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c ++++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c +@@ -2805,8 +2805,12 @@ static int free_mr_modify_qp(struct hns_roce_dev *hr_dev) + + static int free_mr_init(struct hns_roce_dev *hr_dev) + { ++ struct hns_roce_v2_priv *priv = hr_dev->priv; ++ struct hns_roce_v2_free_mr *free_mr = &priv->free_mr; + int ret; + ++ mutex_init(&free_mr->mutex); ++ + ret = free_mr_alloc_res(hr_dev); + if (ret) + return ret; +-- +2.35.1 + diff --git a/queue-6.0/rdma-qedr-clean-up-work-queue-on-failure-in-qedr_all.patch b/queue-6.0/rdma-qedr-clean-up-work-queue-on-failure-in-qedr_all.patch new file mode 100644 index 00000000000..d681d750a22 --- /dev/null +++ b/queue-6.0/rdma-qedr-clean-up-work-queue-on-failure-in-qedr_all.patch @@ -0,0 +1,59 @@ +From 01700e1a2ab96f05d95ee2022b8186f6e1315cab Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 25 Oct 2022 18:32:32 +0300 +Subject: RDMA/qedr: clean up work queue on failure in qedr_alloc_resources() + +From: Dan Carpenter + +[ Upstream commit 7a47e077e503feb73d56e491ce89aa73b67a3972 ] + +Add a check for if create_singlethread_workqueue() fails and also destroy +the work queue on failure paths. + +Fixes: e411e0587e0d ("RDMA/qedr: Add iWARP connection management functions") +Signed-off-by: Dan Carpenter +Link: https://lore.kernel.org/r/Y1gBkDucQhhWj5YM@kili +Signed-off-by: Leon Romanovsky +Signed-off-by: Jason Gunthorpe +Signed-off-by: Sasha Levin +--- + drivers/infiniband/hw/qedr/main.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +diff --git a/drivers/infiniband/hw/qedr/main.c b/drivers/infiniband/hw/qedr/main.c +index 5152f10d2e6d..ba0c3e4c07d8 100644 +--- a/drivers/infiniband/hw/qedr/main.c ++++ b/drivers/infiniband/hw/qedr/main.c +@@ -344,6 +344,10 @@ static int qedr_alloc_resources(struct qedr_dev *dev) + if (IS_IWARP(dev)) { + xa_init(&dev->qps); + dev->iwarp_wq = create_singlethread_workqueue("qedr_iwarpq"); ++ if (!dev->iwarp_wq) { ++ rc = -ENOMEM; ++ goto err1; ++ } + } + + /* Allocate Status blocks for CNQ */ +@@ -351,7 +355,7 @@ static int qedr_alloc_resources(struct qedr_dev *dev) + GFP_KERNEL); + if (!dev->sb_array) { + rc = -ENOMEM; +- goto err1; ++ goto err_destroy_wq; + } + + dev->cnq_array = kcalloc(dev->num_cnq, +@@ -402,6 +406,9 @@ static int qedr_alloc_resources(struct qedr_dev *dev) + kfree(dev->cnq_array); + err2: + kfree(dev->sb_array); ++err_destroy_wq: ++ if (IS_IWARP(dev)) ++ destroy_workqueue(dev->iwarp_wq); + err1: + kfree(dev->sgid_tbl); + return rc; +-- +2.35.1 + diff --git a/queue-6.0/rdma-rxe-fix-mr-leak-in-respst_err_rnr.patch b/queue-6.0/rdma-rxe-fix-mr-leak-in-respst_err_rnr.patch new file mode 100644 index 00000000000..d409873bd87 --- /dev/null +++ b/queue-6.0/rdma-rxe-fix-mr-leak-in-respst_err_rnr.patch @@ -0,0 +1,60 @@ +From 5ffe1b9c58e2771dbf630743fc77d9bba830efb6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 13 Oct 2022 12:03:33 +0800 +Subject: RDMA/rxe: Fix mr leak in RESPST_ERR_RNR + +From: Li Zhijian + +[ Upstream commit b5f9a01fae42684648c2ee3cd9985f80c67ab9f7 ] + +rxe_recheck_mr() will increase mr's ref_cnt, so we should call rxe_put(mr) +to drop mr's ref_cnt in RESPST_ERR_RNR to avoid below warning: + + WARNING: CPU: 0 PID: 4156 at drivers/infiniband/sw/rxe/rxe_pool.c:259 __rxe_cleanup+0x1df/0x240 [rdma_rxe] +... + Call Trace: + rxe_dereg_mr+0x4c/0x60 [rdma_rxe] + ib_dereg_mr_user+0xa8/0x200 [ib_core] + ib_mr_pool_destroy+0x77/0xb0 [ib_core] + nvme_rdma_destroy_queue_ib+0x89/0x240 [nvme_rdma] + nvme_rdma_free_queue+0x40/0x50 [nvme_rdma] + nvme_rdma_teardown_io_queues.part.0+0xc3/0x120 [nvme_rdma] + nvme_rdma_error_recovery_work+0x4d/0xf0 [nvme_rdma] + process_one_work+0x582/0xa40 + ? pwq_dec_nr_in_flight+0x100/0x100 + ? rwlock_bug.part.0+0x60/0x60 + worker_thread+0x2a9/0x700 + ? process_one_work+0xa40/0xa40 + kthread+0x168/0x1a0 + ? kthread_complete_and_exit+0x20/0x20 + ret_from_fork+0x22/0x30 + +Link: https://lore.kernel.org/r/20221024052049.20577-1-lizhijian@fujitsu.com +Fixes: 8a1a0be894da ("RDMA/rxe: Replace mr by rkey in responder resources") +Signed-off-by: Li Zhijian +Signed-off-by: Jason Gunthorpe +Signed-off-by: Leon Romanovsky +Signed-off-by: Sasha Levin +--- + drivers/infiniband/sw/rxe/rxe_resp.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c b/drivers/infiniband/sw/rxe/rxe_resp.c +index 7c336db5cb54..f8b1d9fa0494 100644 +--- a/drivers/infiniband/sw/rxe/rxe_resp.c ++++ b/drivers/infiniband/sw/rxe/rxe_resp.c +@@ -806,8 +806,10 @@ static enum resp_states read_reply(struct rxe_qp *qp, + + skb = prepare_ack_packet(qp, &ack_pkt, opcode, payload, + res->cur_psn, AETH_ACK_UNLIMITED); +- if (!skb) ++ if (!skb) { ++ rxe_put(mr); + return RESPST_ERR_RNR; ++ } + + rxe_mr_copy(mr, res->read.va, payload_addr(&ack_pkt), + payload, RXE_FROM_MR_OBJ); +-- +2.35.1 + diff --git a/queue-6.0/rose-fix-null-pointer-dereference-in-rose_send_frame.patch b/queue-6.0/rose-fix-null-pointer-dereference-in-rose_send_frame.patch new file mode 100644 index 00000000000..294fc234b22 --- /dev/null +++ b/queue-6.0/rose-fix-null-pointer-dereference-in-rose_send_frame.patch @@ -0,0 +1,76 @@ +From a8f2f1d3c748fb20a2529e5a48a1d035403297c1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 29 Oct 2022 00:10:49 +0800 +Subject: rose: Fix NULL pointer dereference in rose_send_frame() + +From: Zhang Qilong + +[ Upstream commit e97c089d7a49f67027395ddf70bf327eeac2611e ] + +The syzkaller reported an issue: + +KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387] +CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0 +Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 +Workqueue: rcu_gp srcu_invoke_callbacks +RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101 +Call Trace: + + rose_transmit_clear_request+0x1d5/0x290 net/rose/rose_link.c:255 + rose_rx_call_request+0x4c0/0x1bc0 net/rose/af_rose.c:1009 + rose_loopback_timer+0x19e/0x590 net/rose/rose_loopback.c:111 + call_timer_fn+0x1a0/0x6b0 kernel/time/timer.c:1474 + expire_timers kernel/time/timer.c:1519 [inline] + __run_timers.part.0+0x674/0xa80 kernel/time/timer.c:1790 + __run_timers kernel/time/timer.c:1768 [inline] + run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1803 + __do_softirq+0x1d0/0x9c8 kernel/softirq.c:571 + [...] + + +It triggers NULL pointer dereference when 'neigh->dev->dev_addr' is +called in the rose_send_frame(). It's the first occurrence of the +`neigh` is in rose_loopback_timer() as `rose_loopback_neigh', and +the 'dev' in 'rose_loopback_neigh' is initialized sa nullptr. + +It had been fixed by commit 3b3fd068c56e3fbea30090859216a368398e39bf +("rose: Fix Null pointer dereference in rose_send_frame()") ever. +But it's introduced by commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8 +("rose: check NULL rose_loopback_neigh->loopback") again. + +We fix it by add NULL check in rose_transmit_clear_request(). When +the 'dev' in 'neigh' is NULL, we don't reply the request and just +clear it. + +syzkaller don't provide repro, and I provide a syz repro like: +r0 = syz_init_net_socket$bt_sco(0x1f, 0x5, 0x2) +ioctl$sock_inet_SIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\x00', 0x201}) +r1 = syz_init_net_socket$rose(0xb, 0x5, 0x0) +bind$rose(r1, &(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default, @null]}, 0x40) +connect$rose(r1, &(0x7f0000000240)=@short={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c) + +Fixes: 3c53cd65dece ("rose: check NULL rose_loopback_neigh->loopback") +Signed-off-by: Zhang Qilong +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/rose/rose_link.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/net/rose/rose_link.c b/net/rose/rose_link.c +index 8b96a56d3a49..0f77ae8ef944 100644 +--- a/net/rose/rose_link.c ++++ b/net/rose/rose_link.c +@@ -236,6 +236,9 @@ void rose_transmit_clear_request(struct rose_neigh *neigh, unsigned int lci, uns + unsigned char *dptr; + int len; + ++ if (!neigh->dev) ++ return; ++ + len = AX25_BPQ_HEADER_LEN + AX25_MAX_HEADER_LEN + ROSE_MIN_LEN + 3; + + if ((skb = alloc_skb(len, GFP_ATOMIC)) == NULL) +-- +2.35.1 + diff --git a/queue-6.0/series b/queue-6.0/series index 0bafa0a7971..ee58cc76993 100644 --- a/queue-6.0/series +++ b/queue-6.0/series @@ -3,3 +3,62 @@ usb-dwc3-gadget-don-t-delay-end-transfer-on-delayed_.patch scsi-qla2xxx-enhance-driver-tracing-with-separate-tu.patch scsi-qla2xxx-define-static-symbols.patch drm-i915-gvt-add-missing-vfio_unregister_group_dev-c.patch +rdma-cma-use-output-interface-for-net_dev-check.patch +ib-hfi1-correctly-move-list-in-sc_disable.patch +rdma-hns-disable-local-invalidate-operation.patch +rdma-hns-fix-null-pointer-problem-in-free_mr_init.patch +docs-process-howto-replace-c89-with-c11.patch +rdma-rxe-fix-mr-leak-in-respst_err_rnr.patch +nfsv4-fix-a-potential-state-reclaim-deadlock.patch +nfsv4.1-handle-reclaim_complete-trunking-errors.patch +nfsv4.1-we-must-always-send-reclaim_complete-after-a.patch +sunrpc-fix-null-ptr-deref-when-xps-sysfs-alloc-faile.patch +nfsv4.2-fixup-clone-dest-file-size-for-zero-length-c.patch +nfs4-fix-kmemleak-when-allocate-slot-failed.patch +net-dsa-fix-possible-memory-leaks-in-dsa_loop_init.patch +rdma-core-fix-null-ptr-deref-in-ib_core_cleanup.patch +rdma-qedr-clean-up-work-queue-on-failure-in-qedr_all.patch +tools-nolibc-fix-missing-strlen-definition-and-infin.patch +net-dsa-fall-back-to-default-tagger-if-we-can-t-load.patch +nfc-fdp-fix-potential-memory-leak-in-fdp_nci_send.patch +nfc-nxp-nci-fix-potential-memory-leak-in-nxp_nci_sen.patch +nfc-s3fwrn5-fix-potential-memory-leak-in-s3fwrn5_nci.patch +nfc-nfcmrvl-fix-potential-memory-leak-in-nfcmrvl_i2c.patch +net-fec-fix-improper-use-of-netdev_tx_busy.patch +ata-pata_legacy-fix-pdc20230_set_piomode.patch +ata-palmld-fix-return-value-check-in-palmld_pata_pro.patch +net-sched-fix-use-after-free-in-red_enqueue.patch +net-tun-fix-bugs-for-oversize-packet-when-napi-frags.patch +netfilter-nf_tables-netlink-notifier-might-race-to-r.patch +netfilter-nf_tables-release-flow-rule-object-from-co.patch +sfc-fix-an-error-handling-path-in-efx_pci_probe.patch +nfsd-fix-nfsd_file_unhash_and_dispose.patch +nfsd-fix-net-namespace-logic-in-__nfsd_file_cache_pu.patch +net-lan966x-fix-the-mtu-calculation.patch +net-lan966x-adjust-maximum-frame-size-when-vlan-is-e.patch +net-lan966x-fix-fdma-when-mtu-is-changed.patch +net-lan966x-fix-unmapping-of-received-frames-using-f.patch +ipvs-use-explicitly-signed-chars.patch +ipvs-fix-warning-in-__ip_vs_cleanup_batch.patch +ipvs-fix-warning-in-ip_vs_app_net_cleanup.patch +rose-fix-null-pointer-dereference-in-rose_send_frame.patch +misdn-fix-possible-memory-leak-in-misdn_register_dev.patch +isdn-misdn-netjet-fix-wrong-check-of-device-registra.patch +btrfs-fix-inode-list-leak-during-backref-walking-at-.patch +btrfs-fix-inode-list-leak-during-backref-walking-at-.patch-31031 +btrfs-fix-ulist-leaks-in-error-paths-of-qgroup-self-.patch +netfilter-ipset-enforce-documented-limit-to-prevent-.patch +bluetooth-l2cap-fix-use-after-free-caused-by-l2cap_r.patch +bluetooth-hci_conn-fix-cis-connection-dst_type-handl.patch +bluetooth-virtio_bt-use-skb_put-to-set-length.patch +bluetooth-l2cap-fix-use-after-free-in-l2cap_conn_del.patch +bluetooth-l2cap-fix-memory-leak-in-vhci_write.patch +bluetooth-hci_conn-fix-not-restoring-iso-buffer-coun.patch +net-mdio-fix-undefined-behavior-in-bit-shift-for-__m.patch +ibmvnic-free-rwi-on-reset-success.patch +stmmac-dwmac-loongson-fix-invalid-mdio_node.patch +net-smc-fix-possible-leaked-pernet-namespace-in-smc_.patch +net-neigh-fix-null-ptr-deref-in-neigh_table_clear.patch +bridge-fix-flushing-of-dynamic-fdb-entries.patch +ipv6-fix-warning-in-ip6_route_net_exit_late.patch +vsock-fix-possible-infinite-sleep-in-vsock_connectib.patch diff --git a/queue-6.0/sfc-fix-an-error-handling-path-in-efx_pci_probe.patch b/queue-6.0/sfc-fix-an-error-handling-path-in-efx_pci_probe.patch new file mode 100644 index 00000000000..76dc1ccf41a --- /dev/null +++ b/queue-6.0/sfc-fix-an-error-handling-path-in-efx_pci_probe.patch @@ -0,0 +1,54 @@ +From 7e9c2230280b6d1c3d0fd51a0f3d756465b24f0f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 29 Oct 2022 22:57:11 +0200 +Subject: sfc: Fix an error handling path in efx_pci_probe() + +From: Christophe JAILLET + +[ Upstream commit 6c412da54c80a54b1a8b7f89677f6e82f0fabec4 ] + +If an error occurs after the first kzalloc() the corresponding memory +allocation is never freed. + +Add the missing kfree() in the error handling path, as already done in the +remove() function. + +Fixes: 7e773594dada ("sfc: Separate efx_nic memory from net_device memory") +Signed-off-by: Christophe JAILLET +Acked-by: Martin Habets +Link: https://lore.kernel.org/r/dc114193121c52c8fa3779e49bdd99d4b41344a9.1667077009.git.christophe.jaillet@wanadoo.fr +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/sfc/efx.c | 8 ++++++-- + 1 file changed, 6 insertions(+), 2 deletions(-) + +diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c +index 153d68e29b8b..68a68477ab7b 100644 +--- a/drivers/net/ethernet/sfc/efx.c ++++ b/drivers/net/ethernet/sfc/efx.c +@@ -1059,8 +1059,10 @@ static int efx_pci_probe(struct pci_dev *pci_dev, + + /* Allocate and initialise a struct net_device */ + net_dev = alloc_etherdev_mq(sizeof(probe_data), EFX_MAX_CORE_TX_QUEUES); +- if (!net_dev) +- return -ENOMEM; ++ if (!net_dev) { ++ rc = -ENOMEM; ++ goto fail0; ++ } + probe_ptr = netdev_priv(net_dev); + *probe_ptr = probe_data; + efx->net_dev = net_dev; +@@ -1132,6 +1134,8 @@ static int efx_pci_probe(struct pci_dev *pci_dev, + WARN_ON(rc > 0); + netif_dbg(efx, drv, efx->net_dev, "initialisation failed. rc=%d\n", rc); + free_netdev(net_dev); ++ fail0: ++ kfree(probe_data); + return rc; + } + +-- +2.35.1 + diff --git a/queue-6.0/stmmac-dwmac-loongson-fix-invalid-mdio_node.patch b/queue-6.0/stmmac-dwmac-loongson-fix-invalid-mdio_node.patch new file mode 100644 index 00000000000..6f619974bb7 --- /dev/null +++ b/queue-6.0/stmmac-dwmac-loongson-fix-invalid-mdio_node.patch @@ -0,0 +1,57 @@ +From 96ea345412f60141aa82b03f76a8ad80ded709c1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 1 Nov 2022 14:02:18 +0800 +Subject: stmmac: dwmac-loongson: fix invalid mdio_node + +From: Liu Peibao + +[ Upstream commit 2ae34111fe4eebb69986f6490015b57c88804373 ] + +In current code "plat->mdio_node" is always NULL, the mdio +support is lost as there is no "mdio_bus_data". The original +driver could work as the "mdio" variable is never set to +false, which is described in commit ("stmmac: +dwmac-loongson: fix uninitialized variable ......"). And +after this commit merged, the "mdio" variable is always +false, causing the mdio supoort logic lost. + +Fixes: 30bba69d7db4 ("stmmac: pci: Add dwmac support for Loongson") +Signed-off-by: Liu Peibao +Reviewed-by: Andrew Lunn +Link: https://lore.kernel.org/r/20221101060218.16453-1-liupeibao@loongson.cn +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c | 7 ++----- + 1 file changed, 2 insertions(+), 5 deletions(-) + +diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c +index 017dbbda0c1c..79fa7870563b 100644 +--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c ++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c +@@ -51,7 +51,6 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id + struct stmmac_resources res; + struct device_node *np; + int ret, i, phy_mode; +- bool mdio = false; + + np = dev_of_node(&pdev->dev); + +@@ -69,12 +68,10 @@ static int loongson_dwmac_probe(struct pci_dev *pdev, const struct pci_device_id + if (!plat) + return -ENOMEM; + ++ plat->mdio_node = of_get_child_by_name(np, "mdio"); + if (plat->mdio_node) { +- dev_err(&pdev->dev, "Found MDIO subnode\n"); +- mdio = true; +- } ++ dev_info(&pdev->dev, "Found MDIO subnode\n"); + +- if (mdio) { + plat->mdio_bus_data = devm_kzalloc(&pdev->dev, + sizeof(*plat->mdio_bus_data), + GFP_KERNEL); +-- +2.35.1 + diff --git a/queue-6.0/sunrpc-fix-null-ptr-deref-when-xps-sysfs-alloc-faile.patch b/queue-6.0/sunrpc-fix-null-ptr-deref-when-xps-sysfs-alloc-faile.patch new file mode 100644 index 00000000000..fca76d45944 --- /dev/null +++ b/queue-6.0/sunrpc-fix-null-ptr-deref-when-xps-sysfs-alloc-faile.patch @@ -0,0 +1,91 @@ +From 80439069cf75d6b69abbc23924b8689e4c96496d Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 20 Oct 2022 11:42:17 +0800 +Subject: SUNRPC: Fix null-ptr-deref when xps sysfs alloc failed + +From: Zhang Xiaoxu + +[ Upstream commit cbdeaee94a415800c65a8c3fa04d9664a8b8fb3a ] + +There is a null-ptr-deref when xps sysfs alloc failed: + BUG: KASAN: null-ptr-deref in sysfs_do_create_link_sd+0x40/0xd0 + Read of size 8 at addr 0000000000000030 by task gssproxy/457 + + CPU: 5 PID: 457 Comm: gssproxy Not tainted 6.0.0-09040-g02357b27ee03 #9 + Call Trace: + + dump_stack_lvl+0x34/0x44 + kasan_report+0xa3/0x120 + sysfs_do_create_link_sd+0x40/0xd0 + rpc_sysfs_client_setup+0x161/0x1b0 + rpc_new_client+0x3fc/0x6e0 + rpc_create_xprt+0x71/0x220 + rpc_create+0x1d4/0x350 + gssp_rpc_create+0xc3/0x160 + set_gssp_clnt+0xbc/0x140 + write_gssp+0x116/0x1a0 + proc_reg_write+0xd6/0x130 + vfs_write+0x177/0x690 + ksys_write+0xb9/0x150 + do_syscall_64+0x35/0x80 + entry_SYSCALL_64_after_hwframe+0x46/0xb0 + +When the xprt_switch sysfs alloc failed, should not add xprt and +switch sysfs to it, otherwise, maybe null-ptr-deref; also initialize +the 'xps_sysfs' to NULL to avoid oops when destroy it. + +Fixes: 2a338a543163 ("sunrpc: add a symlink from rpc-client directory to the xprt_switch") +Fixes: d408ebe04ac5 ("sunrpc: add add sysfs directory per xprt under each xprt_switch") +Fixes: baea99445dd4 ("sunrpc: add xprt_switch direcotry to sunrpc's sysfs") +Signed-off-by: Zhang Xiaoxu +Signed-off-by: Anna Schumaker +Signed-off-by: Sasha Levin +--- + net/sunrpc/sysfs.c | 12 ++++++++++-- + 1 file changed, 10 insertions(+), 2 deletions(-) + +diff --git a/net/sunrpc/sysfs.c b/net/sunrpc/sysfs.c +index c65c90ad626a..c1f559892ae8 100644 +--- a/net/sunrpc/sysfs.c ++++ b/net/sunrpc/sysfs.c +@@ -518,13 +518,16 @@ void rpc_sysfs_client_setup(struct rpc_clnt *clnt, + struct net *net) + { + struct rpc_sysfs_client *rpc_client; ++ struct rpc_sysfs_xprt_switch *xswitch = ++ (struct rpc_sysfs_xprt_switch *)xprt_switch->xps_sysfs; ++ ++ if (!xswitch) ++ return; + + rpc_client = rpc_sysfs_client_alloc(rpc_sunrpc_client_kobj, + net, clnt->cl_clid); + if (rpc_client) { + char name[] = "switch"; +- struct rpc_sysfs_xprt_switch *xswitch = +- (struct rpc_sysfs_xprt_switch *)xprt_switch->xps_sysfs; + int ret; + + clnt->cl_sysfs = rpc_client; +@@ -558,6 +561,8 @@ void rpc_sysfs_xprt_switch_setup(struct rpc_xprt_switch *xprt_switch, + rpc_xprt_switch->xprt_switch = xprt_switch; + rpc_xprt_switch->xprt = xprt; + kobject_uevent(&rpc_xprt_switch->kobject, KOBJ_ADD); ++ } else { ++ xprt_switch->xps_sysfs = NULL; + } + } + +@@ -569,6 +574,9 @@ void rpc_sysfs_xprt_setup(struct rpc_xprt_switch *xprt_switch, + struct rpc_sysfs_xprt_switch *switch_obj = + (struct rpc_sysfs_xprt_switch *)xprt_switch->xps_sysfs; + ++ if (!switch_obj) ++ return; ++ + rpc_xprt = rpc_sysfs_xprt_alloc(&switch_obj->kobject, xprt, gfp_flags); + if (rpc_xprt) { + xprt->xprt_sysfs = rpc_xprt; +-- +2.35.1 + diff --git a/queue-6.0/tools-nolibc-fix-missing-strlen-definition-and-infin.patch b/queue-6.0/tools-nolibc-fix-missing-strlen-definition-and-infin.patch new file mode 100644 index 00000000000..05140fe82db --- /dev/null +++ b/queue-6.0/tools-nolibc-fix-missing-strlen-definition-and-infin.patch @@ -0,0 +1,95 @@ +From 75deb3bd05620447f0faa5307478821fa918f907 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 9 Oct 2022 20:29:36 +0200 +Subject: tools/nolibc: Fix missing strlen() definition and infinite loop with + gcc-12 + +From: Willy Tarreau + +[ Upstream commit bfc3b0f05653a28c8d41067a2aa3875d1f982e3e ] + +When built at -Os, gcc-12 recognizes an strlen() pattern in nolibc_strlen() +and replaces it with a jump to strlen(), which is not defined as a symbol +and breaks compilation. Worse, when the function is called strlen(), the +function is simply replaced with a jump to itself, hence becomes an +infinite loop. + +One way to avoid this is to always set -ffreestanding, but the calling +code doesn't know this and there's no way (either via attributes or +pragmas) to globally enable it from include files, effectively leaving +a painful situation for the caller. + +Alexey suggested to place an empty asm() statement inside the loop to +stop gcc from recognizing a well-known pattern, which happens to work +pretty fine. At least it allows us to make sure our local definition +is not replaced with a self jump. + +The function only needs to be renamed back to strlen() so that the symbol +exists, which implies that nolibc_strlen() which is used on variable +strings has to be declared as a macro that points back to it before the +strlen() macro is redifined. + +It was verified to produce valid code with gcc 3.4 to 12.1 at different +optimization levels, and both with constant and variable strings. + +In case this problem surfaces again in the future, an alternate approach +consisting in adding an optimize("no-tree-loop-distribute-patterns") +function attribute for gcc>=12 worked as well but is less pretty. + +Reported-by: kernel test robot +Link: https://lore.kernel.org/r/202210081618.754a77db-yujie.liu@intel.com +Fixes: 66b6f755ad45 ("rcutorture: Import a copy of nolibc") +Fixes: 96980b833a21 ("tools/nolibc/string: do not use __builtin_strlen() at -O0") +Cc: "Paul E. McKenney" +Cc: Alexey Dobriyan +Signed-off-by: Willy Tarreau +Signed-off-by: Paul E. McKenney +Signed-off-by: Sasha Levin +--- + tools/include/nolibc/string.h | 13 ++++++++----- + 1 file changed, 8 insertions(+), 5 deletions(-) + +diff --git a/tools/include/nolibc/string.h b/tools/include/nolibc/string.h +index bef35bee9c44..718a405ffbc3 100644 +--- a/tools/include/nolibc/string.h ++++ b/tools/include/nolibc/string.h +@@ -125,14 +125,18 @@ char *strcpy(char *dst, const char *src) + } + + /* this function is only used with arguments that are not constants or when +- * it's not known because optimizations are disabled. ++ * it's not known because optimizations are disabled. Note that gcc 12 ++ * recognizes an strlen() pattern and replaces it with a jump to strlen(), ++ * thus itself, hence the asm() statement below that's meant to disable this ++ * confusing practice. + */ + static __attribute__((unused)) +-size_t nolibc_strlen(const char *str) ++size_t strlen(const char *str) + { + size_t len; + +- for (len = 0; str[len]; len++); ++ for (len = 0; str[len]; len++) ++ asm(""); + return len; + } + +@@ -140,13 +144,12 @@ size_t nolibc_strlen(const char *str) + * the two branches, then will rely on an external definition of strlen(). + */ + #if defined(__OPTIMIZE__) ++#define nolibc_strlen(x) strlen(x) + #define strlen(str) ({ \ + __builtin_constant_p((str)) ? \ + __builtin_strlen((str)) : \ + nolibc_strlen((str)); \ + }) +-#else +-#define strlen(str) nolibc_strlen((str)) + #endif + + static __attribute__((unused)) +-- +2.35.1 + diff --git a/queue-6.0/vsock-fix-possible-infinite-sleep-in-vsock_connectib.patch b/queue-6.0/vsock-fix-possible-infinite-sleep-in-vsock_connectib.patch new file mode 100644 index 00000000000..07c491edf5f --- /dev/null +++ b/queue-6.0/vsock-fix-possible-infinite-sleep-in-vsock_connectib.patch @@ -0,0 +1,49 @@ +From d283c5305bd9334fa135c5761a03b83731429760 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 31 Oct 2022 19:17:06 -0700 +Subject: vsock: fix possible infinite sleep in vsock_connectible_wait_data() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Dexuan Cui + +[ Upstream commit 466a85336fee6e3b35eb97b8405a28302fd25809 ] + +Currently vsock_connectible_has_data() may miss a wakeup operation +between vsock_connectible_has_data() == 0 and the prepare_to_wait(). + +Fix the race by adding the process to the wait queue before checking +vsock_connectible_has_data(). + +Fixes: b3f7fd54881b ("af_vsock: separate wait data loop") +Signed-off-by: Dexuan Cui +Reviewed-by: Stefano Garzarella +Reported-by: Frédéric Dalleau +Tested-by: Frédéric Dalleau +Signed-off-by: Paolo Abeni +Signed-off-by: Sasha Levin +--- + net/vmw_vsock/af_vsock.c | 5 ++++- + 1 file changed, 4 insertions(+), 1 deletion(-) + +diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c +index b4ee163154a6..e5ab2418f9d6 100644 +--- a/net/vmw_vsock/af_vsock.c ++++ b/net/vmw_vsock/af_vsock.c +@@ -1894,8 +1894,11 @@ static int vsock_connectible_wait_data(struct sock *sk, + err = 0; + transport = vsk->transport; + +- while ((data = vsock_connectible_has_data(vsk)) == 0) { ++ while (1) { + prepare_to_wait(sk_sleep(sk), wait, TASK_INTERRUPTIBLE); ++ data = vsock_connectible_has_data(vsk); ++ if (data != 0) ++ break; + + if (sk->sk_err != 0 || + (sk->sk_shutdown & RCV_SHUTDOWN) || +-- +2.35.1 +