From: Greg Kroah-Hartman Date: Sat, 5 Mar 2022 11:27:32 +0000 (+0100) Subject: 5.16-stable patches X-Git-Tag: v4.9.305~83 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=8e47df938a53412818368ba6df14ddea9e26135b;p=thirdparty%2Fkernel%2Fstable-queue.git 5.16-stable patches added patches: alsa-intel_hdmi-fix-reference-to-pcm-buffer-address.patch asoc-ops-shift-tested-values-in-snd_soc_put_volsw-by-min.patch binfmt_elf-avoid-total_mapping_size-for-et_exec.patch blktrace-fix-use-after-free-for-struct-blk_trace.patch drm-amd-display-reduce-dmesg-error-to-a-debug-print.patch drm-i915-s-jsp2-icp2-pch.patch iommu-amd-recover-from-event-log-overflow.patch iommu-vt-d-fix-double-list_add-when-enabling-vmd-in-scalable-mode.patch iwlwifi-mvm-check-debugfs_dir-ptr-before-use.patch mac80211-fix-eapol-rekey-fail-in-802.3-rx-path.patch ntb-intel-fix-port-config-status-offset-for-spr.patch riscv-efi_stub-fix-get_boot_hartid_from_fdt-return-value.patch riscv-fix-config-kasan-debug_virtual.patch riscv-fix-config-kasan-sparsemem-sparse_vmemmap.patch thermal-core-fix-tz_get_trip-null-pointer-dereference.patch ucounts-fix-systemd-limitnproc-with-private-users-regression.patch xen-netfront-destroy-queues-before-real_num_tx_queues-is-zeroed.patch --- diff --git a/queue-5.16/alsa-intel_hdmi-fix-reference-to-pcm-buffer-address.patch b/queue-5.16/alsa-intel_hdmi-fix-reference-to-pcm-buffer-address.patch new file mode 100644 index 00000000000..70dc56e2e39 --- /dev/null +++ b/queue-5.16/alsa-intel_hdmi-fix-reference-to-pcm-buffer-address.patch @@ -0,0 +1,35 @@ +From 0aa6b294b312d9710804679abd2c0c8ca52cc2bc Mon Sep 17 00:00:00 2001 +From: Zhen Ni +Date: Wed, 2 Mar 2022 15:42:41 +0800 +Subject: ALSA: intel_hdmi: Fix reference to PCM buffer address + +From: Zhen Ni + +commit 0aa6b294b312d9710804679abd2c0c8ca52cc2bc upstream. + +PCM buffers might be allocated dynamically when the buffer +preallocation failed or a larger buffer is requested, and it's not +guaranteed that substream->dma_buffer points to the actually used +buffer. The driver needs to refer to substream->runtime->dma_addr +instead for the buffer address. + +Signed-off-by: Zhen Ni +Cc: +Link: https://lore.kernel.org/r/20220302074241.30469-1-nizhen@uniontech.com +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/x86/intel_hdmi_audio.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/sound/x86/intel_hdmi_audio.c ++++ b/sound/x86/intel_hdmi_audio.c +@@ -1261,7 +1261,7 @@ static int had_pcm_mmap(struct snd_pcm_s + { + vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot); + return remap_pfn_range(vma, vma->vm_start, +- substream->dma_buffer.addr >> PAGE_SHIFT, ++ substream->runtime->dma_addr >> PAGE_SHIFT, + vma->vm_end - vma->vm_start, vma->vm_page_prot); + } + diff --git a/queue-5.16/asoc-ops-shift-tested-values-in-snd_soc_put_volsw-by-min.patch b/queue-5.16/asoc-ops-shift-tested-values-in-snd_soc_put_volsw-by-min.patch new file mode 100644 index 00000000000..c9231a3200e --- /dev/null +++ b/queue-5.16/asoc-ops-shift-tested-values-in-snd_soc_put_volsw-by-min.patch @@ -0,0 +1,45 @@ +From 9bdd10d57a8807dba0003af0325191f3cec0f11c Mon Sep 17 00:00:00 2001 +From: Marek Vasut +Date: Tue, 15 Feb 2022 14:06:45 +0100 +Subject: ASoC: ops: Shift tested values in snd_soc_put_volsw() by +min + +From: Marek Vasut + +commit 9bdd10d57a8807dba0003af0325191f3cec0f11c upstream. + +While the $val/$val2 values passed in from userspace are always >= 0 +integers, the limits of the control can be signed integers and the $min +can be non-zero and less than zero. To correctly validate $val/$val2 +against platform_max, add the $min offset to val first. + +Fixes: 817f7c9335ec0 ("ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()") +Signed-off-by: Marek Vasut +Cc: Mark Brown +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/20220215130645.164025-1-marex@denx.de +Signed-off-by: Mark Brown +Signed-off-by: Greg Kroah-Hartman +--- + sound/soc/soc-ops.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/sound/soc/soc-ops.c ++++ b/sound/soc/soc-ops.c +@@ -317,7 +317,7 @@ int snd_soc_put_volsw(struct snd_kcontro + mask = BIT(sign_bit + 1) - 1; + + val = ucontrol->value.integer.value[0]; +- if (mc->platform_max && val > mc->platform_max) ++ if (mc->platform_max && ((int)val + min) > mc->platform_max) + return -EINVAL; + if (val > max - min) + return -EINVAL; +@@ -330,7 +330,7 @@ int snd_soc_put_volsw(struct snd_kcontro + val = val << shift; + if (snd_soc_volsw_is_stereo(mc)) { + val2 = ucontrol->value.integer.value[1]; +- if (mc->platform_max && val2 > mc->platform_max) ++ if (mc->platform_max && ((int)val2 + min) > mc->platform_max) + return -EINVAL; + if (val2 > max - min) + return -EINVAL; diff --git a/queue-5.16/binfmt_elf-avoid-total_mapping_size-for-et_exec.patch b/queue-5.16/binfmt_elf-avoid-total_mapping_size-for-et_exec.patch new file mode 100644 index 00000000000..3ec532a9c05 --- /dev/null +++ b/queue-5.16/binfmt_elf-avoid-total_mapping_size-for-et_exec.patch @@ -0,0 +1,98 @@ +From 439a8468242b313486e69b8cc3b45ddcfa898fbf Mon Sep 17 00:00:00 2001 +From: Kees Cook +Date: Mon, 28 Feb 2022 10:59:12 -0800 +Subject: binfmt_elf: Avoid total_mapping_size for ET_EXEC + +From: Kees Cook + +commit 439a8468242b313486e69b8cc3b45ddcfa898fbf upstream. + +Partially revert commit 5f501d555653 ("binfmt_elf: reintroduce using +MAP_FIXED_NOREPLACE"), which applied the ET_DYN "total_mapping_size" +logic also to ET_EXEC. + +At least ia64 has ET_EXEC PT_LOAD segments that are not virtual-address +contiguous (but _are_ file-offset contiguous). This would result in a +giant mapping attempting to cover the entire span, including the virtual +address range hole, and well beyond the size of the ELF file itself, +causing the kernel to refuse to load it. For example: + +$ readelf -lW /usr/bin/gcc +... +Program Headers: + Type Offset VirtAddr PhysAddr FileSiz MemSiz ... +... + LOAD 0x000000 0x4000000000000000 0x4000000000000000 0x00b5a0 0x00b5a0 ... + LOAD 0x00b5a0 0x600000000000b5a0 0x600000000000b5a0 0x0005ac 0x000710 ... +... + ^^^^^^^^ ^^^^^^^^^^^^^^^^^^ ^^^^^^^^ ^^^^^^^^ + +File offset range : 0x000000-0x00bb4c + 0x00bb4c bytes + +Virtual address range : 0x4000000000000000-0x600000000000bcb0 + 0x200000000000bcb0 bytes + +Remove the total_mapping_size logic for ET_EXEC, which reduces the +ET_EXEC MAP_FIXED_NOREPLACE coverage to only the first PT_LOAD (better +than nothing), and retains it for ET_DYN. + +Ironically, this is the reverse of the problem that originally caused +problems with MAP_FIXED_NOREPLACE: overlapping PT_LOAD segments. Future +work could restore full coverage if load_elf_binary() were to perform +mappings in a separate phase from the loading (where it could resolve +both overlaps and holes). + +Cc: Eric Biederman +Cc: Alexander Viro +Cc: linux-fsdevel@vger.kernel.org +Cc: linux-mm@kvack.org +Reported-by: matoro +Fixes: 5f501d555653 ("binfmt_elf: reintroduce using MAP_FIXED_NOREPLACE") +Link: https://lore.kernel.org/r/a3edd529-c42d-3b09-135c-7e98a15b150f@leemhuis.info +Tested-by: matoro +Link: https://lore.kernel.org/lkml/ce8af9c13bcea9230c7689f3c1e0e2cd@matoro.tk +Tested-By: John Paul Adrian Glaubitz +Link: https://lore.kernel.org/lkml/49182d0d-708b-4029-da5f-bc18603440a6@physik.fu-berlin.de +Cc: stable@vger.kernel.org +Signed-off-by: Kees Cook +Signed-off-by: Greg Kroah-Hartman +--- + fs/binfmt_elf.c | 25 ++++++++++++++++++------- + 1 file changed, 18 insertions(+), 7 deletions(-) + +--- a/fs/binfmt_elf.c ++++ b/fs/binfmt_elf.c +@@ -1135,14 +1135,25 @@ out_free_interp: + * is then page aligned. + */ + load_bias = ELF_PAGESTART(load_bias - vaddr); +- } + +- /* +- * Calculate the entire size of the ELF mapping (total_size). +- * (Note that load_addr_set is set to true later once the +- * initial mapping is performed.) +- */ +- if (!load_addr_set) { ++ /* ++ * Calculate the entire size of the ELF mapping ++ * (total_size), used for the initial mapping, ++ * due to load_addr_set which is set to true later ++ * once the initial mapping is performed. ++ * ++ * Note that this is only sensible when the LOAD ++ * segments are contiguous (or overlapping). If ++ * used for LOADs that are far apart, this would ++ * cause the holes between LOADs to be mapped, ++ * running the risk of having the mapping fail, ++ * as it would be larger than the ELF file itself. ++ * ++ * As a result, only ET_DYN does this, since ++ * some ET_EXEC (e.g. ia64) may have large virtual ++ * memory holes between LOADs. ++ * ++ */ + total_size = total_mapping_size(elf_phdata, + elf_ex->e_phnum); + if (!total_size) { diff --git a/queue-5.16/blktrace-fix-use-after-free-for-struct-blk_trace.patch b/queue-5.16/blktrace-fix-use-after-free-for-struct-blk_trace.patch new file mode 100644 index 00000000000..3aa7ec60cf4 --- /dev/null +++ b/queue-5.16/blktrace-fix-use-after-free-for-struct-blk_trace.patch @@ -0,0 +1,180 @@ +From 30939293262eb433c960c4532a0d59c4073b2b84 Mon Sep 17 00:00:00 2001 +From: Yu Kuai +Date: Mon, 28 Feb 2022 11:43:54 +0800 +Subject: blktrace: fix use after free for struct blk_trace + +From: Yu Kuai + +commit 30939293262eb433c960c4532a0d59c4073b2b84 upstream. + +When tracing the whole disk, 'dropped' and 'msg' will be created +under 'q->debugfs_dir' and 'bt->dir' is NULL, thus blk_trace_free() +won't remove those files. What's worse, the following UAF can be +triggered because of accessing stale 'dropped' and 'msg': + +================================================================== +BUG: KASAN: use-after-free in blk_dropped_read+0x89/0x100 +Read of size 4 at addr ffff88816912f3d8 by task blktrace/1188 + +CPU: 27 PID: 1188 Comm: blktrace Not tainted 5.17.0-rc4-next-20220217+ #469 +Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-4 +Call Trace: + + dump_stack_lvl+0x34/0x44 + print_address_description.constprop.0.cold+0xab/0x381 + ? blk_dropped_read+0x89/0x100 + ? blk_dropped_read+0x89/0x100 + kasan_report.cold+0x83/0xdf + ? blk_dropped_read+0x89/0x100 + kasan_check_range+0x140/0x1b0 + blk_dropped_read+0x89/0x100 + ? blk_create_buf_file_callback+0x20/0x20 + ? kmem_cache_free+0xa1/0x500 + ? do_sys_openat2+0x258/0x460 + full_proxy_read+0x8f/0xc0 + vfs_read+0xc6/0x260 + ksys_read+0xb9/0x150 + ? vfs_write+0x3d0/0x3d0 + ? fpregs_assert_state_consistent+0x55/0x60 + ? exit_to_user_mode_prepare+0x39/0x1e0 + do_syscall_64+0x35/0x80 + entry_SYSCALL_64_after_hwframe+0x44/0xae +RIP: 0033:0x7fbc080d92fd +Code: ce 20 00 00 75 10 b8 00 00 00 00 0f 05 48 3d 01 f0 ff ff 73 31 c3 48 83 1 +RSP: 002b:00007fbb95ff9cb0 EFLAGS: 00000293 ORIG_RAX: 0000000000000000 +RAX: ffffffffffffffda RBX: 00007fbb95ff9dc0 RCX: 00007fbc080d92fd +RDX: 0000000000000100 RSI: 00007fbb95ff9cc0 RDI: 0000000000000045 +RBP: 0000000000000045 R08: 0000000000406299 R09: 00000000fffffffd +R10: 000000000153afa0 R11: 0000000000000293 R12: 00007fbb780008c0 +R13: 00007fbb78000938 R14: 0000000000608b30 R15: 00007fbb780029c8 + + +Allocated by task 1050: + kasan_save_stack+0x1e/0x40 + __kasan_kmalloc+0x81/0xa0 + do_blk_trace_setup+0xcb/0x410 + __blk_trace_setup+0xac/0x130 + blk_trace_ioctl+0xe9/0x1c0 + blkdev_ioctl+0xf1/0x390 + __x64_sys_ioctl+0xa5/0xe0 + do_syscall_64+0x35/0x80 + entry_SYSCALL_64_after_hwframe+0x44/0xae + +Freed by task 1050: + kasan_save_stack+0x1e/0x40 + kasan_set_track+0x21/0x30 + kasan_set_free_info+0x20/0x30 + __kasan_slab_free+0x103/0x180 + kfree+0x9a/0x4c0 + __blk_trace_remove+0x53/0x70 + blk_trace_ioctl+0x199/0x1c0 + blkdev_common_ioctl+0x5e9/0xb30 + blkdev_ioctl+0x1a5/0x390 + __x64_sys_ioctl+0xa5/0xe0 + do_syscall_64+0x35/0x80 + entry_SYSCALL_64_after_hwframe+0x44/0xae + +The buggy address belongs to the object at ffff88816912f380 + which belongs to the cache kmalloc-96 of size 96 +The buggy address is located 88 bytes inside of + 96-byte region [ffff88816912f380, ffff88816912f3e0) +The buggy address belongs to the page: +page:000000009a1b4e7c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0f +flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff) +raw: 0017ffffc0000200 ffffea00044f1100 dead000000000002 ffff88810004c780 +raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000 +page dumped because: kasan: bad access detected + +Memory state around the buggy address: + ffff88816912f280: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc + ffff88816912f300: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc +>ffff88816912f380: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc + ^ + ffff88816912f400: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc + ffff88816912f480: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc +================================================================== + +Fixes: c0ea57608b69 ("blktrace: remove debugfs file dentries from struct blk_trace") +Signed-off-by: Yu Kuai +Reviewed-by: Greg Kroah-Hartman +Link: https://lore.kernel.org/r/20220228034354.4047385-1-yukuai3@huawei.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/blktrace.c | 26 ++++++++++++++++++-------- + 1 file changed, 18 insertions(+), 8 deletions(-) + +--- a/kernel/trace/blktrace.c ++++ b/kernel/trace/blktrace.c +@@ -310,10 +310,20 @@ record_it: + local_irq_restore(flags); + } + +-static void blk_trace_free(struct blk_trace *bt) ++static void blk_trace_free(struct request_queue *q, struct blk_trace *bt) + { + relay_close(bt->rchan); +- debugfs_remove(bt->dir); ++ ++ /* ++ * If 'bt->dir' is not set, then both 'dropped' and 'msg' are created ++ * under 'q->debugfs_dir', thus lookup and remove them. ++ */ ++ if (!bt->dir) { ++ debugfs_remove(debugfs_lookup("dropped", q->debugfs_dir)); ++ debugfs_remove(debugfs_lookup("msg", q->debugfs_dir)); ++ } else { ++ debugfs_remove(bt->dir); ++ } + free_percpu(bt->sequence); + free_percpu(bt->msg_data); + kfree(bt); +@@ -335,10 +345,10 @@ static void put_probe_ref(void) + mutex_unlock(&blk_probe_mutex); + } + +-static void blk_trace_cleanup(struct blk_trace *bt) ++static void blk_trace_cleanup(struct request_queue *q, struct blk_trace *bt) + { + synchronize_rcu(); +- blk_trace_free(bt); ++ blk_trace_free(q, bt); + put_probe_ref(); + } + +@@ -352,7 +362,7 @@ static int __blk_trace_remove(struct req + return -EINVAL; + + if (bt->trace_state != Blktrace_running) +- blk_trace_cleanup(bt); ++ blk_trace_cleanup(q, bt); + + return 0; + } +@@ -572,7 +582,7 @@ static int do_blk_trace_setup(struct req + ret = 0; + err: + if (ret) +- blk_trace_free(bt); ++ blk_trace_free(q, bt); + return ret; + } + +@@ -1616,7 +1626,7 @@ static int blk_trace_remove_queue(struct + + put_probe_ref(); + synchronize_rcu(); +- blk_trace_free(bt); ++ blk_trace_free(q, bt); + return 0; + } + +@@ -1647,7 +1657,7 @@ static int blk_trace_setup_queue(struct + return 0; + + free_bt: +- blk_trace_free(bt); ++ blk_trace_free(q, bt); + return ret; + } + diff --git a/queue-5.16/drm-amd-display-reduce-dmesg-error-to-a-debug-print.patch b/queue-5.16/drm-amd-display-reduce-dmesg-error-to-a-debug-print.patch new file mode 100644 index 00000000000..dac75875adc --- /dev/null +++ b/queue-5.16/drm-amd-display-reduce-dmesg-error-to-a-debug-print.patch @@ -0,0 +1,35 @@ +From 1d925758ba1a5d2716a847903e2fd04efcbd9862 Mon Sep 17 00:00:00 2001 +From: "Leo (Hanghong) Ma" +Date: Fri, 12 Nov 2021 10:11:35 -0500 +Subject: drm/amd/display: Reduce dmesg error to a debug print + +From: Leo (Hanghong) Ma + +commit 1d925758ba1a5d2716a847903e2fd04efcbd9862 upstream. + +[Why & How] +Dmesg errors are found on dcn3.1 during reset test, but it's not +a really failure. So reduce it to a debug print. + +Signed-off-by: Leo (Hanghong) Ma +Reviewed-by: Nicholas Kazlauskas +Signed-off-by: Alex Deucher +Cc: Mario Limonciello +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c ++++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c +@@ -4454,7 +4454,9 @@ bool dp_retrieve_lttpr_cap(struct dc_lin + lttpr_dpcd_data, + sizeof(lttpr_dpcd_data)); + if (status != DC_OK) { +- dm_error("%s: Read LTTPR caps data failed.\n", __func__); ++#if defined(CONFIG_DRM_AMD_DC_DCN) ++ DC_LOG_DP2("%s: Read LTTPR caps data failed.\n", __func__); ++#endif + return false; + } + diff --git a/queue-5.16/drm-i915-s-jsp2-icp2-pch.patch b/queue-5.16/drm-i915-s-jsp2-icp2-pch.patch new file mode 100644 index 00000000000..326309bb567 --- /dev/null +++ b/queue-5.16/drm-i915-s-jsp2-icp2-pch.patch @@ -0,0 +1,76 @@ +From 08783aa7693f55619859f4f63f384abf17cb58c5 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= +Date: Thu, 24 Feb 2022 15:21:42 +0200 +Subject: drm/i915: s/JSP2/ICP2/ PCH +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Ville Syrjälä + +commit 08783aa7693f55619859f4f63f384abf17cb58c5 upstream. + +This JSP2 PCH actually seems to be some special Apple +specific ICP variant rather than a JSP. Make it so. Or at +least all the references to it seem to be some Apple ICL +machines. Didn't manage to find these PCI IDs in any +public chipset docs unfortunately. + +The only thing we're losing here with this JSP->ICP change +is Wa_14011294188, but based on the HSD that isn't actually +needed on any ICP based design (including JSP), only TGP +based stuff (including MCC) really need it. The documented +w/a just never made that distinction because Windows didn't +want to differentiate between JSP and MCC (not sure how +they handle hpd/ddc/etc. then though...). + +Cc: stable@vger.kernel.org +Cc: Matt Roper +Cc: Vivek Kasireddy +Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4226 +Fixes: 943682e3bd19 ("drm/i915: Introduce Jasper Lake PCH") +Signed-off-by: Ville Syrjälä +Link: https://patchwork.freedesktop.org/patch/msgid/20220224132142.12927-1-ville.syrjala@linux.intel.com +Acked-by: Vivek Kasireddy +Tested-by: Tomas Bzatek +(cherry picked from commit 53581504a8e216d435f114a4f2596ad0dfd902fc) +Signed-off-by: Tvrtko Ursulin +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpu/drm/i915/intel_pch.c | 2 +- + drivers/gpu/drm/i915/intel_pch.h | 2 +- + 2 files changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/gpu/drm/i915/intel_pch.c ++++ b/drivers/gpu/drm/i915/intel_pch.c +@@ -108,6 +108,7 @@ intel_pch_type(const struct drm_i915_pri + /* Comet Lake V PCH is based on KBP, which is SPT compatible */ + return PCH_SPT; + case INTEL_PCH_ICP_DEVICE_ID_TYPE: ++ case INTEL_PCH_ICP2_DEVICE_ID_TYPE: + drm_dbg_kms(&dev_priv->drm, "Found Ice Lake PCH\n"); + drm_WARN_ON(&dev_priv->drm, !IS_ICELAKE(dev_priv)); + return PCH_ICP; +@@ -123,7 +124,6 @@ intel_pch_type(const struct drm_i915_pri + !IS_GEN9_BC(dev_priv)); + return PCH_TGP; + case INTEL_PCH_JSP_DEVICE_ID_TYPE: +- case INTEL_PCH_JSP2_DEVICE_ID_TYPE: + drm_dbg_kms(&dev_priv->drm, "Found Jasper Lake PCH\n"); + drm_WARN_ON(&dev_priv->drm, !IS_JSL_EHL(dev_priv)); + return PCH_JSP; +--- a/drivers/gpu/drm/i915/intel_pch.h ++++ b/drivers/gpu/drm/i915/intel_pch.h +@@ -50,11 +50,11 @@ enum intel_pch { + #define INTEL_PCH_CMP2_DEVICE_ID_TYPE 0x0680 + #define INTEL_PCH_CMP_V_DEVICE_ID_TYPE 0xA380 + #define INTEL_PCH_ICP_DEVICE_ID_TYPE 0x3480 ++#define INTEL_PCH_ICP2_DEVICE_ID_TYPE 0x3880 + #define INTEL_PCH_MCC_DEVICE_ID_TYPE 0x4B00 + #define INTEL_PCH_TGP_DEVICE_ID_TYPE 0xA080 + #define INTEL_PCH_TGP2_DEVICE_ID_TYPE 0x4380 + #define INTEL_PCH_JSP_DEVICE_ID_TYPE 0x4D80 +-#define INTEL_PCH_JSP2_DEVICE_ID_TYPE 0x3880 + #define INTEL_PCH_ADP_DEVICE_ID_TYPE 0x7A80 + #define INTEL_PCH_ADP2_DEVICE_ID_TYPE 0x5180 + #define INTEL_PCH_P2X_DEVICE_ID_TYPE 0x7100 diff --git a/queue-5.16/iommu-amd-recover-from-event-log-overflow.patch b/queue-5.16/iommu-amd-recover-from-event-log-overflow.patch new file mode 100644 index 00000000000..be986b43df6 --- /dev/null +++ b/queue-5.16/iommu-amd-recover-from-event-log-overflow.patch @@ -0,0 +1,117 @@ +From 5ce97f4ec5e0f8726a5dda1710727b1ee9badcac Mon Sep 17 00:00:00 2001 +From: Lennert Buytenhek +Date: Mon, 4 Oct 2021 13:07:24 +0300 +Subject: iommu/amd: Recover from event log overflow + +From: Lennert Buytenhek + +commit 5ce97f4ec5e0f8726a5dda1710727b1ee9badcac upstream. + +The AMD IOMMU logs I/O page faults and such to a ring buffer in +system memory, and this ring buffer can overflow. The AMD IOMMU +spec has the following to say about the interrupt status bit that +signals this overflow condition: + + EventOverflow: Event log overflow. RW1C. Reset 0b. 1 = IOMMU + event log overflow has occurred. This bit is set when a new + event is to be written to the event log and there is no usable + entry in the event log, causing the new event information to + be discarded. An interrupt is generated when EventOverflow = 1b + and MMIO Offset 0018h[EventIntEn] = 1b. No new event log + entries are written while this bit is set. Software Note: To + resume logging, clear EventOverflow (W1C), and write a 1 to + MMIO Offset 0018h[EventLogEn]. + +The AMD IOMMU driver doesn't currently implement this recovery +sequence, meaning that if a ring buffer overflow occurs, logging +of EVT/PPR/GA events will cease entirely. + +This patch implements the spec-mandated reset sequence, with the +minor tweak that the hardware seems to want to have a 0 written to +MMIO Offset 0018h[EventLogEn] first, before writing an 1 into this +field, or the IOMMU won't actually resume logging events. + +Signed-off-by: Lennert Buytenhek +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/r/YVrSXEdW2rzEfOvk@wantstofly.org +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iommu/amd/amd_iommu.h | 1 + + drivers/iommu/amd/amd_iommu_types.h | 1 + + drivers/iommu/amd/init.c | 10 ++++++++++ + drivers/iommu/amd/iommu.c | 10 ++++++++-- + 4 files changed, 20 insertions(+), 2 deletions(-) + +--- a/drivers/iommu/amd/amd_iommu.h ++++ b/drivers/iommu/amd/amd_iommu.h +@@ -14,6 +14,7 @@ + extern irqreturn_t amd_iommu_int_thread(int irq, void *data); + extern irqreturn_t amd_iommu_int_handler(int irq, void *data); + extern void amd_iommu_apply_erratum_63(u16 devid); ++extern void amd_iommu_restart_event_logging(struct amd_iommu *iommu); + extern void amd_iommu_reset_cmd_buffer(struct amd_iommu *iommu); + extern int amd_iommu_init_devices(void); + extern void amd_iommu_uninit_devices(void); +--- a/drivers/iommu/amd/amd_iommu_types.h ++++ b/drivers/iommu/amd/amd_iommu_types.h +@@ -110,6 +110,7 @@ + #define PASID_MASK 0x0000ffff + + /* MMIO status bits */ ++#define MMIO_STATUS_EVT_OVERFLOW_INT_MASK (1 << 0) + #define MMIO_STATUS_EVT_INT_MASK (1 << 1) + #define MMIO_STATUS_COM_WAIT_INT_MASK (1 << 2) + #define MMIO_STATUS_PPR_INT_MASK (1 << 6) +--- a/drivers/iommu/amd/init.c ++++ b/drivers/iommu/amd/init.c +@@ -658,6 +658,16 @@ static int __init alloc_command_buffer(s + } + + /* ++ * This function restarts event logging in case the IOMMU experienced ++ * an event log buffer overflow. ++ */ ++void amd_iommu_restart_event_logging(struct amd_iommu *iommu) ++{ ++ iommu_feature_disable(iommu, CONTROL_EVT_LOG_EN); ++ iommu_feature_enable(iommu, CONTROL_EVT_LOG_EN); ++} ++ ++/* + * This function resets the command buffer if the IOMMU stopped fetching + * commands from it. + */ +--- a/drivers/iommu/amd/iommu.c ++++ b/drivers/iommu/amd/iommu.c +@@ -764,7 +764,8 @@ amd_iommu_set_pci_msi_domain(struct devi + #endif /* !CONFIG_IRQ_REMAP */ + + #define AMD_IOMMU_INT_MASK \ +- (MMIO_STATUS_EVT_INT_MASK | \ ++ (MMIO_STATUS_EVT_OVERFLOW_INT_MASK | \ ++ MMIO_STATUS_EVT_INT_MASK | \ + MMIO_STATUS_PPR_INT_MASK | \ + MMIO_STATUS_GALOG_INT_MASK) + +@@ -774,7 +775,7 @@ irqreturn_t amd_iommu_int_thread(int irq + u32 status = readl(iommu->mmio_base + MMIO_STATUS_OFFSET); + + while (status & AMD_IOMMU_INT_MASK) { +- /* Enable EVT and PPR and GA interrupts again */ ++ /* Enable interrupt sources again */ + writel(AMD_IOMMU_INT_MASK, + iommu->mmio_base + MMIO_STATUS_OFFSET); + +@@ -795,6 +796,11 @@ irqreturn_t amd_iommu_int_thread(int irq + } + #endif + ++ if (status & MMIO_STATUS_EVT_OVERFLOW_INT_MASK) { ++ pr_info_ratelimited("IOMMU event log overflow\n"); ++ amd_iommu_restart_event_logging(iommu); ++ } ++ + /* + * Hardware bug: ERBT1312 + * When re-enabling interrupt (by writing 1 diff --git a/queue-5.16/iommu-vt-d-fix-double-list_add-when-enabling-vmd-in-scalable-mode.patch b/queue-5.16/iommu-vt-d-fix-double-list_add-when-enabling-vmd-in-scalable-mode.patch new file mode 100644 index 00000000000..17a427d3b5d --- /dev/null +++ b/queue-5.16/iommu-vt-d-fix-double-list_add-when-enabling-vmd-in-scalable-mode.patch @@ -0,0 +1,170 @@ +From b00833768e170a31af09268f7ab96aecfcca9623 Mon Sep 17 00:00:00 2001 +From: Adrian Huang +Date: Mon, 21 Feb 2022 13:33:48 +0800 +Subject: iommu/vt-d: Fix double list_add when enabling VMD in scalable mode + +From: Adrian Huang + +commit b00833768e170a31af09268f7ab96aecfcca9623 upstream. + +When enabling VMD and IOMMU scalable mode, the following kernel panic +call trace/kernel log is shown in Eagle Stream platform (Sapphire Rapids +CPU) during booting: + +pci 0000:59:00.5: Adding to iommu group 42 +... +vmd 0000:59:00.5: PCI host bridge to bus 10000:80 +pci 10000:80:01.0: [8086:352a] type 01 class 0x060400 +pci 10000:80:01.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] +pci 10000:80:01.0: enabling Extended Tags +pci 10000:80:01.0: PME# supported from D0 D3hot D3cold +pci 10000:80:01.0: DMAR: Setup RID2PASID failed +pci 10000:80:01.0: Failed to add to iommu group 42: -16 +pci 10000:80:03.0: [8086:352b] type 01 class 0x060400 +pci 10000:80:03.0: reg 0x10: [mem 0x00000000-0x0001ffff 64bit] +pci 10000:80:03.0: enabling Extended Tags +pci 10000:80:03.0: PME# supported from D0 D3hot D3cold +------------[ cut here ]------------ +kernel BUG at lib/list_debug.c:29! +invalid opcode: 0000 [#1] PREEMPT SMP NOPTI +CPU: 0 PID: 7 Comm: kworker/0:1 Not tainted 5.17.0-rc3+ #7 +Hardware name: Lenovo ThinkSystem SR650V3/SB27A86647, BIOS ESE101Y-1.00 01/13/2022 +Workqueue: events work_for_cpu_fn +RIP: 0010:__list_add_valid.cold+0x26/0x3f +Code: 9a 4a ab ff 4c 89 c1 48 c7 c7 40 0c d9 9e e8 b9 b1 fe ff 0f + 0b 48 89 f2 4c 89 c1 48 89 fe 48 c7 c7 f0 0c d9 9e e8 a2 b1 + fe ff <0f> 0b 48 89 d1 4c 89 c6 4c 89 ca 48 c7 c7 98 0c d9 + 9e e8 8b b1 fe +RSP: 0000:ff5ad434865b3a40 EFLAGS: 00010246 +RAX: 0000000000000058 RBX: ff4d61160b74b880 RCX: ff4d61255e1fffa8 +RDX: 0000000000000000 RSI: 00000000fffeffff RDI: ffffffff9fd34f20 +RBP: ff4d611d8e245c00 R08: 0000000000000000 R09: ff5ad434865b3888 +R10: ff5ad434865b3880 R11: ff4d61257fdc6fe8 R12: ff4d61160b74b8a0 +R13: ff4d61160b74b8a0 R14: ff4d611d8e245c10 R15: ff4d611d8001ba70 +FS: 0000000000000000(0000) GS:ff4d611d5ea00000(0000) knlGS:0000000000000000 +CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 +CR2: ff4d611fa1401000 CR3: 0000000aa0210001 CR4: 0000000000771ef0 +DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 +DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 +PKRU: 55555554 +Call Trace: + + intel_pasid_alloc_table+0x9c/0x1d0 + dmar_insert_one_dev_info+0x423/0x540 + ? device_to_iommu+0x12d/0x2f0 + intel_iommu_attach_device+0x116/0x290 + __iommu_attach_device+0x1a/0x90 + iommu_group_add_device+0x190/0x2c0 + __iommu_probe_device+0x13e/0x250 + iommu_probe_device+0x24/0x150 + iommu_bus_notifier+0x69/0x90 + blocking_notifier_call_chain+0x5a/0x80 + device_add+0x3db/0x7b0 + ? arch_memremap_can_ram_remap+0x19/0x50 + ? memremap+0x75/0x140 + pci_device_add+0x193/0x1d0 + pci_scan_single_device+0xb9/0xf0 + pci_scan_slot+0x4c/0x110 + pci_scan_child_bus_extend+0x3a/0x290 + vmd_enable_domain.constprop.0+0x63e/0x820 + vmd_probe+0x163/0x190 + local_pci_probe+0x42/0x80 + work_for_cpu_fn+0x13/0x20 + process_one_work+0x1e2/0x3b0 + worker_thread+0x1c4/0x3a0 + ? rescuer_thread+0x370/0x370 + kthread+0xc7/0xf0 + ? kthread_complete_and_exit+0x20/0x20 + ret_from_fork+0x1f/0x30 + +Modules linked in: +---[ end trace 0000000000000000 ]--- +... +Kernel panic - not syncing: Fatal exception +Kernel Offset: 0x1ca00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) +---[ end Kernel panic - not syncing: Fatal exception ]--- + +The following 'lspci' output shows devices '10000:80:*' are subdevices of +the VMD device 0000:59:00.5: + + $ lspci + ... + 0000:59:00.5 RAID bus controller: Intel Corporation Volume Management Device NVMe RAID Controller (rev 20) + ... + 10000:80:01.0 PCI bridge: Intel Corporation Device 352a (rev 03) + 10000:80:03.0 PCI bridge: Intel Corporation Device 352b (rev 03) + 10000:80:05.0 PCI bridge: Intel Corporation Device 352c (rev 03) + 10000:80:07.0 PCI bridge: Intel Corporation Device 352d (rev 03) + 10000:81:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller] + 10000:82:00.0 Non-Volatile memory controller: Intel Corporation NVMe Datacenter SSD [3DNAND, Beta Rock Controller] + +The symptom 'list_add double add' is caused by the following failure +message: + + pci 10000:80:01.0: DMAR: Setup RID2PASID failed + pci 10000:80:01.0: Failed to add to iommu group 42: -16 + pci 10000:80:03.0: [8086:352b] type 01 class 0x060400 + +Device 10000:80:01.0 is the subdevice of the VMD device 0000:59:00.5, +so invoking intel_pasid_alloc_table() gets the pasid_table of the VMD +device 0000:59:00.5. Here is call path: + + intel_pasid_alloc_table + pci_for_each_dma_alias + get_alias_pasid_table + search_pasid_table + +pci_real_dma_dev() in pci_for_each_dma_alias() gets the real dma device +which is the VMD device 0000:59:00.5. However, pte of the VMD device +0000:59:00.5 has been configured during this message "pci 0000:59:00.5: +Adding to iommu group 42". So, the status -EBUSY is returned when +configuring pasid entry for device 10000:80:01.0. + +It then invokes dmar_remove_one_dev_info() to release +'struct device_domain_info *' from iommu_devinfo_cache. But, the pasid +table is not released because of the following statement in +__dmar_remove_one_dev_info(): + + if (info->dev && !dev_is_real_dma_subdevice(info->dev)) { + ... + intel_pasid_free_table(info->dev); + } + +The subsequent dmar_insert_one_dev_info() operation of device +10000:80:03.0 allocates 'struct device_domain_info *' from +iommu_devinfo_cache. The allocated address is the same address that +is released previously for device 10000:80:01.0. Finally, invoking +device_attach_pasid_table() causes the issue. + +`git bisect` points to the offending commit 474dd1c65064 ("iommu/vt-d: +Fix clearing real DMA device's scalable-mode context entries"), which +releases the pasid table if the device is not the subdevice by +checking the returned status of dev_is_real_dma_subdevice(). +Reverting the offending commit can work around the issue. + +The solution is to prevent from allocating pasid table if those +devices are subdevices of the VMD device. + +Fixes: 474dd1c65064 ("iommu/vt-d: Fix clearing real DMA device's scalable-mode context entries") +Cc: stable@vger.kernel.org # v5.14+ +Signed-off-by: Adrian Huang +Link: https://lore.kernel.org/r/20220216091307.703-1-adrianhuang0701@gmail.com +Signed-off-by: Lu Baolu +Link: https://lore.kernel.org/r/20220221053348.262724-2-baolu.lu@linux.intel.com +Signed-off-by: Joerg Roedel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iommu/intel/iommu.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iommu/intel/iommu.c ++++ b/drivers/iommu/intel/iommu.c +@@ -2773,7 +2773,7 @@ static struct dmar_domain *dmar_insert_o + spin_unlock_irqrestore(&device_domain_lock, flags); + + /* PASID table is mandatory for a PCI device in scalable mode. */ +- if (dev && dev_is_pci(dev) && sm_supported(iommu)) { ++ if (sm_supported(iommu) && !dev_is_real_dma_subdevice(dev)) { + ret = intel_pasid_alloc_table(dev); + if (ret) { + dev_err(dev, "PASID table allocation failed\n"); diff --git a/queue-5.16/iwlwifi-mvm-check-debugfs_dir-ptr-before-use.patch b/queue-5.16/iwlwifi-mvm-check-debugfs_dir-ptr-before-use.patch new file mode 100644 index 00000000000..722e232fd30 --- /dev/null +++ b/queue-5.16/iwlwifi-mvm-check-debugfs_dir-ptr-before-use.patch @@ -0,0 +1,118 @@ +From 5a6248c0a22352f09ea041665d3bd3e18f6f872c Mon Sep 17 00:00:00 2001 +From: Randy Dunlap +Date: Tue, 22 Feb 2022 19:06:30 -0800 +Subject: iwlwifi: mvm: check debugfs_dir ptr before use + +From: Randy Dunlap + +commit 5a6248c0a22352f09ea041665d3bd3e18f6f872c upstream. + +When "debugfs=off" is used on the kernel command line, iwiwifi's +mvm module uses an invalid/unchecked debugfs_dir pointer and causes +a BUG: + + BUG: kernel NULL pointer dereference, address: 000000000000004f + #PF: supervisor read access in kernel mode + #PF: error_code(0x0000) - not-present page + PGD 0 P4D 0 + Oops: 0000 [#1] PREEMPT SMP + CPU: 1 PID: 503 Comm: modprobe Tainted: G W 5.17.0-rc5 #7 + Hardware name: Dell Inc. Inspiron 15 5510/076F7Y, BIOS 2.4.1 11/05/2021 + RIP: 0010:iwl_mvm_dbgfs_register+0x692/0x700 [iwlmvm] + Code: 69 a0 be 80 01 00 00 48 c7 c7 50 73 6a a0 e8 95 cf ee e0 48 8b 83 b0 1e 00 00 48 c7 c2 54 73 6a a0 be 64 00 00 00 48 8d 7d 8c <48> 8b 48 50 e8 15 22 07 e1 48 8b 43 28 48 8d 55 8c 48 c7 c7 5f 73 + RSP: 0018:ffffc90000a0ba68 EFLAGS: 00010246 + RAX: ffffffffffffffff RBX: ffff88817d6e3328 RCX: ffff88817d6e3328 + RDX: ffffffffa06a7354 RSI: 0000000000000064 RDI: ffffc90000a0ba6c + RBP: ffffc90000a0bae0 R08: ffffffff824e4880 R09: ffffffffa069d620 + R10: ffffc90000a0ba00 R11: ffffffffffffffff R12: 0000000000000000 + R13: ffffc90000a0bb28 R14: ffff88817d6e3328 R15: ffff88817d6e3320 + FS: 00007f64dd92d740(0000) GS:ffff88847f640000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 000000000000004f CR3: 000000016fc79001 CR4: 0000000000770ee0 + PKRU: 55555554 + Call Trace: + + ? iwl_mvm_mac_setup_register+0xbdc/0xda0 [iwlmvm] + iwl_mvm_start_post_nvm+0x71/0x100 [iwlmvm] + iwl_op_mode_mvm_start+0xab8/0xb30 [iwlmvm] + _iwl_op_mode_start+0x6f/0xd0 [iwlwifi] + iwl_opmode_register+0x6a/0xe0 [iwlwifi] + ? 0xffffffffa0231000 + iwl_mvm_init+0x35/0x1000 [iwlmvm] + ? 0xffffffffa0231000 + do_one_initcall+0x5a/0x1b0 + ? kmem_cache_alloc+0x1e5/0x2f0 + ? do_init_module+0x1e/0x220 + do_init_module+0x48/0x220 + load_module+0x2602/0x2bc0 + ? __kernel_read+0x145/0x2e0 + ? kernel_read_file+0x229/0x290 + __do_sys_finit_module+0xc5/0x130 + ? __do_sys_finit_module+0xc5/0x130 + __x64_sys_finit_module+0x13/0x20 + do_syscall_64+0x38/0x90 + entry_SYSCALL_64_after_hwframe+0x44/0xae + RIP: 0033:0x7f64dda564dd + Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 1b 29 0f 00 f7 d8 64 89 01 48 + RSP: 002b:00007ffdba393f88 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 + RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f64dda564dd + RDX: 0000000000000000 RSI: 00005575399e2ab2 RDI: 0000000000000001 + RBP: 000055753a91c5e0 R08: 0000000000000000 R09: 0000000000000002 + R10: 0000000000000001 R11: 0000000000000246 R12: 00005575399e2ab2 + R13: 000055753a91ceb0 R14: 0000000000000000 R15: 000055753a923018 + + Modules linked in: btintel(+) btmtk bluetooth vfat snd_hda_codec_hdmi fat snd_hda_codec_realtek snd_hda_codec_generic iwlmvm(+) snd_sof_pci_intel_tgl mac80211 snd_sof_intel_hda_common soundwire_intel soundwire_generic_allocation soundwire_cadence soundwire_bus snd_sof_intel_hda snd_sof_pci snd_sof snd_sof_xtensa_dsp snd_soc_hdac_hda snd_hda_ext_core snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core btrfs snd_compress snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec raid6_pq iwlwifi snd_hda_core snd_pcm snd_timer snd soundcore cfg80211 intel_ish_ipc(+) thunderbolt rfkill intel_ishtp ucsi_acpi wmi i2c_hid_acpi i2c_hid evdev + CR2: 000000000000004f + ---[ end trace 0000000000000000 ]--- + +Check the debugfs_dir pointer for an error before using it. + +Fixes: 8c082a99edb9 ("iwlwifi: mvm: simplify iwl_mvm_dbgfs_register") +Signed-off-by: Randy Dunlap +Cc: Luca Coelho +Cc: linux-wireless@vger.kernel.org +Cc: Kalle Valo +Cc: Greg Kroah-Hartman +Cc: Emmanuel Grumbach +Cc: stable +Reviewed-by: Greg Kroah-Hartman +Link: https://lore.kernel.org/r/20220223030630.23241-1-rdunlap@infradead.org +[change to make both conditional] +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c | 11 ++++++++--- + 1 file changed, 8 insertions(+), 3 deletions(-) + +--- a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c ++++ b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs.c +@@ -5,6 +5,7 @@ + * Copyright (C) 2016-2017 Intel Deutschland GmbH + */ + #include ++#include + #include + #include + +@@ -1849,7 +1850,6 @@ void iwl_mvm_sta_add_debugfs(struct ieee + void iwl_mvm_dbgfs_register(struct iwl_mvm *mvm) + { + struct dentry *bcast_dir __maybe_unused; +- char buf[100]; + + spin_lock_init(&mvm->drv_stats_lock); + +@@ -1930,6 +1930,11 @@ void iwl_mvm_dbgfs_register(struct iwl_m + * Create a symlink with mac80211. It will be removed when mac80211 + * exists (before the opmode exists which removes the target.) + */ +- snprintf(buf, 100, "../../%pd2", mvm->debugfs_dir->d_parent); +- debugfs_create_symlink("iwlwifi", mvm->hw->wiphy->debugfsdir, buf); ++ if (!IS_ERR(mvm->debugfs_dir)) { ++ char buf[100]; ++ ++ snprintf(buf, 100, "../../%pd2", mvm->debugfs_dir->d_parent); ++ debugfs_create_symlink("iwlwifi", mvm->hw->wiphy->debugfsdir, ++ buf); ++ } + } diff --git a/queue-5.16/mac80211-fix-eapol-rekey-fail-in-802.3-rx-path.patch b/queue-5.16/mac80211-fix-eapol-rekey-fail-in-802.3-rx-path.patch new file mode 100644 index 00000000000..a8bfc2edeef --- /dev/null +++ b/queue-5.16/mac80211-fix-eapol-rekey-fail-in-802.3-rx-path.patch @@ -0,0 +1,65 @@ +From 610d086d6df0b15c3732a7b4a5b0f1c3e1b84d4c Mon Sep 17 00:00:00 2001 +From: Deren Wu +Date: Sun, 13 Feb 2022 00:20:15 +0800 +Subject: mac80211: fix EAPoL rekey fail in 802.3 rx path + +From: Deren Wu + +commit 610d086d6df0b15c3732a7b4a5b0f1c3e1b84d4c upstream. + +mac80211 set capability NL80211_EXT_FEATURE_CONTROL_PORT_OVER_NL80211 +to upper layer by default. That means we should pass EAPoL packets through +nl80211 path only, and should not send the EAPoL skb to netdevice diretly. +At the meanwhile, wpa_supplicant would not register sock to listen EAPoL +skb on the netdevice. + +However, there is no control_port_protocol handler in mac80211 for 802.3 RX +packets, mac80211 driver would pass up the EAPoL rekey frame to netdevice +and wpa_supplicant would be never interactive with this kind of packets, +if SUPPORTS_RX_DECAP_OFFLOAD is enabled. This causes STA always rekey fail +if EAPoL frame go through 802.3 path. + +To avoid this problem, align the same process as 802.11 type to handle +this frame before put it into network stack. + +This also addresses a potential security issue in 802.3 RX mode that was +previously fixed in commit a8c4d76a8dd4 ("mac80211: do not accept/forward +invalid EAPOL frames"). + +Cc: stable@vger.kernel.org # 5.12+ +Fixes: 80a915ec4427 ("mac80211: add rx decapsulation offload support") +Signed-off-by: Deren Wu +Link: https://lore.kernel.org/r/6889c9fced5859ebb088564035f84fd0fa792a49.1644680751.git.deren.wu@mediatek.com +[fix typos, update comment and add note about security issue] +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman +--- + net/mac80211/rx.c | 10 +++------- + 1 file changed, 3 insertions(+), 7 deletions(-) + +--- a/net/mac80211/rx.c ++++ b/net/mac80211/rx.c +@@ -2602,7 +2602,8 @@ static void ieee80211_deliver_skb_to_loc + * address, so that the authenticator (e.g. hostapd) will see + * the frame, but bridge won't forward it anywhere else. Note + * that due to earlier filtering, the only other address can +- * be the PAE group address. ++ * be the PAE group address, unless the hardware allowed them ++ * through in 802.3 offloaded mode. + */ + if (unlikely(skb->protocol == sdata->control_port_protocol && + !ether_addr_equal(ehdr->h_dest, sdata->vif.addr))) +@@ -4509,12 +4510,7 @@ static void ieee80211_rx_8023(struct iee + + /* deliver to local stack */ + skb->protocol = eth_type_trans(skb, fast_rx->dev); +- memset(skb->cb, 0, sizeof(skb->cb)); +- if (rx->list) +- list_add_tail(&skb->list, rx->list); +- else +- netif_receive_skb(skb); +- ++ ieee80211_deliver_skb_to_local_stack(skb, rx); + } + + static bool ieee80211_invoke_fast_rx(struct ieee80211_rx_data *rx, diff --git a/queue-5.16/ntb-intel-fix-port-config-status-offset-for-spr.patch b/queue-5.16/ntb-intel-fix-port-config-status-offset-for-spr.patch new file mode 100644 index 00000000000..34ab3eebefb --- /dev/null +++ b/queue-5.16/ntb-intel-fix-port-config-status-offset-for-spr.patch @@ -0,0 +1,100 @@ +From d5081bf5dcfb1cb83fb538708b0ac07a10a79cc4 Mon Sep 17 00:00:00 2001 +From: Dave Jiang +Date: Thu, 27 Jan 2022 13:31:12 -0700 +Subject: ntb: intel: fix port config status offset for SPR + +From: Dave Jiang + +commit d5081bf5dcfb1cb83fb538708b0ac07a10a79cc4 upstream. + +The field offset for port configuration status on SPR has been changed to +bit 14 from ICX where it resides at bit 12. By chance link status detection +continued to work on SPR. This is due to bit 12 being a configuration bit +which is in sync with the status bit. Fix this by checking for a SPR device +and checking correct status bit. + +Fixes: 26bfe3d0b227 ("ntb: intel: Add Icelake (gen4) support for Intel NTB") +Tested-by: Jerry Dai +Signed-off-by: Dave Jiang +Signed-off-by: Jon Mason +Signed-off-by: Greg Kroah-Hartman +--- + drivers/ntb/hw/intel/ntb_hw_gen4.c | 17 ++++++++++++++++- + drivers/ntb/hw/intel/ntb_hw_gen4.h | 16 ++++++++++++++++ + 2 files changed, 32 insertions(+), 1 deletion(-) + +--- a/drivers/ntb/hw/intel/ntb_hw_gen4.c ++++ b/drivers/ntb/hw/intel/ntb_hw_gen4.c +@@ -168,6 +168,18 @@ static enum ntb_topo gen4_ppd_topo(struc + return NTB_TOPO_NONE; + } + ++static enum ntb_topo spr_ppd_topo(struct intel_ntb_dev *ndev, u32 ppd) ++{ ++ switch (ppd & SPR_PPD_TOPO_MASK) { ++ case SPR_PPD_TOPO_B2B_USD: ++ return NTB_TOPO_B2B_USD; ++ case SPR_PPD_TOPO_B2B_DSD: ++ return NTB_TOPO_B2B_DSD; ++ } ++ ++ return NTB_TOPO_NONE; ++} ++ + int gen4_init_dev(struct intel_ntb_dev *ndev) + { + struct pci_dev *pdev = ndev->ntb.pdev; +@@ -183,7 +195,10 @@ int gen4_init_dev(struct intel_ntb_dev * + } + + ppd1 = ioread32(ndev->self_mmio + GEN4_PPD1_OFFSET); +- ndev->ntb.topo = gen4_ppd_topo(ndev, ppd1); ++ if (pdev_is_ICX(pdev)) ++ ndev->ntb.topo = gen4_ppd_topo(ndev, ppd1); ++ else if (pdev_is_SPR(pdev)) ++ ndev->ntb.topo = spr_ppd_topo(ndev, ppd1); + dev_dbg(&pdev->dev, "ppd %#x topo %s\n", ppd1, + ntb_topo_string(ndev->ntb.topo)); + if (ndev->ntb.topo == NTB_TOPO_NONE) +--- a/drivers/ntb/hw/intel/ntb_hw_gen4.h ++++ b/drivers/ntb/hw/intel/ntb_hw_gen4.h +@@ -49,10 +49,14 @@ + #define GEN4_PPD_CLEAR_TRN 0x0001 + #define GEN4_PPD_LINKTRN 0x0008 + #define GEN4_PPD_CONN_MASK 0x0300 ++#define SPR_PPD_CONN_MASK 0x0700 + #define GEN4_PPD_CONN_B2B 0x0200 + #define GEN4_PPD_DEV_MASK 0x1000 + #define GEN4_PPD_DEV_DSD 0x1000 + #define GEN4_PPD_DEV_USD 0x0000 ++#define SPR_PPD_DEV_MASK 0x4000 ++#define SPR_PPD_DEV_DSD 0x4000 ++#define SPR_PPD_DEV_USD 0x0000 + #define GEN4_LINK_CTRL_LINK_DISABLE 0x0010 + + #define GEN4_SLOTSTS 0xb05a +@@ -62,6 +66,10 @@ + #define GEN4_PPD_TOPO_B2B_USD (GEN4_PPD_CONN_B2B | GEN4_PPD_DEV_USD) + #define GEN4_PPD_TOPO_B2B_DSD (GEN4_PPD_CONN_B2B | GEN4_PPD_DEV_DSD) + ++#define SPR_PPD_TOPO_MASK (SPR_PPD_CONN_MASK | SPR_PPD_DEV_MASK) ++#define SPR_PPD_TOPO_B2B_USD (GEN4_PPD_CONN_B2B | SPR_PPD_DEV_USD) ++#define SPR_PPD_TOPO_B2B_DSD (GEN4_PPD_CONN_B2B | SPR_PPD_DEV_DSD) ++ + #define GEN4_DB_COUNT 32 + #define GEN4_DB_LINK 32 + #define GEN4_DB_LINK_BIT BIT_ULL(GEN4_DB_LINK) +@@ -111,5 +119,13 @@ static inline int pdev_is_ICX(struct pci + return 1; + return 0; + } ++ ++static inline int pdev_is_SPR(struct pci_dev *pdev) ++{ ++ if (pdev_is_gen4(pdev) && ++ pdev->revision > PCI_DEVICE_REVISION_ICX_MAX) ++ return 1; ++ return 0; ++} + + #endif diff --git a/queue-5.16/riscv-efi_stub-fix-get_boot_hartid_from_fdt-return-value.patch b/queue-5.16/riscv-efi_stub-fix-get_boot_hartid_from_fdt-return-value.patch new file mode 100644 index 00000000000..ce4ad521fb3 --- /dev/null +++ b/queue-5.16/riscv-efi_stub-fix-get_boot_hartid_from_fdt-return-value.patch @@ -0,0 +1,67 @@ +From dcf0c838854c86e1f41fb1934aea906845d69782 Mon Sep 17 00:00:00 2001 +From: Sunil V L +Date: Fri, 28 Jan 2022 10:20:04 +0530 +Subject: riscv/efi_stub: Fix get_boot_hartid_from_fdt() return value + +From: Sunil V L + +commit dcf0c838854c86e1f41fb1934aea906845d69782 upstream. + +The get_boot_hartid_from_fdt() function currently returns U32_MAX +for failure case which is not correct because U32_MAX is a valid +hartid value. This patch fixes the issue by returning error code. + +Cc: +Fixes: d7071743db31 ("RISC-V: Add EFI stub support.") +Signed-off-by: Sunil V L +Reviewed-by: Heinrich Schuchardt +Signed-off-by: Ard Biesheuvel +Signed-off-by: Greg Kroah-Hartman +--- + drivers/firmware/efi/libstub/riscv-stub.c | 17 ++++++++++------- + 1 file changed, 10 insertions(+), 7 deletions(-) + +--- a/drivers/firmware/efi/libstub/riscv-stub.c ++++ b/drivers/firmware/efi/libstub/riscv-stub.c +@@ -25,7 +25,7 @@ typedef void __noreturn (*jump_kernel_fu + + static u32 hartid; + +-static u32 get_boot_hartid_from_fdt(void) ++static int get_boot_hartid_from_fdt(void) + { + const void *fdt; + int chosen_node, len; +@@ -33,23 +33,26 @@ static u32 get_boot_hartid_from_fdt(void + + fdt = get_efi_config_table(DEVICE_TREE_GUID); + if (!fdt) +- return U32_MAX; ++ return -EINVAL; + + chosen_node = fdt_path_offset(fdt, "/chosen"); + if (chosen_node < 0) +- return U32_MAX; ++ return -EINVAL; + + prop = fdt_getprop((void *)fdt, chosen_node, "boot-hartid", &len); + if (!prop || len != sizeof(u32)) +- return U32_MAX; ++ return -EINVAL; + +- return fdt32_to_cpu(*prop); ++ hartid = fdt32_to_cpu(*prop); ++ return 0; + } + + efi_status_t check_platform_features(void) + { +- hartid = get_boot_hartid_from_fdt(); +- if (hartid == U32_MAX) { ++ int ret; ++ ++ ret = get_boot_hartid_from_fdt(); ++ if (ret) { + efi_err("/chosen/boot-hartid missing or invalid!\n"); + return EFI_UNSUPPORTED; + } diff --git a/queue-5.16/riscv-fix-config-kasan-debug_virtual.patch b/queue-5.16/riscv-fix-config-kasan-debug_virtual.patch new file mode 100644 index 00000000000..fb2dee3116b --- /dev/null +++ b/queue-5.16/riscv-fix-config-kasan-debug_virtual.patch @@ -0,0 +1,36 @@ +From c648c4bb7d02ceb53ee40172fdc4433b37cee9c6 Mon Sep 17 00:00:00 2001 +From: Alexandre Ghiti +Date: Fri, 25 Feb 2022 13:39:51 +0100 +Subject: riscv: Fix config KASAN && DEBUG_VIRTUAL + +From: Alexandre Ghiti + +commit c648c4bb7d02ceb53ee40172fdc4433b37cee9c6 upstream. + +__virt_to_phys function is called very early in the boot process (ie +kasan_early_init) so it should not be instrumented by KASAN otherwise it +bugs. + +Fix this by declaring phys_addr.c as non-kasan instrumentable. + +Signed-off-by: Alexandre Ghiti +Fixes: 8ad8b72721d0 (riscv: Add KASAN support) +Cc: stable@vger.kernel.org +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/mm/Makefile | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/arch/riscv/mm/Makefile ++++ b/arch/riscv/mm/Makefile +@@ -24,6 +24,9 @@ obj-$(CONFIG_KASAN) += kasan_init.o + ifdef CONFIG_KASAN + KASAN_SANITIZE_kasan_init.o := n + KASAN_SANITIZE_init.o := n ++ifdef CONFIG_DEBUG_VIRTUAL ++KASAN_SANITIZE_physaddr.o := n ++endif + endif + + obj-$(CONFIG_DEBUG_VIRTUAL) += physaddr.o diff --git a/queue-5.16/riscv-fix-config-kasan-sparsemem-sparse_vmemmap.patch b/queue-5.16/riscv-fix-config-kasan-sparsemem-sparse_vmemmap.patch new file mode 100644 index 00000000000..b3612797d8a --- /dev/null +++ b/queue-5.16/riscv-fix-config-kasan-sparsemem-sparse_vmemmap.patch @@ -0,0 +1,39 @@ +From a3d328037846d013bb4c7f3777241e190e4c75e1 Mon Sep 17 00:00:00 2001 +From: Alexandre Ghiti +Date: Fri, 25 Feb 2022 13:39:49 +0100 +Subject: riscv: Fix config KASAN && SPARSEMEM && !SPARSE_VMEMMAP + +From: Alexandre Ghiti + +commit a3d328037846d013bb4c7f3777241e190e4c75e1 upstream. + +In order to get the pfn of a struct page* when sparsemem is enabled +without vmemmap, the mem_section structures need to be initialized which +happens in sparse_init. + +But kasan_early_init calls pfn_to_page way before sparse_init is called, +which then tries to dereference a null mem_section pointer. + +Fix this by removing the usage of this function in kasan_early_init. + +Fixes: 8ad8b72721d0 ("riscv: Add KASAN support") +Signed-off-by: Alexandre Ghiti +Cc: stable@vger.kernel.org +Signed-off-by: Palmer Dabbelt +Signed-off-by: Greg Kroah-Hartman +--- + arch/riscv/mm/kasan_init.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/arch/riscv/mm/kasan_init.c ++++ b/arch/riscv/mm/kasan_init.c +@@ -22,8 +22,7 @@ asmlinkage void __init kasan_early_init( + + for (i = 0; i < PTRS_PER_PTE; ++i) + set_pte(kasan_early_shadow_pte + i, +- mk_pte(virt_to_page(kasan_early_shadow_page), +- PAGE_KERNEL)); ++ pfn_pte(virt_to_pfn(kasan_early_shadow_page), PAGE_KERNEL)); + + for (i = 0; i < PTRS_PER_PMD; ++i) + set_pmd(kasan_early_shadow_pmd + i, diff --git a/queue-5.16/series b/queue-5.16/series index 811deb392ca..b7ed499aa51 100644 --- a/queue-5.16/series +++ b/queue-5.16/series @@ -45,3 +45,20 @@ tracing-add-ustring-operation-to-filtering-string-po.patch ipv6-fix-skb-drops-in-igmp6_event_query-and-igmp6_ev.patch btrfs-defrag-bring-back-the-old-file-extent-search-behavior.patch btrfs-defrag-don-t-use-merged-extent-map-for-their-generation-check.patch +alsa-intel_hdmi-fix-reference-to-pcm-buffer-address.patch +ucounts-fix-systemd-limitnproc-with-private-users-regression.patch +binfmt_elf-avoid-total_mapping_size-for-et_exec.patch +riscv-efi_stub-fix-get_boot_hartid_from_fdt-return-value.patch +riscv-fix-config-kasan-sparsemem-sparse_vmemmap.patch +riscv-fix-config-kasan-debug_virtual.patch +iwlwifi-mvm-check-debugfs_dir-ptr-before-use.patch +asoc-ops-shift-tested-values-in-snd_soc_put_volsw-by-min.patch +iommu-vt-d-fix-double-list_add-when-enabling-vmd-in-scalable-mode.patch +iommu-amd-recover-from-event-log-overflow.patch +drm-i915-s-jsp2-icp2-pch.patch +drm-amd-display-reduce-dmesg-error-to-a-debug-print.patch +xen-netfront-destroy-queues-before-real_num_tx_queues-is-zeroed.patch +thermal-core-fix-tz_get_trip-null-pointer-dereference.patch +mac80211-fix-eapol-rekey-fail-in-802.3-rx-path.patch +blktrace-fix-use-after-free-for-struct-blk_trace.patch +ntb-intel-fix-port-config-status-offset-for-spr.patch diff --git a/queue-5.16/thermal-core-fix-tz_get_trip-null-pointer-dereference.patch b/queue-5.16/thermal-core-fix-tz_get_trip-null-pointer-dereference.patch new file mode 100644 index 00000000000..bf7249d61ab --- /dev/null +++ b/queue-5.16/thermal-core-fix-tz_get_trip-null-pointer-dereference.patch @@ -0,0 +1,38 @@ +From 5838a14832d447990827d85e90afe17e6fb9c175 Mon Sep 17 00:00:00 2001 +From: Nicolas Cavallari +Date: Mon, 28 Feb 2022 12:03:51 +0100 +Subject: thermal: core: Fix TZ_GET_TRIP NULL pointer dereference + +From: Nicolas Cavallari + +commit 5838a14832d447990827d85e90afe17e6fb9c175 upstream. + +Do not call get_trip_hyst() from thermal_genl_cmd_tz_get_trip() if +the thermal zone does not define one. + +Fixes: 1ce50e7d408e ("thermal: core: genetlink support for events/cmd/sampling") +Signed-off-by: Nicolas Cavallari +Cc: 5.10+ # 5.10+ +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman +--- + drivers/thermal/thermal_netlink.c | 5 +++-- + 1 file changed, 3 insertions(+), 2 deletions(-) + +--- a/drivers/thermal/thermal_netlink.c ++++ b/drivers/thermal/thermal_netlink.c +@@ -419,11 +419,12 @@ static int thermal_genl_cmd_tz_get_trip( + for (i = 0; i < tz->trips; i++) { + + enum thermal_trip_type type; +- int temp, hyst; ++ int temp, hyst = 0; + + tz->ops->get_trip_type(tz, i, &type); + tz->ops->get_trip_temp(tz, i, &temp); +- tz->ops->get_trip_hyst(tz, i, &hyst); ++ if (tz->ops->get_trip_hyst) ++ tz->ops->get_trip_hyst(tz, i, &hyst); + + if (nla_put_u32(msg, THERMAL_GENL_ATTR_TZ_TRIP_ID, i) || + nla_put_u32(msg, THERMAL_GENL_ATTR_TZ_TRIP_TYPE, type) || diff --git a/queue-5.16/ucounts-fix-systemd-limitnproc-with-private-users-regression.patch b/queue-5.16/ucounts-fix-systemd-limitnproc-with-private-users-regression.patch new file mode 100644 index 00000000000..a2868a29b6a --- /dev/null +++ b/queue-5.16/ucounts-fix-systemd-limitnproc-with-private-users-regression.patch @@ -0,0 +1,67 @@ +From 0ac983f512033cb7b5e210c9589768ad25b1e36b Mon Sep 17 00:00:00 2001 +From: "Eric W. Biederman" +Date: Thu, 24 Feb 2022 08:32:28 -0600 +Subject: ucounts: Fix systemd LimitNPROC with private users regression + +From: Eric W. Biederman + +commit 0ac983f512033cb7b5e210c9589768ad25b1e36b upstream. + +Long story short recursively enforcing RLIMIT_NPROC when it is not +enforced on the process that creates a new user namespace, causes +currently working code to fail. There is no reason to enforce +RLIMIT_NPROC recursively when we don't enforce it normally so update +the code to detect this case. + +I would like to simply use capable(CAP_SYS_RESOURCE) to detect when +RLIMIT_NPROC is not enforced upon the caller. Unfortunately because +RLIMIT_NPROC is charged and checked for enforcement based upon the +real uid, using capable() which is euid based is inconsistent with reality. +Come as close as possible to testing for capable(CAP_SYS_RESOURCE) by +testing for when the real uid would match the conditions when +CAP_SYS_RESOURCE would be present if the real uid was the effective +uid. + +Reported-by: Etienne Dechamps +Link: https://bugzilla.kernel.org/show_bug.cgi?id=215596 +Link: https://lkml.kernel.org/r/e9589141-cfeb-90cd-2d0e-83a62787239a@edechamps.fr +Link: https://lkml.kernel.org/r/87sfs8jmpz.fsf_-_@email.froward.int.ebiederm.org +Cc: stable@vger.kernel.org +Fixes: 21d1c5e386bc ("Reimplement RLIMIT_NPROC on top of ucounts") +Reviewed-by: Kees Cook +Signed-off-by: "Eric W. Biederman" +Signed-off-by: Greg Kroah-Hartman +--- + kernel/user_namespace.c | 14 +++++++++++++- + 1 file changed, 13 insertions(+), 1 deletion(-) + +--- a/kernel/user_namespace.c ++++ b/kernel/user_namespace.c +@@ -58,6 +58,18 @@ static void set_cred_user_ns(struct cred + cred->user_ns = user_ns; + } + ++static unsigned long enforced_nproc_rlimit(void) ++{ ++ unsigned long limit = RLIM_INFINITY; ++ ++ /* Is RLIMIT_NPROC currently enforced? */ ++ if (!uid_eq(current_uid(), GLOBAL_ROOT_UID) || ++ (current_user_ns() != &init_user_ns)) ++ limit = rlimit(RLIMIT_NPROC); ++ ++ return limit; ++} ++ + /* + * Create a new user namespace, deriving the creator from the user in the + * passed credentials, and replacing that user with the new root user for the +@@ -122,7 +134,7 @@ int create_user_ns(struct cred *new) + for (i = 0; i < MAX_PER_NAMESPACE_UCOUNTS; i++) { + ns->ucount_max[i] = INT_MAX; + } +- set_rlimit_ucount_max(ns, UCOUNT_RLIMIT_NPROC, rlimit(RLIMIT_NPROC)); ++ set_rlimit_ucount_max(ns, UCOUNT_RLIMIT_NPROC, enforced_nproc_rlimit()); + set_rlimit_ucount_max(ns, UCOUNT_RLIMIT_MSGQUEUE, rlimit(RLIMIT_MSGQUEUE)); + set_rlimit_ucount_max(ns, UCOUNT_RLIMIT_SIGPENDING, rlimit(RLIMIT_SIGPENDING)); + set_rlimit_ucount_max(ns, UCOUNT_RLIMIT_MEMLOCK, rlimit(RLIMIT_MEMLOCK)); diff --git a/queue-5.16/xen-netfront-destroy-queues-before-real_num_tx_queues-is-zeroed.patch b/queue-5.16/xen-netfront-destroy-queues-before-real_num_tx_queues-is-zeroed.patch new file mode 100644 index 00000000000..dfc7f09ccba --- /dev/null +++ b/queue-5.16/xen-netfront-destroy-queues-before-real_num_tx_queues-is-zeroed.patch @@ -0,0 +1,138 @@ +From dcf4ff7a48e7598e6b10126cc02177abb8ae4f3f Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?= + +Date: Wed, 23 Feb 2022 22:19:54 +0100 +Subject: xen/netfront: destroy queues before real_num_tx_queues is zeroed +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Marek Marczykowski-Górecki + +commit dcf4ff7a48e7598e6b10126cc02177abb8ae4f3f upstream. + +xennet_destroy_queues() relies on info->netdev->real_num_tx_queues to +delete queues. Since d7dac083414eb5bb99a6d2ed53dc2c1b405224e5 +("net-sysfs: update the queue counts in the unregistration path"), +unregister_netdev() indirectly sets real_num_tx_queues to 0. Those two +facts together means, that xennet_destroy_queues() called from +xennet_remove() cannot do its job, because it's called after +unregister_netdev(). This results in kfree-ing queues that are still +linked in napi, which ultimately crashes: + + BUG: kernel NULL pointer dereference, address: 0000000000000000 + #PF: supervisor read access in kernel mode + #PF: error_code(0x0000) - not-present page + PGD 0 P4D 0 + Oops: 0000 [#1] PREEMPT SMP PTI + CPU: 1 PID: 52 Comm: xenwatch Tainted: G W 5.16.10-1.32.fc32.qubes.x86_64+ #226 + RIP: 0010:free_netdev+0xa3/0x1a0 + Code: ff 48 89 df e8 2e e9 00 00 48 8b 43 50 48 8b 08 48 8d b8 a0 fe ff ff 48 8d a9 a0 fe ff ff 49 39 c4 75 26 eb 47 e8 ed c1 66 ff <48> 8b 85 60 01 00 00 48 8d 95 60 01 00 00 48 89 ef 48 2d 60 01 00 + RSP: 0000:ffffc90000bcfd00 EFLAGS: 00010286 + RAX: 0000000000000000 RBX: ffff88800edad000 RCX: 0000000000000000 + RDX: 0000000000000001 RSI: ffffc90000bcfc30 RDI: 00000000ffffffff + RBP: fffffffffffffea0 R08: 0000000000000000 R09: 0000000000000000 + R10: 0000000000000000 R11: 0000000000000001 R12: ffff88800edad050 + R13: ffff8880065f8f88 R14: 0000000000000000 R15: ffff8880066c6680 + FS: 0000000000000000(0000) GS:ffff8880f3300000(0000) knlGS:0000000000000000 + CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 + CR2: 0000000000000000 CR3: 00000000e998c006 CR4: 00000000003706e0 + Call Trace: + + xennet_remove+0x13d/0x300 [xen_netfront] + xenbus_dev_remove+0x6d/0xf0 + __device_release_driver+0x17a/0x240 + device_release_driver+0x24/0x30 + bus_remove_device+0xd8/0x140 + device_del+0x18b/0x410 + ? _raw_spin_unlock+0x16/0x30 + ? klist_iter_exit+0x14/0x20 + ? xenbus_dev_request_and_reply+0x80/0x80 + device_unregister+0x13/0x60 + xenbus_dev_changed+0x18e/0x1f0 + xenwatch_thread+0xc0/0x1a0 + ? do_wait_intr_irq+0xa0/0xa0 + kthread+0x16b/0x190 + ? set_kthread_struct+0x40/0x40 + ret_from_fork+0x22/0x30 + + +Fix this by calling xennet_destroy_queues() from xennet_uninit(), +when real_num_tx_queues is still available. This ensures that queues are +destroyed when real_num_tx_queues is set to 0, regardless of how +unregister_netdev() was called. + +Originally reported at +https://github.com/QubesOS/qubes-issues/issues/7257 + +Fixes: d7dac083414eb5bb9 ("net-sysfs: update the queue counts in the unregistration path") +Cc: stable@vger.kernel.org +Signed-off-by: Marek Marczykowski-Górecki +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/xen-netfront.c | 39 +++++++++++++++++++++++---------------- + 1 file changed, 23 insertions(+), 16 deletions(-) + +--- a/drivers/net/xen-netfront.c ++++ b/drivers/net/xen-netfront.c +@@ -842,6 +842,28 @@ static int xennet_close(struct net_devic + return 0; + } + ++static void xennet_destroy_queues(struct netfront_info *info) ++{ ++ unsigned int i; ++ ++ for (i = 0; i < info->netdev->real_num_tx_queues; i++) { ++ struct netfront_queue *queue = &info->queues[i]; ++ ++ if (netif_running(info->netdev)) ++ napi_disable(&queue->napi); ++ netif_napi_del(&queue->napi); ++ } ++ ++ kfree(info->queues); ++ info->queues = NULL; ++} ++ ++static void xennet_uninit(struct net_device *dev) ++{ ++ struct netfront_info *np = netdev_priv(dev); ++ xennet_destroy_queues(np); ++} ++ + static void xennet_set_rx_rsp_cons(struct netfront_queue *queue, RING_IDX val) + { + unsigned long flags; +@@ -1611,6 +1633,7 @@ static int xennet_xdp(struct net_device + } + + static const struct net_device_ops xennet_netdev_ops = { ++ .ndo_uninit = xennet_uninit, + .ndo_open = xennet_open, + .ndo_stop = xennet_close, + .ndo_start_xmit = xennet_start_xmit, +@@ -2103,22 +2126,6 @@ error: + return err; + } + +-static void xennet_destroy_queues(struct netfront_info *info) +-{ +- unsigned int i; +- +- for (i = 0; i < info->netdev->real_num_tx_queues; i++) { +- struct netfront_queue *queue = &info->queues[i]; +- +- if (netif_running(info->netdev)) +- napi_disable(&queue->napi); +- netif_napi_del(&queue->napi); +- } +- +- kfree(info->queues); +- info->queues = NULL; +-} +- + + + static int xennet_create_page_pool(struct netfront_queue *queue)