--- /dev/null
+From 266a8ffea23547a452905f6a0b5cb0e256733f99 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 20 Mar 2023 14:33:18 +0000
+Subject: atm: idt77252: fix kmemleak when rmmod idt77252
+
+From: Li Zetao <lizetao1@huawei.com>
+
+[ Upstream commit 4fe3c88552a3fbe1944426a4506a18cdeb457b5a ]
+
+There are memory leaks reported by kmemleak:
+
+ unreferenced object 0xffff888106500800 (size 128):
+ comm "modprobe", pid 1017, jiffies 4297787785 (age 67.152s)
+ hex dump (first 32 bytes):
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ backtrace:
+ [<00000000970ce626>] __kmem_cache_alloc_node+0x20c/0x380
+ [<00000000fb5f78d9>] kmalloc_trace+0x2f/0xb0
+ [<000000000e947e2a>] idt77252_init_one+0x2847/0x3c90 [idt77252]
+ [<000000006efb048e>] local_pci_probe+0xeb/0x1a0
+ ...
+
+ unreferenced object 0xffff888106500b00 (size 128):
+ comm "modprobe", pid 1017, jiffies 4297787785 (age 67.152s)
+ hex dump (first 32 bytes):
+ 00 20 3d 01 80 88 ff ff 00 20 3d 01 80 88 ff ff . =...... =.....
+ f0 23 3d 01 80 88 ff ff 00 20 3d 01 00 00 00 00 .#=...... =.....
+ backtrace:
+ [<00000000970ce626>] __kmem_cache_alloc_node+0x20c/0x380
+ [<00000000fb5f78d9>] kmalloc_trace+0x2f/0xb0
+ [<00000000f451c5be>] alloc_scq.constprop.0+0x4a/0x400 [idt77252]
+ [<00000000e6313849>] idt77252_init_one+0x28cf/0x3c90 [idt77252]
+
+The root cause is traced to the vc_maps which alloced in open_card_oam()
+are not freed in close_card_oam(). The vc_maps are used to record
+open connections, so when close a vc_map in close_card_oam(), the memory
+should be freed. Moreover, the ubr0 is not closed when close a idt77252
+device, leading to the memory leak of vc_map and scq_info.
+
+Fix them by adding kfree in close_card_oam() and implementing new
+close_card_ubr0() to close ubr0.
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Li Zetao <lizetao1@huawei.com>
+Reviewed-by: Francois Romieu <romieu@fr.zoreil.com>
+Link: https://lore.kernel.org/r/20230320143318.2644630-1-lizetao1@huawei.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/atm/idt77252.c | 11 +++++++++++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/drivers/atm/idt77252.c b/drivers/atm/idt77252.c
+index 18f386466f943..e7a6b4903f9c7 100644
+--- a/drivers/atm/idt77252.c
++++ b/drivers/atm/idt77252.c
+@@ -2912,6 +2912,7 @@ close_card_oam(struct idt77252_dev *card)
+
+ recycle_rx_pool_skb(card, &vc->rcv.rx_pool);
+ }
++ kfree(vc);
+ }
+ }
+ }
+@@ -2955,6 +2956,15 @@ open_card_ubr0(struct idt77252_dev *card)
+ return 0;
+ }
+
++static void
++close_card_ubr0(struct idt77252_dev *card)
++{
++ struct vc_map *vc = card->vcs[0];
++
++ free_scq(card, vc->scq);
++ kfree(vc);
++}
++
+ static int
+ idt77252_dev_open(struct idt77252_dev *card)
+ {
+@@ -3004,6 +3014,7 @@ static void idt77252_dev_close(struct atm_dev *dev)
+ struct idt77252_dev *card = dev->dev_data;
+ u32 conf;
+
++ close_card_ubr0(card);
+ close_card_oam(card);
+
+ conf = SAR_CFG_RXPTH | /* enable receive path */
+--
+2.39.2
+
--- /dev/null
+From 8b7ecd6faf311180eea27e1a7888ddd5c48ab352 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 8 Mar 2023 14:31:55 +0100
+Subject: Bluetooth: btqcomsmd: Fix command timeout after setting BD address
+
+From: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
+
+[ Upstream commit 5d44ab9e204200a78ad55cdf185aa2bb109b5950 ]
+
+On most devices using the btqcomsmd driver (e.g. the DragonBoard 410c
+and other devices based on the Qualcomm MSM8916/MSM8909/... SoCs)
+the Bluetooth firmware seems to become unresponsive for a while after
+setting the BD address. On recent kernel versions (at least 5.17+)
+this often causes timeouts for subsequent commands, e.g. the HCI reset
+sent by the Bluetooth core during initialization:
+
+ Bluetooth: hci0: Opcode 0x c03 failed: -110
+
+Unfortunately this behavior does not seem to be documented anywhere.
+Experimentation suggests that the minimum necessary delay to avoid
+the problem is ~150us. However, to be sure add a sleep for > 1ms
+in case it is a bit longer on other firmware versions.
+
+Older kernel versions are likely also affected, although perhaps with
+slightly different errors or less probability. Side effects can easily
+hide the issue in most cases, e.g. unrelated incoming interrupts that
+cause the necessary delay.
+
+Fixes: 1511cc750c3d ("Bluetooth: Introduce Qualcomm WCNSS SMD based HCI driver")
+Signed-off-by: Stephan Gerhold <stephan.gerhold@kernkonzept.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/bluetooth/btqcomsmd.c | 17 ++++++++++++++++-
+ 1 file changed, 16 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
+index 3a32150104c30..2f372ab7c9b78 100644
+--- a/drivers/bluetooth/btqcomsmd.c
++++ b/drivers/bluetooth/btqcomsmd.c
+@@ -134,6 +134,21 @@ static int btqcomsmd_setup(struct hci_dev *hdev)
+ return 0;
+ }
+
++static int btqcomsmd_set_bdaddr(struct hci_dev *hdev, const bdaddr_t *bdaddr)
++{
++ int ret;
++
++ ret = qca_set_bdaddr_rome(hdev, bdaddr);
++ if (ret)
++ return ret;
++
++ /* The firmware stops responding for a while after setting the bdaddr,
++ * causing timeouts for subsequent commands. Sleep a bit to avoid this.
++ */
++ usleep_range(1000, 10000);
++ return 0;
++}
++
+ static int btqcomsmd_probe(struct platform_device *pdev)
+ {
+ struct btqcomsmd *btq;
+@@ -174,7 +189,7 @@ static int btqcomsmd_probe(struct platform_device *pdev)
+ hdev->close = btqcomsmd_close;
+ hdev->send = btqcomsmd_send;
+ hdev->setup = btqcomsmd_setup;
+- hdev->set_bdaddr = qca_set_bdaddr_rome;
++ hdev->set_bdaddr = btqcomsmd_set_bdaddr;
+
+ ret = hci_register_dev(hdev);
+ if (ret < 0)
+--
+2.39.2
+
--- /dev/null
+From 00617cc8cc387af88c4f467ba526079fd0da7b23 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 9 Mar 2023 16:07:39 +0800
+Subject: Bluetooth: btsdio: fix use after free bug in btsdio_remove due to
+ unfinished work
+
+From: Zheng Wang <zyytlz.wz@163.com>
+
+[ Upstream commit 1e9ac114c4428fdb7ff4635b45d4f46017e8916f ]
+
+In btsdio_probe, &data->work was bound with btsdio_work.In
+btsdio_send_frame, it was started by schedule_work.
+
+If we call btsdio_remove with an unfinished job, there may
+be a race condition and cause UAF bug on hdev.
+
+Fixes: ddbaf13e3609 ("[Bluetooth] Add generic driver for Bluetooth SDIO devices")
+Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/bluetooth/btsdio.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/bluetooth/btsdio.c b/drivers/bluetooth/btsdio.c
+index 20142bc77554c..bd55bf7a9914c 100644
+--- a/drivers/bluetooth/btsdio.c
++++ b/drivers/bluetooth/btsdio.c
+@@ -353,6 +353,7 @@ static void btsdio_remove(struct sdio_func *func)
+
+ BT_DBG("func %p", func);
+
++ cancel_work_sync(&data->work);
+ if (!data)
+ return;
+
+--
+2.39.2
+
--- /dev/null
+From 35517328870ab41da23d24796cdec1be5397bee4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 20 Mar 2023 15:37:25 +0100
+Subject: bpf: Adjust insufficient default bpf_jit_limit
+
+From: Daniel Borkmann <daniel@iogearbox.net>
+
+[ Upstream commit 10ec8ca8ec1a2f04c4ed90897225231c58c124a7 ]
+
+We've seen recent AWS EKS (Kubernetes) user reports like the following:
+
+ After upgrading EKS nodes from v20230203 to v20230217 on our 1.24 EKS
+ clusters after a few days a number of the nodes have containers stuck
+ in ContainerCreating state or liveness/readiness probes reporting the
+ following error:
+
+ Readiness probe errored: rpc error: code = Unknown desc = failed to
+ exec in container: failed to start exec "4a11039f730203ffc003b7[...]":
+ OCI runtime exec failed: exec failed: unable to start container process:
+ unable to init seccomp: error loading seccomp filter into kernel:
+ error loading seccomp filter: errno 524: unknown
+
+ However, we had not been seeing this issue on previous AMIs and it only
+ started to occur on v20230217 (following the upgrade from kernel 5.4 to
+ 5.10) with no other changes to the underlying cluster or workloads.
+
+ We tried the suggestions from that issue (sysctl net.core.bpf_jit_limit=452534528)
+ which helped to immediately allow containers to be created and probes to
+ execute but after approximately a day the issue returned and the value
+ returned by cat /proc/vmallocinfo | grep bpf_jit | awk '{s+=$2} END {print s}'
+ was steadily increasing.
+
+I tested bpf tree to observe bpf_jit_charge_modmem, bpf_jit_uncharge_modmem
+their sizes passed in as well as bpf_jit_current under tcpdump BPF filter,
+seccomp BPF and native (e)BPF programs, and the behavior all looks sane
+and expected, that is nothing "leaking" from an upstream perspective.
+
+The bpf_jit_limit knob was originally added in order to avoid a situation
+where unprivileged applications loading BPF programs (e.g. seccomp BPF
+policies) consuming all the module memory space via BPF JIT such that loading
+of kernel modules would be prevented. The default limit was defined back in
+2018 and while good enough back then, we are generally seeing far more BPF
+consumers today.
+
+Adjust the limit for the BPF JIT pool from originally 1/4 to now 1/2 of the
+module memory space to better reflect today's needs and avoid more users
+running into potentially hard to debug issues.
+
+Fixes: fdadd04931c2 ("bpf: fix bpf_jit_limit knob for PAGE_SIZE >= 64K")
+Reported-by: Stephen Haynes <sh@synk.net>
+Reported-by: Lefteris Alexakis <lefteris.alexakis@kpn.com>
+Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
+Link: https://github.com/awslabs/amazon-eks-ami/issues/1179
+Link: https://github.com/awslabs/amazon-eks-ami/issues/1219
+Reviewed-by: Kuniyuki Iwashima <kuniyu@amazon.com>
+Link: https://lore.kernel.org/r/20230320143725.8394-1-daniel@iogearbox.net
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/bpf/core.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c
+index 2ca36bb440ded..1f586204673d5 100644
+--- a/kernel/bpf/core.c
++++ b/kernel/bpf/core.c
+@@ -555,7 +555,7 @@ static int __init bpf_jit_charge_init(void)
+ {
+ /* Only used as heuristic here to derive limit. */
+ bpf_jit_limit_max = bpf_jit_alloc_exec_limit();
+- bpf_jit_limit = min_t(u64, round_up(bpf_jit_limit_max >> 2,
++ bpf_jit_limit = min_t(u64, round_up(bpf_jit_limit_max >> 1,
+ PAGE_SIZE), LONG_MAX);
+ return 0;
+ }
+--
+2.39.2
+
--- /dev/null
+From f736bfc6d0238ca4b25dcfcdc515da78ba37bcfd Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 30 Nov 2022 16:09:11 +0100
+Subject: hvc/xen: prevent concurrent accesses to the shared ring
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Roger Pau Monne <roger.pau@citrix.com>
+
+[ Upstream commit 6214894f49a967c749ee6c07cb00f9cede748df4 ]
+
+The hvc machinery registers both a console and a tty device based on
+the hv ops provided by the specific implementation. Those two
+interfaces however have different locks, and there's no single locks
+that's shared between the tty and the console implementations, hence
+the driver needs to protect itself against concurrent accesses.
+Otherwise concurrent calls using the split interfaces are likely to
+corrupt the ring indexes, leaving the console unusable.
+
+Introduce a lock to xencons_info to serialize accesses to the shared
+ring. This is only required when using the shared memory console,
+concurrent accesses to the hypercall based console implementation are
+not an issue.
+
+Note the conditional logic in domU_read_console() is slightly modified
+so the notify_daemon() call can be done outside of the locked region:
+it's an hypercall and there's no need for it to be done with the lock
+held.
+
+Fixes: b536b4b96230 ('xen: use the hvc console infrastructure for Xen console')
+Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
+Reviewed-by: Juergen Gross <jgross@suse.com>
+Link: https://lore.kernel.org/r/20221130150919.13935-1-roger.pau@citrix.com
+Signed-off-by: Juergen Gross <jgross@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/tty/hvc/hvc_xen.c | 19 +++++++++++++++++--
+ 1 file changed, 17 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c
+index 625b5660b05fe..1031ec4a6fb99 100644
+--- a/drivers/tty/hvc/hvc_xen.c
++++ b/drivers/tty/hvc/hvc_xen.c
+@@ -56,6 +56,7 @@ struct xencons_info {
+ int irq;
+ int vtermno;
+ grant_ref_t gntref;
++ spinlock_t ring_lock;
+ };
+
+ static LIST_HEAD(xenconsoles);
+@@ -102,12 +103,15 @@ static int __write_console(struct xencons_info *xencons,
+ XENCONS_RING_IDX cons, prod;
+ struct xencons_interface *intf = xencons->intf;
+ int sent = 0;
++ unsigned long flags;
+
++ spin_lock_irqsave(&xencons->ring_lock, flags);
+ cons = intf->out_cons;
+ prod = intf->out_prod;
+ mb(); /* update queue values before going on */
+
+ if ((prod - cons) > sizeof(intf->out)) {
++ spin_unlock_irqrestore(&xencons->ring_lock, flags);
+ pr_err_once("xencons: Illegal ring page indices");
+ return -EINVAL;
+ }
+@@ -117,6 +121,7 @@ static int __write_console(struct xencons_info *xencons,
+
+ wmb(); /* write ring before updating pointer */
+ intf->out_prod = prod;
++ spin_unlock_irqrestore(&xencons->ring_lock, flags);
+
+ if (sent)
+ notify_daemon(xencons);
+@@ -159,16 +164,19 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
+ int recv = 0;
+ struct xencons_info *xencons = vtermno_to_xencons(vtermno);
+ unsigned int eoiflag = 0;
++ unsigned long flags;
+
+ if (xencons == NULL)
+ return -EINVAL;
+ intf = xencons->intf;
+
++ spin_lock_irqsave(&xencons->ring_lock, flags);
+ cons = intf->in_cons;
+ prod = intf->in_prod;
+ mb(); /* get pointers before reading ring */
+
+ if ((prod - cons) > sizeof(intf->in)) {
++ spin_unlock_irqrestore(&xencons->ring_lock, flags);
+ pr_err_once("xencons: Illegal ring page indices");
+ return -EINVAL;
+ }
+@@ -192,10 +200,13 @@ static int domU_read_console(uint32_t vtermno, char *buf, int len)
+ xencons->out_cons = intf->out_cons;
+ xencons->out_cons_same = 0;
+ }
++ if (!recv && xencons->out_cons_same++ > 1) {
++ eoiflag = XEN_EOI_FLAG_SPURIOUS;
++ }
++ spin_unlock_irqrestore(&xencons->ring_lock, flags);
++
+ if (recv) {
+ notify_daemon(xencons);
+- } else if (xencons->out_cons_same++ > 1) {
+- eoiflag = XEN_EOI_FLAG_SPURIOUS;
+ }
+
+ xen_irq_lateeoi(xencons->irq, eoiflag);
+@@ -252,6 +263,7 @@ static int xen_hvm_console_init(void)
+ info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
++ spin_lock_init(&info->ring_lock);
+ } else if (info->intf != NULL) {
+ /* already configured */
+ return 0;
+@@ -288,6 +300,7 @@ static int xen_hvm_console_init(void)
+
+ static int xencons_info_pv_init(struct xencons_info *info, int vtermno)
+ {
++ spin_lock_init(&info->ring_lock);
+ info->evtchn = xen_start_info->console.domU.evtchn;
+ /* GFN == MFN for PV guest */
+ info->intf = gfn_to_virt(xen_start_info->console.domU.mfn);
+@@ -338,6 +351,7 @@ static int xen_initial_domain_console_init(void)
+ info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
++ spin_lock_init(&info->ring_lock);
+ }
+
+ info->irq = bind_virq_to_irq(VIRQ_CONSOLE, 0, false);
+@@ -495,6 +509,7 @@ static int xencons_probe(struct xenbus_device *dev,
+ info = kzalloc(sizeof(struct xencons_info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
++ spin_lock_init(&info->ring_lock);
+ dev_set_drvdata(&dev->dev, info);
+ info->xbdev = dev;
+ info->vtermno = xenbus_devid_to_vtermno(devid);
+--
+2.39.2
+
--- /dev/null
+From dbf6c90f4c5ca2e3712774d0889076b0e15f6687 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 30 Jan 2023 16:32:47 +0100
+Subject: i2c: imx-lpi2c: check only for enabled interrupt flags
+
+From: Alexander Stein <alexander.stein@ew.tq-group.com>
+
+[ Upstream commit 1c7885004567e8951d65a983be095f254dd20bef ]
+
+When reading from I2C, the Tx watermark is set to 0. Unfortunately the
+TDF (transmit data flag) is enabled when Tx FIFO entries is equal or less
+than watermark. So it is set in every case, hence the reset default of 1.
+This results in the MSR_RDF _and_ MSR_TDF flags to be set thus trying
+to send Tx data on a read message.
+Mask the IRQ status to filter for wanted flags only.
+
+Fixes: a55fa9d0e42e ("i2c: imx-lpi2c: add low power i2c bus driver")
+Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
+Tested-by: Emanuele Ghidoli <emanuele.ghidoli@toradex.com>
+Signed-off-by: Wolfram Sang <wsa@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/i2c/busses/i2c-imx-lpi2c.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
+index e86801a631206..ca4d554126579 100644
+--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
++++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
+@@ -515,10 +515,14 @@ static int lpi2c_imx_xfer(struct i2c_adapter *adapter,
+ static irqreturn_t lpi2c_imx_isr(int irq, void *dev_id)
+ {
+ struct lpi2c_imx_struct *lpi2c_imx = dev_id;
++ unsigned int enabled;
+ unsigned int temp;
+
++ enabled = readl(lpi2c_imx->base + LPI2C_MIER);
++
+ lpi2c_imx_intctrl(lpi2c_imx, 0);
+ temp = readl(lpi2c_imx->base + LPI2C_MSR);
++ temp &= enabled;
+
+ if (temp & MSR_RDF)
+ lpi2c_imx_read_rxfifo(lpi2c_imx);
+--
+2.39.2
+
--- /dev/null
+From 044c7042e90f79a26f12cf0ff77f8799fa6a7c58 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 1 Mar 2023 12:59:07 +0100
+Subject: iavf: fix inverted Rx hash condition leading to disabled hash
+
+From: Alexander Lobakin <aleksander.lobakin@intel.com>
+
+[ Upstream commit 32d57f667f871bc5a8babbe27ea4c5e668ee0ea8 ]
+
+Condition, which checks whether the netdev has hashing enabled is
+inverted. Basically, the tagged commit effectively disabled passing flow
+hash from descriptor to skb, unless user *disables* it via Ethtool.
+Commit a876c3ba59a6 ("i40e/i40evf: properly report Rx packet hash")
+fixed this problem, but only for i40e.
+Invert the condition now in iavf and unblock passing hash to skbs again.
+
+Fixes: 857942fd1aa1 ("i40e: Fix Rx hash reported to the stack by our driver")
+Reviewed-by: Larysa Zaremba <larysa.zaremba@intel.com>
+Reviewed-by: Michal Kubiak <michal.kubiak@intel.com>
+Signed-off-by: Alexander Lobakin <aleksander.lobakin@intel.com>
+Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/i40evf/i40e_txrx.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
+index d74a307da8f18..d468960bcfd7f 100644
+--- a/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
++++ b/drivers/net/ethernet/intel/i40evf/i40e_txrx.c
+@@ -888,7 +888,7 @@ static inline void i40e_rx_hash(struct i40e_ring *ring,
+ cpu_to_le64((u64)I40E_RX_DESC_FLTSTAT_RSS_HASH <<
+ I40E_RX_DESC_STATUS_FLTSTAT_SHIFT);
+
+- if (ring->netdev->features & NETIF_F_RXHASH)
++ if (!(ring->netdev->features & NETIF_F_RXHASH))
+ return;
+
+ if ((rx_desc->wb.qword1.status_error_len & rss_mask) == rss_mask) {
+--
+2.39.2
+
--- /dev/null
+From 34733adff38172ee2f026b55fe8850830bc70970 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 1 Dec 2022 19:20:03 +0900
+Subject: igbvf: Regard vf reset nack as success
+
+From: Akihiko Odaki <akihiko.odaki@daynix.com>
+
+[ Upstream commit 02c83791ef969c6a8a150b4927193d0d0e50fb23 ]
+
+vf reset nack actually represents the reset operation itself is
+performed but no address is assigned. Therefore, e1000_reset_hw_vf
+should fill the "perm_addr" with the zero address and return success on
+such an occasion. This prevents its callers in netdev.c from saying PF
+still resetting, and instead allows them to correctly report that no
+address is assigned.
+
+Fixes: 6ddbc4cf1f4d ("igb: Indicate failure on vf reset for empty mac address")
+Signed-off-by: Akihiko Odaki <akihiko.odaki@daynix.com>
+Reviewed-by: Leon Romanovsky <leonro@nvidia.com>
+Tested-by: Marek Szlosek <marek.szlosek@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/igbvf/vf.c | 13 ++++++++++---
+ 1 file changed, 10 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/net/ethernet/intel/igbvf/vf.c b/drivers/net/ethernet/intel/igbvf/vf.c
+index 9577ccf4b26ad..7156684337e56 100644
+--- a/drivers/net/ethernet/intel/igbvf/vf.c
++++ b/drivers/net/ethernet/intel/igbvf/vf.c
+@@ -24,6 +24,8 @@
+
+ *******************************************************************************/
+
++#include <linux/etherdevice.h>
++
+ #include "vf.h"
+
+ static s32 e1000_check_for_link_vf(struct e1000_hw *hw);
+@@ -154,11 +156,16 @@ static s32 e1000_reset_hw_vf(struct e1000_hw *hw)
+ /* set our "perm_addr" based on info provided by PF */
+ ret_val = mbx->ops.read_posted(hw, msgbuf, 3);
+ if (!ret_val) {
+- if (msgbuf[0] == (E1000_VF_RESET |
+- E1000_VT_MSGTYPE_ACK))
++ switch (msgbuf[0]) {
++ case E1000_VF_RESET | E1000_VT_MSGTYPE_ACK:
+ memcpy(hw->mac.perm_addr, addr, ETH_ALEN);
+- else
++ break;
++ case E1000_VF_RESET | E1000_VT_MSGTYPE_NACK:
++ eth_zero_addr(hw->mac.perm_addr);
++ break;
++ default:
+ ret_val = -E1000_ERR_MAC_INIT;
++ }
+ }
+ }
+
+--
+2.39.2
+
--- /dev/null
+From 651b11e2913fe2f58fad8d558aacc05bcad5370c Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 22 Nov 2022 10:28:52 +0800
+Subject: intel/igbvf: free irq on the error path in igbvf_request_msix()
+
+From: Gaosheng Cui <cuigaosheng1@huawei.com>
+
+[ Upstream commit 85eb39bb39cbb5c086df1e19ba67cc1366693a77 ]
+
+In igbvf_request_msix(), irqs have not been freed on the err path,
+we need to free it. Fix it.
+
+Fixes: d4e0fe01a38a ("igbvf: add new driver to support 82576 virtual functions")
+Signed-off-by: Gaosheng Cui <cuigaosheng1@huawei.com>
+Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
+Tested-by: Marek Szlosek <marek.szlosek@intel.com>
+Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/intel/igbvf/netdev.c | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/intel/igbvf/netdev.c b/drivers/net/ethernet/intel/igbvf/netdev.c
+index 98fd214f2c42b..cc1a608904ab8 100644
+--- a/drivers/net/ethernet/intel/igbvf/netdev.c
++++ b/drivers/net/ethernet/intel/igbvf/netdev.c
+@@ -1093,7 +1093,7 @@ static int igbvf_request_msix(struct igbvf_adapter *adapter)
+ igbvf_intr_msix_rx, 0, adapter->rx_ring->name,
+ netdev);
+ if (err)
+- goto out;
++ goto free_irq_tx;
+
+ adapter->rx_ring->itr_register = E1000_EITR(vector);
+ adapter->rx_ring->itr_val = adapter->current_itr;
+@@ -1102,10 +1102,14 @@ static int igbvf_request_msix(struct igbvf_adapter *adapter)
+ err = request_irq(adapter->msix_entries[vector].vector,
+ igbvf_msix_other, 0, netdev->name, netdev);
+ if (err)
+- goto out;
++ goto free_irq_rx;
+
+ igbvf_configure_msix(adapter);
+ return 0;
++free_irq_rx:
++ free_irq(adapter->msix_entries[--vector].vector, netdev);
++free_irq_tx:
++ free_irq(adapter->msix_entries[--vector].vector, netdev);
+ out:
+ return err;
+ }
+--
+2.39.2
+
--- /dev/null
+From a8d439f76ea1e9a572f0d6c435ac0dfdb5f31c1d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 22 Mar 2023 14:20:57 +0800
+Subject: net: mdio: thunder: Add missing fwnode_handle_put()
+
+From: Liang He <windhl@126.com>
+
+[ Upstream commit b1de5c78ebe9858ccec9d49af2f76724f1d47e3e ]
+
+In device_for_each_child_node(), we should add fwnode_handle_put()
+when break out of the iteration device_for_each_child_node()
+as it will automatically increase and decrease the refcounter.
+
+Fixes: 379d7ac7ca31 ("phy: mdio-thunder: Add driver for Cavium Thunder SoC MDIO buses.")
+Signed-off-by: Liang He <windhl@126.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/phy/mdio-thunder.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/net/phy/mdio-thunder.c b/drivers/net/phy/mdio-thunder.c
+index c0c922eff760c..959bf342133a7 100644
+--- a/drivers/net/phy/mdio-thunder.c
++++ b/drivers/net/phy/mdio-thunder.c
+@@ -107,6 +107,7 @@ static int thunder_mdiobus_pci_probe(struct pci_dev *pdev,
+ if (i >= ARRAY_SIZE(nexus->buses))
+ break;
+ }
++ fwnode_handle_put(fwn);
+ return 0;
+
+ err_release_regions:
+--
+2.39.2
+
--- /dev/null
+From 08254250068c3f9b3150860dd0163f0b38417d7d Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 15 Mar 2023 11:04:38 +0200
+Subject: net/mlx5: Read the TC mapping of all priorities on ETS query
+
+From: Maher Sanalla <msanalla@nvidia.com>
+
+[ Upstream commit 44d553188c38ac74b799dfdcebafef2f7bb70942 ]
+
+When ETS configurations are queried by the user to get the mapping
+assignment between packet priority and traffic class, only priorities up
+to maximum TCs are queried from QTCT register in FW to retrieve their
+assigned TC, leaving the rest of the priorities mapped to the default
+TC #0 which might be misleading.
+
+Fix by querying the TC mapping of all priorities on each ETS query,
+regardless of the maximum number of TCs configured in FW.
+
+Fixes: 820c2c5e773d ("net/mlx5e: Read ETS settings directly from firmware")
+Signed-off-by: Maher Sanalla <msanalla@nvidia.com>
+Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
+Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
+index a5dd99aaf3212..9ebd43bcc19a0 100644
+--- a/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/en_dcbnl.c
+@@ -99,12 +99,14 @@ static int mlx5e_dcbnl_ieee_getets(struct net_device *netdev,
+ if (!MLX5_CAP_GEN(priv->mdev, ets))
+ return -EOPNOTSUPP;
+
+- ets->ets_cap = mlx5_max_tc(priv->mdev) + 1;
+- for (i = 0; i < ets->ets_cap; i++) {
++ for (i = 0; i < IEEE_8021QAZ_MAX_TCS; i++) {
+ err = mlx5_query_port_prio_tc(mdev, i, &ets->prio_tc[i]);
+ if (err)
+ return err;
++ }
+
++ ets->ets_cap = mlx5_max_tc(priv->mdev) + 1;
++ for (i = 0; i < ets->ets_cap; i++) {
+ err = mlx5_query_port_tc_group(mdev, i, &tc_group[i]);
+ if (err)
+ return err;
+--
+2.39.2
+
--- /dev/null
+From 912339e0c5f2cefde3308be466c5214bd7c4e9b3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 18 Mar 2023 17:39:16 +0000
+Subject: net/ps3_gelic_net: Fix RX sk_buff length
+
+From: Geoff Levand <geoff@infradead.org>
+
+[ Upstream commit 19b3bb51c3bc288b3f2c6f8c4450b0f548320625 ]
+
+The Gelic Ethernet device needs to have the RX sk_buffs aligned to
+GELIC_NET_RXBUF_ALIGN, and also the length of the RX sk_buffs must
+be a multiple of GELIC_NET_RXBUF_ALIGN.
+
+The current Gelic Ethernet driver was not allocating sk_buffs large
+enough to allow for this alignment.
+
+Also, correct the maximum and minimum MTU sizes, and add a new
+preprocessor macro for the maximum frame size, GELIC_NET_MAX_FRAME.
+
+Fixes various randomly occurring runtime network errors.
+
+Fixes: 02c1889166b4 ("ps3: gigabit ethernet driver for PS3, take3")
+Signed-off-by: Geoff Levand <geoff@infradead.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/toshiba/ps3_gelic_net.c | 19 ++++++++++---------
+ drivers/net/ethernet/toshiba/ps3_gelic_net.h | 5 +++--
+ 2 files changed, 13 insertions(+), 11 deletions(-)
+
+diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+index 75237c81c63d6..67f61379ba672 100644
+--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
++++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+@@ -378,28 +378,29 @@ static int gelic_card_init_chain(struct gelic_card *card,
+ *
+ * allocates a new rx skb, iommu-maps it and attaches it to the descriptor.
+ * Activate the descriptor state-wise
++ *
++ * Gelic RX sk_buffs must be aligned to GELIC_NET_RXBUF_ALIGN and the length
++ * must be a multiple of GELIC_NET_RXBUF_ALIGN.
+ */
+ static int gelic_descr_prepare_rx(struct gelic_card *card,
+ struct gelic_descr *descr)
+ {
++ static const unsigned int rx_skb_size =
++ ALIGN(GELIC_NET_MAX_FRAME, GELIC_NET_RXBUF_ALIGN) +
++ GELIC_NET_RXBUF_ALIGN - 1;
+ int offset;
+- unsigned int bufsize;
+
+ if (gelic_descr_get_status(descr) != GELIC_DESCR_DMA_NOT_IN_USE)
+ dev_info(ctodev(card), "%s: ERROR status\n", __func__);
+- /* we need to round up the buffer size to a multiple of 128 */
+- bufsize = ALIGN(GELIC_NET_MAX_MTU, GELIC_NET_RXBUF_ALIGN);
+
+- /* and we need to have it 128 byte aligned, therefore we allocate a
+- * bit more */
+- descr->skb = dev_alloc_skb(bufsize + GELIC_NET_RXBUF_ALIGN - 1);
++ descr->skb = netdev_alloc_skb(*card->netdev, rx_skb_size);
+ if (!descr->skb) {
+ descr->buf_addr = 0; /* tell DMAC don't touch memory */
+ dev_info(ctodev(card),
+ "%s:allocate skb failed !!\n", __func__);
+ return -ENOMEM;
+ }
+- descr->buf_size = cpu_to_be32(bufsize);
++ descr->buf_size = cpu_to_be32(rx_skb_size);
+ descr->dmac_cmd_status = 0;
+ descr->result_size = 0;
+ descr->valid_size = 0;
+@@ -412,7 +413,7 @@ static int gelic_descr_prepare_rx(struct gelic_card *card,
+ /* io-mmu-map the skb */
+ descr->buf_addr = cpu_to_be32(dma_map_single(ctodev(card),
+ descr->skb->data,
+- GELIC_NET_MAX_MTU,
++ GELIC_NET_MAX_FRAME,
+ DMA_FROM_DEVICE));
+ if (!descr->buf_addr) {
+ dev_kfree_skb_any(descr->skb);
+@@ -930,7 +931,7 @@ static void gelic_net_pass_skb_up(struct gelic_descr *descr,
+ data_error = be32_to_cpu(descr->data_error);
+ /* unmap skb buffer */
+ dma_unmap_single(ctodev(card), be32_to_cpu(descr->buf_addr),
+- GELIC_NET_MAX_MTU,
++ GELIC_NET_MAX_FRAME,
+ DMA_FROM_DEVICE);
+
+ skb_put(skb, be32_to_cpu(descr->valid_size)?
+diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.h b/drivers/net/ethernet/toshiba/ps3_gelic_net.h
+index fbbf9b54b173b..0e592fc19f6c5 100644
+--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.h
++++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.h
+@@ -32,8 +32,9 @@
+ #define GELIC_NET_RX_DESCRIPTORS 128 /* num of descriptors */
+ #define GELIC_NET_TX_DESCRIPTORS 128 /* num of descriptors */
+
+-#define GELIC_NET_MAX_MTU VLAN_ETH_FRAME_LEN
+-#define GELIC_NET_MIN_MTU VLAN_ETH_ZLEN
++#define GELIC_NET_MAX_FRAME 2312
++#define GELIC_NET_MAX_MTU 2294
++#define GELIC_NET_MIN_MTU 64
+ #define GELIC_NET_RXBUF_ALIGN 128
+ #define GELIC_CARD_RX_CSUM_DEFAULT 1 /* hw chksum */
+ #define GELIC_NET_WATCHDOG_TIMEOUT 5*HZ
+--
+2.39.2
+
--- /dev/null
+From 45b35394ac6f7f028edd0d2ec4959e2ebe6f141b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 18 Mar 2023 17:39:16 +0000
+Subject: net/ps3_gelic_net: Use dma_mapping_error
+
+From: Geoff Levand <geoff@infradead.org>
+
+[ Upstream commit bebe933d35a63d4f042fbf4dce4f22e689ba0fcd ]
+
+The current Gelic Etherenet driver was checking the return value of its
+dma_map_single call, and not using the dma_mapping_error() routine.
+
+Fixes runtime problems like these:
+
+ DMA-API: ps3_gelic_driver sb_05: device driver failed to check map error
+ WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:1027 .check_unmap+0x888/0x8dc
+
+Fixes: 02c1889166b4 ("ps3: gigabit ethernet driver for PS3, take3")
+Reviewed-by: Alexander Duyck <alexanderduyck@fb.com>
+Signed-off-by: Geoff Levand <geoff@infradead.org>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/toshiba/ps3_gelic_net.c | 24 +++++++++++---------
+ 1 file changed, 13 insertions(+), 11 deletions(-)
+
+diff --git a/drivers/net/ethernet/toshiba/ps3_gelic_net.c b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+index 67f61379ba672..572294678faf0 100644
+--- a/drivers/net/ethernet/toshiba/ps3_gelic_net.c
++++ b/drivers/net/ethernet/toshiba/ps3_gelic_net.c
+@@ -330,15 +330,17 @@ static int gelic_card_init_chain(struct gelic_card *card,
+
+ /* set up the hardware pointers in each descriptor */
+ for (i = 0; i < no; i++, descr++) {
++ dma_addr_t cpu_addr;
++
+ gelic_descr_set_status(descr, GELIC_DESCR_DMA_NOT_IN_USE);
+- descr->bus_addr =
+- dma_map_single(ctodev(card), descr,
+- GELIC_DESCR_SIZE,
+- DMA_BIDIRECTIONAL);
+
+- if (!descr->bus_addr)
++ cpu_addr = dma_map_single(ctodev(card), descr,
++ GELIC_DESCR_SIZE, DMA_BIDIRECTIONAL);
++
++ if (dma_mapping_error(ctodev(card), cpu_addr))
+ goto iommu_error;
+
++ descr->bus_addr = cpu_to_be32(cpu_addr);
+ descr->next = descr + 1;
+ descr->prev = descr - 1;
+ }
+@@ -388,6 +390,7 @@ static int gelic_descr_prepare_rx(struct gelic_card *card,
+ static const unsigned int rx_skb_size =
+ ALIGN(GELIC_NET_MAX_FRAME, GELIC_NET_RXBUF_ALIGN) +
+ GELIC_NET_RXBUF_ALIGN - 1;
++ dma_addr_t cpu_addr;
+ int offset;
+
+ if (gelic_descr_get_status(descr) != GELIC_DESCR_DMA_NOT_IN_USE)
+@@ -411,11 +414,10 @@ static int gelic_descr_prepare_rx(struct gelic_card *card,
+ if (offset)
+ skb_reserve(descr->skb, GELIC_NET_RXBUF_ALIGN - offset);
+ /* io-mmu-map the skb */
+- descr->buf_addr = cpu_to_be32(dma_map_single(ctodev(card),
+- descr->skb->data,
+- GELIC_NET_MAX_FRAME,
+- DMA_FROM_DEVICE));
+- if (!descr->buf_addr) {
++ cpu_addr = dma_map_single(ctodev(card), descr->skb->data,
++ GELIC_NET_MAX_FRAME, DMA_FROM_DEVICE);
++ descr->buf_addr = cpu_to_be32(cpu_addr);
++ if (dma_mapping_error(ctodev(card), cpu_addr)) {
+ dev_kfree_skb_any(descr->skb);
+ descr->skb = NULL;
+ dev_info(ctodev(card),
+@@ -795,7 +797,7 @@ static int gelic_descr_prepare_tx(struct gelic_card *card,
+
+ buf = dma_map_single(ctodev(card), skb->data, skb->len, DMA_TO_DEVICE);
+
+- if (!buf) {
++ if (dma_mapping_error(ctodev(card), buf)) {
+ dev_err(ctodev(card),
+ "dma map 2 failed (%p, %i). Dropping packet\n",
+ skb->data, skb->len);
+--
+2.39.2
+
--- /dev/null
+From 7c025c1f8330e27af3821d8ad12d621f8ed2c76b Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sat, 18 Mar 2023 16:05:26 +0800
+Subject: net: qcom/emac: Fix use after free bug in emac_remove due to race
+ condition
+
+From: Zheng Wang <zyytlz.wz@163.com>
+
+[ Upstream commit 6b6bc5b8bd2d4ca9e1efa9ae0f98a0b0687ace75 ]
+
+In emac_probe, &adpt->work_thread is bound with
+emac_work_thread. Then it will be started by timeout
+handler emac_tx_timeout or a IRQ handler emac_isr.
+
+If we remove the driver which will call emac_remove
+ to make cleanup, there may be a unfinished work.
+
+The possible sequence is as follows:
+
+Fix it by finishing the work before cleanup in the emac_remove
+and disable timeout response.
+
+CPU0 CPU1
+
+ |emac_work_thread
+emac_remove |
+free_netdev |
+kfree(netdev); |
+ |emac_reinit_locked
+ |emac_mac_down
+ |//use netdev
+Fixes: b9b17debc69d ("net: emac: emac gigabit ethernet controller driver")
+Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
+
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/qualcomm/emac/emac.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c b/drivers/net/ethernet/qualcomm/emac/emac.c
+index cae570f1d7e12..527c4dd250833 100644
+--- a/drivers/net/ethernet/qualcomm/emac/emac.c
++++ b/drivers/net/ethernet/qualcomm/emac/emac.c
+@@ -758,9 +758,15 @@ static int emac_remove(struct platform_device *pdev)
+ struct net_device *netdev = dev_get_drvdata(&pdev->dev);
+ struct emac_adapter *adpt = netdev_priv(netdev);
+
++ netif_carrier_off(netdev);
++ netif_tx_disable(netdev);
++
+ unregister_netdev(netdev);
+ netif_napi_del(&adpt->rx_q.napi);
+
++ free_irq(adpt->irq.irq, &adpt->irq);
++ cancel_work_sync(&adpt->work_thread);
++
+ emac_clks_teardown(adpt);
+
+ put_device(&adpt->phydev->mdio.dev);
+--
+2.39.2
+
--- /dev/null
+From 157815d287a4f04a70ea677a6ccb6f6efe85e1d0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 16 Mar 2023 11:19:54 +0100
+Subject: net: usb: smsc95xx: Limit packet length to skb->len
+
+From: Szymon Heidrich <szymon.heidrich@gmail.com>
+
+[ Upstream commit ff821092cf02a70c2bccd2d19269f01e29aa52cf ]
+
+Packet length retrieved from descriptor may be larger than
+the actual socket buffer length. In such case the cloned
+skb passed up the network stack will leak kernel memory contents.
+
+Fixes: 2f7ca802bdae ("net: Add SMSC LAN9500 USB2.0 10/100 ethernet adapter driver")
+Signed-off-by: Szymon Heidrich <szymon.heidrich@gmail.com>
+Reviewed-by: Jakub Kicinski <kuba@kernel.org>
+Link: https://lore.kernel.org/r/20230316101954.75836-1-szymon.heidrich@gmail.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/usb/smsc95xx.c | 6 ++++++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
+index bc6bcea67bff3..b1e3ec3dcac3b 100644
+--- a/drivers/net/usb/smsc95xx.c
++++ b/drivers/net/usb/smsc95xx.c
+@@ -1950,6 +1950,12 @@ static int smsc95xx_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
+ size = (u16)((header & RX_STS_FL_) >> 16);
+ align_count = (4 - ((size + NET_IP_ALIGN) % 4)) % 4;
+
++ if (unlikely(size > skb->len)) {
++ netif_dbg(dev, rx_err, dev->net,
++ "size err header=0x%08x\n", header);
++ return 0;
++ }
++
+ if (unlikely(header & RX_STS_ES_)) {
+ netif_dbg(dev, rx_err, dev->net,
+ "Error header=0x%08x\n", header);
+--
+2.39.2
+
--- /dev/null
+From 04f5fe0be7ea16b50af1c3f1639c825f6576efce Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 12 Mar 2023 01:46:50 +0800
+Subject: power: supply: da9150: Fix use after free bug in
+ da9150_charger_remove due to race condition
+
+From: Zheng Wang <zyytlz.wz@163.com>
+
+[ Upstream commit 06615d11cc78162dfd5116efb71f29eb29502d37 ]
+
+In da9150_charger_probe, &charger->otg_work is bound with
+da9150_charger_otg_work. da9150_charger_otg_ncb may be
+called to start the work.
+
+If we remove the module which will call da9150_charger_remove
+to make cleanup, there may be a unfinished work. The possible
+sequence is as follows:
+
+Fix it by canceling the work before cleanup in the da9150_charger_remove
+
+CPU0 CPUc1
+
+ |da9150_charger_otg_work
+da9150_charger_remove |
+power_supply_unregister |
+device_unregister |
+power_supply_dev_release|
+kfree(psy) |
+ |
+ | power_supply_changed(charger->usb);
+ | //use
+
+Fixes: c1a281e34dae ("power: Add support for DA9150 Charger")
+Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
+Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/power/supply/da9150-charger.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/drivers/power/supply/da9150-charger.c b/drivers/power/supply/da9150-charger.c
+index 60099815296e7..b2d38eb32288a 100644
+--- a/drivers/power/supply/da9150-charger.c
++++ b/drivers/power/supply/da9150-charger.c
+@@ -666,6 +666,7 @@ static int da9150_charger_remove(struct platform_device *pdev)
+
+ if (!IS_ERR_OR_NULL(charger->usb_phy))
+ usb_unregister_notifier(charger->usb_phy, &charger->otg_nb);
++ cancel_work_sync(&charger->otg_work);
+
+ power_supply_unregister(charger->battery);
+ power_supply_unregister(charger->usb);
+--
+2.39.2
+
--- /dev/null
+From f09b6d752886053bf6867cefcc593529422db5fa Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 16 Mar 2023 13:29:21 +0300
+Subject: qed/qed_sriov: guard against NULL derefs from qed_iov_get_vf_info
+
+From: Daniil Tatianin <d-tatianin@yandex-team.ru>
+
+[ Upstream commit 25143b6a01d0cc5319edd3de22ffa2578b045550 ]
+
+We have to make sure that the info returned by the helper is valid
+before using it.
+
+Found by Linux Verification Center (linuxtesting.org) with the SVACE
+static analysis tool.
+
+Fixes: f990c82c385b ("qed*: Add support for ndo_set_vf_trust")
+Fixes: 733def6a04bf ("qed*: IOV link control")
+Signed-off-by: Daniil Tatianin <d-tatianin@yandex-team.ru>
+Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/qlogic/qed/qed_sriov.c | 5 ++++-
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+index 3dbea6be4e553..ef6c3da38fc68 100644
+--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
++++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+@@ -4285,6 +4285,9 @@ qed_iov_configure_min_tx_rate(struct qed_dev *cdev, int vfid, u32 rate)
+ }
+
+ vf = qed_iov_get_vf_info(QED_LEADING_HWFN(cdev), (u16)vfid, true);
++ if (!vf)
++ return -EINVAL;
++
+ vport_id = vf->vport_id;
+
+ return qed_configure_vport_wfq(cdev, vport_id, rate);
+@@ -4922,7 +4925,7 @@ static void qed_iov_handle_trust_change(struct qed_hwfn *hwfn)
+
+ /* Validate that the VF has a configured vport */
+ vf = qed_iov_get_vf_info(hwfn, i, true);
+- if (!vf->vport_instance)
++ if (!vf || !vf->vport_instance)
+ continue;
+
+ memset(¶ms, 0, sizeof(params));
+--
+2.39.2
+
--- /dev/null
+From 95675bd051896818bf11ea468c1bfa706cd52635 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 15 Mar 2023 14:21:54 +0800
+Subject: scsi: scsi_dh_alua: Fix memleak for 'qdata' in alua_activate()
+
+From: Yu Kuai <yukuai3@huawei.com>
+
+[ Upstream commit a13faca032acbf2699293587085293bdfaafc8ae ]
+
+If alua_rtpg_queue() failed from alua_activate(), then 'qdata' is not
+freed, which will cause following memleak:
+
+unreferenced object 0xffff88810b2c6980 (size 32):
+ comm "kworker/u16:2", pid 635322, jiffies 4355801099 (age 1216426.076s)
+ hex dump (first 32 bytes):
+ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
+ 40 39 24 c1 ff ff ff ff 00 f8 ea 0a 81 88 ff ff @9$.............
+ backtrace:
+ [<0000000098f3a26d>] alua_activate+0xb0/0x320
+ [<000000003b529641>] scsi_dh_activate+0xb2/0x140
+ [<000000007b296db3>] activate_path_work+0xc6/0xe0 [dm_multipath]
+ [<000000007adc9ace>] process_one_work+0x3c5/0x730
+ [<00000000c457a985>] worker_thread+0x93/0x650
+ [<00000000cb80e628>] kthread+0x1ba/0x210
+ [<00000000a1e61077>] ret_from_fork+0x22/0x30
+
+Fix the problem by freeing 'qdata' in error path.
+
+Fixes: 625fe857e4fa ("scsi: scsi_dh_alua: Check scsi_device_get() return value")
+Signed-off-by: Yu Kuai <yukuai3@huawei.com>
+Link: https://lore.kernel.org/r/20230315062154.668812-1-yukuai1@huaweicloud.com
+Reviewed-by: Benjamin Block <bblock@linux.ibm.com>
+Reviewed-by: Bart Van Assche <bvanassche@acm.org>
+Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/scsi/device_handler/scsi_dh_alua.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/scsi/device_handler/scsi_dh_alua.c b/drivers/scsi/device_handler/scsi_dh_alua.c
+index 2cf5579a9ad9c..750d57d77be3b 100644
+--- a/drivers/scsi/device_handler/scsi_dh_alua.c
++++ b/drivers/scsi/device_handler/scsi_dh_alua.c
+@@ -1025,10 +1025,12 @@ static int alua_activate(struct scsi_device *sdev,
+ rcu_read_unlock();
+ mutex_unlock(&h->init_mutex);
+
+- if (alua_rtpg_queue(pg, sdev, qdata, true))
++ if (alua_rtpg_queue(pg, sdev, qdata, true)) {
+ fn = NULL;
+- else
++ } else {
++ kfree(qdata);
+ err = SCSI_DH_DEV_OFFLINED;
++ }
+ kref_put(&pg->kref, release_port_group);
+ out:
+ if (fn)
+--
+2.39.2
+
--- /dev/null
+power-supply-da9150-fix-use-after-free-bug-in-da9150.patch
+iavf-fix-inverted-rx-hash-condition-leading-to-disab.patch
+intel-igbvf-free-irq-on-the-error-path-in-igbvf_requ.patch
+igbvf-regard-vf-reset-nack-as-success.patch
+i2c-imx-lpi2c-check-only-for-enabled-interrupt-flags.patch
+scsi-scsi_dh_alua-fix-memleak-for-qdata-in-alua_acti.patch
+net-usb-smsc95xx-limit-packet-length-to-skb-len.patch
+qed-qed_sriov-guard-against-null-derefs-from-qed_iov.patch
+xirc2ps_cs-fix-use-after-free-bug-in-xirc2ps_detach.patch
+net-qcom-emac-fix-use-after-free-bug-in-emac_remove-.patch
+net-ps3_gelic_net-fix-rx-sk_buff-length.patch
+net-ps3_gelic_net-use-dma_mapping_error.patch
+bpf-adjust-insufficient-default-bpf_jit_limit.patch
+net-mlx5-read-the-tc-mapping-of-all-priorities-on-et.patch
+atm-idt77252-fix-kmemleak-when-rmmod-idt77252.patch
+hvc-xen-prevent-concurrent-accesses-to-the-shared-ri.patch
+net-mdio-thunder-add-missing-fwnode_handle_put.patch
+bluetooth-btqcomsmd-fix-command-timeout-after-settin.patch
+bluetooth-btsdio-fix-use-after-free-bug-in-btsdio_re.patch
--- /dev/null
+From 13c1dd3c3f834ea3b284282005a317a66384a03a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 17 Mar 2023 00:15:26 +0800
+Subject: xirc2ps_cs: Fix use after free bug in xirc2ps_detach
+
+From: Zheng Wang <zyytlz.wz@163.com>
+
+[ Upstream commit e8d20c3ded59a092532513c9bd030d1ea66f5f44 ]
+
+In xirc2ps_probe, the local->tx_timeout_task was bounded
+with xirc2ps_tx_timeout_task. When timeout occurs,
+it will call xirc_tx_timeout->schedule_work to start the
+work.
+
+When we call xirc2ps_detach to remove the driver, there
+may be a sequence as follows:
+
+Stop responding to timeout tasks and complete scheduled
+tasks before cleanup in xirc2ps_detach, which will fix
+the problem.
+
+CPU0 CPU1
+
+ |xirc2ps_tx_timeout_task
+xirc2ps_detach |
+ free_netdev |
+ kfree(dev); |
+ |
+ | do_reset
+ | //use dev
+
+Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
+Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/xircom/xirc2ps_cs.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/net/ethernet/xircom/xirc2ps_cs.c b/drivers/net/ethernet/xircom/xirc2ps_cs.c
+index fd5288ff53b53..e3438cef5f9c6 100644
+--- a/drivers/net/ethernet/xircom/xirc2ps_cs.c
++++ b/drivers/net/ethernet/xircom/xirc2ps_cs.c
+@@ -503,6 +503,11 @@ static void
+ xirc2ps_detach(struct pcmcia_device *link)
+ {
+ struct net_device *dev = link->priv;
++ struct local_info *local = netdev_priv(dev);
++
++ netif_carrier_off(dev);
++ netif_tx_disable(dev);
++ cancel_work_sync(&local->tx_timeout_task);
+
+ dev_dbg(&link->dev, "detach\n");
+
+--
+2.39.2
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
