From: Sasha Levin Date: Mon, 18 Apr 2022 03:55:08 +0000 (-0400) Subject: Fixes for 4.14 X-Git-Tag: v4.9.311~36 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=b0ba332e2cb8e4273fb207f3d3aea345bd1c646b;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.14 Signed-off-by: Sasha Levin --- diff --git a/queue-4.14/ata-libata-core-disable-read-log-dma-ext-for-samsung.patch b/queue-4.14/ata-libata-core-disable-read-log-dma-ext-for-samsung.patch new file mode 100644 index 00000000000..75bd38c9842 --- /dev/null +++ b/queue-4.14/ata-libata-core-disable-read-log-dma-ext-for-samsung.patch @@ -0,0 +1,45 @@ +From 3ea2382b6124e9551ce2e65fb9c0d3226954a627 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 19 Mar 2022 21:11:03 +0100 +Subject: ata: libata-core: Disable READ LOG DMA EXT for Samsung 840 EVOs + +From: Christian Lamparter + +[ Upstream commit 5399752299396a3c9df6617f4b3c907d7aa4ded8 ] + +Samsung' 840 EVO with the latest firmware (EXT0DB6Q) locks up with +the a message: "READ LOG DMA EXT failed, trying PIO" during boot. + +Initially this was discovered because it caused a crash +with the sata_dwc_460ex controller on a WD MyBook Live DUO. + +The reporter "Tice Rex" which has the unique opportunity that he +has two Samsung 840 EVO SSD! One with the older firmware "EXT0BB0Q" +which booted fine and didn't expose "READ LOG DMA EXT". But the +newer/latest firmware "EXT0DB6Q" caused the headaches. + +BugLink: https://github.com/openwrt/openwrt/issues/9505 +Signed-off-by: Christian Lamparter +Signed-off-by: Damien Le Moal +Signed-off-by: Sasha Levin +--- + drivers/ata/libata-core.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c +index 791374199e22..d3a7b3bb5043 100644 +--- a/drivers/ata/libata-core.c ++++ b/drivers/ata/libata-core.c +@@ -4588,6 +4588,9 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { + ATA_HORKAGE_ZERO_AFTER_TRIM, }, + { "Crucial_CT*MX100*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM | + ATA_HORKAGE_ZERO_AFTER_TRIM, }, ++ { "Samsung SSD 840 EVO*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | ++ ATA_HORKAGE_NO_DMA_LOG | ++ ATA_HORKAGE_ZERO_AFTER_TRIM, }, + { "Samsung SSD 840*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | + ATA_HORKAGE_ZERO_AFTER_TRIM, }, + { "Samsung SSD 850*", NULL, ATA_HORKAGE_NO_NCQ_TRIM | +-- +2.35.1 + diff --git a/queue-4.14/cifs-potential-buffer-overflow-in-handling-symlinks.patch b/queue-4.14/cifs-potential-buffer-overflow-in-handling-symlinks.patch new file mode 100644 index 00000000000..b413675dc5e --- /dev/null +++ b/queue-4.14/cifs-potential-buffer-overflow-in-handling-symlinks.patch @@ -0,0 +1,43 @@ +From d0b167e6b8ec9bf609c9d57d2d5d1d94cf71730a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 13 Apr 2022 04:42:51 -0700 +Subject: cifs: potential buffer overflow in handling symlinks + +From: Harshit Mogalapalli + +[ Upstream commit 64c4a37ac04eeb43c42d272f6e6c8c12bfcf4304 ] + +Smatch printed a warning: + arch/x86/crypto/poly1305_glue.c:198 poly1305_update_arch() error: + __memcpy() 'dctx->buf' too small (16 vs u32max) + +It's caused because Smatch marks 'link_len' as untrusted since it comes +from sscanf(). Add a check to ensure that 'link_len' is not larger than +the size of the 'link_str' buffer. + +Fixes: c69c1b6eaea1 ("cifs: implement CIFSParseMFSymlink()") +Signed-off-by: Harshit Mogalapalli +Reviewed-by: Ronnie Sahlberg +Signed-off-by: Steve French +Signed-off-by: Sasha Levin +--- + fs/cifs/link.c | 3 +++ + 1 file changed, 3 insertions(+) + +diff --git a/fs/cifs/link.c b/fs/cifs/link.c +index 9451a7f6893d..a89b8ff82040 100644 +--- a/fs/cifs/link.c ++++ b/fs/cifs/link.c +@@ -97,6 +97,9 @@ parse_mf_symlink(const u8 *buf, unsigned int buf_len, unsigned int *_link_len, + if (rc != 1) + return -EINVAL; + ++ if (link_len > CIFS_MF_SYMLINK_LINK_MAXLEN) ++ return -EINVAL; ++ + rc = symlink_hash(link_len, link_str, md5_hash); + if (rc) { + cifs_dbg(FYI, "%s: MD5 hash failure: %d\n", __func__, rc); +-- +2.35.1 + diff --git a/queue-4.14/drivers-hv-vmbus-prevent-load-re-ordering-when-readi.patch b/queue-4.14/drivers-hv-vmbus-prevent-load-re-ordering-when-readi.patch new file mode 100644 index 00000000000..98a3436b9e7 --- /dev/null +++ b/queue-4.14/drivers-hv-vmbus-prevent-load-re-ordering-when-readi.patch @@ -0,0 +1,57 @@ +From a5303a5a6eef0e777d89f4a93a85b02a000269d1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 27 Mar 2022 08:25:10 -0700 +Subject: Drivers: hv: vmbus: Prevent load re-ordering when reading ring buffer + +From: Michael Kelley + +[ Upstream commit b6cae15b5710c8097aad26a2e5e752c323ee5348 ] + +When reading a packet from a host-to-guest ring buffer, there is no +memory barrier between reading the write index (to see if there is +a packet to read) and reading the contents of the packet. The Hyper-V +host uses store-release when updating the write index to ensure that +writes of the packet data are completed first. On the guest side, +the processor can reorder and read the packet data before the write +index, and sometimes get stale packet data. Getting such stale packet +data has been observed in a reproducible case in a VM on ARM64. + +Fix this by using virt_load_acquire() to read the write index, +ensuring that reads of the packet data cannot be reordered +before it. Preventing such reordering is logically correct, and +with this change, getting stale data can no longer be reproduced. + +Signed-off-by: Michael Kelley +Reviewed-by: Andrea Parri (Microsoft) +Link: https://lore.kernel.org/r/1648394710-33480-1-git-send-email-mikelley@microsoft.com +Signed-off-by: Wei Liu +Signed-off-by: Sasha Levin +--- + drivers/hv/ring_buffer.c | 11 ++++++++++- + 1 file changed, 10 insertions(+), 1 deletion(-) + +diff --git a/drivers/hv/ring_buffer.c b/drivers/hv/ring_buffer.c +index 74c1dfb8183b..6b08e9d9b382 100644 +--- a/drivers/hv/ring_buffer.c ++++ b/drivers/hv/ring_buffer.c +@@ -340,7 +340,16 @@ int hv_ringbuffer_read(struct vmbus_channel *channel, + static u32 hv_pkt_iter_avail(const struct hv_ring_buffer_info *rbi) + { + u32 priv_read_loc = rbi->priv_read_index; +- u32 write_loc = READ_ONCE(rbi->ring_buffer->write_index); ++ u32 write_loc; ++ ++ /* ++ * The Hyper-V host writes the packet data, then uses ++ * store_release() to update the write_index. Use load_acquire() ++ * here to prevent loads of the packet data from being re-ordered ++ * before the read of the write_index and potentially getting ++ * stale data. ++ */ ++ write_loc = virt_load_acquire(&rbi->ring_buffer->write_index); + + if (write_loc >= priv_read_loc) + return write_loc - priv_read_loc; +-- +2.35.1 + diff --git a/queue-4.14/drivers-net-slip-fix-npd-bug-in-sl_tx_timeout.patch b/queue-4.14/drivers-net-slip-fix-npd-bug-in-sl_tx_timeout.patch new file mode 100644 index 00000000000..168367c7a7b --- /dev/null +++ b/queue-4.14/drivers-net-slip-fix-npd-bug-in-sl_tx_timeout.patch @@ -0,0 +1,60 @@ +From 17326f41483ae21fdbdafe96568b7340a53417ac Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 5 Apr 2022 21:22:06 +0800 +Subject: drivers: net: slip: fix NPD bug in sl_tx_timeout() + +From: Duoming Zhou + +[ Upstream commit ec4eb8a86ade4d22633e1da2a7d85a846b7d1798 ] + +When a slip driver is detaching, the slip_close() will act to +cleanup necessary resources and sl->tty is set to NULL in +slip_close(). Meanwhile, the packet we transmit is blocked, +sl_tx_timeout() will be called. Although slip_close() and +sl_tx_timeout() use sl->lock to synchronize, we don`t judge +whether sl->tty equals to NULL in sl_tx_timeout() and the +null pointer dereference bug will happen. + + (Thread 1) | (Thread 2) + | slip_close() + | spin_lock_bh(&sl->lock) + | ... +... | sl->tty = NULL //(1) +sl_tx_timeout() | spin_unlock_bh(&sl->lock) + spin_lock(&sl->lock); | + ... | ... + tty_chars_in_buffer(sl->tty)| + if (tty->ops->..) //(2) | + ... | synchronize_rcu() + +We set NULL to sl->tty in position (1) and dereference sl->tty +in position (2). + +This patch adds check in sl_tx_timeout(). If sl->tty equals to +NULL, sl_tx_timeout() will goto out. + +Signed-off-by: Duoming Zhou +Reviewed-by: Jiri Slaby +Link: https://lore.kernel.org/r/20220405132206.55291-1-duoming@zju.edu.cn +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/slip/slip.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/net/slip/slip.c b/drivers/net/slip/slip.c +index d7882b548b79..dd95d6181afa 100644 +--- a/drivers/net/slip/slip.c ++++ b/drivers/net/slip/slip.c +@@ -471,7 +471,7 @@ static void sl_tx_timeout(struct net_device *dev) + spin_lock(&sl->lock); + + if (netif_queue_stopped(dev)) { +- if (!netif_running(dev)) ++ if (!netif_running(dev) || !sl->tty) + goto out; + + /* May be we must check transmitter timeout here ? +-- +2.35.1 + diff --git a/queue-4.14/drm-amd-add-usbc-connector-id.patch b/queue-4.14/drm-amd-add-usbc-connector-id.patch new file mode 100644 index 00000000000..0d11dd742cf --- /dev/null +++ b/queue-4.14/drm-amd-add-usbc-connector-id.patch @@ -0,0 +1,35 @@ +From 72f0a66cf59d4ab72f51b56b76c264a2d0ebfe6f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 15 Mar 2022 14:53:24 -0400 +Subject: drm/amd: Add USBC connector ID + +From: Aurabindo Pillai + +[ Upstream commit c5c948aa894a831f96fccd025e47186b1ee41615 ] + +[Why&How] Add a dedicated AMDGPU specific ID for use with +newer ASICs that support USB-C output + +Signed-off-by: Aurabindo Pillai +Reviewed-by: Alex Deucher +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/amd/amdgpu/ObjectID.h | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/gpu/drm/amd/amdgpu/ObjectID.h b/drivers/gpu/drm/amd/amdgpu/ObjectID.h +index 06192698bd96..c90567de8bf7 100644 +--- a/drivers/gpu/drm/amd/amdgpu/ObjectID.h ++++ b/drivers/gpu/drm/amd/amdgpu/ObjectID.h +@@ -119,6 +119,7 @@ + #define CONNECTOR_OBJECT_ID_eDP 0x14 + #define CONNECTOR_OBJECT_ID_MXM 0x15 + #define CONNECTOR_OBJECT_ID_LVDS_eDP 0x16 ++#define CONNECTOR_OBJECT_ID_USBC 0x17 + + /* deleted */ + +-- +2.35.1 + diff --git a/queue-4.14/drm-amdkfd-check-for-potential-null-return-of-kmallo.patch b/queue-4.14/drm-amdkfd-check-for-potential-null-return-of-kmallo.patch new file mode 100644 index 00000000000..a817bb2e633 --- /dev/null +++ b/queue-4.14/drm-amdkfd-check-for-potential-null-return-of-kmallo.patch @@ -0,0 +1,35 @@ +From 03c4463f80a1d6870774b3f1c0d24b195911f876 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 24 Mar 2022 16:26:23 +0800 +Subject: drm/amdkfd: Check for potential null return of kmalloc_array() + +From: QintaoShen + +[ Upstream commit ebbb7bb9e80305820dc2328a371c1b35679f2667 ] + +As the kmalloc_array() may return null, the 'event_waiters[i].wait' would lead to null-pointer dereference. +Therefore, it is better to check the return value of kmalloc_array() to avoid this confusion. + +Signed-off-by: QintaoShen +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/amd/amdkfd/kfd_events.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_events.c b/drivers/gpu/drm/amd/amdkfd/kfd_events.c +index 944abfad39c1..1d8dd81dfc70 100644 +--- a/drivers/gpu/drm/amd/amdkfd/kfd_events.c ++++ b/drivers/gpu/drm/amd/amdkfd/kfd_events.c +@@ -607,6 +607,8 @@ static struct kfd_event_waiter *alloc_event_waiters(uint32_t num_events) + event_waiters = kmalloc_array(num_events, + sizeof(struct kfd_event_waiter), + GFP_KERNEL); ++ if (!event_waiters) ++ return NULL; + + for (i = 0; (event_waiters) && (i < num_events) ; i++) { + INIT_LIST_HEAD(&event_waiters[i].waiters); +-- +2.35.1 + diff --git a/queue-4.14/gpiolib-acpi-use-correct-format-characters.patch b/queue-4.14/gpiolib-acpi-use-correct-format-characters.patch new file mode 100644 index 00000000000..92a3e941039 --- /dev/null +++ b/queue-4.14/gpiolib-acpi-use-correct-format-characters.patch @@ -0,0 +1,97 @@ +From 67111f7840591021dbd2ae416d3b53e1ac32ba54 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 19 Mar 2022 16:21:09 -0700 +Subject: gpiolib: acpi: use correct format characters + +From: Linus Torvalds + +[ Upstream commit 213d266ebfb1621aab79cfe63388facc520a1381 ] + +When compiling with -Wformat, clang emits the following warning: + + gpiolib-acpi.c:393:4: warning: format specifies type 'unsigned char' but the argument has type 'int' [-Wformat] + pin); + ^~~ + +So warning that '%hhX' is paired with an 'int' is all just completely +mindless and wrong. Sadly, I can see a different bogus warning reason +why people would want to use '%02hhX'. + +Again, the *sane* thing from a human perspective is to use '%02X. But +if the compiler doesn't do any range analysis at all, it could decide +that "Oh, that print format could need up to 8 bytes of space in the +result". Using '%02hhX' would cut that down to two. + +And since we use + + char ev_name[5]; + +and currently use "_%c%02hhX" as the format string, even a compiler +that doesn't notice that "pin <= 255" test that guards this all will +go "OK, that's at most 4 bytes and the final NUL termination, so it's +fine". + +While a compiler - like gcc - that only sees that the original source +of the 'pin' value is a 'unsigned short' array, and then doesn't take +the "pin <= 255" into account, will warn like this: + + gpiolib-acpi.c: In function 'acpi_gpiochip_request_interrupt': + gpiolib-acpi.c:206:24: warning: '%02X' directive writing between 2 and 4 bytes into a region of size 3 [-Wformat-overflow=] + sprintf(ev_name, "_%c%02X", + ^~~~ + gpiolib-acpi.c:206:20: note: directive argument in the range [0, 65535] + +because gcc isn't being very good at that argument range analysis either. + +In other words, the original use of 'hhx' was bogus to begin with, and +due to *another* compiler warning being bad, and we had that bad code +being written back in 2016 to work around _that_ compiler warning +(commit e40a3ae1f794: "gpio: acpi: work around false-positive +-Wstring-overflow warning"). + +Sadly, two different bad compiler warnings together does not make for +one good one. + +It just makes for even more pain. + +End result: I think the simplest and cleanest option is simply the +proposed change which undoes that '%hhX' change for gcc, and replaces +it with just using a slightly bigger stack allocation. It's not like +a 5-byte allocation is in any way likely to have saved any actual stack, +since all the other variables in that function are 'int' or bigger. + +False-positive compiler warnings really do make people write worse +code, and that's a problem. But on a scale of bad code, I feel that +extending the buffer trivially is better than adding a pointless cast +that literally makes no sense. + +At least in this case the end result isn't unreadable or buggy. We've +had several cases of bad compiler warnings that caused changes that +were actually horrendously wrong. + +Fixes: e40a3ae1f794 ("gpio: acpi: work around false-positive -Wstring-overflow warning") +Signed-off-by: Linus Torvalds +Signed-off-by: Andy Shevchenko +Signed-off-by: Sasha Levin +--- + drivers/gpio/gpiolib-acpi.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/gpio/gpiolib-acpi.c b/drivers/gpio/gpiolib-acpi.c +index 60e394da9709..713dc43024c9 100644 +--- a/drivers/gpio/gpiolib-acpi.c ++++ b/drivers/gpio/gpiolib-acpi.c +@@ -335,8 +335,8 @@ static acpi_status acpi_gpiochip_alloc_event(struct acpi_resource *ares, + pin = agpio->pin_table[0]; + + if (pin <= 255) { +- char ev_name[5]; +- sprintf(ev_name, "_%c%02hhX", ++ char ev_name[8]; ++ sprintf(ev_name, "_%c%02X", + agpio->triggering == ACPI_EDGE_SENSITIVE ? 'E' : 'L', + pin); + if (ACPI_SUCCESS(acpi_get_handle(handle, ev_name, &evt_handle))) +-- +2.35.1 + diff --git a/queue-4.14/gpu-ipu-v3-fix-dev_dbg-frequency-output.patch b/queue-4.14/gpu-ipu-v3-fix-dev_dbg-frequency-output.patch new file mode 100644 index 00000000000..7023a26d5eb --- /dev/null +++ b/queue-4.14/gpu-ipu-v3-fix-dev_dbg-frequency-output.patch @@ -0,0 +1,53 @@ +From 011ed684c8532062a3693751ce0308c2a89c8cc4 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 7 Feb 2022 16:14:11 +0100 +Subject: gpu: ipu-v3: Fix dev_dbg frequency output + +From: Leo Ruan + +[ Upstream commit 070a88fd4a03f921b73a2059e97d55faaa447dab ] + +This commit corrects the printing of the IPU clock error percentage if +it is between -0.1% to -0.9%. For example, if the pixel clock requested +is 27.2 MHz but only 27.0 MHz can be achieved the deviation is -0.8%. +But the fixed point math had a flaw and calculated error of 0.2%. + +Before: + Clocks: IPU 270000000Hz DI 24716667Hz Needed 27200000Hz + IPU clock can give 27000000 with divider 10, error 0.2% + Want 27200000Hz IPU 270000000Hz DI 24716667Hz using IPU, 27000000Hz + +After: + Clocks: IPU 270000000Hz DI 24716667Hz Needed 27200000Hz + IPU clock can give 27000000 with divider 10, error -0.8% + Want 27200000Hz IPU 270000000Hz DI 24716667Hz using IPU, 27000000Hz + +Signed-off-by: Leo Ruan +Signed-off-by: Mark Jonas +Reviewed-by: Philipp Zabel +Signed-off-by: Philipp Zabel +Link: https://lore.kernel.org/r/20220207151411.5009-1-mark.jonas@de.bosch.com +Signed-off-by: Sasha Levin +--- + drivers/gpu/ipu-v3/ipu-di.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +diff --git a/drivers/gpu/ipu-v3/ipu-di.c b/drivers/gpu/ipu-v3/ipu-di.c +index d2f1bd9d3deb..c498dc7d8838 100644 +--- a/drivers/gpu/ipu-v3/ipu-di.c ++++ b/drivers/gpu/ipu-v3/ipu-di.c +@@ -460,8 +460,9 @@ static void ipu_di_config_clock(struct ipu_di *di, + + error = rate / (sig->mode.pixelclock / 1000); + +- dev_dbg(di->ipu->dev, " IPU clock can give %lu with divider %u, error %d.%u%%\n", +- rate, div, (signed)(error - 1000) / 10, error % 10); ++ dev_dbg(di->ipu->dev, " IPU clock can give %lu with divider %u, error %c%d.%d%%\n", ++ rate, div, error < 1000 ? '-' : '+', ++ abs(error - 1000) / 10, abs(error - 1000) % 10); + + /* Allow a 1% error */ + if (error < 1010 && error >= 990) { +-- +2.35.1 + diff --git a/queue-4.14/memory-atmel-ebi-fix-missing-of_node_put-in-atmel_eb.patch b/queue-4.14/memory-atmel-ebi-fix-missing-of_node_put-in-atmel_eb.patch new file mode 100644 index 00000000000..de237e1da83 --- /dev/null +++ b/queue-4.14/memory-atmel-ebi-fix-missing-of_node_put-in-atmel_eb.patch @@ -0,0 +1,74 @@ +From e3d06dd2471570c526309f749811f9737badd587 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 9 Mar 2022 11:01:43 +0000 +Subject: memory: atmel-ebi: Fix missing of_node_put in atmel_ebi_probe + +From: Miaoqian Lin + +[ Upstream commit 6f296a9665ba5ac68937bf11f96214eb9de81baa ] + +The device_node pointer is returned by of_parse_phandle() with refcount +incremented. We should use of_node_put() on it when done. + +Fixes: 87108dc78eb8 ("memory: atmel-ebi: Enable the SMC clock if specified") +Signed-off-by: Miaoqian Lin +Reviewed-by: Claudiu Beznea +Link: https://lore.kernel.org/r/20220309110144.22412-1-linmq006@gmail.com +Signed-off-by: Krzysztof Kozlowski +Signed-off-by: Sasha Levin +--- + drivers/memory/atmel-ebi.c | 23 +++++++++++++++++------ + 1 file changed, 17 insertions(+), 6 deletions(-) + +diff --git a/drivers/memory/atmel-ebi.c b/drivers/memory/atmel-ebi.c +index 2b9283d4fcb1..8e7b5a1d2983 100644 +--- a/drivers/memory/atmel-ebi.c ++++ b/drivers/memory/atmel-ebi.c +@@ -524,20 +524,27 @@ static int atmel_ebi_probe(struct platform_device *pdev) + smc_np = of_parse_phandle(dev->of_node, "atmel,smc", 0); + + ebi->smc.regmap = syscon_node_to_regmap(smc_np); +- if (IS_ERR(ebi->smc.regmap)) +- return PTR_ERR(ebi->smc.regmap); ++ if (IS_ERR(ebi->smc.regmap)) { ++ ret = PTR_ERR(ebi->smc.regmap); ++ goto put_node; ++ } + + ebi->smc.layout = atmel_hsmc_get_reg_layout(smc_np); +- if (IS_ERR(ebi->smc.layout)) +- return PTR_ERR(ebi->smc.layout); ++ if (IS_ERR(ebi->smc.layout)) { ++ ret = PTR_ERR(ebi->smc.layout); ++ goto put_node; ++ } + + ebi->smc.clk = of_clk_get(smc_np, 0); + if (IS_ERR(ebi->smc.clk)) { +- if (PTR_ERR(ebi->smc.clk) != -ENOENT) +- return PTR_ERR(ebi->smc.clk); ++ if (PTR_ERR(ebi->smc.clk) != -ENOENT) { ++ ret = PTR_ERR(ebi->smc.clk); ++ goto put_node; ++ } + + ebi->smc.clk = NULL; + } ++ of_node_put(smc_np); + ret = clk_prepare_enable(ebi->smc.clk); + if (ret) + return ret; +@@ -587,6 +594,10 @@ static int atmel_ebi_probe(struct platform_device *pdev) + } + + return of_platform_populate(np, NULL, NULL, dev); ++ ++put_node: ++ of_node_put(smc_np); ++ return ret; + } + + static __maybe_unused int atmel_ebi_resume(struct device *dev) +-- +2.35.1 + diff --git a/queue-4.14/mlxsw-i2c-fix-initialization-error-flow.patch b/queue-4.14/mlxsw-i2c-fix-initialization-error-flow.patch new file mode 100644 index 00000000000..b02fca78768 --- /dev/null +++ b/queue-4.14/mlxsw-i2c-fix-initialization-error-flow.patch @@ -0,0 +1,36 @@ +From cd4b1bf69cc31ad1a14eb55cdbf722ae3d2a4316 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 7 Apr 2022 10:07:03 +0300 +Subject: mlxsw: i2c: Fix initialization error flow + +From: Vadim Pasternak + +[ Upstream commit d452088cdfd5a4ad9d96d847d2273fe958d6339b ] + +Add mutex_destroy() call in driver initialization error flow. + +Fixes: 6882b0aee180f ("mlxsw: Introduce support for I2C bus") +Signed-off-by: Vadim Pasternak +Signed-off-by: Ido Schimmel +Link: https://lore.kernel.org/r/20220407070703.2421076-1-idosch@nvidia.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/mellanox/mlxsw/i2c.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/net/ethernet/mellanox/mlxsw/i2c.c b/drivers/net/ethernet/mellanox/mlxsw/i2c.c +index c0dcfa05b077..3d10e6100748 100644 +--- a/drivers/net/ethernet/mellanox/mlxsw/i2c.c ++++ b/drivers/net/ethernet/mellanox/mlxsw/i2c.c +@@ -548,6 +548,7 @@ static int mlxsw_i2c_probe(struct i2c_client *client, + return 0; + + errout: ++ mutex_destroy(&mlxsw_i2c->cmd.lock); + i2c_set_clientdata(client, NULL); + + return err; +-- +2.35.1 + diff --git a/queue-4.14/net-ethernet-stmmac-fix-altr_tse_pcs-function-when-u.patch b/queue-4.14/net-ethernet-stmmac-fix-altr_tse_pcs-function-when-u.patch new file mode 100644 index 00000000000..2a97b6ffe73 --- /dev/null +++ b/queue-4.14/net-ethernet-stmmac-fix-altr_tse_pcs-function-when-u.patch @@ -0,0 +1,120 @@ +From 5fc36ba3636651424888cc834cc44d9bfec4fac9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 7 Apr 2022 08:25:21 -0500 +Subject: net: ethernet: stmmac: fix altr_tse_pcs function when using a + fixed-link + +From: Dinh Nguyen + +[ Upstream commit a6aaa00324240967272b451bfa772547bd576ee6 ] + +When using a fixed-link, the altr_tse_pcs driver crashes +due to null-pointer dereference as no phy_device is provided to +tse_pcs_fix_mac_speed function. Fix this by adding a check for +phy_dev before calling the tse_pcs_fix_mac_speed() function. + +Also clean up the tse_pcs_fix_mac_speed function a bit. There is +no need to check for splitter_base and sgmii_adapter_base +because the driver will fail if these 2 variables are not +derived from the device tree. + +Fixes: fb3bbdb85989 ("net: ethernet: Add TSE PCS support to dwmac-socfpga") +Signed-off-by: Dinh Nguyen +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c | 8 -------- + drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h | 4 ++++ + drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c | 13 +++++-------- + 3 files changed, 9 insertions(+), 16 deletions(-) + +diff --git a/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c b/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c +index 6a9c954492f2..6ca428a702f1 100644 +--- a/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c ++++ b/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c +@@ -68,10 +68,6 @@ + #define TSE_PCS_USE_SGMII_ENA BIT(0) + #define TSE_PCS_IF_USE_SGMII 0x03 + +-#define SGMII_ADAPTER_CTRL_REG 0x00 +-#define SGMII_ADAPTER_DISABLE 0x0001 +-#define SGMII_ADAPTER_ENABLE 0x0000 +- + #define AUTONEGO_LINK_TIMER 20 + + static int tse_pcs_reset(void __iomem *base, struct tse_pcs *pcs) +@@ -215,12 +211,8 @@ void tse_pcs_fix_mac_speed(struct tse_pcs *pcs, struct phy_device *phy_dev, + unsigned int speed) + { + void __iomem *tse_pcs_base = pcs->tse_pcs_base; +- void __iomem *sgmii_adapter_base = pcs->sgmii_adapter_base; + u32 val; + +- writew(SGMII_ADAPTER_ENABLE, +- sgmii_adapter_base + SGMII_ADAPTER_CTRL_REG); +- + pcs->autoneg = phy_dev->autoneg; + + if (phy_dev->autoneg == AUTONEG_ENABLE) { +diff --git a/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h b/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h +index 2f5882450b06..254199f2efdb 100644 +--- a/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h ++++ b/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h +@@ -21,6 +21,10 @@ + #include + #include + ++#define SGMII_ADAPTER_CTRL_REG 0x00 ++#define SGMII_ADAPTER_ENABLE 0x0000 ++#define SGMII_ADAPTER_DISABLE 0x0001 ++ + struct tse_pcs { + struct device *dev; + void __iomem *tse_pcs_base; +diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c +index 33407df6bea6..32ead4a4b460 100644 +--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c ++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c +@@ -29,9 +29,6 @@ + + #include "altr_tse_pcs.h" + +-#define SGMII_ADAPTER_CTRL_REG 0x00 +-#define SGMII_ADAPTER_DISABLE 0x0001 +- + #define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_GMII_MII 0x0 + #define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RGMII 0x1 + #define SYSMGR_EMACGRP_CTRL_PHYSEL_ENUM_RMII 0x2 +@@ -65,16 +62,14 @@ static void socfpga_dwmac_fix_mac_speed(void *priv, unsigned int speed) + { + struct socfpga_dwmac *dwmac = (struct socfpga_dwmac *)priv; + void __iomem *splitter_base = dwmac->splitter_base; +- void __iomem *tse_pcs_base = dwmac->pcs.tse_pcs_base; + void __iomem *sgmii_adapter_base = dwmac->pcs.sgmii_adapter_base; + struct device *dev = dwmac->dev; + struct net_device *ndev = dev_get_drvdata(dev); + struct phy_device *phy_dev = ndev->phydev; + u32 val; + +- if ((tse_pcs_base) && (sgmii_adapter_base)) +- writew(SGMII_ADAPTER_DISABLE, +- sgmii_adapter_base + SGMII_ADAPTER_CTRL_REG); ++ writew(SGMII_ADAPTER_DISABLE, ++ sgmii_adapter_base + SGMII_ADAPTER_CTRL_REG); + + if (splitter_base) { + val = readl(splitter_base + EMAC_SPLITTER_CTRL_REG); +@@ -96,7 +91,9 @@ static void socfpga_dwmac_fix_mac_speed(void *priv, unsigned int speed) + writel(val, splitter_base + EMAC_SPLITTER_CTRL_REG); + } + +- if (tse_pcs_base && sgmii_adapter_base) ++ writew(SGMII_ADAPTER_ENABLE, ++ sgmii_adapter_base + SGMII_ADAPTER_CTRL_REG); ++ if (phy_dev) + tse_pcs_fix_mac_speed(&dwmac->pcs, phy_dev, speed); + } + +-- +2.35.1 + diff --git a/queue-4.14/net-micrel-fix-ks8851_mll-kconfig.patch b/queue-4.14/net-micrel-fix-ks8851_mll-kconfig.patch new file mode 100644 index 00000000000..0c88c749f47 --- /dev/null +++ b/queue-4.14/net-micrel-fix-ks8851_mll-kconfig.patch @@ -0,0 +1,50 @@ +From 118abb4eb64ad139d6fa59e1b8262ba03f9dc3aa Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 31 Mar 2022 22:42:44 -0700 +Subject: net: micrel: fix KS8851_MLL Kconfig + +From: Randy Dunlap + +[ Upstream commit c3efcedd272aa6dd5929e20cf902a52ddaa1197a ] + +KS8851_MLL selects MICREL_PHY, which depends on PTP_1588_CLOCK_OPTIONAL, +so make KS8851_MLL also depend on PTP_1588_CLOCK_OPTIONAL since +'select' does not follow any dependency chains. + +Fixes kconfig warning and build errors: + +WARNING: unmet direct dependencies detected for MICREL_PHY + Depends on [m]: NETDEVICES [=y] && PHYLIB [=y] && PTP_1588_CLOCK_OPTIONAL [=m] + Selected by [y]: + - KS8851_MLL [=y] && NETDEVICES [=y] && ETHERNET [=y] && NET_VENDOR_MICREL [=y] && HAS_IOMEM [=y] + +ld: drivers/net/phy/micrel.o: in function `lan8814_ts_info': +micrel.c:(.text+0xb35): undefined reference to `ptp_clock_index' +ld: drivers/net/phy/micrel.o: in function `lan8814_probe': +micrel.c:(.text+0x2586): undefined reference to `ptp_clock_register' + +Signed-off-by: Randy Dunlap +Cc: "David S. Miller" +Cc: Jakub Kicinski +Cc: Paolo Abeni +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/micrel/Kconfig | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/net/ethernet/micrel/Kconfig b/drivers/net/ethernet/micrel/Kconfig +index b7e2f49696b7..aa12bace8673 100644 +--- a/drivers/net/ethernet/micrel/Kconfig ++++ b/drivers/net/ethernet/micrel/Kconfig +@@ -45,6 +45,7 @@ config KS8851 + config KS8851_MLL + tristate "Micrel KS8851 MLL" + depends on HAS_IOMEM ++ depends on PTP_1588_CLOCK_OPTIONAL + select MII + ---help--- + This platform driver is for Micrel KS8851 Address/data bus +-- +2.35.1 + diff --git a/queue-4.14/nfc-nci-add-flush_workqueue-to-prevent-uaf.patch b/queue-4.14/nfc-nci-add-flush_workqueue-to-prevent-uaf.patch new file mode 100644 index 00000000000..af80792bdc4 --- /dev/null +++ b/queue-4.14/nfc-nci-add-flush_workqueue-to-prevent-uaf.patch @@ -0,0 +1,128 @@ +From 6781bb9eadb475ff23ad4eb61e749e2d045ba4a3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 13 Apr 2022 00:04:30 +0800 +Subject: nfc: nci: add flush_workqueue to prevent uaf + +From: Lin Ma + +[ Upstream commit ef27324e2cb7bb24542d6cb2571740eefe6b00dc ] + +Our detector found a concurrent use-after-free bug when detaching an +NCI device. The main reason for this bug is the unexpected scheduling +between the used delayed mechanism (timer and workqueue). + +The race can be demonstrated below: + +Thread-1 Thread-2 + | nci_dev_up() + | nci_open_device() + | __nci_request(nci_reset_req) + | nci_send_cmd + | queue_work(cmd_work) +nci_unregister_device() | + nci_close_device() | ... + del_timer_sync(cmd_timer)[1] | +... | Worker +nci_free_device() | nci_cmd_work() + kfree(ndev)[3] | mod_timer(cmd_timer)[2] + +In short, the cleanup routine thought that the cmd_timer has already +been detached by [1] but the mod_timer can re-attach the timer [2], even +it is already released [3], resulting in UAF. + +This UAF is easy to trigger, crash trace by POC is like below + +[ 66.703713] ================================================================== +[ 66.703974] BUG: KASAN: use-after-free in enqueue_timer+0x448/0x490 +[ 66.703974] Write of size 8 at addr ffff888009fb7058 by task kworker/u4:1/33 +[ 66.703974] +[ 66.703974] CPU: 1 PID: 33 Comm: kworker/u4:1 Not tainted 5.18.0-rc2 #5 +[ 66.703974] Workqueue: nfc2_nci_cmd_wq nci_cmd_work +[ 66.703974] Call Trace: +[ 66.703974] +[ 66.703974] dump_stack_lvl+0x57/0x7d +[ 66.703974] print_report.cold+0x5e/0x5db +[ 66.703974] ? enqueue_timer+0x448/0x490 +[ 66.703974] kasan_report+0xbe/0x1c0 +[ 66.703974] ? enqueue_timer+0x448/0x490 +[ 66.703974] enqueue_timer+0x448/0x490 +[ 66.703974] __mod_timer+0x5e6/0xb80 +[ 66.703974] ? mark_held_locks+0x9e/0xe0 +[ 66.703974] ? try_to_del_timer_sync+0xf0/0xf0 +[ 66.703974] ? lockdep_hardirqs_on_prepare+0x17b/0x410 +[ 66.703974] ? queue_work_on+0x61/0x80 +[ 66.703974] ? lockdep_hardirqs_on+0xbf/0x130 +[ 66.703974] process_one_work+0x8bb/0x1510 +[ 66.703974] ? lockdep_hardirqs_on_prepare+0x410/0x410 +[ 66.703974] ? pwq_dec_nr_in_flight+0x230/0x230 +[ 66.703974] ? rwlock_bug.part.0+0x90/0x90 +[ 66.703974] ? _raw_spin_lock_irq+0x41/0x50 +[ 66.703974] worker_thread+0x575/0x1190 +[ 66.703974] ? process_one_work+0x1510/0x1510 +[ 66.703974] kthread+0x2a0/0x340 +[ 66.703974] ? kthread_complete_and_exit+0x20/0x20 +[ 66.703974] ret_from_fork+0x22/0x30 +[ 66.703974] +[ 66.703974] +[ 66.703974] Allocated by task 267: +[ 66.703974] kasan_save_stack+0x1e/0x40 +[ 66.703974] __kasan_kmalloc+0x81/0xa0 +[ 66.703974] nci_allocate_device+0xd3/0x390 +[ 66.703974] nfcmrvl_nci_register_dev+0x183/0x2c0 +[ 66.703974] nfcmrvl_nci_uart_open+0xf2/0x1dd +[ 66.703974] nci_uart_tty_ioctl+0x2c3/0x4a0 +[ 66.703974] tty_ioctl+0x764/0x1310 +[ 66.703974] __x64_sys_ioctl+0x122/0x190 +[ 66.703974] do_syscall_64+0x3b/0x90 +[ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae +[ 66.703974] +[ 66.703974] Freed by task 406: +[ 66.703974] kasan_save_stack+0x1e/0x40 +[ 66.703974] kasan_set_track+0x21/0x30 +[ 66.703974] kasan_set_free_info+0x20/0x30 +[ 66.703974] __kasan_slab_free+0x108/0x170 +[ 66.703974] kfree+0xb0/0x330 +[ 66.703974] nfcmrvl_nci_unregister_dev+0x90/0xd0 +[ 66.703974] nci_uart_tty_close+0xdf/0x180 +[ 66.703974] tty_ldisc_kill+0x73/0x110 +[ 66.703974] tty_ldisc_hangup+0x281/0x5b0 +[ 66.703974] __tty_hangup.part.0+0x431/0x890 +[ 66.703974] tty_release+0x3a8/0xc80 +[ 66.703974] __fput+0x1f0/0x8c0 +[ 66.703974] task_work_run+0xc9/0x170 +[ 66.703974] exit_to_user_mode_prepare+0x194/0x1a0 +[ 66.703974] syscall_exit_to_user_mode+0x19/0x50 +[ 66.703974] do_syscall_64+0x48/0x90 +[ 66.703974] entry_SYSCALL_64_after_hwframe+0x44/0xae + +To fix the UAF, this patch adds flush_workqueue() to ensure the +nci_cmd_work is finished before the following del_timer_sync. +This combination will promise the timer is actually detached. + +Fixes: 6a2968aaf50c ("NFC: basic NCI protocol implementation") +Signed-off-by: Lin Ma +Reviewed-by: Krzysztof Kozlowski +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/nfc/nci/core.c | 4 ++++ + 1 file changed, 4 insertions(+) + +diff --git a/net/nfc/nci/core.c b/net/nfc/nci/core.c +index c6dc82f66bd9..99f4573fd917 100644 +--- a/net/nfc/nci/core.c ++++ b/net/nfc/nci/core.c +@@ -560,6 +560,10 @@ static int nci_close_device(struct nci_dev *ndev) + mutex_lock(&ndev->req_lock); + + if (!test_and_clear_bit(NCI_UP, &ndev->flags)) { ++ /* Need to flush the cmd wq in case ++ * there is a queued/running cmd_work ++ */ ++ flush_workqueue(ndev->cmd_wq); + del_timer_sync(&ndev->cmd_timer); + del_timer_sync(&ndev->data_timer); + mutex_unlock(&ndev->req_lock); +-- +2.35.1 + diff --git a/queue-4.14/scsi-ibmvscsis-increase-initial_srp_limit-to-1024.patch b/queue-4.14/scsi-ibmvscsis-increase-initial_srp_limit-to-1024.patch new file mode 100644 index 00000000000..8a5c9bc49d2 --- /dev/null +++ b/queue-4.14/scsi-ibmvscsis-increase-initial_srp_limit-to-1024.patch @@ -0,0 +1,44 @@ +From 74ee609a334475fc09684dfb1c31ceab7d68d384 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 22 Mar 2022 12:44:43 -0700 +Subject: scsi: ibmvscsis: Increase INITIAL_SRP_LIMIT to 1024 + +From: Tyrel Datwyler + +[ Upstream commit 0bade8e53279157c7cc9dd95d573b7e82223d78a ] + +The adapter request_limit is hardcoded to be INITIAL_SRP_LIMIT which is +currently an arbitrary value of 800. Increase this value to 1024 which +better matches the characteristics of the typical IBMi Initiator that +supports 32 LUNs and a queue depth of 32. + +This change also has the secondary benefit of being a power of two as +required by the kfifo API. Since, Commit ab9bb6318b09 ("Partially revert +"kfifo: fix kfifo_alloc() and kfifo_init()"") the size of IU pool for each +target has been rounded down to 512 when attempting to kfifo_init() those +pools with the current request_limit size of 800. + +Link: https://lore.kernel.org/r/20220322194443.678433-1-tyreld@linux.ibm.com +Signed-off-by: Tyrel Datwyler +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c +index 25d2741cdf96..b97140661119 100644 +--- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c ++++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c +@@ -44,7 +44,7 @@ + + #define IBMVSCSIS_VERSION "v0.2" + +-#define INITIAL_SRP_LIMIT 800 ++#define INITIAL_SRP_LIMIT 1024 + #define DEFAULT_MAX_SECTORS 256 + #define MAX_TXU 1024 * 1024 + +-- +2.35.1 + diff --git a/queue-4.14/scsi-mvsas-add-pci-id-of-rocketraid-2640.patch b/queue-4.14/scsi-mvsas-add-pci-id-of-rocketraid-2640.patch new file mode 100644 index 00000000000..b1537186d8e --- /dev/null +++ b/queue-4.14/scsi-mvsas-add-pci-id-of-rocketraid-2640.patch @@ -0,0 +1,36 @@ +From b2f91d347ee3fd881a9c5f3e505f6173b2b44a55 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 9 Mar 2022 22:25:35 +0100 +Subject: scsi: mvsas: Add PCI ID of RocketRaid 2640 + +From: Alexey Galakhov + +[ Upstream commit 5f2bce1e222028dc1c15f130109a17aa654ae6e8 ] + +The HighPoint RocketRaid 2640 is a low-cost SAS controller based on Marvell +chip. The chip in question was already supported by the kernel, just the +PCI ID of this particular board was missing. + +Link: https://lore.kernel.org/r/20220309212535.402987-1-agalakhov@gmail.com +Signed-off-by: Alexey Galakhov +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/mvsas/mv_init.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/scsi/mvsas/mv_init.c b/drivers/scsi/mvsas/mv_init.c +index f6070b1fe1d8..b03fdff72adb 100644 +--- a/drivers/scsi/mvsas/mv_init.c ++++ b/drivers/scsi/mvsas/mv_init.c +@@ -678,6 +678,7 @@ static struct pci_device_id mvs_pci_table[] = { + { PCI_VDEVICE(ARECA, PCI_DEVICE_ID_ARECA_1300), chip_1300 }, + { PCI_VDEVICE(ARECA, PCI_DEVICE_ID_ARECA_1320), chip_1320 }, + { PCI_VDEVICE(ADAPTEC2, 0x0450), chip_6440 }, ++ { PCI_VDEVICE(TTI, 0x2640), chip_6440 }, + { PCI_VDEVICE(TTI, 0x2710), chip_9480 }, + { PCI_VDEVICE(TTI, 0x2720), chip_9480 }, + { PCI_VDEVICE(TTI, 0x2721), chip_9480 }, +-- +2.35.1 + diff --git a/queue-4.14/scsi-target-tcmu-fix-possible-page-uaf.patch b/queue-4.14/scsi-target-tcmu-fix-possible-page-uaf.patch new file mode 100644 index 00000000000..2f08e048e3e --- /dev/null +++ b/queue-4.14/scsi-target-tcmu-fix-possible-page-uaf.patch @@ -0,0 +1,57 @@ +From 2b3edb7652cd694868c745b59b6446a18c821587 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 11 Mar 2022 21:22:05 +0800 +Subject: scsi: target: tcmu: Fix possible page UAF + +From: Xiaoguang Wang + +[ Upstream commit a6968f7a367f128d120447360734344d5a3d5336 ] + +tcmu_try_get_data_page() looks up pages under cmdr_lock, but it does not +take refcount properly and just returns page pointer. When +tcmu_try_get_data_page() returns, the returned page may have been freed by +tcmu_blocks_release(). + +We need to get_page() under cmdr_lock to avoid concurrent +tcmu_blocks_release(). + +Link: https://lore.kernel.org/r/20220311132206.24515-1-xiaoguang.wang@linux.alibaba.com +Reviewed-by: Bodo Stroesser +Signed-off-by: Xiaoguang Wang +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/target/target_core_user.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/target/target_core_user.c b/drivers/target/target_core_user.c +index 96601fda47b1..f687481ccfdc 100644 +--- a/drivers/target/target_core_user.c ++++ b/drivers/target/target_core_user.c +@@ -1165,6 +1165,7 @@ static struct page *tcmu_try_get_block_page(struct tcmu_dev *udev, uint32_t dbi) + mutex_lock(&udev->cmdr_lock); + page = tcmu_get_block_page(udev, dbi); + if (likely(page)) { ++ get_page(page); + mutex_unlock(&udev->cmdr_lock); + return page; + } +@@ -1233,6 +1234,7 @@ static int tcmu_vma_fault(struct vm_fault *vmf) + /* For the vmalloc()ed cmd area pages */ + addr = (void *)(unsigned long)info->mem[mi].addr + offset; + page = vmalloc_to_page(addr); ++ get_page(page); + } else { + uint32_t dbi; + +@@ -1243,7 +1245,6 @@ static int tcmu_vma_fault(struct vm_fault *vmf) + return VM_FAULT_NOPAGE; + } + +- get_page(page); + vmf->page = page; + return 0; + } +-- +2.35.1 + diff --git a/queue-4.14/series b/queue-4.14/series index 19d71c5c72f..a44424c141f 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -258,3 +258,20 @@ cgroup-use-open-time-credentials-for-process-migraton-perm-checks.patch cgroup-allocate-cgroup_file_ctx-for-kernfs_open_file-priv.patch cgroup-use-open-time-cgroup-namespace-for-process-migration-perm-checks.patch xfrm-policy-match-with-both-mark-and-mask-on-user-interfaces.patch +memory-atmel-ebi-fix-missing-of_node_put-in-atmel_eb.patch +veth-ensure-eth-header-is-in-skb-s-linear-part.patch +gpiolib-acpi-use-correct-format-characters.patch +mlxsw-i2c-fix-initialization-error-flow.patch +net-ethernet-stmmac-fix-altr_tse_pcs-function-when-u.patch +nfc-nci-add-flush_workqueue-to-prevent-uaf.patch +cifs-potential-buffer-overflow-in-handling-symlinks.patch +drm-amd-add-usbc-connector-id.patch +drm-amdkfd-check-for-potential-null-return-of-kmallo.patch +drivers-hv-vmbus-prevent-load-re-ordering-when-readi.patch +scsi-target-tcmu-fix-possible-page-uaf.patch +scsi-ibmvscsis-increase-initial_srp_limit-to-1024.patch +net-micrel-fix-ks8851_mll-kconfig.patch +ata-libata-core-disable-read-log-dma-ext-for-samsung.patch +gpu-ipu-v3-fix-dev_dbg-frequency-output.patch +scsi-mvsas-add-pci-id-of-rocketraid-2640.patch +drivers-net-slip-fix-npd-bug-in-sl_tx_timeout.patch diff --git a/queue-4.14/veth-ensure-eth-header-is-in-skb-s-linear-part.patch b/queue-4.14/veth-ensure-eth-header-is-in-skb-s-linear-part.patch new file mode 100644 index 00000000000..642368f4f6b --- /dev/null +++ b/queue-4.14/veth-ensure-eth-header-is-in-skb-s-linear-part.patch @@ -0,0 +1,72 @@ +From 94cf140008c2ef5ed58c3d742bfbf9bb6f99209f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 6 Apr 2022 16:18:54 +0200 +Subject: veth: Ensure eth header is in skb's linear part + +From: Guillaume Nault + +[ Upstream commit 726e2c5929de841fdcef4e2bf995680688ae1b87 ] + +After feeding a decapsulated packet to a veth device with act_mirred, +skb_headlen() may be 0. But veth_xmit() calls __dev_forward_skb(), +which expects at least ETH_HLEN byte of linear data (as +__dev_forward_skb2() calls eth_type_trans(), which pulls ETH_HLEN bytes +unconditionally). + +Use pskb_may_pull() to ensure veth_xmit() respects this constraint. + +kernel BUG at include/linux/skbuff.h:2328! +RIP: 0010:eth_type_trans+0xcf/0x140 +Call Trace: + + __dev_forward_skb2+0xe3/0x160 + veth_xmit+0x6e/0x250 [veth] + dev_hard_start_xmit+0xc7/0x200 + __dev_queue_xmit+0x47f/0x520 + ? skb_ensure_writable+0x85/0xa0 + ? skb_mpls_pop+0x98/0x1c0 + tcf_mirred_act+0x442/0x47e [act_mirred] + tcf_action_exec+0x86/0x140 + fl_classify+0x1d8/0x1e0 [cls_flower] + ? dma_pte_clear_level+0x129/0x1a0 + ? dma_pte_clear_level+0x129/0x1a0 + ? prb_fill_curr_block+0x2f/0xc0 + ? skb_copy_bits+0x11a/0x220 + __tcf_classify+0x58/0x110 + tcf_classify_ingress+0x6b/0x140 + __netif_receive_skb_core.constprop.0+0x47d/0xfd0 + ? __iommu_dma_unmap_swiotlb+0x44/0x90 + __netif_receive_skb_one_core+0x3d/0xa0 + netif_receive_skb+0x116/0x170 + be_process_rx+0x22f/0x330 [be2net] + be_poll+0x13c/0x370 [be2net] + __napi_poll+0x2a/0x170 + net_rx_action+0x22f/0x2f0 + __do_softirq+0xca/0x2a8 + __irq_exit_rcu+0xc1/0xe0 + common_interrupt+0x83/0xa0 + +Fixes: e314dbdc1c0d ("[NET]: Virtual ethernet device driver.") +Signed-off-by: Guillaume Nault +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/veth.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/net/veth.c b/drivers/net/veth.c +index a69ad39ee57e..f0b26768a639 100644 +--- a/drivers/net/veth.c ++++ b/drivers/net/veth.c +@@ -106,7 +106,7 @@ static netdev_tx_t veth_xmit(struct sk_buff *skb, struct net_device *dev) + + rcu_read_lock(); + rcv = rcu_dereference(priv->peer); +- if (unlikely(!rcv)) { ++ if (unlikely(!rcv) || !pskb_may_pull(skb, ETH_HLEN)) { + kfree_skb(skb); + goto drop; + } +-- +2.35.1 +