--- /dev/null
+From cca9016d2024305ece9bb4347bbc3f022a931523 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 13 Mar 2023 22:43:25 +0800
+Subject: 9p/xen : Fix use after free bug in xen_9pfs_front_remove due to race
+ condition
+
+From: Zheng Wang <zyytlz.wz@163.com>
+
+[ Upstream commit ea4f1009408efb4989a0f139b70fb338e7f687d0 ]
+
+In xen_9pfs_front_probe, it calls xen_9pfs_front_alloc_dataring
+to init priv->rings and bound &ring->work with p9_xen_response.
+
+When it calls xen_9pfs_front_event_handler to handle IRQ requests,
+it will finally call schedule_work to start the work.
+
+When we call xen_9pfs_front_remove to remove the driver, there
+may be a sequence as follows:
+
+Fix it by finishing the work before cleanup in xen_9pfs_front_free.
+
+Note that, this bug is found by static analysis, which might be
+false positive.
+
+CPU0 CPU1
+
+ |p9_xen_response
+xen_9pfs_front_remove|
+ xen_9pfs_front_free|
+kfree(priv) |
+//free priv |
+ |p9_tag_lookup
+ |//use priv->client
+
+Fixes: 71ebd71921e4 ("xen/9pfs: connect to the backend")
+Signed-off-by: Zheng Wang <zyytlz.wz@163.com>
+Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
+Signed-off-by: Eric Van Hensbergen <ericvh@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/9p/trans_xen.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/net/9p/trans_xen.c b/net/9p/trans_xen.c
+index ebe232fd45f74..f7008f1daaace 100644
+--- a/net/9p/trans_xen.c
++++ b/net/9p/trans_xen.c
+@@ -290,6 +290,10 @@ static void xen_9pfs_front_free(struct xen_9pfs_front_priv *priv)
+ write_unlock(&xen_9pfs_lock);
+
+ for (i = 0; i < priv->num_rings; i++) {
++ struct xen_9pfs_dataring *ring = &priv->rings[i];
++
++ cancel_work_sync(&ring->work);
++
+ if (!priv->rings[i].intf)
+ break;
+ if (priv->rings[i].irq > 0)
+--
+2.39.2
+
--- /dev/null
+From 5bcdf8d62b42d2b0dac6dbec24f38740e1f90ac9 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 14 Mar 2023 13:31:03 +0100
+Subject: efi: sysfb_efi: Add quirk for Lenovo Yoga Book X91F/L
+
+From: Hans de Goede <hdegoede@redhat.com>
+
+[ Upstream commit 5ed213dd64681f84a01ceaa82fb336cf7d59ddcf ]
+
+Another Lenovo convertable which reports a landscape resolution of
+1920x1200 with a pitch of (1920 * 4) bytes, while the actual framebuffer
+has a resolution of 1200x1920 with a pitch of (1200 * 4) bytes.
+
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
+Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/x86/kernel/sysfb_efi.c | 8 ++++++++
+ 1 file changed, 8 insertions(+)
+
+diff --git a/arch/x86/kernel/sysfb_efi.c b/arch/x86/kernel/sysfb_efi.c
+index dd8d7636c5420..5bc0fedb33420 100644
+--- a/arch/x86/kernel/sysfb_efi.c
++++ b/arch/x86/kernel/sysfb_efi.c
+@@ -273,6 +273,14 @@ static const struct dmi_system_id efifb_dmi_swap_width_height[] __initconst = {
+ "IdeaPad Duet 3 10IGL5"),
+ },
+ },
++ {
++ /* Lenovo Yoga Book X91F / X91L */
++ .matches = {
++ DMI_EXACT_MATCH(DMI_SYS_VENDOR, "LENOVO"),
++ /* Non exact match to match F + L versions */
++ DMI_MATCH(DMI_PRODUCT_NAME, "Lenovo YB1-X91"),
++ },
++ },
+ {},
+ };
+
+--
+2.39.2
+
--- /dev/null
+From 7f7f6327ca24a3d26d26a47f1b81a21a35282ae4 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 30 Jan 2023 16:32:46 +0100
+Subject: i2c: imx-lpi2c: clean rx/tx buffers upon new message
+
+From: Alexander Stein <alexander.stein@ew.tq-group.com>
+
+[ Upstream commit 987dd36c0141f6ab9f0fbf14d6b2ec3342dedb2f ]
+
+When start sending a new message clear the Rx & Tx buffer pointers in
+order to avoid using stale pointers.
+
+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 | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c b/drivers/i2c/busses/i2c-imx-lpi2c.c
+index ca4d554126579..511d332f47326 100644
+--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
++++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
+@@ -475,6 +475,8 @@ static int lpi2c_imx_xfer(struct i2c_adapter *adapter,
+ if (num == 1 && msgs[0].len == 0)
+ goto stop;
+
++ lpi2c_imx->rx_buf = NULL;
++ lpi2c_imx->tx_buf = NULL;
+ lpi2c_imx->delivered = 0;
+ lpi2c_imx->msglen = msgs[i].len;
+ init_completion(&lpi2c_imx->complete);
+--
+2.39.2
+
--- /dev/null
+From 2b52e9e219876572c82811d9e2b803a5523bde89 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 12 Apr 2023 16:21:44 -0700
+Subject: net: macb: fix a memory corruption in extended buffer descriptor mode
+
+From: Roman Gushchin <roman.gushchin@linux.dev>
+
+[ Upstream commit e8b74453555872851bdd7ea43a7c0ec39659834f ]
+
+For quite some time we were chasing a bug which looked like a sudden
+permanent failure of networking and mmc on some of our devices.
+The bug was very sensitive to any software changes and even more to
+any kernel debug options.
+
+Finally we got a setup where the problem was reproducible with
+CONFIG_DMA_API_DEBUG=y and it revealed the issue with the rx dma:
+
+[ 16.992082] ------------[ cut here ]------------
+[ 16.996779] DMA-API: macb ff0b0000.ethernet: device driver tries to free DMA memory it has not allocated [device address=0x0000000875e3e244] [size=1536 bytes]
+[ 17.011049] WARNING: CPU: 0 PID: 85 at kernel/dma/debug.c:1011 check_unmap+0x6a0/0x900
+[ 17.018977] Modules linked in: xxxxx
+[ 17.038823] CPU: 0 PID: 85 Comm: irq/55-8000f000 Not tainted 5.4.0 #28
+[ 17.045345] Hardware name: xxxxx
+[ 17.049528] pstate: 60000005 (nZCv daif -PAN -UAO)
+[ 17.054322] pc : check_unmap+0x6a0/0x900
+[ 17.058243] lr : check_unmap+0x6a0/0x900
+[ 17.062163] sp : ffffffc010003c40
+[ 17.065470] x29: ffffffc010003c40 x28: 000000004000c03c
+[ 17.070783] x27: ffffffc010da7048 x26: ffffff8878e38800
+[ 17.076095] x25: ffffff8879d22810 x24: ffffffc010003cc8
+[ 17.081407] x23: 0000000000000000 x22: ffffffc010a08750
+[ 17.086719] x21: ffffff8878e3c7c0 x20: ffffffc010acb000
+[ 17.092032] x19: 0000000875e3e244 x18: 0000000000000010
+[ 17.097343] x17: 0000000000000000 x16: 0000000000000000
+[ 17.102647] x15: ffffff8879e4a988 x14: 0720072007200720
+[ 17.107959] x13: 0720072007200720 x12: 0720072007200720
+[ 17.113261] x11: 0720072007200720 x10: 0720072007200720
+[ 17.118565] x9 : 0720072007200720 x8 : 000000000000022d
+[ 17.123869] x7 : 0000000000000015 x6 : 0000000000000098
+[ 17.129173] x5 : 0000000000000000 x4 : 0000000000000000
+[ 17.134475] x3 : 00000000ffffffff x2 : ffffffc010a1d370
+[ 17.139778] x1 : b420c9d75d27bb00 x0 : 0000000000000000
+[ 17.145082] Call trace:
+[ 17.147524] check_unmap+0x6a0/0x900
+[ 17.151091] debug_dma_unmap_page+0x88/0x90
+[ 17.155266] gem_rx+0x114/0x2f0
+[ 17.158396] macb_poll+0x58/0x100
+[ 17.161705] net_rx_action+0x118/0x400
+[ 17.165445] __do_softirq+0x138/0x36c
+[ 17.169100] irq_exit+0x98/0xc0
+[ 17.172234] __handle_domain_irq+0x64/0xc0
+[ 17.176320] gic_handle_irq+0x5c/0xc0
+[ 17.179974] el1_irq+0xb8/0x140
+[ 17.183109] xiic_process+0x5c/0xe30
+[ 17.186677] irq_thread_fn+0x28/0x90
+[ 17.190244] irq_thread+0x208/0x2a0
+[ 17.193724] kthread+0x130/0x140
+[ 17.196945] ret_from_fork+0x10/0x20
+[ 17.200510] ---[ end trace 7240980785f81d6f ]---
+
+[ 237.021490] ------------[ cut here ]------------
+[ 237.026129] DMA-API: exceeded 7 overlapping mappings of cacheline 0x0000000021d79e7b
+[ 237.033886] WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:499 add_dma_entry+0x214/0x240
+[ 237.041802] Modules linked in: xxxxx
+[ 237.061637] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.4.0 #28
+[ 237.068941] Hardware name: xxxxx
+[ 237.073116] pstate: 80000085 (Nzcv daIf -PAN -UAO)
+[ 237.077900] pc : add_dma_entry+0x214/0x240
+[ 237.081986] lr : add_dma_entry+0x214/0x240
+[ 237.086072] sp : ffffffc010003c30
+[ 237.089379] x29: ffffffc010003c30 x28: ffffff8878a0be00
+[ 237.094683] x27: 0000000000000180 x26: ffffff8878e387c0
+[ 237.099987] x25: 0000000000000002 x24: 0000000000000000
+[ 237.105290] x23: 000000000000003b x22: ffffffc010a0fa00
+[ 237.110594] x21: 0000000021d79e7b x20: ffffffc010abe600
+[ 237.115897] x19: 00000000ffffffef x18: 0000000000000010
+[ 237.121201] x17: 0000000000000000 x16: 0000000000000000
+[ 237.126504] x15: ffffffc010a0fdc8 x14: 0720072007200720
+[ 237.131807] x13: 0720072007200720 x12: 0720072007200720
+[ 237.137111] x11: 0720072007200720 x10: 0720072007200720
+[ 237.142415] x9 : 0720072007200720 x8 : 0000000000000259
+[ 237.147718] x7 : 0000000000000001 x6 : 0000000000000000
+[ 237.153022] x5 : ffffffc010003a20 x4 : 0000000000000001
+[ 237.158325] x3 : 0000000000000006 x2 : 0000000000000007
+[ 237.163628] x1 : 8ac721b3a7dc1c00 x0 : 0000000000000000
+[ 237.168932] Call trace:
+[ 237.171373] add_dma_entry+0x214/0x240
+[ 237.175115] debug_dma_map_page+0xf8/0x120
+[ 237.179203] gem_rx_refill+0x190/0x280
+[ 237.182942] gem_rx+0x224/0x2f0
+[ 237.186075] macb_poll+0x58/0x100
+[ 237.189384] net_rx_action+0x118/0x400
+[ 237.193125] __do_softirq+0x138/0x36c
+[ 237.196780] irq_exit+0x98/0xc0
+[ 237.199914] __handle_domain_irq+0x64/0xc0
+[ 237.204000] gic_handle_irq+0x5c/0xc0
+[ 237.207654] el1_irq+0xb8/0x140
+[ 237.210789] arch_cpu_idle+0x40/0x200
+[ 237.214444] default_idle_call+0x18/0x30
+[ 237.218359] do_idle+0x200/0x280
+[ 237.221578] cpu_startup_entry+0x20/0x30
+[ 237.225493] rest_init+0xe4/0xf0
+[ 237.228713] arch_call_rest_init+0xc/0x14
+[ 237.232714] start_kernel+0x47c/0x4a8
+[ 237.236367] ---[ end trace 7240980785f81d70 ]---
+
+Lars was fast to find an explanation: according to the datasheet
+bit 2 of the rx buffer descriptor entry has a different meaning in the
+extended mode:
+ Address [2] of beginning of buffer, or
+ in extended buffer descriptor mode (DMA configuration register [28] = 1),
+ indicates a valid timestamp in the buffer descriptor entry.
+
+The macb driver didn't mask this bit while getting an address and it
+eventually caused a memory corruption and a dma failure.
+
+The problem is resolved by explicitly clearing the problematic bit
+if hw timestamping is used.
+
+Fixes: 7b4296148066 ("net: macb: Add support for PTP timestamps in DMA descriptors")
+Signed-off-by: Roman Gushchin <roman.gushchin@linux.dev>
+Co-developed-by: Lars-Peter Clausen <lars@metafoo.de>
+Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
+Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
+Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
+Link: https://lore.kernel.org/r/20230412232144.770336-1-roman.gushchin@linux.dev
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/cadence/macb_main.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
+index 456d84cbcc6be..9e51e0462e2c6 100644
+--- a/drivers/net/ethernet/cadence/macb_main.c
++++ b/drivers/net/ethernet/cadence/macb_main.c
+@@ -701,6 +701,10 @@ static dma_addr_t macb_get_addr(struct macb *bp, struct macb_dma_desc *desc)
+ }
+ #endif
+ addr |= MACB_BF(RX_WADDR, MACB_BFEXT(RX_WADDR, desc->addr));
++#ifdef CONFIG_MACB_USE_HWSTAMP
++ if (bp->hw_dma_cap & HW_DMA_CAP_PTP)
++ addr &= ~GEM_BIT(DMA_RXVALID);
++#endif
+ return addr;
+ }
+
+--
+2.39.2
+
--- /dev/null
+From c925c03983002d18a77a7e81c943cca158c83ac6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 5 Apr 2023 23:31:18 -0700
+Subject: niu: Fix missing unwind goto in niu_alloc_channels()
+
+From: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
+
+[ Upstream commit 8ce07be703456acb00e83d99f3b8036252c33b02 ]
+
+Smatch reports: drivers/net/ethernet/sun/niu.c:4525
+ niu_alloc_channels() warn: missing unwind goto?
+
+If niu_rbr_fill() fails, then we are directly returning 'err' without
+freeing the channels.
+
+Fix this by changing direct return to a goto 'out_err'.
+
+Fixes: a3138df9f20e ("[NIU]: Add Sun Neptune ethernet driver.")
+Signed-off-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
+Reviewed-by: Simon Horman <simon.horman@corigine.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/sun/niu.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
+index 7ba9cad183414..08ac19884133b 100644
+--- a/drivers/net/ethernet/sun/niu.c
++++ b/drivers/net/ethernet/sun/niu.c
+@@ -4520,7 +4520,7 @@ static int niu_alloc_channels(struct niu *np)
+
+ err = niu_rbr_fill(np, rp, GFP_KERNEL);
+ if (err)
+- return err;
++ goto out_err;
+ }
+
+ tx_rings = kcalloc(num_tx_rings, sizeof(struct tx_ring_info),
+--
+2.39.2
+
--- /dev/null
+From a17e33e12b834386b929d19e8ef98eb7105c6edb Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 7 Apr 2023 10:18:49 +0300
+Subject: qlcnic: check pci_reset_function result
+
+From: Denis Plotnikov <den-plotnikov@yandex-team.ru>
+
+[ Upstream commit 7573099e10ca69c3be33995c1fcd0d241226816d ]
+
+Static code analyzer complains to unchecked return value.
+The result of pci_reset_function() is unchecked.
+Despite, the issue is on the FLR supported code path and in that
+case reset can be done with pcie_flr(), the patch uses less invasive
+approach by adding the result check of pci_reset_function().
+
+Found by Linux Verification Center (linuxtesting.org) with SVACE.
+
+Fixes: 7e2cf4feba05 ("qlcnic: change driver hardware interface mechanism")
+Signed-off-by: Denis Plotnikov <den-plotnikov@yandex-team.ru>
+Reviewed-by: Simon Horman <simon.horman@corigine.com>
+Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 8 +++++++-
+ 1 file changed, 7 insertions(+), 1 deletion(-)
+
+diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
+index d344e9d438321..d3030bd967d5a 100644
+--- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
++++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
+@@ -629,7 +629,13 @@ int qlcnic_fw_create_ctx(struct qlcnic_adapter *dev)
+ int i, err, ring;
+
+ if (dev->flags & QLCNIC_NEED_FLR) {
+- pci_reset_function(dev->pdev);
++ err = pci_reset_function(dev->pdev);
++ if (err) {
++ dev_err(&dev->pdev->dev,
++ "Adapter reset failed (%d). Please reboot\n",
++ err);
++ return err;
++ }
+ dev->flags &= ~QLCNIC_NEED_FLR;
+ }
+
+--
+2.39.2
+
bluetooth-l2cap-fix-use-after-free-in-l2cap_disconnect_-req-rsp.patch
bluetooth-fix-race-condition-in-hidp_session_thread.patch
mtdblock-tolerate-corrected-bit-flips.patch
+9p-xen-fix-use-after-free-bug-in-xen_9pfs_front_remo.patch
+niu-fix-missing-unwind-goto-in-niu_alloc_channels.patch
+qlcnic-check-pci_reset_function-result.patch
+net-macb-fix-a-memory-corruption-in-extended-buffer-.patch
+i2c-imx-lpi2c-clean-rx-tx-buffers-upon-new-message.patch
+efi-sysfb_efi-add-quirk-for-lenovo-yoga-book-x91f-l.patch
+verify_pefile-relax-wrapper-length-check.patch
--- /dev/null
+From 10419e0d148b7bfad040f344a405de01efdd15ed Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 20 Feb 2023 12:12:53 -0500
+Subject: verify_pefile: relax wrapper length check
+
+From: Robbie Harwood <rharwood@redhat.com>
+
+[ Upstream commit 4fc5c74dde69a7eda172514aaeb5a7df3600adb3 ]
+
+The PE Format Specification (section "The Attribute Certificate Table
+(Image Only)") states that `dwLength` is to be rounded up to 8-byte
+alignment when used for traversal. Therefore, the field is not required
+to be an 8-byte multiple in the first place.
+
+Accordingly, pesign has not performed this alignment since version
+0.110. This causes kexec failure on pesign'd binaries with "PEFILE:
+Signature wrapper len wrong". Update the comment and relax the check.
+
+Signed-off-by: Robbie Harwood <rharwood@redhat.com>
+Signed-off-by: David Howells <dhowells@redhat.com>
+cc: Jarkko Sakkinen <jarkko@kernel.org>
+cc: Eric Biederman <ebiederm@xmission.com>
+cc: Herbert Xu <herbert@gondor.apana.org.au>
+cc: keyrings@vger.kernel.org
+cc: linux-crypto@vger.kernel.org
+cc: kexec@lists.infradead.org
+Link: https://learn.microsoft.com/en-us/windows/win32/debug/pe-format#the-attribute-certificate-table-image-only
+Link: https://github.com/rhboot/pesign
+Link: https://lore.kernel.org/r/20230220171254.592347-2-rharwood@redhat.com/ # v2
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ crypto/asymmetric_keys/verify_pefile.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+diff --git a/crypto/asymmetric_keys/verify_pefile.c b/crypto/asymmetric_keys/verify_pefile.c
+index d178650fd524c..411977947adbe 100644
+--- a/crypto/asymmetric_keys/verify_pefile.c
++++ b/crypto/asymmetric_keys/verify_pefile.c
+@@ -139,11 +139,15 @@ static int pefile_strip_sig_wrapper(const void *pebuf,
+ pr_debug("sig wrapper = { %x, %x, %x }\n",
+ wrapper.length, wrapper.revision, wrapper.cert_type);
+
+- /* Both pesign and sbsign round up the length of certificate table
+- * (in optional header data directories) to 8 byte alignment.
++ /* sbsign rounds up the length of certificate table (in optional
++ * header data directories) to 8 byte alignment. However, the PE
++ * specification states that while entries are 8-byte aligned, this is
++ * not included in their length, and as a result, pesign has not
++ * rounded up since 0.110.
+ */
+- if (round_up(wrapper.length, 8) != ctx->sig_len) {
+- pr_debug("Signature wrapper len wrong\n");
++ if (wrapper.length > ctx->sig_len) {
++ pr_debug("Signature wrapper bigger than sig len (%x > %x)\n",
++ ctx->sig_len, wrapper.length);
+ return -ELIBBAD;
+ }
+ if (wrapper.revision != WIN_CERT_REVISION_2_0) {
+--
+2.39.2
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
