From 636ecacf55fd3f63b348ce1326c7f9409bd98263 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 6 Sep 2022 13:37:44 +0200 Subject: [PATCH] 5.19-stable patches added patches: arm64-kexec-fix-missing-extra-range-for-crashkres_low.patch dma-buf-dma-resv-check-if-the-new-fence-is-really-later.patch driver-core-don-t-probe-devices-after-bus_type.match-probe-deferral.patch usb-gadget-fix-obscure-lockdep-violation-for-udc_mutex.patch --- ...issing-extra-range-for-crashkres_low.patch | 37 ++++ ...eck-if-the-new-fence-is-really-later.patch | 44 ++++ ...-after-bus_type.match-probe-deferral.patch | 67 ++++++ queue-5.19/series | 4 + ...cure-lockdep-violation-for-udc_mutex.patch | 203 ++++++++++++++++++ 5 files changed, 355 insertions(+) create mode 100644 queue-5.19/arm64-kexec-fix-missing-extra-range-for-crashkres_low.patch create mode 100644 queue-5.19/dma-buf-dma-resv-check-if-the-new-fence-is-really-later.patch create mode 100644 queue-5.19/driver-core-don-t-probe-devices-after-bus_type.match-probe-deferral.patch create mode 100644 queue-5.19/usb-gadget-fix-obscure-lockdep-violation-for-udc_mutex.patch diff --git a/queue-5.19/arm64-kexec-fix-missing-extra-range-for-crashkres_low.patch b/queue-5.19/arm64-kexec-fix-missing-extra-range-for-crashkres_low.patch new file mode 100644 index 00000000000..15adf5b1fe0 --- /dev/null +++ b/queue-5.19/arm64-kexec-fix-missing-extra-range-for-crashkres_low.patch @@ -0,0 +1,37 @@ +From 4831be702b95047c89b3fa5728d07091e9e9f7c9 Mon Sep 17 00:00:00 2001 +From: Levi Yun +Date: Wed, 31 Aug 2022 19:39:13 +0900 +Subject: arm64/kexec: Fix missing extra range for crashkres_low. + +From: Levi Yun + +commit 4831be702b95047c89b3fa5728d07091e9e9f7c9 upstream. + +Like crashk_res, Calling crash_exclude_mem_range function with +crashk_low_res area would need extra crash_mem range too. + +Add one more extra cmem slot in case of crashk_low_res is used. + +Signed-off-by: Levi Yun +Fixes: 944a45abfabc ("arm64: kdump: Reimplement crashkernel=X") +Cc: # 5.19.x +Acked-by: Baoquan He +Reviewed-by: Catalin Marinas +Link: https://lore.kernel.org/r/20220831103913.12661-1-ppbuk5246@gmail.com +Signed-off-by: Will Deacon +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm64/kernel/machine_kexec_file.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/arm64/kernel/machine_kexec_file.c ++++ b/arch/arm64/kernel/machine_kexec_file.c +@@ -47,7 +47,7 @@ static int prepare_elf_headers(void **ad + u64 i; + phys_addr_t start, end; + +- nr_ranges = 1; /* for exclusion of crashkernel region */ ++ nr_ranges = 2; /* for exclusion of crashkernel region */ + for_each_mem_range(i, &start, &end) + nr_ranges++; + diff --git a/queue-5.19/dma-buf-dma-resv-check-if-the-new-fence-is-really-later.patch b/queue-5.19/dma-buf-dma-resv-check-if-the-new-fence-is-really-later.patch new file mode 100644 index 00000000000..1fea04dab87 --- /dev/null +++ b/queue-5.19/dma-buf-dma-resv-check-if-the-new-fence-is-really-later.patch @@ -0,0 +1,44 @@ +From a3f7c10a269d5b77dd5822ade822643ced3057f0 Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Christian=20K=C3=B6nig?= +Date: Wed, 10 Aug 2022 19:26:17 +0200 +Subject: dma-buf/dma-resv: check if the new fence is really later +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Christian König + +commit a3f7c10a269d5b77dd5822ade822643ced3057f0 upstream. + +Previously when we added a fence to a dma_resv object we always +assumed the the newer than all the existing fences. + +With Jason's work to add an UAPI to explicit export/import that's not +necessary the case any more. So without this check we would allow +userspace to force the kernel into an use after free error. + +Since the change is very small and defensive it's probably a good +idea to backport this to stable kernels as well just in case others +are using the dma_resv object in the same way. + +Signed-off-by: Christian König +Reviewed-by: Jason Ekstrand +Link: https://patchwork.freedesktop.org/patch/msgid/20220810172617.140047-1-christian.koenig@amd.com +Cc: stable@vger.kernel.org # v5.19+ +Signed-off-by: Greg Kroah-Hartman +--- + drivers/dma-buf/dma-resv.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/dma-buf/dma-resv.c ++++ b/drivers/dma-buf/dma-resv.c +@@ -295,7 +295,8 @@ void dma_resv_add_fence(struct dma_resv + enum dma_resv_usage old_usage; + + dma_resv_list_entry(fobj, i, obj, &old, &old_usage); +- if ((old->context == fence->context && old_usage >= usage) || ++ if ((old->context == fence->context && old_usage >= usage && ++ dma_fence_is_later(fence, old)) || + dma_fence_is_signaled(old)) { + dma_resv_list_set(fobj, i, fence, usage); + dma_fence_put(old); diff --git a/queue-5.19/driver-core-don-t-probe-devices-after-bus_type.match-probe-deferral.patch b/queue-5.19/driver-core-don-t-probe-devices-after-bus_type.match-probe-deferral.patch new file mode 100644 index 00000000000..06a1afcc1da --- /dev/null +++ b/queue-5.19/driver-core-don-t-probe-devices-after-bus_type.match-probe-deferral.patch @@ -0,0 +1,67 @@ +From 25e9fbf0fd38868a429feabc38abebfc6dbf6542 Mon Sep 17 00:00:00 2001 +From: "Isaac J. Manjarres" +Date: Wed, 17 Aug 2022 11:40:26 -0700 +Subject: driver core: Don't probe devices after bus_type.match() probe deferral + +From: Isaac J. Manjarres + +commit 25e9fbf0fd38868a429feabc38abebfc6dbf6542 upstream. + +Both __device_attach_driver() and __driver_attach() check the return +code of the bus_type.match() function to see if the device needs to be +added to the deferred probe list. After adding the device to the list, +the logic attempts to bind the device to the driver anyway, as if the +device had matched with the driver, which is not correct. + +If __device_attach_driver() detects that the device in question is not +ready to match with a driver on the bus, then it doesn't make sense for +the device to attempt to bind with the current driver or continue +attempting to match with any of the other drivers on the bus. So, update +the logic in __device_attach_driver() to reflect this. + +If __driver_attach() detects that a driver tried to match with a device +that is not ready to match yet, then the driver should not attempt to bind +with the device. However, the driver can still attempt to match and bind +with other devices on the bus, as drivers can be bound to multiple +devices. So, update the logic in __driver_attach() to reflect this. + +Fixes: 656b8035b0ee ("ARM: 8524/1: driver cohandle -EPROBE_DEFER from bus_type.match()") +Cc: stable@vger.kernel.org +Cc: Saravana Kannan +Reported-by: Guenter Roeck +Tested-by: Guenter Roeck +Tested-by: Linus Walleij +Reviewed-by: Saravana Kannan +Signed-off-by: Isaac J. Manjarres +Link: https://lore.kernel.org/r/20220817184026.3468620-1-isaacmanjarres@google.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/base/dd.c | 10 ++++++++++ + 1 file changed, 10 insertions(+) + +--- a/drivers/base/dd.c ++++ b/drivers/base/dd.c +@@ -897,6 +897,11 @@ static int __device_attach_driver(struct + dev_dbg(dev, "Device match requests probe deferral\n"); + dev->can_match = true; + driver_deferred_probe_add(dev); ++ /* ++ * Device can't match with a driver right now, so don't attempt ++ * to match or bind with other drivers on the bus. ++ */ ++ return ret; + } else if (ret < 0) { + dev_dbg(dev, "Bus failed to match device: %d\n", ret); + return ret; +@@ -1136,6 +1141,11 @@ static int __driver_attach(struct device + dev_dbg(dev, "Device match requests probe deferral\n"); + dev->can_match = true; + driver_deferred_probe_add(dev); ++ /* ++ * Driver could not match with device, but may match with ++ * another device on the bus. ++ */ ++ return 0; + } else if (ret < 0) { + dev_dbg(dev, "Bus failed to match device: %d\n", ret); + return ret; diff --git a/queue-5.19/series b/queue-5.19/series index d4a3bf276aa..84e00e91f6e 100644 --- a/queue-5.19/series +++ b/queue-5.19/series @@ -132,3 +132,7 @@ usb-xhci-mtk-relax-tt-periodic-bandwidth-allocation.patch usb-xhci-mtk-fix-bandwidth-release-issue.patch usb-gadget-f_uac2-fix-superspeed-transfer.patch usb-gadget-mass_storage-fix-cdrom-data-transfers-on-mac-os.patch +usb-gadget-fix-obscure-lockdep-violation-for-udc_mutex.patch +dma-buf-dma-resv-check-if-the-new-fence-is-really-later.patch +arm64-kexec-fix-missing-extra-range-for-crashkres_low.patch +driver-core-don-t-probe-devices-after-bus_type.match-probe-deferral.patch diff --git a/queue-5.19/usb-gadget-fix-obscure-lockdep-violation-for-udc_mutex.patch b/queue-5.19/usb-gadget-fix-obscure-lockdep-violation-for-udc_mutex.patch new file mode 100644 index 00000000000..e83a6e1a67b --- /dev/null +++ b/queue-5.19/usb-gadget-fix-obscure-lockdep-violation-for-udc_mutex.patch @@ -0,0 +1,203 @@ +From 1016fc0c096c92dd0e6e0541daac7a7868169903 Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Fri, 26 Aug 2022 15:31:17 -0400 +Subject: USB: gadget: Fix obscure lockdep violation for udc_mutex +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Alan Stern + +commit 1016fc0c096c92dd0e6e0541daac7a7868169903 upstream. + +A recent commit expanding the scope of the udc_lock mutex in the +gadget core managed to cause an obscure and slightly bizarre lockdep +violation. In abbreviated form: + +====================================================== +WARNING: possible circular locking dependency detected +5.19.0-rc7+ #12510 Not tainted +------------------------------------------------------ +udevadm/312 is trying to acquire lock: +ffff80000aae1058 (udc_lock){+.+.}-{3:3}, at: usb_udc_uevent+0x54/0xe0 + +but task is already holding lock: +ffff000002277548 (kn->active#4){++++}-{0:0}, at: kernfs_seq_start+0x34/0xe0 + +which lock already depends on the new lock. + +the existing dependency chain (in reverse order) is: + +-> #3 (kn->active#4){++++}-{0:0}: +        lock_acquire+0x68/0x84 +        __kernfs_remove+0x268/0x380 +        kernfs_remove_by_name_ns+0x58/0xac +        sysfs_remove_file_ns+0x18/0x24 +        device_del+0x15c/0x440 + +-> #2 (device_links_lock){+.+.}-{3:3}: +        lock_acquire+0x68/0x84 +        __mutex_lock+0x9c/0x430 +        mutex_lock_nested+0x38/0x64 +        device_link_remove+0x3c/0xa0 +        _regulator_put.part.0+0x168/0x190 +        regulator_put+0x3c/0x54 +        devm_regulator_release+0x14/0x20 + +-> #1 (regulator_list_mutex){+.+.}-{3:3}: +        lock_acquire+0x68/0x84 +        __mutex_lock+0x9c/0x430 +        mutex_lock_nested+0x38/0x64 +        regulator_lock_dependent+0x54/0x284 +        regulator_enable+0x34/0x80 +        phy_power_on+0x24/0x130 +        __dwc2_lowlevel_hw_enable+0x100/0x130 +        dwc2_lowlevel_hw_enable+0x18/0x40 +        dwc2_hsotg_udc_start+0x6c/0x2f0 +        gadget_bind_driver+0x124/0x1f4 + +-> #0 (udc_lock){+.+.}-{3:3}: +        __lock_acquire+0x1298/0x20cc +        lock_acquire.part.0+0xe0/0x230 +        lock_acquire+0x68/0x84 +        __mutex_lock+0x9c/0x430 +        mutex_lock_nested+0x38/0x64 +        usb_udc_uevent+0x54/0xe0 + +Evidently this was caused by the scope of udc_mutex being too large. +The mutex is only meant to protect udc->driver along with a few other +things. As far as I can tell, there's no reason for the mutex to be +held while the gadget core calls a gadget driver's ->bind or ->unbind +routine, or while a UDC is being started or stopped. (This accounts +for link #1 in the chain above, where the mutex is held while the +dwc2_hsotg_udc is started as part of driver probing.) + +Gadget drivers' ->disconnect callbacks are problematic. Even though +usb_gadget_disconnect() will now acquire the udc_mutex, there's a +window in usb_gadget_bind_driver() between the times when the mutex is +released and the ->bind callback is invoked. If a disconnect occurred +during that window, we could call the driver's ->disconnect routine +before its ->bind routine. To prevent this from happening, it will be +necessary to prevent a UDC from connecting while it has no gadget +driver. This should be done already but it doesn't seem to be; +currently usb_gadget_connect() has no check for this. Such a check +will have to be added later. + +Some degree of mutual exclusion is required in soft_connect_store(), +which can dereference udc->driver at arbitrary times since it is a +sysfs callback. The solution here is to acquire the gadget's device +lock rather than the udc_mutex. Since the driver core guarantees that +the device lock is always held during driver binding and unbinding, +this will make the accesses in soft_connect_store() mutually exclusive +with any changes to udc->driver. + +Lastly, it turns out there is one place which should hold the +udc_mutex but currently does not: The function_show() routine needs +protection while it dereferences udc->driver. The missing lock and +unlock calls are added. + +Link: https://lore.kernel.org/all/b2ba4245-9917-e399-94c8-03a383e7070e@samsung.com/ +Fixes: 2191c00855b0 ("USB: gadget: Fix use-after-free Read in usb_udc_uevent()") +Cc: Felipe Balbi +Cc: stable@vger.kernel.org +Reported-by: Marek Szyprowski +Tested-by: Marek Szyprowski +Signed-off-by: Alan Stern +Link: https://lore.kernel.org/r/YwkfhdxA/I2nOcK7@rowland.harvard.edu +Signed-off-by: Greg Kroah-Hartman +--- + drivers/usb/gadget/udc/core.c | 26 ++++++++++++++++---------- + 1 file changed, 16 insertions(+), 10 deletions(-) + +--- a/drivers/usb/gadget/udc/core.c ++++ b/drivers/usb/gadget/udc/core.c +@@ -736,7 +736,10 @@ int usb_gadget_disconnect(struct usb_gad + ret = gadget->ops->pullup(gadget, 0); + if (!ret) { + gadget->connected = 0; +- gadget->udc->driver->disconnect(gadget); ++ mutex_lock(&udc_lock); ++ if (gadget->udc->driver) ++ gadget->udc->driver->disconnect(gadget); ++ mutex_unlock(&udc_lock); + } + + out: +@@ -1489,7 +1492,6 @@ static int gadget_bind_driver(struct dev + + usb_gadget_udc_set_speed(udc, driver->max_speed); + +- mutex_lock(&udc_lock); + ret = driver->bind(udc->gadget, driver); + if (ret) + goto err_bind; +@@ -1499,7 +1501,6 @@ static int gadget_bind_driver(struct dev + goto err_start; + usb_gadget_enable_async_callbacks(udc); + usb_udc_connect_control(udc); +- mutex_unlock(&udc_lock); + + kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE); + return 0; +@@ -1512,6 +1513,7 @@ static int gadget_bind_driver(struct dev + dev_err(&udc->dev, "failed to start %s: %d\n", + driver->function, ret); + ++ mutex_lock(&udc_lock); + udc->driver = NULL; + driver->is_bound = false; + mutex_unlock(&udc_lock); +@@ -1529,7 +1531,6 @@ static void gadget_unbind_driver(struct + + kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE); + +- mutex_lock(&udc_lock); + usb_gadget_disconnect(gadget); + usb_gadget_disable_async_callbacks(udc); + if (gadget->irq) +@@ -1537,6 +1538,7 @@ static void gadget_unbind_driver(struct + udc->driver->unbind(gadget); + usb_gadget_udc_stop(udc); + ++ mutex_lock(&udc_lock); + driver->is_bound = false; + udc->driver = NULL; + mutex_unlock(&udc_lock); +@@ -1612,7 +1614,7 @@ static ssize_t soft_connect_store(struct + struct usb_udc *udc = container_of(dev, struct usb_udc, dev); + ssize_t ret; + +- mutex_lock(&udc_lock); ++ device_lock(&udc->gadget->dev); + if (!udc->driver) { + dev_err(dev, "soft-connect without a gadget driver\n"); + ret = -EOPNOTSUPP; +@@ -1633,7 +1635,7 @@ static ssize_t soft_connect_store(struct + + ret = n; + out: +- mutex_unlock(&udc_lock); ++ device_unlock(&udc->gadget->dev); + return ret; + } + static DEVICE_ATTR_WO(soft_connect); +@@ -1652,11 +1654,15 @@ static ssize_t function_show(struct devi + char *buf) + { + struct usb_udc *udc = container_of(dev, struct usb_udc, dev); +- struct usb_gadget_driver *drv = udc->driver; ++ struct usb_gadget_driver *drv; ++ int rc = 0; + +- if (!drv || !drv->function) +- return 0; +- return scnprintf(buf, PAGE_SIZE, "%s\n", drv->function); ++ mutex_lock(&udc_lock); ++ drv = udc->driver; ++ if (drv && drv->function) ++ rc = scnprintf(buf, PAGE_SIZE, "%s\n", drv->function); ++ mutex_unlock(&udc_lock); ++ return rc; + } + static DEVICE_ATTR_RO(function); + -- 2.47.3