From: Sasha Levin Date: Sun, 8 Nov 2020 23:14:03 +0000 (-0500) Subject: Fixes for 4.14 X-Git-Tag: v4.4.242~22 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=57778476840be657263f4ff7f2339af6cb401bfb;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.14 Signed-off-by: Sasha Levin --- diff --git a/queue-4.14/acpi-nfit-fix-comparison-to-enxio.patch b/queue-4.14/acpi-nfit-fix-comparison-to-enxio.patch new file mode 100644 index 00000000000..4df8adf126b --- /dev/null +++ b/queue-4.14/acpi-nfit-fix-comparison-to-enxio.patch @@ -0,0 +1,38 @@ +From 3bec9bf29ced572cfcdac4f9d285e75d3f17d8a7 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 27 Oct 2020 21:49:01 +0800 +Subject: ACPI: NFIT: Fix comparison to '-ENXIO' + +From: Zhang Qilong + +[ Upstream commit 85f971b65a692b68181438e099b946cc06ed499b ] + +Initial value of rc is '-ENXIO', and we should +use the initial value to check it. + +Signed-off-by: Zhang Qilong +Reviewed-by: Pankaj Gupta +Reviewed-by: Vishal Verma +[ rjw: Subject edit ] +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Sasha Levin +--- + drivers/acpi/nfit/core.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/acpi/nfit/core.c b/drivers/acpi/nfit/core.c +index 68205002f561e..20fd197ef74cc 100644 +--- a/drivers/acpi/nfit/core.c ++++ b/drivers/acpi/nfit/core.c +@@ -1273,7 +1273,7 @@ static ssize_t format1_show(struct device *dev, + le16_to_cpu(nfit_dcr->dcr->code)); + break; + } +- if (rc != ENXIO) ++ if (rc != -ENXIO) + break; + } + mutex_unlock(&acpi_desc->init_mutex); +-- +2.27.0 + diff --git a/queue-4.14/arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch b/queue-4.14/arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch new file mode 100644 index 00000000000..2a18284f59f --- /dev/null +++ b/queue-4.14/arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch @@ -0,0 +1,43 @@ +From bf04fc5873f36f5c76d6a79fdc484b130a1e7e98 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 3 Oct 2020 12:03:32 +0200 +Subject: ARM: dts: sun4i-a10: fix cpu_alert temperature +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Clément Péron + +[ Upstream commit dea252fa41cd8ce332d148444e4799235a8a03ec ] + +When running dtbs_check thermal_zone warn about the +temperature declared. + +thermal-zones: cpu-thermal:trips:cpu-alert0:temperature:0:0: 850000 is greater than the maximum of 200000 + +It's indeed wrong the real value is 85°C and not 850°C. + +Signed-off-by: Clément Péron +Signed-off-by: Maxime Ripard +Link: https://lore.kernel.org/r/20201003100332.431178-1-peron.clem@gmail.com +Signed-off-by: Sasha Levin +--- + arch/arm/boot/dts/sun4i-a10.dtsi | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi +index 41c2579143fd6..b3a3488fdfd68 100644 +--- a/arch/arm/boot/dts/sun4i-a10.dtsi ++++ b/arch/arm/boot/dts/sun4i-a10.dtsi +@@ -143,7 +143,7 @@ + trips { + cpu_alert0: cpu_alert0 { + /* milliCelsius */ +- temperature = <850000>; ++ temperature = <85000>; + hysteresis = <2000>; + type = "passive"; + }; +-- +2.27.0 + diff --git a/queue-4.14/blk-cgroup-fix-memleak-on-error-path.patch b/queue-4.14/blk-cgroup-fix-memleak-on-error-path.patch new file mode 100644 index 00000000000..ba8ce18cdc6 --- /dev/null +++ b/queue-4.14/blk-cgroup-fix-memleak-on-error-path.patch @@ -0,0 +1,35 @@ +From 774b2fbafc52e868be9b32997e7cf230f10e6ae8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 22 Oct 2020 16:58:41 -0400 +Subject: blk-cgroup: Fix memleak on error path + +From: Gabriel Krisman Bertazi + +[ Upstream commit 52abfcbd57eefdd54737fc8c2dc79d8f46d4a3e5 ] + +If new_blkg allocation raced with blk_policy change and +blkg_lookup_check fails, new_blkg is leaked. + +Acked-by: Tejun Heo +Signed-off-by: Gabriel Krisman Bertazi +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + block/blk-cgroup.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c +index 3dc7c0b4adcbb..a7217caea699d 100644 +--- a/block/blk-cgroup.c ++++ b/block/blk-cgroup.c +@@ -878,6 +878,7 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct blkcg_policy *pol, + blkg = blkg_lookup_check(pos, pol, q); + if (IS_ERR(blkg)) { + ret = PTR_ERR(blkg); ++ blkg_free(new_blkg); + goto fail_unlock; + } + +-- +2.27.0 + diff --git a/queue-4.14/blk-cgroup-pre-allocate-tree-node-on-blkg_conf_prep.patch b/queue-4.14/blk-cgroup-pre-allocate-tree-node-on-blkg_conf_prep.patch new file mode 100644 index 00000000000..4acd051077c --- /dev/null +++ b/queue-4.14/blk-cgroup-pre-allocate-tree-node-on-blkg_conf_prep.patch @@ -0,0 +1,82 @@ +From 15d5f9f04753e207cfc06c0c260c09d51df4dbad Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 22 Oct 2020 16:58:42 -0400 +Subject: blk-cgroup: Pre-allocate tree node on blkg_conf_prep + +From: Gabriel Krisman Bertazi + +[ Upstream commit f255c19b3ab46d3cad3b1b2e1036f4c926cb1d0c ] + +Similarly to commit 457e490f2b741 ("blkcg: allocate struct blkcg_gq +outside request queue spinlock"), blkg_create can also trigger +occasional -ENOMEM failures at the radix insertion because any +allocation inside blkg_create has to be non-blocking, making it more +likely to fail. This causes trouble for userspace tools trying to +configure io weights who need to deal with this condition. + +This patch reduces the occurrence of -ENOMEMs on this path by preloading +the radix tree element on a GFP_KERNEL context, such that we guarantee +the later non-blocking insertion won't fail. + +A similar solution exists in blkcg_init_queue for the same situation. + +Acked-by: Tejun Heo +Signed-off-by: Gabriel Krisman Bertazi +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + block/blk-cgroup.c | 14 ++++++++++++-- + 1 file changed, 12 insertions(+), 2 deletions(-) + +diff --git a/block/blk-cgroup.c b/block/blk-cgroup.c +index a7217caea699d..34f8e69078cc1 100644 +--- a/block/blk-cgroup.c ++++ b/block/blk-cgroup.c +@@ -872,6 +872,12 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct blkcg_policy *pol, + goto fail; + } + ++ if (radix_tree_preload(GFP_KERNEL)) { ++ blkg_free(new_blkg); ++ ret = -ENOMEM; ++ goto fail; ++ } ++ + rcu_read_lock(); + spin_lock_irq(q->queue_lock); + +@@ -879,7 +885,7 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct blkcg_policy *pol, + if (IS_ERR(blkg)) { + ret = PTR_ERR(blkg); + blkg_free(new_blkg); +- goto fail_unlock; ++ goto fail_preloaded; + } + + if (blkg) { +@@ -888,10 +894,12 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct blkcg_policy *pol, + blkg = blkg_create(pos, q, new_blkg); + if (unlikely(IS_ERR(blkg))) { + ret = PTR_ERR(blkg); +- goto fail_unlock; ++ goto fail_preloaded; + } + } + ++ radix_tree_preload_end(); ++ + if (pos == blkcg) + goto success; + } +@@ -901,6 +909,8 @@ int blkg_conf_prep(struct blkcg *blkcg, const struct blkcg_policy *pol, + ctx->body = body; + return 0; + ++fail_preloaded: ++ radix_tree_preload_end(); + fail_unlock: + spin_unlock_irq(q->queue_lock); + rcu_read_unlock(); +-- +2.27.0 + diff --git a/queue-4.14/drm-vc4-drv-add-error-handding-for-bind.patch b/queue-4.14/drm-vc4-drv-add-error-handding-for-bind.patch new file mode 100644 index 00000000000..d9d954ad946 --- /dev/null +++ b/queue-4.14/drm-vc4-drv-add-error-handding-for-bind.patch @@ -0,0 +1,35 @@ +From 55b443c3ecacca7bf1d22f4b728ffcf65d613d0a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 27 Oct 2020 13:14:42 +0900 +Subject: drm/vc4: drv: Add error handding for bind + +From: Hoegeun Kwon + +[ Upstream commit 9ce0af3e9573fb84c4c807183d13ea2a68271e4b ] + +There is a problem that if vc4_drm bind fails, a memory leak occurs on +the drm_property_create side. Add error handding for drm_mode_config. + +Signed-off-by: Hoegeun Kwon +Signed-off-by: Maxime Ripard +Link: https://patchwork.freedesktop.org/patch/msgid/20201027041442.30352-2-hoegeun.kwon@samsung.com +Signed-off-by: Sasha Levin +--- + drivers/gpu/drm/vc4/vc4_drv.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c +index 1c96edcb302be..028dc2819a368 100644 +--- a/drivers/gpu/drm/vc4/vc4_drv.c ++++ b/drivers/gpu/drm/vc4/vc4_drv.c +@@ -283,6 +283,7 @@ static int vc4_drm_bind(struct device *dev) + component_unbind_all(dev, drm); + gem_destroy: + vc4_gem_destroy(drm); ++ drm_mode_config_cleanup(drm); + vc4_bo_cache_destroy(drm); + dev_unref: + drm_dev_unref(drm); +-- +2.27.0 + diff --git a/queue-4.14/nvme-rdma-handle-unexpected-nvme-completion-data-len.patch b/queue-4.14/nvme-rdma-handle-unexpected-nvme-completion-data-len.patch new file mode 100644 index 00000000000..c7373d35908 --- /dev/null +++ b/queue-4.14/nvme-rdma-handle-unexpected-nvme-completion-data-len.patch @@ -0,0 +1,56 @@ +From 3d19bdec779c3c21fa1c6662a1bac2b85b0a8aa5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 25 Oct 2020 19:51:24 +0800 +Subject: nvme-rdma: handle unexpected nvme completion data length + +From: zhenwei pi + +[ Upstream commit 25c1ca6ecaba3b751d3f7ff92d5cddff3b05f8d0 ] + +Receiving a zero length message leads to the following warnings because +the CQE is processed twice: + +refcount_t: underflow; use-after-free. +WARNING: CPU: 0 PID: 0 at lib/refcount.c:28 + +RIP: 0010:refcount_warn_saturate+0xd9/0xe0 +Call Trace: + + nvme_rdma_recv_done+0xf3/0x280 [nvme_rdma] + __ib_process_cq+0x76/0x150 [ib_core] + ... + +Sanity check the received data length, to avoids this. + +Thanks to Chao Leng & Sagi for suggestions. + +Signed-off-by: zhenwei pi +Reviewed-by: Sagi Grimberg +Signed-off-by: Christoph Hellwig +Signed-off-by: Sasha Levin +--- + drivers/nvme/host/rdma.c | 8 ++++++++ + 1 file changed, 8 insertions(+) + +diff --git a/drivers/nvme/host/rdma.c b/drivers/nvme/host/rdma.c +index 564e457f1345e..d04c9769ebfa2 100644 +--- a/drivers/nvme/host/rdma.c ++++ b/drivers/nvme/host/rdma.c +@@ -1382,6 +1382,14 @@ static int __nvme_rdma_recv_done(struct ib_cq *cq, struct ib_wc *wc, int tag) + return 0; + } + ++ /* sanity checking for received data length */ ++ if (unlikely(wc->byte_len < len)) { ++ dev_err(queue->ctrl->ctrl.device, ++ "Unexpected nvme completion length(%d)\n", wc->byte_len); ++ nvme_rdma_error_recovery(queue->ctrl); ++ return; ++ } ++ + ib_dma_sync_single_for_cpu(ibdev, qe->dma, len, DMA_FROM_DEVICE); + /* + * AEN requests are special as they don't time out and can +-- +2.27.0 + diff --git a/queue-4.14/of-fix-reserved-memory-overlap-detection.patch b/queue-4.14/of-fix-reserved-memory-overlap-detection.patch new file mode 100644 index 00000000000..2b9d06d0fda --- /dev/null +++ b/queue-4.14/of-fix-reserved-memory-overlap-detection.patch @@ -0,0 +1,85 @@ +From 52411fa7afcace155145bd008d673ea69ee331cc Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 21 Oct 2020 11:53:59 +0200 +Subject: of: Fix reserved-memory overlap detection + +From: Vincent Whitchurch + +[ Upstream commit ca05f33316559a04867295dd49f85aeedbfd6bfd ] + +The reserved-memory overlap detection code fails to detect overlaps if +either of the regions starts at address 0x0. The code explicitly checks +for and ignores such regions, apparently in order to ignore dynamically +allocated regions which have an address of 0x0 at this point. These +dynamically allocated regions also have a size of 0x0 at this point, so +fix this by removing the check and sorting the dynamically allocated +regions ahead of any static regions at address 0x0. + +For example, there are two overlaps in this case but they are not +currently reported: + + foo@0 { + reg = <0x0 0x2000>; + }; + + bar@0 { + reg = <0x0 0x1000>; + }; + + baz@1000 { + reg = <0x1000 0x1000>; + }; + + quux { + size = <0x1000>; + }; + +but they are after this patch: + + OF: reserved mem: OVERLAP DETECTED! + bar@0 (0x00000000--0x00001000) overlaps with foo@0 (0x00000000--0x00002000) + OF: reserved mem: OVERLAP DETECTED! + foo@0 (0x00000000--0x00002000) overlaps with baz@1000 (0x00001000--0x00002000) + +Signed-off-by: Vincent Whitchurch +Link: https://lore.kernel.org/r/ded6fd6b47b58741aabdcc6967f73eca6a3f311e.1603273666.git-series.vincent.whitchurch@axis.com +Signed-off-by: Rob Herring +Signed-off-by: Sasha Levin +--- + drivers/of/of_reserved_mem.c | 13 +++++++++++-- + 1 file changed, 11 insertions(+), 2 deletions(-) + +diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c +index 32771c2ced7bb..55cbafdb93aef 100644 +--- a/drivers/of/of_reserved_mem.c ++++ b/drivers/of/of_reserved_mem.c +@@ -222,6 +222,16 @@ static int __init __rmem_cmp(const void *a, const void *b) + if (ra->base > rb->base) + return 1; + ++ /* ++ * Put the dynamic allocations (address == 0, size == 0) before static ++ * allocations at address 0x0 so that overlap detection works ++ * correctly. ++ */ ++ if (ra->size < rb->size) ++ return -1; ++ if (ra->size > rb->size) ++ return 1; ++ + return 0; + } + +@@ -239,8 +249,7 @@ static void __init __rmem_check_for_overlap(void) + + this = &reserved_mem[i]; + next = &reserved_mem[i + 1]; +- if (!(this->base && next->base)) +- continue; ++ + if (this->base + this->size > next->base) { + phys_addr_t this_end, next_end; + +-- +2.27.0 + diff --git a/queue-4.14/scsi-core-don-t-start-concurrent-async-scan-on-same-.patch b/queue-4.14/scsi-core-don-t-start-concurrent-async-scan-on-same-.patch new file mode 100644 index 00000000000..2117ddb90b6 --- /dev/null +++ b/queue-4.14/scsi-core-don-t-start-concurrent-async-scan-on-same-.patch @@ -0,0 +1,75 @@ +From b961fc34a96fc44f2cb41f1bb9c5f5640fdbd520 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sat, 10 Oct 2020 11:25:39 +0800 +Subject: scsi: core: Don't start concurrent async scan on same host + +From: Ming Lei + +[ Upstream commit 831e3405c2a344018a18fcc2665acc5a38c3a707 ] + +The current scanning mechanism is supposed to fall back to a synchronous +host scan if an asynchronous scan is in progress. However, this rule isn't +strictly respected, scsi_prep_async_scan() doesn't hold scan_mutex when +checking shost->async_scan. When scsi_scan_host() is called concurrently, +two async scans on same host can be started and a hang in do_scan_async() +is observed. + +Fixes this issue by checking & setting shost->async_scan atomically with +shost->scan_mutex. + +Link: https://lore.kernel.org/r/20201010032539.426615-1-ming.lei@redhat.com +Cc: Christoph Hellwig +Cc: Ewan D. Milne +Cc: Hannes Reinecke +Cc: Bart Van Assche +Reviewed-by: Lee Duncan +Reviewed-by: Bart Van Assche +Signed-off-by: Ming Lei +Signed-off-by: Martin K. Petersen +Signed-off-by: Sasha Levin +--- + drivers/scsi/scsi_scan.c | 7 ++++--- + 1 file changed, 4 insertions(+), 3 deletions(-) + +diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c +index 0b11405bfd7ea..40acc060b6558 100644 +--- a/drivers/scsi/scsi_scan.c ++++ b/drivers/scsi/scsi_scan.c +@@ -1720,15 +1720,16 @@ static void scsi_sysfs_add_devices(struct Scsi_Host *shost) + */ + static struct async_scan_data *scsi_prep_async_scan(struct Scsi_Host *shost) + { +- struct async_scan_data *data; ++ struct async_scan_data *data = NULL; + unsigned long flags; + + if (strncmp(scsi_scan_type, "sync", 4) == 0) + return NULL; + ++ mutex_lock(&shost->scan_mutex); + if (shost->async_scan) { + shost_printk(KERN_DEBUG, shost, "%s called twice\n", __func__); +- return NULL; ++ goto err; + } + + data = kmalloc(sizeof(*data), GFP_KERNEL); +@@ -1739,7 +1740,6 @@ static struct async_scan_data *scsi_prep_async_scan(struct Scsi_Host *shost) + goto err; + init_completion(&data->prev_finished); + +- mutex_lock(&shost->scan_mutex); + spin_lock_irqsave(shost->host_lock, flags); + shost->async_scan = 1; + spin_unlock_irqrestore(shost->host_lock, flags); +@@ -1754,6 +1754,7 @@ static struct async_scan_data *scsi_prep_async_scan(struct Scsi_Host *shost) + return data; + + err: ++ mutex_unlock(&shost->scan_mutex); + kfree(data); + return NULL; + } +-- +2.27.0 + diff --git a/queue-4.14/series b/queue-4.14/series index f52210c6d4e..bc7d837edef 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -23,3 +23,13 @@ ftrace-fix-recursion-check-for-nmi-test.patch ftrace-handle-tracing-when-switching-between-context.patch tracing-fix-out-of-bounds-write-in-get_trace_buf.patch futex-handle-transient-ownerless-rtmutex-state-correctly.patch +arm-dts-sun4i-a10-fix-cpu_alert-temperature.patch +x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch +of-fix-reserved-memory-overlap-detection.patch +blk-cgroup-fix-memleak-on-error-path.patch +blk-cgroup-pre-allocate-tree-node-on-blkg_conf_prep.patch +scsi-core-don-t-start-concurrent-async-scan-on-same-.patch +vsock-use-ns_capable_noaudit-on-socket-create.patch +nvme-rdma-handle-unexpected-nvme-completion-data-len.patch +drm-vc4-drv-add-error-handding-for-bind.patch +acpi-nfit-fix-comparison-to-enxio.patch diff --git a/queue-4.14/vsock-use-ns_capable_noaudit-on-socket-create.patch b/queue-4.14/vsock-use-ns_capable_noaudit-on-socket-create.patch new file mode 100644 index 00000000000..9230ec45ca7 --- /dev/null +++ b/queue-4.14/vsock-use-ns_capable_noaudit-on-socket-create.patch @@ -0,0 +1,46 @@ +From 6edf9145cdbc9bcff2174e3054dd4497fa2024ee Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 23 Oct 2020 16:37:57 +0200 +Subject: vsock: use ns_capable_noaudit() on socket create + +From: Jeff Vander Stoep + +[ Upstream commit af545bb5ee53f5261db631db2ac4cde54038bdaf ] + +During __vsock_create() CAP_NET_ADMIN is used to determine if the +vsock_sock->trusted should be set to true. This value is used later +for determing if a remote connection should be allowed to connect +to a restricted VM. Unfortunately, if the caller doesn't have +CAP_NET_ADMIN, an audit message such as an selinux denial is +generated even if the caller does not want a trusted socket. + +Logging errors on success is confusing. To avoid this, switch the +capable(CAP_NET_ADMIN) check to the noaudit version. + +Reported-by: Roman Kiryanov +https://android-review.googlesource.com/c/device/generic/goldfish/+/1468545/ +Signed-off-by: Jeff Vander Stoep +Reviewed-by: James Morris +Link: https://lore.kernel.org/r/20201023143757.377574-1-jeffv@google.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Sasha Levin +--- + net/vmw_vsock/af_vsock.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c +index f297a427b421b..29f7491acb354 100644 +--- a/net/vmw_vsock/af_vsock.c ++++ b/net/vmw_vsock/af_vsock.c +@@ -636,7 +636,7 @@ struct sock *__vsock_create(struct net *net, + vsk->owner = get_cred(psk->owner); + vsk->connect_timeout = psk->connect_timeout; + } else { +- vsk->trusted = capable(CAP_NET_ADMIN); ++ vsk->trusted = ns_capable_noaudit(&init_user_ns, CAP_NET_ADMIN); + vsk->owner = get_current_cred(); + vsk->connect_timeout = VSOCK_DEFAULT_CONNECT_TIMEOUT; + } +-- +2.27.0 + diff --git a/queue-4.14/x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch b/queue-4.14/x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch new file mode 100644 index 00000000000..6114ad3e61a --- /dev/null +++ b/queue-4.14/x86-kexec-use-up-to-dated-screen_info-copy-to-fill-b.patch @@ -0,0 +1,50 @@ +From a6f66e425e2587598ecac85ab45834c4a7db9648 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 14 Oct 2020 17:24:28 +0800 +Subject: x86/kexec: Use up-to-dated screen_info copy to fill boot params + +From: Kairui Song + +[ Upstream commit afc18069a2cb7ead5f86623a5f3d4ad6e21f940d ] + +kexec_file_load() currently reuses the old boot_params.screen_info, +but if drivers have change the hardware state, boot_param.screen_info +could contain invalid info. + +For example, the video type might be no longer VGA, or the frame buffer +address might be changed. If the kexec kernel keeps using the old screen_info, +kexec'ed kernel may attempt to write to an invalid framebuffer +memory region. + +There are two screen_info instances globally available, boot_params.screen_info +and screen_info. Later one is a copy, and is updated by drivers. + +So let kexec_file_load use the updated copy. + +[ mingo: Tidied up the changelog. ] + +Signed-off-by: Kairui Song +Signed-off-by: Ingo Molnar +Link: https://lore.kernel.org/r/20201014092429.1415040-2-kasong@redhat.com +Signed-off-by: Sasha Levin +--- + arch/x86/kernel/kexec-bzimage64.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c +index 4d948d87f01cc..a65636d60296c 100644 +--- a/arch/x86/kernel/kexec-bzimage64.c ++++ b/arch/x86/kernel/kexec-bzimage64.c +@@ -211,8 +211,7 @@ setup_boot_parameters(struct kimage *image, struct boot_params *params, + params->hdr.hardware_subarch = boot_params.hdr.hardware_subarch; + + /* Copying screen_info will do? */ +- memcpy(¶ms->screen_info, &boot_params.screen_info, +- sizeof(struct screen_info)); ++ memcpy(¶ms->screen_info, &screen_info, sizeof(struct screen_info)); + + /* Fill in memsize later */ + params->screen_info.ext_mem_k = 0; +-- +2.27.0 +