From: Sasha Levin Date: Mon, 18 Apr 2022 03:55:07 +0000 (-0400) Subject: Fixes for 5.4 X-Git-Tag: v4.9.311~38 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=0ebafd1a4e9a6966a28a3cceff8e914ea57f29f0;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 5.4 Signed-off-by: Sasha Levin --- diff --git a/queue-5.4/arm64-alternatives-mark-patch_alternative-as-noinstr.patch b/queue-5.4/arm64-alternatives-mark-patch_alternative-as-noinstr.patch new file mode 100644 index 00000000000..d2f5b02ae80 --- /dev/null +++ b/queue-5.4/arm64-alternatives-mark-patch_alternative-as-noinstr.patch @@ -0,0 +1,86 @@ +From 244e00ba932defa8c942ba7f261d26b229c2f2db Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 5 Apr 2022 11:47:33 +0100 +Subject: arm64: alternatives: mark patch_alternative() as `noinstr` + +From: Joey Gouly + +[ Upstream commit a2c0b0fbe01419f8f5d1c0b9c581631f34ffce8b ] + +The alternatives code must be `noinstr` such that it does not patch itself, +as the cache invalidation is only performed after all the alternatives have +been applied. + +Mark patch_alternative() as `noinstr`. Mark branch_insn_requires_update() +and get_alt_insn() with `__always_inline` since they are both only called +through patch_alternative(). + +Booting a kernel in QEMU TCG with KCSAN=y and ARM64_USE_LSE_ATOMICS=y caused +a boot hang: +[ 0.241121] CPU: All CPU(s) started at EL2 + +The alternatives code was patching the atomics in __tsan_read4() from LL/SC +atomics to LSE atomics. + +The following fragment is using LL/SC atomics in the .text section: + | <__tsan_unaligned_read4+304>: ldxr x6, [x2] + | <__tsan_unaligned_read4+308>: add x6, x6, x5 + | <__tsan_unaligned_read4+312>: stxr w7, x6, [x2] + | <__tsan_unaligned_read4+316>: cbnz w7, <__tsan_unaligned_read4+304> + +This LL/SC atomic sequence was to be replaced with LSE atomics. However since +the alternatives code was instrumentable, __tsan_read4() was being called after +only the first instruction was replaced, which led to the following code in memory: + | <__tsan_unaligned_read4+304>: ldadd x5, x6, [x2] + | <__tsan_unaligned_read4+308>: add x6, x6, x5 + | <__tsan_unaligned_read4+312>: stxr w7, x6, [x2] + | <__tsan_unaligned_read4+316>: cbnz w7, <__tsan_unaligned_read4+304> + +This caused an infinite loop as the `stxr` instruction never completed successfully, +so `w7` was always 0. + +Signed-off-by: Joey Gouly +Cc: Mark Rutland +Cc: Catalin Marinas +Cc: Will Deacon +Link: https://lore.kernel.org/r/20220405104733.11476-1-joey.gouly@arm.com +Signed-off-by: Will Deacon +Signed-off-by: Sasha Levin +--- + arch/arm64/kernel/alternative.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +diff --git a/arch/arm64/kernel/alternative.c b/arch/arm64/kernel/alternative.c +index 73039949b5ce..5f8e4c2df53c 100644 +--- a/arch/arm64/kernel/alternative.c ++++ b/arch/arm64/kernel/alternative.c +@@ -41,7 +41,7 @@ bool alternative_is_applied(u16 cpufeature) + /* + * Check if the target PC is within an alternative block. + */ +-static bool branch_insn_requires_update(struct alt_instr *alt, unsigned long pc) ++static __always_inline bool branch_insn_requires_update(struct alt_instr *alt, unsigned long pc) + { + unsigned long replptr = (unsigned long)ALT_REPL_PTR(alt); + return !(pc >= replptr && pc <= (replptr + alt->alt_len)); +@@ -49,7 +49,7 @@ static bool branch_insn_requires_update(struct alt_instr *alt, unsigned long pc) + + #define align_down(x, a) ((unsigned long)(x) & ~(((unsigned long)(a)) - 1)) + +-static u32 get_alt_insn(struct alt_instr *alt, __le32 *insnptr, __le32 *altinsnptr) ++static __always_inline u32 get_alt_insn(struct alt_instr *alt, __le32 *insnptr, __le32 *altinsnptr) + { + u32 insn; + +@@ -94,7 +94,7 @@ static u32 get_alt_insn(struct alt_instr *alt, __le32 *insnptr, __le32 *altinsnp + return insn; + } + +-static void patch_alternative(struct alt_instr *alt, ++static noinstr void patch_alternative(struct alt_instr *alt, + __le32 *origptr, __le32 *updptr, int nr_inst) + { + __le32 *replptr; +-- +2.35.1 + diff --git a/queue-5.4/ata-libata-core-disable-read-log-dma-ext-for-samsung.patch b/queue-5.4/ata-libata-core-disable-read-log-dma-ext-for-samsung.patch new file mode 100644 index 00000000000..3f8fce7525d --- /dev/null +++ b/queue-5.4/ata-libata-core-disable-read-log-dma-ext-for-samsung.patch @@ -0,0 +1,45 @@ +From ce9a278926198f3079dfb8dbcccaf4267fde0989 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 dca1590f295d..af8a1bac9345 100644 +--- a/drivers/ata/libata-core.c ++++ b/drivers/ata/libata-core.c +@@ -4580,6 +4580,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-5.4/cfg80211-hold-bss_lock-while-updating-nontrans_list.patch b/queue-5.4/cfg80211-hold-bss_lock-while-updating-nontrans_list.patch new file mode 100644 index 00000000000..c7ffaf9555e --- /dev/null +++ b/queue-5.4/cfg80211-hold-bss_lock-while-updating-nontrans_list.patch @@ -0,0 +1,45 @@ +From 5ed7ed81a973d43e1e518bc1bb57ffdeb2642250 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 11 Apr 2022 14:37:51 +0530 +Subject: cfg80211: hold bss_lock while updating nontrans_list + +From: Rameshkumar Sundaram + +[ Upstream commit a5199b5626cd6913cf8776a835bc63d40e0686ad ] + +Synchronize additions to nontrans_list of transmitting BSS with +bss_lock to avoid races. Also when cfg80211_add_nontrans_list() fails +__cfg80211_unlink_bss() needs bss_lock to be held (has lockdep assert +on bss_lock). So protect the whole block with bss_lock to avoid +races and warnings. Found during code review. + +Fixes: 0b8fb8235be8 ("cfg80211: Parsing of Multiple BSSID information in scanning") +Signed-off-by: Rameshkumar Sundaram +Link: https://lore.kernel.org/r/1649668071-9370-1-git-send-email-quic_ramess@quicinc.com +Signed-off-by: Johannes Berg +Signed-off-by: Sasha Levin +--- + net/wireless/scan.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/net/wireless/scan.c b/net/wireless/scan.c +index 6cefaad3b7f8..6bb9437af28b 100644 +--- a/net/wireless/scan.c ++++ b/net/wireless/scan.c +@@ -1457,11 +1457,13 @@ cfg80211_inform_single_bss_data(struct wiphy *wiphy, + /* this is a nontransmitting bss, we need to add it to + * transmitting bss' list if it is not there + */ ++ spin_lock_bh(&rdev->bss_lock); + if (cfg80211_add_nontrans_list(non_tx_data->tx_bss, + &res->pub)) { + if (__cfg80211_unlink_bss(rdev, res)) + rdev->bss_generation++; + } ++ spin_unlock_bh(&rdev->bss_lock); + } + + trace_cfg80211_return_bss(&res->pub); +-- +2.35.1 + diff --git a/queue-5.4/cifs-potential-buffer-overflow-in-handling-symlinks.patch b/queue-5.4/cifs-potential-buffer-overflow-in-handling-symlinks.patch new file mode 100644 index 00000000000..a616ecc431e --- /dev/null +++ b/queue-5.4/cifs-potential-buffer-overflow-in-handling-symlinks.patch @@ -0,0 +1,43 @@ +From adb416695d2fec4a0a3b67caf30015f6b7af940e 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 b736acd3917b..a24bcbbb5033 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-5.4/drivers-hv-vmbus-prevent-load-re-ordering-when-readi.patch b/queue-5.4/drivers-hv-vmbus-prevent-load-re-ordering-when-readi.patch new file mode 100644 index 00000000000..af851e3be19 --- /dev/null +++ b/queue-5.4/drivers-hv-vmbus-prevent-load-re-ordering-when-readi.patch @@ -0,0 +1,57 @@ +From 33187865635e237e432263bcd9504a42339f49e0 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 9a03b163cbbd..59f1e64908b1 100644 +--- a/drivers/hv/ring_buffer.c ++++ b/drivers/hv/ring_buffer.c +@@ -378,7 +378,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-5.4/drivers-net-slip-fix-npd-bug-in-sl_tx_timeout.patch b/queue-5.4/drivers-net-slip-fix-npd-bug-in-sl_tx_timeout.patch new file mode 100644 index 00000000000..dfaa57ff426 --- /dev/null +++ b/queue-5.4/drivers-net-slip-fix-npd-bug-in-sl_tx_timeout.patch @@ -0,0 +1,60 @@ +From 8920837f28ae31f8deffa45b4d4838a3747ab7b7 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 8e56a41dd758..096617982998 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-5.4/drm-amd-add-usbc-connector-id.patch b/queue-5.4/drm-amd-add-usbc-connector-id.patch new file mode 100644 index 00000000000..b78e225f9d8 --- /dev/null +++ b/queue-5.4/drm-amd-add-usbc-connector-id.patch @@ -0,0 +1,35 @@ +From e02e6ee414d1e6f8ef1a3e77c1944f9995609e65 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 5b393622f592..a0f0a17e224f 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-5.4/drm-amd-display-fix-allocate_mst_payload-assert-on-r.patch b/queue-5.4/drm-amd-display-fix-allocate_mst_payload-assert-on-r.patch new file mode 100644 index 00000000000..eb65c241602 --- /dev/null +++ b/queue-5.4/drm-amd-display-fix-allocate_mst_payload-assert-on-r.patch @@ -0,0 +1,46 @@ +From 2d318ecec8ac885bb79eab26bc7cdc4fde6d7e18 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 17 Mar 2022 19:55:05 -0400 +Subject: drm/amd/display: Fix allocate_mst_payload assert on resume + +From: Roman Li + +[ Upstream commit f4346fb3edf7720db3f7f5e1cab1f667cd024280 ] + +[Why] +On resume we do link detection for all non-MST connectors. +MST is handled separately. However the condition for telling +if connector is on mst branch is not enough for mst hub case. +Link detection for mst branch link leads to mst topology reset. +That causes assert in dc_link_allocate_mst_payload() + +[How] +Use link type as indicator for mst link. + +Reviewed-by: Wayne Lin +Acked-by: Alex Hung +Signed-off-by: Roman Li +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +index c5231c50c412..de33864af70b 100644 +--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c ++++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +@@ -1210,7 +1210,8 @@ static int dm_resume(void *handle) + * this is the case when traversing through already created + * MST connectors, should be skipped + */ +- if (aconnector->mst_port) ++ if (aconnector->dc_link && ++ aconnector->dc_link->type == dc_connection_mst_branch) + continue; + + mutex_lock(&aconnector->hpd_lock); +-- +2.35.1 + diff --git a/queue-5.4/drm-amd-display-fix-audio-format-not-updated-after-e.patch b/queue-5.4/drm-amd-display-fix-audio-format-not-updated-after-e.patch new file mode 100644 index 00000000000..d44af2ed844 --- /dev/null +++ b/queue-5.4/drm-amd-display-fix-audio-format-not-updated-after-e.patch @@ -0,0 +1,42 @@ +From 5d252211935678d9a7325cf0ff1887a485a12552 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 7 Mar 2022 18:31:29 -0500 +Subject: drm/amd/display: fix audio format not updated after edid updated + +From: Charlene Liu + +[ Upstream commit 5e8a71cf13bc9184fee915b2220be71b4c6cac74 ] + +[why] +for the case edid change only changed audio format. +driver still need to update stream. + +Reviewed-by: Alvin Lee +Reviewed-by: Aric Cyr +Acked-by: Alex Hung +Signed-off-by: Charlene Liu +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/amd/display/dc/core/dc_resource.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c +index 95a5310e9e66..de246e183d6b 100644 +--- a/drivers/gpu/drm/amd/display/dc/core/dc_resource.c ++++ b/drivers/gpu/drm/amd/display/dc/core/dc_resource.c +@@ -1546,8 +1546,8 @@ bool dc_is_stream_unchanged( + if (old_stream->ignore_msa_timing_param != stream->ignore_msa_timing_param) + return false; + +- // Only Have Audio left to check whether it is same or not. This is a corner case for Tiled sinks +- if (old_stream->audio_info.mode_count != stream->audio_info.mode_count) ++ /*compare audio info*/ ++ if (memcmp(&old_stream->audio_info, &stream->audio_info, sizeof(stream->audio_info)) != 0) + return false; + + return true; +-- +2.35.1 + diff --git a/queue-5.4/drm-amd-display-update-vtem-infopacket-definition.patch b/queue-5.4/drm-amd-display-update-vtem-infopacket-definition.patch new file mode 100644 index 00000000000..1988524e6e3 --- /dev/null +++ b/queue-5.4/drm-amd-display-update-vtem-infopacket-definition.patch @@ -0,0 +1,50 @@ +From da8fb31ee2af379aab0fd1877d3cfd611ad943cc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 11 Mar 2022 11:35:29 -0500 +Subject: drm/amd/display: Update VTEM Infopacket definition + +From: Leo (Hanghong) Ma + +[ Upstream commit c9fbf6435162ed5fb7201d1d4adf6585c6a8c327 ] + +[Why & How] +The latest HDMI SPEC has updated the VTEM packet structure, +so change the VTEM Infopacket defined in the driver side to align +with the SPEC. + +Reviewed-by: Chris Park +Acked-by: Alex Hung +Signed-off-by: Leo (Hanghong) Ma +Tested-by: Daniel Wheeler +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + .../gpu/drm/amd/display/modules/info_packet/info_packet.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +diff --git a/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c b/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c +index d885d642ed7f..537736713598 100644 +--- a/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c ++++ b/drivers/gpu/drm/amd/display/modules/info_packet/info_packet.c +@@ -85,7 +85,8 @@ + //PB7 = MD0 + #define MASK_VTEM_MD0__VRR_EN 0x01 + #define MASK_VTEM_MD0__M_CONST 0x02 +-#define MASK_VTEM_MD0__RESERVED2 0x0C ++#define MASK_VTEM_MD0__QMS_EN 0x04 ++#define MASK_VTEM_MD0__RESERVED2 0x08 + #define MASK_VTEM_MD0__FVA_FACTOR_M1 0xF0 + + //MD1 +@@ -94,7 +95,7 @@ + //MD2 + #define MASK_VTEM_MD2__BASE_REFRESH_RATE_98 0x03 + #define MASK_VTEM_MD2__RB 0x04 +-#define MASK_VTEM_MD2__RESERVED3 0xF8 ++#define MASK_VTEM_MD2__NEXT_TFR 0xF8 + + //MD3 + #define MASK_VTEM_MD3__BASE_REFRESH_RATE_07 0xFF +-- +2.35.1 + diff --git a/queue-5.4/drm-amdkfd-check-for-potential-null-return-of-kmallo.patch b/queue-5.4/drm-amdkfd-check-for-potential-null-return-of-kmallo.patch new file mode 100644 index 00000000000..a66d34a0907 --- /dev/null +++ b/queue-5.4/drm-amdkfd-check-for-potential-null-return-of-kmallo.patch @@ -0,0 +1,35 @@ +From a6fc27372ee295e514588857fadda87d029fd119 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 d674d4b3340f..adbb2fec2e0f 100644 +--- a/drivers/gpu/drm/amd/amdkfd/kfd_events.c ++++ b/drivers/gpu/drm/amd/amdkfd/kfd_events.c +@@ -532,6 +532,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_wait(&event_waiters[i].wait); +-- +2.35.1 + diff --git a/queue-5.4/drm-amdkfd-fix-incorrect-vmids-passed-to-hws.patch b/queue-5.4/drm-amdkfd-fix-incorrect-vmids-passed-to-hws.patch new file mode 100644 index 00000000000..26e9bc9fc78 --- /dev/null +++ b/queue-5.4/drm-amdkfd-fix-incorrect-vmids-passed-to-hws.patch @@ -0,0 +1,62 @@ +From 07f3459112e0211e881174dd5a12e198d44fdbfe Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 17 Mar 2022 15:31:22 -0400 +Subject: drm/amdkfd: Fix Incorrect VMIDs passed to HWS + +From: Tushar Patel + +[ Upstream commit b7dfbd2e601f3fee545bc158feceba4f340fe7cf ] + +Compute-only GPUs have more than 8 VMIDs allocated to KFD. Fix +this by passing correct number of VMIDs to HWS + +v2: squash in warning fix (Alex) + +Signed-off-by: Tushar Patel +Reviewed-by: Felix Kuehling +Signed-off-by: Alex Deucher +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- + drivers/gpu/drm/amd/amdkfd/kfd_device.c | 11 +++-------- + 2 files changed, 4 insertions(+), 9 deletions(-) + +diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +index e8e172010416..ffd754713522 100644 +--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c ++++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c +@@ -633,7 +633,7 @@ MODULE_PARM_DESC(sched_policy, + * Maximum number of processes that HWS can schedule concurrently. The maximum is the + * number of VMIDs assigned to the HWS, which is also the default. + */ +-int hws_max_conc_proc = 8; ++int hws_max_conc_proc = -1; + module_param(hws_max_conc_proc, int, 0444); + MODULE_PARM_DESC(hws_max_conc_proc, + "Max # processes HWS can execute concurrently when sched_policy=0 (0 = no concurrency, #VMIDs for KFD = Maximum(default))"); +diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c b/drivers/gpu/drm/amd/amdkfd/kfd_device.c +index ad9483b9eea3..60ee1a832112 100644 +--- a/drivers/gpu/drm/amd/amdkfd/kfd_device.c ++++ b/drivers/gpu/drm/amd/amdkfd/kfd_device.c +@@ -609,15 +609,10 @@ bool kgd2kfd_device_init(struct kfd_dev *kfd, + - kfd->vm_info.first_vmid_kfd + 1; + + /* Verify module parameters regarding mapped process number*/ +- if ((hws_max_conc_proc < 0) +- || (hws_max_conc_proc > kfd->vm_info.vmid_num_kfd)) { +- dev_err(kfd_device, +- "hws_max_conc_proc %d must be between 0 and %d, use %d instead\n", +- hws_max_conc_proc, kfd->vm_info.vmid_num_kfd, +- kfd->vm_info.vmid_num_kfd); ++ if (hws_max_conc_proc >= 0) ++ kfd->max_proc_per_quantum = min((u32)hws_max_conc_proc, kfd->vm_info.vmid_num_kfd); ++ else + kfd->max_proc_per_quantum = kfd->vm_info.vmid_num_kfd; +- } else +- kfd->max_proc_per_quantum = hws_max_conc_proc; + + /* Allocate global GWS that is shared by all KFD processes */ + if (hws_gws_support && amdgpu_amdkfd_alloc_gws(kfd->kgd, +-- +2.35.1 + diff --git a/queue-5.4/drm-msm-dsi-use-connector-directly-in-msm_dsi_manage.patch b/queue-5.4/drm-msm-dsi-use-connector-directly-in-msm_dsi_manage.patch new file mode 100644 index 00000000000..6e9b80abd37 --- /dev/null +++ b/queue-5.4/drm-msm-dsi-use-connector-directly-in-msm_dsi_manage.patch @@ -0,0 +1,45 @@ +From b2ff2b043064cd521caf7dc0158398824997115b Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 17 Mar 2022 17:07:31 -0700 +Subject: drm/msm/dsi: Use connector directly in + msm_dsi_manager_connector_init() + +From: Stephen Boyd + +[ Upstream commit 47b7de6b88b962ef339a2427a023d2a23d161654 ] + +The member 'msm_dsi->connector' isn't assigned until +msm_dsi_manager_connector_init() returns (see msm_dsi_modeset_init() and +how it assigns the return value). Therefore this pointer is going to be +NULL here. Let's use 'connector' which is what was intended. + +Cc: Dmitry Baryshkov +Cc: Sean Paul +Fixes: 6d5e78406991 ("drm/msm/dsi: Move dsi panel init into modeset init path") +Signed-off-by: Stephen Boyd +Reviewed-by: Dmitry Baryshkov +Patchwork: https://patchwork.freedesktop.org/patch/478693/ +Link: https://lore.kernel.org/r/20220318000731.2823718-1-swboyd@chromium.org +Signed-off-by: Dmitry Baryshkov +Signed-off-by: Rob Clark +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c b/drivers/gpu/drm/msm/dsi/dsi_manager.c +index 73127948f54d..f3ff2cdc288b 100644 +--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c ++++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c +@@ -625,7 +625,7 @@ struct drm_connector *msm_dsi_manager_connector_init(u8 id) + return connector; + + fail: +- connector->funcs->destroy(msm_dsi->connector); ++ connector->funcs->destroy(connector); + return ERR_PTR(ret); + } + +-- +2.35.1 + diff --git a/queue-5.4/gpiolib-acpi-use-correct-format-characters.patch b/queue-5.4/gpiolib-acpi-use-correct-format-characters.patch new file mode 100644 index 00000000000..989451a853a --- /dev/null +++ b/queue-5.4/gpiolib-acpi-use-correct-format-characters.patch @@ -0,0 +1,97 @@ +From fe63afc1911696cc2829ee96cb30bf9cf46b6824 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 13c6eee481da..d71c7b9b9665 100644 +--- a/drivers/gpio/gpiolib-acpi.c ++++ b/drivers/gpio/gpiolib-acpi.c +@@ -275,8 +275,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-5.4/gpu-ipu-v3-fix-dev_dbg-frequency-output.patch b/queue-5.4/gpu-ipu-v3-fix-dev_dbg-frequency-output.patch new file mode 100644 index 00000000000..4391d175757 --- /dev/null +++ b/queue-5.4/gpu-ipu-v3-fix-dev_dbg-frequency-output.patch @@ -0,0 +1,53 @@ +From d9a60d6e35ee583282397b7a65471595c1d316ff 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 b4a31d506fcc..74eca68891ad 100644 +--- a/drivers/gpu/ipu-v3/ipu-di.c ++++ b/drivers/gpu/ipu-v3/ipu-di.c +@@ -451,8 +451,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-5.4/memory-atmel-ebi-fix-missing-of_node_put-in-atmel_eb.patch b/queue-5.4/memory-atmel-ebi-fix-missing-of_node_put-in-atmel_eb.patch new file mode 100644 index 00000000000..5802b4c1344 --- /dev/null +++ b/queue-5.4/memory-atmel-ebi-fix-missing-of_node_put-in-atmel_eb.patch @@ -0,0 +1,74 @@ +From 126aba62630ae7e74af65261fe361b50b9ee391a 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 89646896a183..6f9cf6270a43 100644 +--- a/drivers/memory/atmel-ebi.c ++++ b/drivers/memory/atmel-ebi.c +@@ -545,20 +545,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; +@@ -609,6 +616,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-5.4/mlxsw-i2c-fix-initialization-error-flow.patch b/queue-5.4/mlxsw-i2c-fix-initialization-error-flow.patch new file mode 100644 index 00000000000..a5f9f84e2a0 --- /dev/null +++ b/queue-5.4/mlxsw-i2c-fix-initialization-error-flow.patch @@ -0,0 +1,36 @@ +From b4d1e8bd5fe57b4ac8fd3c97ee3b807b167cc068 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 95f408d0e103..7cc4c30af1a7 100644 +--- a/drivers/net/ethernet/mellanox/mlxsw/i2c.c ++++ b/drivers/net/ethernet/mellanox/mlxsw/i2c.c +@@ -649,6 +649,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-5.4/net-ethernet-stmmac-fix-altr_tse_pcs-function-when-u.patch b/queue-5.4/net-ethernet-stmmac-fix-altr_tse_pcs-function-when-u.patch new file mode 100644 index 00000000000..2158e92fd17 --- /dev/null +++ b/queue-5.4/net-ethernet-stmmac-fix-altr_tse_pcs-function-when-u.patch @@ -0,0 +1,120 @@ +From d8233318ddb8cbaf1b783fe587d0099a4237a461 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 cd478d2cd871..00f6d347eaf7 100644 +--- a/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c ++++ b/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.c +@@ -57,10 +57,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) +@@ -202,12 +198,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 442812c0a4bd..694ac25ef426 100644 +--- a/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h ++++ b/drivers/net/ethernet/stmicro/stmmac/altr_tse_pcs.h +@@ -10,6 +10,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 70d41783329d..72e47621d27c 100644 +--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c ++++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c +@@ -18,9 +18,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 +@@ -62,16 +59,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); +@@ -93,7 +88,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-5.4/net-micrel-fix-ks8851_mll-kconfig.patch b/queue-5.4/net-micrel-fix-ks8851_mll-kconfig.patch new file mode 100644 index 00000000000..4d440aad79a --- /dev/null +++ b/queue-5.4/net-micrel-fix-ks8851_mll-kconfig.patch @@ -0,0 +1,50 @@ +From 27d50803c7d2d68273804c737ead0811067943b4 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 b9c4d48e28e4..120ed4633a09 100644 +--- a/drivers/net/ethernet/micrel/Kconfig ++++ b/drivers/net/ethernet/micrel/Kconfig +@@ -37,6 +37,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-5.4/net-sched-fix-initialization-order-when-updating-cha.patch b/queue-5.4/net-sched-fix-initialization-order-when-updating-cha.patch new file mode 100644 index 00000000000..a8d0e0e3060 --- /dev/null +++ b/queue-5.4/net-sched-fix-initialization-order-when-updating-cha.patch @@ -0,0 +1,66 @@ +From 6aac5024453e201cd4e1445e79a451f22f768d40 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 7 Apr 2022 11:29:23 -0300 +Subject: net/sched: fix initialization order when updating chain 0 head + +From: Marcelo Ricardo Leitner + +[ Upstream commit e65812fd22eba32f11abe28cb377cbd64cfb1ba0 ] + +Currently, when inserting a new filter that needs to sit at the head +of chain 0, it will first update the heads pointer on all devices using +the (shared) block, and only then complete the initialization of the new +element so that it has a "next" element. + +This can lead to a situation that the chain 0 head is propagated to +another CPU before the "next" initialization is done. When this race +condition is triggered, packets being matched on that CPU will simply +miss all other filters, and will flow through the stack as if there were +no other filters installed. If the system is using OVS + TC, such +packets will get handled by vswitchd via upcall, which results in much +higher latency and reordering. For other applications it may result in +packet drops. + +This is reproducible with a tc only setup, but it varies from system to +system. It could be reproduced with a shared block amongst 10 veth +tunnels, and an ingress filter mirroring packets to another veth. +That's because using the last added veth tunnel to the shared block to +do the actual traffic, it makes the race window bigger and easier to +trigger. + +The fix is rather simple, to just initialize the next pointer of the new +filter instance (tp) before propagating the head change. + +The fixes tag is pointing to the original code though this issue should +only be observed when using it unlocked. + +Fixes: 2190d1d0944f ("net: sched: introduce helpers to work with filter chains") +Signed-off-by: Marcelo Ricardo Leitner +Signed-off-by: Vlad Buslov +Reviewed-by: Davide Caratti +Link: https://lore.kernel.org/r/b97d5f4eaffeeb9d058155bcab63347527261abf.1649341369.git.marcelo.leitner@gmail.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/sched/cls_api.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c +index 80205b138d11..919c7fa5f02d 100644 +--- a/net/sched/cls_api.c ++++ b/net/sched/cls_api.c +@@ -1639,10 +1639,10 @@ static int tcf_chain_tp_insert(struct tcf_chain *chain, + if (chain->flushing) + return -EAGAIN; + ++ RCU_INIT_POINTER(tp->next, tcf_chain_tp_prev(chain, chain_info)); + if (*chain_info->pprev == chain->filter_chain) + tcf_chain0_head_change(chain, tp); + tcf_proto_get(tp); +- RCU_INIT_POINTER(tp->next, tcf_chain_tp_prev(chain, chain_info)); + rcu_assign_pointer(*chain_info->pprev, tp); + + return 0; +-- +2.35.1 + diff --git a/queue-5.4/net-sched-flower-fix-parsing-of-ethertype-following-.patch b/queue-5.4/net-sched-flower-fix-parsing-of-ethertype-following-.patch new file mode 100644 index 00000000000..f05c9ea1f79 --- /dev/null +++ b/queue-5.4/net-sched-flower-fix-parsing-of-ethertype-following-.patch @@ -0,0 +1,132 @@ +From 218b9812310dac2a16639449ef488e93a3406621 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 6 Apr 2022 14:22:41 +0300 +Subject: net/sched: flower: fix parsing of ethertype following VLAN header + +From: Vlad Buslov + +[ Upstream commit 2105f700b53c24aa48b65c15652acc386044d26a ] + +A tc flower filter matching TCA_FLOWER_KEY_VLAN_ETH_TYPE is expected to +match the L2 ethertype following the first VLAN header, as confirmed by +linked discussion with the maintainer. However, such rule also matches +packets that have additional second VLAN header, even though filter has +both eth_type and vlan_ethtype set to "ipv4". Looking at the code this +seems to be mostly an artifact of the way flower uses flow dissector. +First, even though looking at the uAPI eth_type and vlan_ethtype appear +like a distinct fields, in flower they are all mapped to the same +key->basic.n_proto. Second, flow dissector skips following VLAN header as +no keys for FLOW_DISSECTOR_KEY_CVLAN are set and eventually assigns the +value of n_proto to last parsed header. With these, such filters ignore any +headers present between first VLAN header and first "non magic" +header (ipv4 in this case) that doesn't result +FLOW_DISSECT_RET_PROTO_AGAIN. + +Fix the issue by extending flow dissector VLAN key structure with new +'vlan_eth_type' field that matches first ethertype following previously +parsed VLAN header. Modify flower classifier to set the new +flow_dissector_key_vlan->vlan_eth_type with value obtained from +TCA_FLOWER_KEY_VLAN_ETH_TYPE/TCA_FLOWER_KEY_CVLAN_ETH_TYPE uAPIs. + +Link: https://lore.kernel.org/all/Yjhgi48BpTGh6dig@nanopsycho/ +Fixes: 9399ae9a6cb2 ("net_sched: flower: Add vlan support") +Fixes: d64efd0926ba ("net/sched: flower: Add supprt for matching on QinQ vlan headers") +Signed-off-by: Vlad Buslov +Reviewed-by: Jiri Pirko +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + include/net/flow_dissector.h | 2 ++ + net/core/flow_dissector.c | 1 + + net/sched/cls_flower.c | 18 +++++++++++++----- + 3 files changed, 16 insertions(+), 5 deletions(-) + +diff --git a/include/net/flow_dissector.h b/include/net/flow_dissector.h +index 78f6437cbc3a..02171416c68e 100644 +--- a/include/net/flow_dissector.h ++++ b/include/net/flow_dissector.h +@@ -51,6 +51,8 @@ struct flow_dissector_key_vlan { + vlan_dei:1, + vlan_priority:3; + __be16 vlan_tpid; ++ __be16 vlan_eth_type; ++ u16 padding; + }; + + struct flow_dissector_key_mpls { +diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c +index b740a74f06f2..4dac27c98623 100644 +--- a/net/core/flow_dissector.c ++++ b/net/core/flow_dissector.c +@@ -1149,6 +1149,7 @@ bool __skb_flow_dissect(const struct net *net, + VLAN_PRIO_MASK) >> VLAN_PRIO_SHIFT; + } + key_vlan->vlan_tpid = saved_vlan_tpid; ++ key_vlan->vlan_eth_type = proto; + } + + fdret = FLOW_DISSECT_RET_PROTO_AGAIN; +diff --git a/net/sched/cls_flower.c b/net/sched/cls_flower.c +index 26979b4853bd..007fbc199352 100644 +--- a/net/sched/cls_flower.c ++++ b/net/sched/cls_flower.c +@@ -784,6 +784,7 @@ static int fl_set_key_mpls(struct nlattr **tb, + static void fl_set_key_vlan(struct nlattr **tb, + __be16 ethertype, + int vlan_id_key, int vlan_prio_key, ++ int vlan_next_eth_type_key, + struct flow_dissector_key_vlan *key_val, + struct flow_dissector_key_vlan *key_mask) + { +@@ -802,6 +803,11 @@ static void fl_set_key_vlan(struct nlattr **tb, + } + key_val->vlan_tpid = ethertype; + key_mask->vlan_tpid = cpu_to_be16(~0); ++ if (tb[vlan_next_eth_type_key]) { ++ key_val->vlan_eth_type = ++ nla_get_be16(tb[vlan_next_eth_type_key]); ++ key_mask->vlan_eth_type = cpu_to_be16(~0); ++ } + } + + static void fl_set_key_flag(u32 flower_key, u32 flower_mask, +@@ -1076,8 +1082,9 @@ static int fl_set_key(struct net *net, struct nlattr **tb, + + if (eth_type_vlan(ethertype)) { + fl_set_key_vlan(tb, ethertype, TCA_FLOWER_KEY_VLAN_ID, +- TCA_FLOWER_KEY_VLAN_PRIO, &key->vlan, +- &mask->vlan); ++ TCA_FLOWER_KEY_VLAN_PRIO, ++ TCA_FLOWER_KEY_VLAN_ETH_TYPE, ++ &key->vlan, &mask->vlan); + + if (tb[TCA_FLOWER_KEY_VLAN_ETH_TYPE]) { + ethertype = nla_get_be16(tb[TCA_FLOWER_KEY_VLAN_ETH_TYPE]); +@@ -1085,6 +1092,7 @@ static int fl_set_key(struct net *net, struct nlattr **tb, + fl_set_key_vlan(tb, ethertype, + TCA_FLOWER_KEY_CVLAN_ID, + TCA_FLOWER_KEY_CVLAN_PRIO, ++ TCA_FLOWER_KEY_CVLAN_ETH_TYPE, + &key->cvlan, &mask->cvlan); + fl_set_key_val(tb, &key->basic.n_proto, + TCA_FLOWER_KEY_CVLAN_ETH_TYPE, +@@ -2272,13 +2280,13 @@ static int fl_dump_key(struct sk_buff *skb, struct net *net, + goto nla_put_failure; + + if (mask->basic.n_proto) { +- if (mask->cvlan.vlan_tpid) { ++ if (mask->cvlan.vlan_eth_type) { + if (nla_put_be16(skb, TCA_FLOWER_KEY_CVLAN_ETH_TYPE, + key->basic.n_proto)) + goto nla_put_failure; +- } else if (mask->vlan.vlan_tpid) { ++ } else if (mask->vlan.vlan_eth_type) { + if (nla_put_be16(skb, TCA_FLOWER_KEY_VLAN_ETH_TYPE, +- key->basic.n_proto)) ++ key->vlan.vlan_eth_type)) + goto nla_put_failure; + } + } +-- +2.35.1 + diff --git a/queue-5.4/net-sched-taprio-check-if-socket-flags-are-valid.patch b/queue-5.4/net-sched-taprio-check-if-socket-flags-are-valid.patch new file mode 100644 index 00000000000..f33c94177a3 --- /dev/null +++ b/queue-5.4/net-sched-taprio-check-if-socket-flags-are-valid.patch @@ -0,0 +1,48 @@ +From f82b03d432ddaf27a9c6ee708e99fcccbd6f3ab9 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 8 Apr 2022 11:47:45 +0200 +Subject: net/sched: taprio: Check if socket flags are valid + +From: Benedikt Spranger + +[ Upstream commit e8a64bbaaad1f6548cec5508297bc6d45e8ab69e ] + +A user may set the SO_TXTIME socket option to ensure a packet is send +at a given time. The taprio scheduler has to confirm, that it is allowed +to send a packet at that given time, by a check against the packet time +schedule. The scheduler drop the packet, if the gates are closed at the +given send time. + +The check, if SO_TXTIME is set, may fail since sk_flags are part of an +union and the union is used otherwise. This happen, if a socket is not +a full socket, like a request socket for example. + +Add a check to verify, if the union is used for sk_flags. + +Fixes: 4cfd5779bd6e ("taprio: Add support for txtime-assist mode") +Signed-off-by: Benedikt Spranger +Reviewed-by: Kurt Kanzenbach +Acked-by: Vinicius Costa Gomes +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + net/sched/sch_taprio.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/net/sched/sch_taprio.c b/net/sched/sch_taprio.c +index b268e6130451..4c26f7fb32b3 100644 +--- a/net/sched/sch_taprio.c ++++ b/net/sched/sch_taprio.c +@@ -427,7 +427,8 @@ static int taprio_enqueue(struct sk_buff *skb, struct Qdisc *sch, + if (unlikely(!child)) + return qdisc_drop(skb, sch, to_free); + +- if (skb->sk && sock_flag(skb->sk, SOCK_TXTIME)) { ++ /* sk_flags are only safe to use on full sockets. */ ++ if (skb->sk && sk_fullsock(skb->sk) && sock_flag(skb->sk, SOCK_TXTIME)) { + if (!is_valid_interval(skb, sch)) + return qdisc_drop(skb, sch, to_free); + } else if (TXTIME_ASSIST_IS_ENABLED(q->flags)) { +-- +2.35.1 + diff --git a/queue-5.4/net-smc-fix-null-pointer-dereference-in-smc_pnet_fin.patch b/queue-5.4/net-smc-fix-null-pointer-dereference-in-smc_pnet_fin.patch new file mode 100644 index 00000000000..79bfa6d30ff --- /dev/null +++ b/queue-5.4/net-smc-fix-null-pointer-dereference-in-smc_pnet_fin.patch @@ -0,0 +1,41 @@ +From a0599b243824a2c5fe952d6fbdbe4bddc9635687 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 8 Apr 2022 17:10:34 +0200 +Subject: net/smc: Fix NULL pointer dereference in smc_pnet_find_ib() + +From: Karsten Graul + +[ Upstream commit d22f4f977236f97e01255a80bca2ea93a8094fc8 ] + +dev_name() was called with dev.parent as argument but without to +NULL-check it before. +Solve this by checking the pointer before the call to dev_name(). + +Fixes: af5f60c7e3d5 ("net/smc: allow PCI IDs as ib device names in the pnet table") +Reported-by: syzbot+03e3e228510223dabd34@syzkaller.appspotmail.com +Signed-off-by: Karsten Graul +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/smc/smc_pnet.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +diff --git a/net/smc/smc_pnet.c b/net/smc/smc_pnet.c +index 571e6d84da3b..660608202f28 100644 +--- a/net/smc/smc_pnet.c ++++ b/net/smc/smc_pnet.c +@@ -295,8 +295,9 @@ static struct smc_ib_device *smc_pnet_find_ib(char *ib_name) + list_for_each_entry(ibdev, &smc_ib_devices.list, list) { + if (!strncmp(ibdev->ibdev->name, ib_name, + sizeof(ibdev->ibdev->name)) || +- !strncmp(dev_name(ibdev->ibdev->dev.parent), ib_name, +- IB_DEVICE_NAME_MAX - 1)) { ++ (ibdev->ibdev->dev.parent && ++ !strncmp(dev_name(ibdev->ibdev->dev.parent), ib_name, ++ IB_DEVICE_NAME_MAX - 1))) { + goto out; + } + } +-- +2.35.1 + diff --git a/queue-5.4/net-usb-aqc111-fix-out-of-bounds-accesses-in-rx-fixu.patch b/queue-5.4/net-usb-aqc111-fix-out-of-bounds-accesses-in-rx-fixu.patch new file mode 100644 index 00000000000..40e8d34417d --- /dev/null +++ b/queue-5.4/net-usb-aqc111-fix-out-of-bounds-accesses-in-rx-fixu.patch @@ -0,0 +1,56 @@ +From 8d94c6e5272f742514b256f87ab424428d157254 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 6 Apr 2022 10:05:37 +0200 +Subject: net: usb: aqc111: Fix out-of-bounds accesses in RX fixup + +From: Marcin Kozlowski + +[ Upstream commit afb8e246527536848b9b4025b40e613edf776a9d ] + +aqc111_rx_fixup() contains several out-of-bounds accesses that can be +triggered by a malicious (or defective) USB device, in particular: + + - The metadata array (desc_offset..desc_offset+2*pkt_count) can be out of bounds, + causing OOB reads and (on big-endian systems) OOB endianness flips. + - A packet can overlap the metadata array, causing a later OOB + endianness flip to corrupt data used by a cloned SKB that has already + been handed off into the network stack. + - A packet SKB can be constructed whose tail is far beyond its end, + causing out-of-bounds heap data to be considered part of the SKB's + data. + +Found doing variant analysis. Tested it with another driver (ax88179_178a), since +I don't have a aqc111 device to test it, but the code looks very similar. + +Signed-off-by: Marcin Kozlowski +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/usb/aqc111.c | 9 +++++++-- + 1 file changed, 7 insertions(+), 2 deletions(-) + +diff --git a/drivers/net/usb/aqc111.c b/drivers/net/usb/aqc111.c +index 7e44110746dd..68912e266826 100644 +--- a/drivers/net/usb/aqc111.c ++++ b/drivers/net/usb/aqc111.c +@@ -1102,10 +1102,15 @@ static int aqc111_rx_fixup(struct usbnet *dev, struct sk_buff *skb) + if (start_of_descs != desc_offset) + goto err; + +- /* self check desc_offset from header*/ +- if (desc_offset >= skb_len) ++ /* self check desc_offset from header and make sure that the ++ * bounds of the metadata array are inside the SKB ++ */ ++ if (pkt_count * 2 + desc_offset >= skb_len) + goto err; + ++ /* Packets must not overlap the metadata array */ ++ skb_trim(skb, desc_offset); ++ + if (pkt_count == 0) + goto err; + +-- +2.35.1 + diff --git a/queue-5.4/nfc-nci-add-flush_workqueue-to-prevent-uaf.patch b/queue-5.4/nfc-nci-add-flush_workqueue-to-prevent-uaf.patch new file mode 100644 index 00000000000..14e3f56e74d --- /dev/null +++ b/queue-5.4/nfc-nci-add-flush_workqueue-to-prevent-uaf.patch @@ -0,0 +1,128 @@ +From 1ba6e3026ea19a724a6c5473d585328e1bfa3302 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 b8ecb002e623..b2e922fcc70d 100644 +--- a/net/nfc/nci/core.c ++++ b/net/nfc/nci/core.c +@@ -548,6 +548,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-5.4/perf-imx_ddr-fix-undefined-behavior-due-to-shift-ove.patch b/queue-5.4/perf-imx_ddr-fix-undefined-behavior-due-to-shift-ove.patch new file mode 100644 index 00000000000..aa18504ae64 --- /dev/null +++ b/queue-5.4/perf-imx_ddr-fix-undefined-behavior-due-to-shift-ove.patch @@ -0,0 +1,60 @@ +From e16ef8d3078199d3380bfe351843e1ab86673ab3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 5 Apr 2022 17:15:15 +0200 +Subject: perf/imx_ddr: Fix undefined behavior due to shift overflowing the + constant +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Borislav Petkov + +[ Upstream commit d02b4dd84e1a90f7f1444d027c0289bf355b0d5a ] + +Fix: + + In file included from :0:0: + In function ‘ddr_perf_counter_enable’, + inlined from ‘ddr_perf_irq_handler’ at drivers/perf/fsl_imx8_ddr_perf.c:651:2: + ././include/linux/compiler_types.h:352:38: error: call to ‘__compiletime_assert_729’ \ + declared with attribute error: FIELD_PREP: mask is not constant + _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) +... + +See https://lore.kernel.org/r/YkwQ6%2BtIH8GQpuct@zn.tnic for the gory +details as to why it triggers with older gccs only. + +Signed-off-by: Borislav Petkov +Cc: Frank Li +Cc: Will Deacon +Cc: Mark Rutland +Cc: Shawn Guo +Cc: Sascha Hauer +Cc: Pengutronix Kernel Team +Cc: Fabio Estevam +Cc: NXP Linux Team +Cc: linux-arm-kernel@lists.infradead.org +Acked-by: Will Deacon +Link: https://lore.kernel.org/r/20220405151517.29753-10-bp@alien8.de +Signed-off-by: Will Deacon +Signed-off-by: Sasha Levin +--- + drivers/perf/fsl_imx8_ddr_perf.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/perf/fsl_imx8_ddr_perf.c b/drivers/perf/fsl_imx8_ddr_perf.c +index 726ed8f59868..912a220a9db9 100644 +--- a/drivers/perf/fsl_imx8_ddr_perf.c ++++ b/drivers/perf/fsl_imx8_ddr_perf.c +@@ -29,7 +29,7 @@ + #define CNTL_OVER_MASK 0xFFFFFFFE + + #define CNTL_CSV_SHIFT 24 +-#define CNTL_CSV_MASK (0xFF << CNTL_CSV_SHIFT) ++#define CNTL_CSV_MASK (0xFFU << CNTL_CSV_SHIFT) + + #define EVENT_CYCLES_ID 0 + #define EVENT_CYCLES_COUNTER 0 +-- +2.35.1 + diff --git a/queue-5.4/powerpc-fix-virt_addr_valid-for-64-bit-book3e-32-bit.patch b/queue-5.4/powerpc-fix-virt_addr_valid-for-64-bit-book3e-32-bit.patch new file mode 100644 index 00000000000..4d1f6dd1a96 --- /dev/null +++ b/queue-5.4/powerpc-fix-virt_addr_valid-for-64-bit-book3e-32-bit.patch @@ -0,0 +1,96 @@ +From be09e09204632bc111facb08d80c72f92f059668 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 7 Apr 2022 00:57:57 +1000 +Subject: powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit + +From: Kefeng Wang + +[ Upstream commit ffa0b64e3be58519ae472ea29a1a1ad681e32f48 ] + +mpe: On 64-bit Book3E vmalloc space starts at 0x8000000000000000. + +Because of the way __pa() works we have: + __pa(0x8000000000000000) == 0, and therefore + virt_to_pfn(0x8000000000000000) == 0, and therefore + virt_addr_valid(0x8000000000000000) == true + +Which is wrong, virt_addr_valid() should be false for vmalloc space. +In fact all vmalloc addresses that alias with a valid PFN will return +true from virt_addr_valid(). That can cause bugs with hardened usercopy +as described below by Kefeng Wang: + + When running ethtool eth0 on 64-bit Book3E, a BUG occurred: + + usercopy: Kernel memory exposure attempt detected from SLUB object not in SLUB page?! (offset 0, size 1048)! + kernel BUG at mm/usercopy.c:99 + ... + usercopy_abort+0x64/0xa0 (unreliable) + __check_heap_object+0x168/0x190 + __check_object_size+0x1a0/0x200 + dev_ethtool+0x2494/0x2b20 + dev_ioctl+0x5d0/0x770 + sock_do_ioctl+0xf0/0x1d0 + sock_ioctl+0x3ec/0x5a0 + __se_sys_ioctl+0xf0/0x160 + system_call_exception+0xfc/0x1f0 + system_call_common+0xf8/0x200 + + The code shows below, + + data = vzalloc(array_size(gstrings.len, ETH_GSTRING_LEN)); + copy_to_user(useraddr, data, gstrings.len * ETH_GSTRING_LEN)) + + The data is alloced by vmalloc(), virt_addr_valid(ptr) will return true + on 64-bit Book3E, which leads to the panic. + + As commit 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va + and __pa addresses") does, make sure the virt addr above PAGE_OFFSET in + the virt_addr_valid() for 64-bit, also add upper limit check to make + sure the virt is below high_memory. + + Meanwhile, for 32-bit PAGE_OFFSET is the virtual address of the start + of lowmem, high_memory is the upper low virtual address, the check is + suitable for 32-bit, this will fix the issue mentioned in commit + 602946ec2f90 ("powerpc: Set max_mapnr correctly") too. + +On 32-bit there is a similar problem with high memory, that was fixed in +commit 602946ec2f90 ("powerpc: Set max_mapnr correctly"), but that +commit breaks highmem and needs to be reverted. + +We can't easily fix __pa(), we have code that relies on its current +behaviour. So for now add extra checks to virt_addr_valid(). + +For 64-bit Book3S the extra checks are not necessary, the combination of +virt_to_pfn() and pfn_valid() should yield the correct result, but they +are harmless. + +Signed-off-by: Kefeng Wang +Reviewed-by: Christophe Leroy +[mpe: Add additional change log detail] +Signed-off-by: Michael Ellerman +Link: https://lore.kernel.org/r/20220406145802.538416-1-mpe@ellerman.id.au +Signed-off-by: Sasha Levin +--- + arch/powerpc/include/asm/page.h | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h +index 6ba5adb96a3b..0d8f9246ce15 100644 +--- a/arch/powerpc/include/asm/page.h ++++ b/arch/powerpc/include/asm/page.h +@@ -132,7 +132,11 @@ static inline bool pfn_valid(unsigned long pfn) + #define virt_to_page(kaddr) pfn_to_page(virt_to_pfn(kaddr)) + #define pfn_to_kaddr(pfn) __va((pfn) << PAGE_SHIFT) + +-#define virt_addr_valid(kaddr) pfn_valid(virt_to_pfn(kaddr)) ++#define virt_addr_valid(vaddr) ({ \ ++ unsigned long _addr = (unsigned long)vaddr; \ ++ _addr >= PAGE_OFFSET && _addr < (unsigned long)high_memory && \ ++ pfn_valid(virt_to_pfn(_addr)); \ ++}) + + /* + * On Book-E parts we need __va to parse the device tree and we can't +-- +2.35.1 + diff --git a/queue-5.4/regulator-wm8994-add-an-off-on-delay-for-wm8994-vari.patch b/queue-5.4/regulator-wm8994-add-an-off-on-delay-for-wm8994-vari.patch new file mode 100644 index 00000000000..89d2c706347 --- /dev/null +++ b/queue-5.4/regulator-wm8994-add-an-off-on-delay-for-wm8994-vari.patch @@ -0,0 +1,94 @@ +From 0887a322d4fafe4f6140e49a3fe0dcd830ba0458 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 27 Mar 2022 18:01:54 -0700 +Subject: regulator: wm8994: Add an off-on delay for WM8994 variant + +From: Jonathan Bakker + +[ Upstream commit 92d96b603738ec4f35cde7198c303ae264dd47cb ] + +As per Table 130 of the wm8994 datasheet at [1], there is an off-on +delay for LDO1 and LDO2. In the wm8958 datasheet [2], I could not +find any reference to it. I could not find a wm1811 datasheet to +double-check there, but as no one has complained presumably it works +without it. + +This solves the issue on Samsung Aries boards with a wm8994 where +register writes fail when the device is powered off and back-on +quickly. + +[1] https://statics.cirrus.com/pubs/proDatasheet/WM8994_Rev4.6.pdf +[2] https://statics.cirrus.com/pubs/proDatasheet/WM8958_v3.5.pdf + +Signed-off-by: Jonathan Bakker +Acked-by: Charles Keepax +Link: https://lore.kernel.org/r/CY4PR04MB056771CFB80DC447C30D5A31CB1D9@CY4PR04MB0567.namprd04.prod.outlook.com +Signed-off-by: Mark Brown +Signed-off-by: Sasha Levin +--- + drivers/regulator/wm8994-regulator.c | 42 ++++++++++++++++++++++++++-- + 1 file changed, 39 insertions(+), 3 deletions(-) + +diff --git a/drivers/regulator/wm8994-regulator.c b/drivers/regulator/wm8994-regulator.c +index cadea0344486..40befdd9dfa9 100644 +--- a/drivers/regulator/wm8994-regulator.c ++++ b/drivers/regulator/wm8994-regulator.c +@@ -71,6 +71,35 @@ static const struct regulator_ops wm8994_ldo2_ops = { + }; + + static const struct regulator_desc wm8994_ldo_desc[] = { ++ { ++ .name = "LDO1", ++ .id = 1, ++ .type = REGULATOR_VOLTAGE, ++ .n_voltages = WM8994_LDO1_MAX_SELECTOR + 1, ++ .vsel_reg = WM8994_LDO_1, ++ .vsel_mask = WM8994_LDO1_VSEL_MASK, ++ .ops = &wm8994_ldo1_ops, ++ .min_uV = 2400000, ++ .uV_step = 100000, ++ .enable_time = 3000, ++ .off_on_delay = 36000, ++ .owner = THIS_MODULE, ++ }, ++ { ++ .name = "LDO2", ++ .id = 2, ++ .type = REGULATOR_VOLTAGE, ++ .n_voltages = WM8994_LDO2_MAX_SELECTOR + 1, ++ .vsel_reg = WM8994_LDO_2, ++ .vsel_mask = WM8994_LDO2_VSEL_MASK, ++ .ops = &wm8994_ldo2_ops, ++ .enable_time = 3000, ++ .off_on_delay = 36000, ++ .owner = THIS_MODULE, ++ }, ++}; ++ ++static const struct regulator_desc wm8958_ldo_desc[] = { + { + .name = "LDO1", + .id = 1, +@@ -172,9 +201,16 @@ static int wm8994_ldo_probe(struct platform_device *pdev) + * regulator core and we need not worry about it on the + * error path. + */ +- ldo->regulator = devm_regulator_register(&pdev->dev, +- &wm8994_ldo_desc[id], +- &config); ++ if (ldo->wm8994->type == WM8994) { ++ ldo->regulator = devm_regulator_register(&pdev->dev, ++ &wm8994_ldo_desc[id], ++ &config); ++ } else { ++ ldo->regulator = devm_regulator_register(&pdev->dev, ++ &wm8958_ldo_desc[id], ++ &config); ++ } ++ + if (IS_ERR(ldo->regulator)) { + ret = PTR_ERR(ldo->regulator); + dev_err(wm8994->dev, "Failed to register LDO%d: %d\n", +-- +2.35.1 + diff --git a/queue-5.4/scsi-ibmvscsis-increase-initial_srp_limit-to-1024.patch b/queue-5.4/scsi-ibmvscsis-increase-initial_srp_limit-to-1024.patch new file mode 100644 index 00000000000..3b8e254d8cf --- /dev/null +++ b/queue-5.4/scsi-ibmvscsis-increase-initial_srp_limit-to-1024.patch @@ -0,0 +1,44 @@ +From cb1aeeb9c1642e757ecb4fa442e5cc45162396f2 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 a929fe76102b..d5b2917aea44 100644 +--- a/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c ++++ b/drivers/scsi/ibmvscsi_tgt/ibmvscsi_tgt.c +@@ -35,7 +35,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-5.4/scsi-megaraid_sas-target-with-invalid-lun-id-is-dele.patch b/queue-5.4/scsi-megaraid_sas-target-with-invalid-lun-id-is-dele.patch new file mode 100644 index 00000000000..abcf20b47d0 --- /dev/null +++ b/queue-5.4/scsi-megaraid_sas-target-with-invalid-lun-id-is-dele.patch @@ -0,0 +1,68 @@ +From dc5819e71a006f919f0908fdd719e39b41339ab1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 24 Mar 2022 02:47:11 -0700 +Subject: scsi: megaraid_sas: Target with invalid LUN ID is deleted during scan + +From: Chandrakanth patil + +[ Upstream commit 56495f295d8e021f77d065b890fc0100e3f9f6d8 ] + +The megaraid_sas driver supports single LUN for RAID devices. That is LUN +0. All other LUNs are unsupported. When a device scan on a logical target +with invalid LUN number is invoked through sysfs, that target ends up +getting removed. + +Add LUN ID validation in the slave destroy function to avoid the target +deletion. + +Link: https://lore.kernel.org/r/20220324094711.48833-1-chandrakanth.patil@broadcom.com +Signed-off-by: Chandrakanth patil +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/megaraid/megaraid_sas.h | 3 +++ + drivers/scsi/megaraid/megaraid_sas_base.c | 7 +++++++ + 2 files changed, 10 insertions(+) + +diff --git a/drivers/scsi/megaraid/megaraid_sas.h b/drivers/scsi/megaraid/megaraid_sas.h +index 3d43ac9772f7..aa62cc8ffd0a 100644 +--- a/drivers/scsi/megaraid/megaraid_sas.h ++++ b/drivers/scsi/megaraid/megaraid_sas.h +@@ -2551,6 +2551,9 @@ struct megasas_instance_template { + #define MEGASAS_IS_LOGICAL(sdev) \ + ((sdev->channel < MEGASAS_MAX_PD_CHANNELS) ? 0 : 1) + ++#define MEGASAS_IS_LUN_VALID(sdev) \ ++ (((sdev)->lun == 0) ? 1 : 0) ++ + #define MEGASAS_DEV_INDEX(scp) \ + (((scp->device->channel % 2) * MEGASAS_MAX_DEV_PER_CHANNEL) + \ + scp->device->id) +diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c b/drivers/scsi/megaraid/megaraid_sas_base.c +index 6700d43b12ff..a261ce511e9e 100644 +--- a/drivers/scsi/megaraid/megaraid_sas_base.c ++++ b/drivers/scsi/megaraid/megaraid_sas_base.c +@@ -2102,6 +2102,9 @@ static int megasas_slave_alloc(struct scsi_device *sdev) + goto scan_target; + } + return -ENXIO; ++ } else if (!MEGASAS_IS_LUN_VALID(sdev)) { ++ sdev_printk(KERN_INFO, sdev, "%s: invalid LUN\n", __func__); ++ return -ENXIO; + } + + scan_target: +@@ -2132,6 +2135,10 @@ static void megasas_slave_destroy(struct scsi_device *sdev) + instance = megasas_lookup_instance(sdev->host->host_no); + + if (MEGASAS_IS_LOGICAL(sdev)) { ++ if (!MEGASAS_IS_LUN_VALID(sdev)) { ++ sdev_printk(KERN_INFO, sdev, "%s: invalid LUN\n", __func__); ++ return; ++ } + ld_tgt_id = MEGASAS_TARGET_ID(sdev); + instance->ld_tgtid_status[ld_tgt_id] = LD_TARGET_ID_DELETED; + if (megasas_dbg_lvl & LD_PD_DEBUG) +-- +2.35.1 + diff --git a/queue-5.4/scsi-mvsas-add-pci-id-of-rocketraid-2640.patch b/queue-5.4/scsi-mvsas-add-pci-id-of-rocketraid-2640.patch new file mode 100644 index 00000000000..5901f782e7c --- /dev/null +++ b/queue-5.4/scsi-mvsas-add-pci-id-of-rocketraid-2640.patch @@ -0,0 +1,36 @@ +From b3b2ad9e408350f2ae970983a14cbeb3dae5334f 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 c16d7fb0fdcb..0c5e2c610586 100644 +--- a/drivers/scsi/mvsas/mv_init.c ++++ b/drivers/scsi/mvsas/mv_init.c +@@ -646,6 +646,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-5.4/scsi-target-tcmu-fix-possible-page-uaf.patch b/queue-5.4/scsi-target-tcmu-fix-possible-page-uaf.patch new file mode 100644 index 00000000000..45abf9bfdc7 --- /dev/null +++ b/queue-5.4/scsi-target-tcmu-fix-possible-page-uaf.patch @@ -0,0 +1,57 @@ +From b27f02c6e0be7279d6e2059fc352b1101dff2ae7 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 71144e33272a..077c56cbed4e 100644 +--- a/drivers/target/target_core_user.c ++++ b/drivers/target/target_core_user.c +@@ -1488,6 +1488,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; + } +@@ -1526,6 +1527,7 @@ static vm_fault_t 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; + +@@ -1536,7 +1538,6 @@ static vm_fault_t tcmu_vma_fault(struct vm_fault *vmf) + return VM_FAULT_SIGBUS; + } + +- get_page(page); + vmf->page = page; + return 0; + } +-- +2.35.1 + diff --git a/queue-5.4/sctp-initialize-daddr-on-peeled-off-socket.patch b/queue-5.4/sctp-initialize-daddr-on-peeled-off-socket.patch new file mode 100644 index 00000000000..130c7f936b6 --- /dev/null +++ b/queue-5.4/sctp-initialize-daddr-on-peeled-off-socket.patch @@ -0,0 +1,40 @@ +From cf362a16e2b0a17e86baa15337aa21d7d78cd73f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 9 Apr 2022 08:36:11 +0200 +Subject: sctp: Initialize daddr on peeled off socket + +From: Petr Malat + +[ Upstream commit 8467dda0c26583547731e7f3ea73fc3856bae3bf ] + +Function sctp_do_peeloff() wrongly initializes daddr of the original +socket instead of the peeled off socket, which makes getpeername() +return zeroes instead of the primary address. Initialize the new socket +instead. + +Fixes: d570ee490fb1 ("[SCTP]: Correctly set daddr for IPv6 sockets during peeloff") +Signed-off-by: Petr Malat +Acked-by: Marcelo Ricardo Leitner +Link: https://lore.kernel.org/r/20220409063611.673193-1-oss@malat.biz +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/sctp/socket.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/net/sctp/socket.c b/net/sctp/socket.c +index 565aa77fe5cb..c76b40322ac7 100644 +--- a/net/sctp/socket.c ++++ b/net/sctp/socket.c +@@ -5682,7 +5682,7 @@ int sctp_do_peeloff(struct sock *sk, sctp_assoc_t id, struct socket **sockp) + * Set the daddr and initialize id to something more random and also + * copy over any ip options. + */ +- sp->pf->to_sk_daddr(&asoc->peer.primary_addr, sk); ++ sp->pf->to_sk_daddr(&asoc->peer.primary_addr, sock->sk); + sp->pf->copy_ip_options(sk, sock->sk); + + /* Populate the fields of the newsk from the oldsk and migrate the +-- +2.35.1 + diff --git a/queue-5.4/series b/queue-5.4/series new file mode 100644 index 00000000000..b0f671cb869 --- /dev/null +++ b/queue-5.4/series @@ -0,0 +1,36 @@ +memory-atmel-ebi-fix-missing-of_node_put-in-atmel_eb.patch +net-sched-flower-fix-parsing-of-ethertype-following-.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-sched-fix-initialization-order-when-updating-cha.patch +net-ethernet-stmmac-fix-altr_tse_pcs-function-when-u.patch +net-sched-taprio-check-if-socket-flags-are-valid.patch +cfg80211-hold-bss_lock-while-updating-nontrans_list.patch +drm-msm-dsi-use-connector-directly-in-msm_dsi_manage.patch +net-smc-fix-null-pointer-dereference-in-smc_pnet_fin.patch +sctp-initialize-daddr-on-peeled-off-socket.patch +testing-selftests-mqueue-fix-mq_perf_tests-to-free-t.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-amd-display-fix-audio-format-not-updated-after-e.patch +drm-amd-display-update-vtem-infopacket-definition.patch +drm-amdkfd-fix-incorrect-vmids-passed-to-hws.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 +regulator-wm8994-add-an-off-on-delay-for-wm8994-vari.patch +arm64-alternatives-mark-patch_alternative-as-noinstr.patch +tlb-hugetlb-add-more-sizes-to-tlb_remove_huge_tlb_en.patch +net-usb-aqc111-fix-out-of-bounds-accesses-in-rx-fixu.patch +drm-amd-display-fix-allocate_mst_payload-assert-on-r.patch +powerpc-fix-virt_addr_valid-for-64-bit-book3e-32-bit.patch +scsi-mvsas-add-pci-id-of-rocketraid-2640.patch +scsi-megaraid_sas-target-with-invalid-lun-id-is-dele.patch +drivers-net-slip-fix-npd-bug-in-sl_tx_timeout.patch +perf-imx_ddr-fix-undefined-behavior-due-to-shift-ove.patch diff --git a/queue-5.4/testing-selftests-mqueue-fix-mq_perf_tests-to-free-t.patch b/queue-5.4/testing-selftests-mqueue-fix-mq_perf_tests-to-free-t.patch new file mode 100644 index 00000000000..fe98ad7161e --- /dev/null +++ b/queue-5.4/testing-selftests-mqueue-fix-mq_perf_tests-to-free-t.patch @@ -0,0 +1,105 @@ +From f29aed6521bfa27907849c7f5b083f62def824c5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 8 Apr 2022 12:54:31 +0530 +Subject: testing/selftests/mqueue: Fix mq_perf_tests to free the allocated cpu + set + +From: Athira Rajeev + +[ Upstream commit ce64763c63854b4079f2e036638aa881a1fb3fbc ] + +The selftest "mqueue/mq_perf_tests.c" use CPU_ALLOC to allocate +CPU set. This cpu set is used further in pthread_attr_setaffinity_np +and by pthread_create in the code. But in current code, allocated +cpu set is not freed. + +Fix this issue by adding CPU_FREE in the "shutdown" function which +is called in most of the error/exit path for the cleanup. There are +few error paths which exit without using shutdown. Add a common goto +error path with CPU_FREE for these cases. + +Fixes: 7820b0715b6f ("tools/selftests: add mq_perf_tests") +Signed-off-by: Athira Rajeev +Signed-off-by: Shuah Khan +Signed-off-by: Sasha Levin +--- + .../testing/selftests/mqueue/mq_perf_tests.c | 25 +++++++++++++------ + 1 file changed, 17 insertions(+), 8 deletions(-) + +diff --git a/tools/testing/selftests/mqueue/mq_perf_tests.c b/tools/testing/selftests/mqueue/mq_perf_tests.c +index b019e0b8221c..84fda3b49073 100644 +--- a/tools/testing/selftests/mqueue/mq_perf_tests.c ++++ b/tools/testing/selftests/mqueue/mq_perf_tests.c +@@ -180,6 +180,9 @@ void shutdown(int exit_val, char *err_cause, int line_no) + if (in_shutdown++) + return; + ++ /* Free the cpu_set allocated using CPU_ALLOC in main function */ ++ CPU_FREE(cpu_set); ++ + for (i = 0; i < num_cpus_to_pin; i++) + if (cpu_threads[i]) { + pthread_kill(cpu_threads[i], SIGUSR1); +@@ -551,6 +554,12 @@ int main(int argc, char *argv[]) + perror("sysconf(_SC_NPROCESSORS_ONLN)"); + exit(1); + } ++ ++ if (getuid() != 0) ++ ksft_exit_skip("Not running as root, but almost all tests " ++ "require root in order to modify\nsystem settings. " ++ "Exiting.\n"); ++ + cpus_online = min(MAX_CPUS, sysconf(_SC_NPROCESSORS_ONLN)); + cpu_set = CPU_ALLOC(cpus_online); + if (cpu_set == NULL) { +@@ -589,7 +598,7 @@ int main(int argc, char *argv[]) + cpu_set)) { + fprintf(stderr, "Any given CPU may " + "only be given once.\n"); +- exit(1); ++ goto err_code; + } else + CPU_SET_S(cpus_to_pin[cpu], + cpu_set_size, cpu_set); +@@ -607,7 +616,7 @@ int main(int argc, char *argv[]) + queue_path = malloc(strlen(option) + 2); + if (!queue_path) { + perror("malloc()"); +- exit(1); ++ goto err_code; + } + queue_path[0] = '/'; + queue_path[1] = 0; +@@ -622,17 +631,12 @@ int main(int argc, char *argv[]) + fprintf(stderr, "Must pass at least one CPU to continuous " + "mode.\n"); + poptPrintUsage(popt_context, stderr, 0); +- exit(1); ++ goto err_code; + } else if (!continuous_mode) { + num_cpus_to_pin = 1; + cpus_to_pin[0] = cpus_online - 1; + } + +- if (getuid() != 0) +- ksft_exit_skip("Not running as root, but almost all tests " +- "require root in order to modify\nsystem settings. " +- "Exiting.\n"); +- + max_msgs = fopen(MAX_MSGS, "r+"); + max_msgsize = fopen(MAX_MSGSIZE, "r+"); + if (!max_msgs) +@@ -740,4 +744,9 @@ int main(int argc, char *argv[]) + sleep(1); + } + shutdown(0, "", 0); ++ ++err_code: ++ CPU_FREE(cpu_set); ++ exit(1); ++ + } +-- +2.35.1 + diff --git a/queue-5.4/tlb-hugetlb-add-more-sizes-to-tlb_remove_huge_tlb_en.patch b/queue-5.4/tlb-hugetlb-add-more-sizes-to-tlb_remove_huge_tlb_en.patch new file mode 100644 index 00000000000..db0e56e53a3 --- /dev/null +++ b/queue-5.4/tlb-hugetlb-add-more-sizes-to-tlb_remove_huge_tlb_en.patch @@ -0,0 +1,66 @@ +From a4dee44f080005228955efde358113f71278a7ab Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 30 Mar 2022 12:25:43 +0100 +Subject: tlb: hugetlb: Add more sizes to tlb_remove_huge_tlb_entry + +From: Steve Capper + +[ Upstream commit 697a1d44af8ba0477ee729e632f4ade37999249a ] + +tlb_remove_huge_tlb_entry only considers PMD_SIZE and PUD_SIZE when +updating the mmu_gather structure. + +Unfortunately on arm64 there are two additional huge page sizes that +need to be covered: CONT_PTE_SIZE and CONT_PMD_SIZE. Where an end-user +attempts to employ contiguous huge pages, a VM_BUG_ON can be experienced +due to the fact that the tlb structure hasn't been correctly updated by +the relevant tlb_flush_p.._range() call from tlb_remove_huge_tlb_entry. + +This patch adds inequality logic to the generic implementation of +tlb_remove_huge_tlb_entry s.t. CONT_PTE_SIZE and CONT_PMD_SIZE are +effectively covered on arm64. Also, as well as ptes, pmds and puds; +p4ds are now considered too. + +Reported-by: David Hildenbrand +Suggested-by: Peter Zijlstra (Intel) +Cc: Anshuman Khandual +Cc: Catalin Marinas +Cc: Will Deacon +Link: https://lore.kernel.org/linux-mm/811c5c8e-b3a2-85d2-049c-717f17c3a03a@redhat.com/ +Signed-off-by: Steve Capper +Acked-by: David Hildenbrand +Reviewed-by: Anshuman Khandual +Reviewed-by: Catalin Marinas +Acked-by: Peter Zijlstra (Intel) +Link: https://lore.kernel.org/r/20220330112543.863-1-steve.capper@arm.com +Signed-off-by: Will Deacon +Signed-off-by: Sasha Levin +--- + include/asm-generic/tlb.h | 10 +++++++--- + 1 file changed, 7 insertions(+), 3 deletions(-) + +diff --git a/include/asm-generic/tlb.h b/include/asm-generic/tlb.h +index 46294ef620ff..268674c1d568 100644 +--- a/include/asm-generic/tlb.h ++++ b/include/asm-generic/tlb.h +@@ -547,10 +547,14 @@ static inline void tlb_flush_p4d_range(struct mmu_gather *tlb, + #define tlb_remove_huge_tlb_entry(h, tlb, ptep, address) \ + do { \ + unsigned long _sz = huge_page_size(h); \ +- if (_sz == PMD_SIZE) \ +- tlb_flush_pmd_range(tlb, address, _sz); \ +- else if (_sz == PUD_SIZE) \ ++ if (_sz >= P4D_SIZE) \ ++ tlb_flush_p4d_range(tlb, address, _sz); \ ++ else if (_sz >= PUD_SIZE) \ + tlb_flush_pud_range(tlb, address, _sz); \ ++ else if (_sz >= PMD_SIZE) \ ++ tlb_flush_pmd_range(tlb, address, _sz); \ ++ else \ ++ tlb_flush_pte_range(tlb, address, _sz); \ + __tlb_remove_tlb_entry(tlb, ptep, address); \ + } while (0) + +-- +2.35.1 + diff --git a/queue-5.4/veth-ensure-eth-header-is-in-skb-s-linear-part.patch b/queue-5.4/veth-ensure-eth-header-is-in-skb-s-linear-part.patch new file mode 100644 index 00000000000..5933f277698 --- /dev/null +++ b/queue-5.4/veth-ensure-eth-header-is-in-skb-s-linear-part.patch @@ -0,0 +1,72 @@ +From 38b14401936854ba92a054cdba2812aa336003ca 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 10a876f8831c..683425e3a353 100644 +--- a/drivers/net/veth.c ++++ b/drivers/net/veth.c +@@ -245,7 +245,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 +