kernel.git/drivers/usb/gadget/function/f_mass_storage.c, branch linux-5.6.y

usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt

2019-08-12T05:55:24Z

If fsg_disable() and fsg_set_alt() are called too closely to each other (for example due to a quick reset/reconnect), what can happen is that fsg_set_alt sets common->new_fsg from an interrupt while handle_exception is trying to process the config change caused by fsg_disable(): fsg_disable() ... handle_exception() sets state back to FSG_STATE_NORMAL hasn't yet called do_set_interface() or is inside it. ---> interrupt fsg_set_alt sets common->new_fsg queues a new FSG_STATE_CONFIG_CHANGE <--- Now, the first handle_exception can "see" the updated new_fsg, treats it as if it was a fsg_set_alt() response, call usb_composite_setup_continue() etc... But then, the thread sees the second FSG_STATE_CONFIG_CHANGE, and goes back down the same path, wipes and reattaches a now active fsg, and .. calls usb_composite_setup_continue() which at this point is wrong. Not only we get a backtrace, but I suspect the second set_interface wrecks some state causing the host to get upset in my case. This fixes it by replacing "new_fsg" by a "state argument" (same principle) which is set in the same lock section as the state update, and retrieved similarly. That way, there is never any discrepancy between the dequeued state and the observed value of it. We keep the ability to have the latest reconfig operation take precedence, but we guarantee that once "dequeued" the argument (new_fsg) will not be clobbered by any new event. Signed-off-by: Benjamin Herrenschmidt Acked-by: Alan Stern Signed-off-by: Felipe Balbi

Revert "usb: gadget: storage: Remove warning message"

2019-07-04T11:05:59Z

This reverts commit e70b3f5da00119e057b7faa557753fee7f786f17. EJ writes: Thinh found this patch might cause a failure in USB CV TD 9.13 Set Configuration Test. We are trying to fix it. Could you please defer the merging of this patch until we fix it? So am now dropping it. Reported-by: EJ Hsu Cc: Alan Stern Cc: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

Merge tag 'usb-for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-next

2019-07-01T10:01:33Z

Felipe writes: usb: changes for v5.3 merge window The biggest part here is a set of patches removing unnecesary variables from several drivers. Meson-g12a's dwc3 glue implemented IRQ-based OTG/DRD role swap. Qcom's dwc3 glue added support for ACPI, mainly for the AArch64-based SoCs. DWC3 also got support for Intel Elkhart Lake platforms. * tag 'usb-for-v5.3' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb: (30 commits) usb: dwc3: remove unused @lock member of dwc3_ep struct usb: dwc3: pci: Add Support for Intel Elkhart Lake Devices usb: Replace snprintf with scnprintf in gether_get_ifname usb: gadget: ether: Fix race between gether_disconnect and rx_submit usb: gadget: storage: Remove warning message usb: dwc3: gadget: Add support for disabling U1 and U2 entries usb: gadget: send usb_gadget as an argument in get_config_params doc: dt: bindings: usb: dwc3: Update entries for disabling U1 and U2 usb: dwc3: qcom: Use of_clk_get_parent_count() usb: dwc3: Fix core validation in probe, move after clocks are enabled usb: dwc3: qcom: Improve error handling usb: dwc3: qcom: Start USB in 'host mode' on the SDM845 usb: dwc3: qcom: Add support for booting with ACPI soc: qcom: geni: Add support for ACPI Revert "usb: dwc2: host: Setting qtd to NULL after freeing it" usb: gadget: net2272: remove redundant assignments to pointer 's' usb: gadget: Zero ffs_io_data USB: omap_udc: Remove unneeded variable fotg210-udc: Remove unneeded variable usb: gadget: at91_udc: Remove unneeded variable ...

docs: usb: rename files to .rst and add them to drivers-api

2019-06-20T12:28:36Z

While there are a mix of things here, most of the stuff were written from Kernel developer's PoV. So, add them to the driver-api book. A follow up for this patch would be to move documents from there that are specific to sysadmins, adding them to the admin-guide. Signed-off-by: Mauro Carvalho Chehab Acked-by: Johan Hovold Acked-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

usb: gadget: storage: Remove warning message

2019-06-18T08:58:30Z

This change is to fix below warning message in following scenario: usb_composite_setup_continue: Unexpected call When system tried to enter suspend, the fsg_disable() will be called to disable fsg driver and send a signal to fsg_main_thread. However, at this point, the fsg_main_thread has already been frozen and can not respond to this signal. So, this signal will be pended until fsg_main_thread wakes up. Once system resumes from suspend, fsg_main_thread will detect a signal pended and do some corresponding action (in handle_exception()). Then, host will send some setup requests (get descriptor, set configuration...) to UDC driver trying to enumerate this device. During the handling of "set configuration" request, it will try to sync up with fsg_main_thread by sending a signal (which is the same as the signal sent by fsg_disable) to it. In a similar manner, once the fsg_main_thread receives this signal, it will call handle_exception() to handle the request. However, if the fsg_main_thread wakes up from suspend a little late and "set configuration" request from Host arrives a little earlier, fsg_main_thread might come across the request from "set configuration" when it handles the signal from fsg_disable(). In this case, it will handle this request as well. So, when fsg_main_thread tries to handle the signal sent from "set configuration" later, there will nothing left to do and warning message "Unexpected call" is printed. Acked-by: Alan Stern Signed-off-by: EJ Hsu Signed-off-by: Felipe Balbi

