From: Sasha Levin Date: Mon, 29 Jun 2020 04:36:08 +0000 (-0400) Subject: Fixes for 4.4 X-Git-Tag: v5.7.7~39^2 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=26fb3e87ca017beb0a5042dc08ddd947a02ee9a6;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 4.4 Signed-off-by: Sasha Levin --- diff --git a/queue-4.4/arm-imx5-add-missing-put_device-call-in-imx_suspend_.patch b/queue-4.4/arm-imx5-add-missing-put_device-call-in-imx_suspend_.patch new file mode 100644 index 00000000000..35c2684f53a --- /dev/null +++ b/queue-4.4/arm-imx5-add-missing-put_device-call-in-imx_suspend_.patch @@ -0,0 +1,54 @@ +From 017ac71164f84c2809309a4679a246cd337fd79f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 4 Jun 2020 20:42:06 +0800 +Subject: ARM: imx5: add missing put_device() call in imx_suspend_alloc_ocram() + +From: yu kuai + +[ Upstream commit 586745f1598ccf71b0a5a6df2222dee0a865954e ] + +if of_find_device_by_node() succeed, imx_suspend_alloc_ocram() doesn't +have a corresponding put_device(). Thus add a jump target to fix the +exception handling for this function implementation. + +Fixes: 1579c7b9fe01 ("ARM: imx53: Set DDR pins to high impedance when in suspend to RAM.") +Signed-off-by: yu kuai +Signed-off-by: Shawn Guo +Signed-off-by: Sasha Levin +--- + arch/arm/mach-imx/pm-imx5.c | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +diff --git a/arch/arm/mach-imx/pm-imx5.c b/arch/arm/mach-imx/pm-imx5.c +index 532d4b08276dc..fd996187fc5fb 100644 +--- a/arch/arm/mach-imx/pm-imx5.c ++++ b/arch/arm/mach-imx/pm-imx5.c +@@ -301,14 +301,14 @@ static int __init imx_suspend_alloc_ocram( + if (!ocram_pool) { + pr_warn("%s: ocram pool unavailable!\n", __func__); + ret = -ENODEV; +- goto put_node; ++ goto put_device; + } + + ocram_base = gen_pool_alloc(ocram_pool, size); + if (!ocram_base) { + pr_warn("%s: unable to alloc ocram!\n", __func__); + ret = -ENOMEM; +- goto put_node; ++ goto put_device; + } + + phys = gen_pool_virt_to_phys(ocram_pool, ocram_base); +@@ -318,6 +318,8 @@ static int __init imx_suspend_alloc_ocram( + if (virt_out) + *virt_out = virt; + ++put_device: ++ put_device(&pdev->dev); + put_node: + of_node_put(node); + +-- +2.25.1 + diff --git a/queue-4.4/blktrace-break-out-of-blktrace-setup-on-concurrent-c.patch b/queue-4.4/blktrace-break-out-of-blktrace-setup-on-concurrent-c.patch new file mode 100644 index 00000000000..5e691bd4f4b --- /dev/null +++ b/queue-4.4/blktrace-break-out-of-blktrace-setup-on-concurrent-c.patch @@ -0,0 +1,93 @@ +From 9c010528a87f9bfbd058dc442abb29f5d0ff2b6c Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 5 Jun 2020 16:58:36 +0200 +Subject: blktrace: break out of blktrace setup on concurrent calls + +From: Luis Chamberlain + +[ Upstream commit 1b0b283648163dae2a214ca28ed5a99f62a77319 ] + +We use one blktrace per request_queue, that means one per the entire +disk. So we cannot run one blktrace on say /dev/vda and then /dev/vda1, +or just two calls on /dev/vda. + +We check for concurrent setup only at the very end of the blktrace setup though. + +If we try to run two concurrent blktraces on the same block device the +second one will fail, and the first one seems to go on. However when +one tries to kill the first one one will see things like this: + +The kernel will show these: + +``` +debugfs: File 'dropped' in directory 'nvme1n1' already present! +debugfs: File 'msg' in directory 'nvme1n1' already present! +debugfs: File 'trace0' in directory 'nvme1n1' already present! +`` + +And userspace just sees this error message for the second call: + +``` +blktrace /dev/nvme1n1 +BLKTRACESETUP(2) /dev/nvme1n1 failed: 5/Input/output error +``` + +The first userspace process #1 will also claim that the files +were taken underneath their nose as well. The files are taken +away form the first process given that when the second blktrace +fails, it will follow up with a BLKTRACESTOP and BLKTRACETEARDOWN. +This means that even if go-happy process #1 is waiting for blktrace +data, we *have* been asked to take teardown the blktrace. + +This can easily be reproduced with break-blktrace [0] run_0005.sh test. + +Just break out early if we know we're already going to fail, this will +prevent trying to create the files all over again, which we know still +exist. + +[0] https://github.com/mcgrof/break-blktrace + +Signed-off-by: Luis Chamberlain +Signed-off-by: Jan Kara +Reviewed-by: Bart Van Assche +Reviewed-by: Christoph Hellwig +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + kernel/trace/blktrace.c | 13 +++++++++++++ + 1 file changed, 13 insertions(+) + +diff --git a/kernel/trace/blktrace.c b/kernel/trace/blktrace.c +index 6737564680193..8ac3663e0012d 100644 +--- a/kernel/trace/blktrace.c ++++ b/kernel/trace/blktrace.c +@@ -15,6 +15,9 @@ + * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + * + */ ++ ++#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt ++ + #include + #include + #include +@@ -481,6 +484,16 @@ int do_blk_trace_setup(struct request_queue *q, char *name, dev_t dev, + */ + strreplace(buts->name, '/', '_'); + ++ /* ++ * bdev can be NULL, as with scsi-generic, this is a helpful as ++ * we can be. ++ */ ++ if (q->blk_trace) { ++ pr_warn("Concurrent blktraces are not allowed on %s\n", ++ buts->name); ++ return -EBUSY; ++ } ++ + bt = kzalloc(sizeof(*bt), GFP_KERNEL); + if (!bt) + return -ENOMEM; +-- +2.25.1 + diff --git a/queue-4.4/efi-esrt-fix-reference-count-leak-in-esre_create_sys.patch b/queue-4.4/efi-esrt-fix-reference-count-leak-in-esre_create_sys.patch new file mode 100644 index 00000000000..162f76b9b22 --- /dev/null +++ b/queue-4.4/efi-esrt-fix-reference-count-leak-in-esre_create_sys.patch @@ -0,0 +1,39 @@ +From 25dd63afcd74aaa39a1b38387a21da0bba4decd1 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 28 May 2020 13:38:04 -0500 +Subject: efi/esrt: Fix reference count leak in esre_create_sysfs_entry. + +From: Qiushi Wu + +[ Upstream commit 4ddf4739be6e375116c375f0a68bf3893ffcee21 ] + +kobject_init_and_add() takes reference even when it fails. +If this function returns an error, kobject_put() must be called to +properly clean up the memory associated with the object. Previous +commit "b8eb718348b8" fixed a similar problem. + +Fixes: 0bb549052d33 ("efi: Add esrt support") +Signed-off-by: Qiushi Wu +Link: https://lore.kernel.org/r/20200528183804.4497-1-wu000273@umn.edu +Signed-off-by: Ard Biesheuvel +Signed-off-by: Sasha Levin +--- + drivers/firmware/efi/esrt.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/drivers/firmware/efi/esrt.c b/drivers/firmware/efi/esrt.c +index 341b8c686ec7b..4aaaccf95b362 100644 +--- a/drivers/firmware/efi/esrt.c ++++ b/drivers/firmware/efi/esrt.c +@@ -182,7 +182,7 @@ static int esre_create_sysfs_entry(void *esre, int entry_num) + rc = kobject_init_and_add(&entry->kobj, &esre1_ktype, NULL, + "%s", name); + if (rc) { +- kfree(entry); ++ kobject_put(&entry->kobj); + return rc; + } + } +-- +2.25.1 + diff --git a/queue-4.4/kbuild-improve-cc-option-to-clean-up-all-temporary-f.patch b/queue-4.4/kbuild-improve-cc-option-to-clean-up-all-temporary-f.patch new file mode 100644 index 00000000000..45754afe3a9 --- /dev/null +++ b/queue-4.4/kbuild-improve-cc-option-to-clean-up-all-temporary-f.patch @@ -0,0 +1,72 @@ +From b2df42c58fbf304a507bb748e688c42723be3ba8 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 14 Jun 2020 23:43:40 +0900 +Subject: kbuild: improve cc-option to clean up all temporary files + +From: Masahiro Yamada + +[ Upstream commit f2f02ebd8f3833626642688b2d2c6a7b3c141fa9 ] + +When cc-option and friends evaluate compiler flags, the temporary file +$$TMP is created as an output object, and automatically cleaned up. +The actual file path of $$TMP is ..tmp, here is the process +ID of $(shell ...) invoked from cc-option. (Please note $$$$ is the +escape sequence of $$). + +Such garbage files are cleaned up in most cases, but some compiler flags +create additional output files. + +For example, -gsplit-dwarf creates a .dwo file. + +When CONFIG_DEBUG_INFO_SPLIT=y, you will see a bunch of ..dwo files +left in the top of build directories. You may not notice them unless you +do 'ls -a', but the garbage files will increase every time you run 'make'. + +This commit changes the temporary object path to .tmp_/tmp, and +removes .tmp_ directory when exiting. Separate build artifacts such +as *.dwo will be cleaned up all together because their file paths are +usually determined based on the base name of the object. + +Another example is -ftest-coverage, which outputs the coverage data into +.gcno + +Signed-off-by: Masahiro Yamada +Signed-off-by: Sasha Levin +--- + scripts/Kbuild.include | 11 ++++++----- + 1 file changed, 6 insertions(+), 5 deletions(-) + +diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include +index e61a5c29b08c5..b6f055157b89a 100644 +--- a/scripts/Kbuild.include ++++ b/scripts/Kbuild.include +@@ -81,20 +81,21 @@ cc-cross-prefix = \ + fi))) + + # output directory for tests below +-TMPOUT := $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/) ++TMPOUT = $(if $(KBUILD_EXTMOD),$(firstword $(KBUILD_EXTMOD))/).tmp_$$$$ + + # try-run + # Usage: option = $(call try-run, $(CC)...-o "$$TMP",option-ok,otherwise) + # Exit code chooses option. "$$TMP" is can be used as temporary file and + # is automatically cleaned up. + try-run = $(shell set -e; \ +- TMP="$(TMPOUT).$$$$.tmp"; \ +- TMPO="$(TMPOUT).$$$$.o"; \ ++ TMP=$(TMPOUT)/tmp; \ ++ TMPO=$(TMPOUT)/tmp.o; \ ++ mkdir -p $(TMPOUT); \ ++ trap "rm -rf $(TMPOUT)" EXIT; \ + if ($(1)) >/dev/null 2>&1; \ + then echo "$(2)"; \ + else echo "$(3)"; \ +- fi; \ +- rm -f "$$TMP" "$$TMPO") ++ fi) + + # as-option + # Usage: cflags-y += $(call as-option,-Wa$(comma)-isa=foo,) +-- +2.25.1 + diff --git a/queue-4.4/net-alx-fix-race-condition-in-alx_remove.patch b/queue-4.4/net-alx-fix-race-condition-in-alx_remove.patch new file mode 100644 index 00000000000..89a029a757f --- /dev/null +++ b/queue-4.4/net-alx-fix-race-condition-in-alx_remove.patch @@ -0,0 +1,59 @@ +From 0217498b5a712339f8ecee7ecefb2686198836be Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 15 Jun 2020 11:50:29 -0400 +Subject: net: alx: fix race condition in alx_remove + +From: Zekun Shen + +[ Upstream commit e89df5c4322c1bf495f62d74745895b5fd2a4393 ] + +There is a race condition exist during termination. The path is +alx_stop and then alx_remove. An alx_schedule_link_check could be called +before alx_stop by interrupt handler and invoke alx_link_check later. +Alx_stop frees the napis, and alx_remove cancels any pending works. +If any of the work is scheduled before termination and invoked before +alx_remove, a null-ptr-deref occurs because both expect alx->napis[i]. + +This patch fix the race condition by moving cancel_work_sync functions +before alx_free_napis inside alx_stop. Because interrupt handler can call +alx_schedule_link_check again, alx_free_irq is moved before +cancel_work_sync calls too. + +Signed-off-by: Zekun Shen +Signed-off-by: David S. Miller +Signed-off-by: Sasha Levin +--- + drivers/net/ethernet/atheros/alx/main.c | 9 +++++---- + 1 file changed, 5 insertions(+), 4 deletions(-) + +diff --git a/drivers/net/ethernet/atheros/alx/main.c b/drivers/net/ethernet/atheros/alx/main.c +index df54475d163bf..43bcc19c90680 100644 +--- a/drivers/net/ethernet/atheros/alx/main.c ++++ b/drivers/net/ethernet/atheros/alx/main.c +@@ -872,8 +872,12 @@ static int __alx_open(struct alx_priv *alx, bool resume) + + static void __alx_stop(struct alx_priv *alx) + { +- alx_halt(alx); + alx_free_irq(alx); ++ ++ cancel_work_sync(&alx->link_check_wk); ++ cancel_work_sync(&alx->reset_wk); ++ ++ alx_halt(alx); + alx_free_rings(alx); + } + +@@ -1406,9 +1410,6 @@ static void alx_remove(struct pci_dev *pdev) + struct alx_priv *alx = pci_get_drvdata(pdev); + struct alx_hw *hw = &alx->hw; + +- cancel_work_sync(&alx->link_check_wk); +- cancel_work_sync(&alx->reset_wk); +- + /* restore permanent mac address */ + alx_set_macaddr(hw, hw->perm_addr); + +-- +2.25.1 + diff --git a/queue-4.4/netfilter-ipset-fix-unaligned-atomic-access.patch b/queue-4.4/netfilter-ipset-fix-unaligned-atomic-access.patch new file mode 100644 index 00000000000..c7fce539d03 --- /dev/null +++ b/queue-4.4/netfilter-ipset-fix-unaligned-atomic-access.patch @@ -0,0 +1,57 @@ +From d9293ac110a094ed12a7f5fba341c143fa7d5063 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 10 Jun 2020 21:51:11 +0100 +Subject: netfilter: ipset: fix unaligned atomic access + +From: Russell King + +[ Upstream commit 715028460082d07a7ec6fcd87b14b46784346a72 ] + +When using ip_set with counters and comment, traffic causes the kernel +to panic on 32-bit ARM: + +Alignment trap: not handling instruction e1b82f9f at [] +Unhandled fault: alignment exception (0x221) at 0xea08133c +PC is at ip_set_match_extensions+0xe0/0x224 [ip_set] + +The problem occurs when we try to update the 64-bit counters - the +faulting address above is not 64-bit aligned. The problem occurs +due to the way elements are allocated, for example: + + set->dsize = ip_set_elem_len(set, tb, 0, 0); + map = ip_set_alloc(sizeof(*map) + elements * set->dsize); + +If the element has a requirement for a member to be 64-bit aligned, +and set->dsize is not a multiple of 8, but is a multiple of four, +then every odd numbered elements will be misaligned - and hitting +an atomic64_add() on that element will cause the kernel to panic. + +ip_set_elem_len() must return a size that is rounded to the maximum +alignment of any extension field stored in the element. This change +ensures that is the case. + +Fixes: 95ad1f4a9358 ("netfilter: ipset: Fix extension alignment") +Signed-off-by: Russell King +Acked-by: Jozsef Kadlecsik +Signed-off-by: Pablo Neira Ayuso +Signed-off-by: Sasha Levin +--- + net/netfilter/ipset/ip_set_core.c | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/net/netfilter/ipset/ip_set_core.c b/net/netfilter/ipset/ip_set_core.c +index 0583e2491770d..3231030a73edb 100644 +--- a/net/netfilter/ipset/ip_set_core.c ++++ b/net/netfilter/ipset/ip_set_core.c +@@ -379,6 +379,8 @@ ip_set_elem_len(struct ip_set *set, struct nlattr *tb[], size_t len, + for (id = 0; id < IPSET_EXT_ID_MAX; id++) { + if (!add_extension(id, cadt_flags, tb)) + continue; ++ if (align < ip_set_extensions[id].align) ++ align = ip_set_extensions[id].align; + len = ALIGN(len, ip_set_extensions[id].align); + set->offset[id] = len; + set->extensions |= ip_set_extensions[id].type; +-- +2.25.1 + diff --git a/queue-4.4/rdma-mad-fix-possible-memory-leak-in-ib_mad_post_rec.patch b/queue-4.4/rdma-mad-fix-possible-memory-leak-in-ib_mad_post_rec.patch new file mode 100644 index 00000000000..5cc63cebcd7 --- /dev/null +++ b/queue-4.4/rdma-mad-fix-possible-memory-leak-in-ib_mad_post_rec.patch @@ -0,0 +1,38 @@ +From a1e9ee16f343d843843234c2164bf2876d89d348 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 12 Jun 2020 14:38:24 +0800 +Subject: RDMA/mad: Fix possible memory leak in ib_mad_post_receive_mads() + +From: Fan Guo + +[ Upstream commit a17f4bed811c60712d8131883cdba11a105d0161 ] + +If ib_dma_mapping_error() returns non-zero value, +ib_mad_post_receive_mads() will jump out of loops and return -ENOMEM +without freeing mad_priv. Fix this memory-leak problem by freeing mad_priv +in this case. + +Fixes: 2c34e68f4261 ("IB/mad: Check and handle potential DMA mapping errors") +Link: https://lore.kernel.org/r/20200612063824.180611-1-guofan5@huawei.com +Signed-off-by: Fan Guo +Signed-off-by: Jason Gunthorpe +Signed-off-by: Sasha Levin +--- + drivers/infiniband/core/mad.c | 1 + + 1 file changed, 1 insertion(+) + +diff --git a/drivers/infiniband/core/mad.c b/drivers/infiniband/core/mad.c +index 616173b7a5e8a..c26fdcb7dddf8 100644 +--- a/drivers/infiniband/core/mad.c ++++ b/drivers/infiniband/core/mad.c +@@ -2912,6 +2912,7 @@ static int ib_mad_post_receive_mads(struct ib_mad_qp_info *qp_info, + DMA_FROM_DEVICE); + if (unlikely(ib_dma_mapping_error(qp_info->port_priv->device, + sg_list.addr))) { ++ kfree(mad_priv); + ret = -ENOMEM; + break; + } +-- +2.25.1 + diff --git a/queue-4.4/sched-core-fix-pi-boosting-between-rt-and-deadline-t.patch b/queue-4.4/sched-core-fix-pi-boosting-between-rt-and-deadline-t.patch new file mode 100644 index 00000000000..53c4a952e4a --- /dev/null +++ b/queue-4.4/sched-core-fix-pi-boosting-between-rt-and-deadline-t.patch @@ -0,0 +1,75 @@ +From 0ea25479275c787d64fe6dc819a7f10047407a89 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 19 Nov 2018 16:32:01 +0100 +Subject: sched/core: Fix PI boosting between RT and DEADLINE tasks + +From: Juri Lelli + +[ Upstream commit 740797ce3a124b7dd22b7fb832d87bc8fba1cf6f ] + +syzbot reported the following warning: + + WARNING: CPU: 1 PID: 6351 at kernel/sched/deadline.c:628 + enqueue_task_dl+0x22da/0x38a0 kernel/sched/deadline.c:1504 + +At deadline.c:628 we have: + + 623 static inline void setup_new_dl_entity(struct sched_dl_entity *dl_se) + 624 { + 625 struct dl_rq *dl_rq = dl_rq_of_se(dl_se); + 626 struct rq *rq = rq_of_dl_rq(dl_rq); + 627 + 628 WARN_ON(dl_se->dl_boosted); + 629 WARN_ON(dl_time_before(rq_clock(rq), dl_se->deadline)); + [...] + } + +Which means that setup_new_dl_entity() has been called on a task +currently boosted. This shouldn't happen though, as setup_new_dl_entity() +is only called when the 'dynamic' deadline of the new entity +is in the past w.r.t. rq_clock and boosted tasks shouldn't verify this +condition. + +Digging through the PI code I noticed that what above might in fact happen +if an RT tasks blocks on an rt_mutex hold by a DEADLINE task. In the +first branch of boosting conditions we check only if a pi_task 'dynamic' +deadline is earlier than mutex holder's and in this case we set mutex +holder to be dl_boosted. However, since RT 'dynamic' deadlines are only +initialized if such tasks get boosted at some point (or if they become +DEADLINE of course), in general RT 'dynamic' deadlines are usually equal +to 0 and this verifies the aforementioned condition. + +Fix it by checking that the potential donor task is actually (even if +temporary because in turn boosted) running at DEADLINE priority before +using its 'dynamic' deadline value. + +Fixes: 2d3d891d3344 ("sched/deadline: Add SCHED_DEADLINE inheritance logic") +Reported-by: syzbot+119ba87189432ead09b4@syzkaller.appspotmail.com +Signed-off-by: Juri Lelli +Signed-off-by: Peter Zijlstra (Intel) +Signed-off-by: Ingo Molnar +Reviewed-by: Daniel Bristot de Oliveira +Tested-by: Daniel Wagner +Link: https://lkml.kernel.org/r/20181119153201.GB2119@localhost.localdomain +Signed-off-by: Sasha Levin +--- + kernel/sched/core.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/kernel/sched/core.c b/kernel/sched/core.c +index d81bcc6362fff..14a87c1f3a3ac 100644 +--- a/kernel/sched/core.c ++++ b/kernel/sched/core.c +@@ -3439,7 +3439,8 @@ void rt_mutex_setprio(struct task_struct *p, int prio) + if (dl_prio(prio)) { + struct task_struct *pi_task = rt_mutex_get_top_task(p); + if (!dl_prio(p->normal_prio) || +- (pi_task && dl_entity_preempt(&pi_task->dl, &p->dl))) { ++ (pi_task && dl_prio(pi_task->prio) && ++ dl_entity_preempt(&pi_task->dl, &p->dl))) { + p->dl.dl_boosted = 1; + enqueue_flag |= ENQUEUE_REPLENISH; + } else +-- +2.25.1 + diff --git a/queue-4.4/series b/queue-4.4/series index 3812603bffa..aca0c5d3417 100644 --- a/queue-4.4/series +++ b/queue-4.4/series @@ -108,3 +108,12 @@ alsa-usb-audio-fix-oob-access-of-mixer-element-list.patch xhci-poll-for-u0-after-disabling-usb2-lpm.patch cifs-smb3-fix-data-inconsistent-when-punch-hole.patch cifs-smb3-fix-data-inconsistent-when-zero-file-range.patch +efi-esrt-fix-reference-count-leak-in-esre_create_sys.patch +rdma-mad-fix-possible-memory-leak-in-ib_mad_post_rec.patch +arm-imx5-add-missing-put_device-call-in-imx_suspend_.patch +usb-gadget-udc-potential-oops-in-error-handling-code.patch +netfilter-ipset-fix-unaligned-atomic-access.patch +sched-core-fix-pi-boosting-between-rt-and-deadline-t.patch +net-alx-fix-race-condition-in-alx_remove.patch +kbuild-improve-cc-option-to-clean-up-all-temporary-f.patch +blktrace-break-out-of-blktrace-setup-on-concurrent-c.patch diff --git a/queue-4.4/usb-gadget-udc-potential-oops-in-error-handling-code.patch b/queue-4.4/usb-gadget-udc-potential-oops-in-error-handling-code.patch new file mode 100644 index 00000000000..c00f280761a --- /dev/null +++ b/queue-4.4/usb-gadget-udc-potential-oops-in-error-handling-code.patch @@ -0,0 +1,38 @@ +From 86bd369317f14b1a35509c6921b64e950218ebbb Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 15 Jun 2020 14:27:19 +0300 +Subject: usb: gadget: udc: Potential Oops in error handling code + +From: Dan Carpenter + +[ Upstream commit e55f3c37cb8d31c7e301f46396b2ac6a19eb3a7c ] + +If this is in "transceiver" mode the the ->qwork isn't required and is +a NULL pointer. This can lead to a NULL dereference when we call +destroy_workqueue(udc->qwork). + +Fixes: 3517c31a8ece ("usb: gadget: mv_udc: use devm_xxx for probe") +Signed-off-by: Dan Carpenter +Signed-off-by: Felipe Balbi +Signed-off-by: Sasha Levin +--- + drivers/usb/gadget/udc/mv_udc_core.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +diff --git a/drivers/usb/gadget/udc/mv_udc_core.c b/drivers/usb/gadget/udc/mv_udc_core.c +index 81b6229c78054..4f480059f851c 100644 +--- a/drivers/usb/gadget/udc/mv_udc_core.c ++++ b/drivers/usb/gadget/udc/mv_udc_core.c +@@ -2322,7 +2322,8 @@ static int mv_udc_probe(struct platform_device *pdev) + return 0; + + err_create_workqueue: +- destroy_workqueue(udc->qwork); ++ if (udc->qwork) ++ destroy_workqueue(udc->qwork); + err_destroy_dma: + dma_pool_destroy(udc->dtd_pool); + err_free_dma: +-- +2.25.1 +