Merge branch 'siginfo-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace

2018-10-24T10:22:39Z

Pull siginfo updates from Eric Biederman: "I have been slowly sorting out siginfo and this is the culmination of that work. The primary result is in several ways the signal infrastructure has been made less error prone. The code has been updated so that manually specifying SEND_SIG_FORCED is never necessary. The conversion to the new siginfo sending functions is now complete, which makes it difficult to send a signal without filling in the proper siginfo fields. At the tail end of the patchset comes the optimization of decreasing the size of struct siginfo in the kernel from 128 bytes to about 48 bytes on 64bit. The fundamental observation that enables this is by definition none of the known ways to use struct siginfo uses the extra bytes. This comes at the cost of a small user space observable difference. For the rare case of siginfo being injected into the kernel only what can be copied into kernel_siginfo is delivered to the destination, the rest of the bytes are set to 0. For cases where the signal and the si_code are known this is safe, because we know those bytes are not used. For cases where the signal and si_code combination is unknown the bits that won't fit into struct kernel_siginfo are tested to verify they are zero, and the send fails if they are not. I made an extensive search through userspace code and I could not find anything that would break because of the above change. If it turns out I did break something it will take just the revert of a single change to restore kernel_siginfo to the same size as userspace siginfo. Testing did reveal dependencies on preferring the signo passed to sigqueueinfo over si->signo, so bit the bullet and added the complexity necessary to handle that case. Testing also revealed bad things can happen if a negative signal number is passed into the system calls. Something no sane application will do but something a malicious program or a fuzzer might do. So I have fixed the code that performs the bounds checks to ensure negative signal numbers are handled" * 'siginfo-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace: (80 commits) signal: Guard against negative signal numbers in copy_siginfo_from_user32 signal: Guard against negative signal numbers in copy_siginfo_from_user signal: In sigqueueinfo prefer sig not si_signo signal: Use a smaller struct siginfo in the kernel signal: Distinguish between kernel_siginfo and siginfo signal: Introduce copy_siginfo_from_user and use it's return value signal: Remove the need for __ARCH_SI_PREABLE_SIZE and SI_PAD_SIZE signal: Fail sigqueueinfo if si_signo != sig signal/sparc: Move EMT_TAGOVF into the generic siginfo.h signal/unicore32: Use force_sig_fault where appropriate signal/unicore32: Generate siginfo in ucs32_notify_die signal/unicore32: Use send_sig_fault where appropriate signal/arc: Use force_sig_fault where appropriate signal/arc: Push siginfo generation into unhandled_exception signal/ia64: Use force_sig_fault where appropriate signal/ia64: Use the force_sig(SIGSEGV,...) in ia64_rt_sigreturn signal/ia64: Use the generic force_sigsegv in setup_frame signal/arm/kvm: Use send_sig_mceerr signal/arm: Use send_sig_fault where appropriate signal/arm: Use force_sig_fault where appropriate ...

usb: gadget: storage: Fix Spectre v1 vulnerability

2018-10-17T18:57:55Z

num can be indirectly controlled by user-space, hence leading to a potential exploitation of the Spectre variant 1 vulnerability. This issue was detected with the help of Smatch: drivers/usb/gadget/function/f_mass_storage.c:3177 fsg_lun_make() warn: potential spectre issue 'fsg_opts->common->luns' [r] (local cap) Fix this by sanitizing num before using it to index fsg_opts->common->luns Notice that given that speculation windows are large, the policy is to kill the speculation on the first load and not worry if it can be completed with a dependent load/store [1]. [1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2 Cc: stable@vger.kernel.org Signed-off-by: Gustavo A. R. Silva Acked-by: Felipe Balbi Signed-off-by: Greg Kroah-Hartman

signal: Don't send siginfo to kthreads.

2018-09-11T19:19:22Z

Today kernel threads never dequeue siginfo so it is pointless to enqueue siginfo for them. The usb gadget mass storage driver goes one farther and uses SEND_SIG_FORCED to guarantee that no siginfo is even enqueued. Generalize the optimization of the usb mass storage driver and never perform an unnecessary allocation when delivering signals to kthreads. Switch the mass storage driver from sending signals with SEND_SIG_FORCED to SEND_SIG_PRIV. As using SEND_SIG_FORCED is now unnecessary. Reviewed-by: Thomas Gleixner Signed-off-by: "Eric W. Biederman"

signal: Remove the siginfo paramater from kernel_dqueue_signal

2018-09-11T19:19:14Z

None of the callers use the it so remove it. Reviewed-by: Thomas Gleixner Signed-off-by: "Eric W. Biederman"

usb: gadget: storage: Remove reference counting

2018-07-26T10:55:39Z

The kref used to be needed because sharing of fsg_common among multiple USB function instances was handled by fsg. Now this is managed by configfs, we don't need it anymore. So let's eliminate kref from this driver. Acked-by: Alan Stern Acked-by: Michal Nazarewicz Signed-off-by: Jaejoong Kim Signed-off-by: Felipe Balbi