[Android Q&A, Help & Troubleshooting] xKillerXSmileZx:
Basically, there has been an app ported to Android that allows even unrooted(stock) devices to deliver a bootrom exploit to the Nintendo Switch via USB-OTG and a USB cable (or C-to-C). USB 3.0 (xHCI) devices have no issues and deliver the exploit just fine. Apparently it is not even a USB 2.0 problem but rather how the EHCI performs, as certain USB 2.0 phones actually have the xHCI controller and can run the exploit just fine. What happens is that although it can detect the connected Switch in Tegra Recovery Mode, it just doesn't do anything and gives an error in the logs, "SUMBITURB failed".

On Linux desktop systems it is similar, but the exploit can still work with a kernel patch provided by a hacking group that discovered the exploit in the first place:

--- linux-4.14.27/drivers/usb/host/ehci-hcd.c.old	2018-04-17 18:00:00.000000000 +0000
+++ linux-4.14.27/drivers/usb/host/ehci-hcd.c	2018-04-17 18:00:00.000000000 +0000
@@ -873,14 +873,6 @@
INIT_LIST_HEAD (&qtd_list);

switch (usb_pipetype (urb->pipe)) {
-	case PIPE_CONTROL:
-	/* qh_completions() code doesn't handle all the fault cases
-	* in multi-TD control transfers. Even 1KB is rare anyway.
-	*/
-	if (urb->transfer_buffer_length > (16 * 1024))
-	return -EMSGSIZE;
-	/* FALLTHROUGH */
-	/* case PIPE_BULK: */
default:
if (!qh_urb_transaction (ehci, urb, &qtd_list, mem_flags))
return -ENOMEM;

The author of the Android port had also written a Python "hotpatch" script for desktop Linux systems:

#!/usr/bin/env python3
import os

"""
Cursed Code.
This code literally patches your kernel memory, proceed at your own risk.
Tested on Ubuntu 17.10 and Arch, x86_64. Should work on other distros, maybe even other architectures!
Run fusee-launcher.py with the "--override-checks" argument.
If you'd rather patch your drivers properly:
https://github.com/fail0verflow/shofel2/blob/master/linux-ehci-enable-large-ctl-xfers.patch
"""

ksyms = {
line[2]: int(line[0], 16)
for line in
map(lambda l: l.strip().split(),
open("/proc/kallsyms", "r").readlines())}

print(hex(ksyms["ehci_urb_enqueue"]))

patch_c = """
#include <linux/module.h>
#include <linux/kernel.h>
#include <asm/pgtable.h>
static u32 ORIG_MAX = 16*1024;
static u32 NEW_MAX = 0x1000000;
/* borrowed from MUSL because I'm lazy AF */
static char *fourbyte_memmem(const unsigned char *h, size_t k, const unsigned char *n)
{
uint32_t nw = n[0]<<24 | n[1]<<16 | n[2]<<8 | n[3];
uint32_t hw = h[0]<<24 | h[1]<<16 | h[2]<<8 | h[3];
for (h+=3, k-=3; k; k--, hw = hw<<8 | *++h)
if (hw == nw) return (char *)h-3;
return 0;
}
static pte_t* (*lookup_addr)(unsigned long, unsigned int*) = (void *) PLACE2;
static void set_addr_rw(unsigned long addr) {
unsigned int level;
pte_t *pte = lookup_addr(addr, &level);
set_pte_atomic(pte, pte_mkwrite(*pte));
}
int init_module(void) {
void * ehci_urb_enqueue_start = (void *) PLACEHOLDER;
u32 * patch_addr;
printk(KERN_INFO "Patch module loaded\\n");
patch_addr = (u32 *) fourbyte_memmem(ehci_urb_enqueue_start, 0x400, (void *)&ORIG_MAX);
if (patch_addr == NULL) {
printk(KERN_INFO "Failed to find patch site :(\\n");
return -1;
}
printk(KERN_INFO "patch_addr: 0x%px\\n", patch_addr);
set_addr_rw((unsigned long)patch_addr);
*patch_addr = NEW_MAX;
printk(KERN_INFO "Patching done!\\n");
return -1;
}
""".replace("PLACEHOLDER", hex(ksyms["ehci_urb_enqueue"])).replace("PLACE2", hex(ksyms["lookup_address"]))

makefile = """
obj-m += patch.o
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
"""

with open("patch.c", "w") as patchfile:
patchfile.write(patch_c)

with open("Makefile", "w") as mf:
mf.write(makefile)

os.system("make")

print("About to insert patch module, 'Operation not permitted' means it probably worked, check dmesg output.")

os.system("insmod patch.ko")

I tried to see if running it in Termux would do anything but I got the following error:

0x0
Traceback (most recent call last):
File "ehci_patch.py", line 70, in <module>
" " ".replace("PLACEHOLDER", hex(ksyms["ehci_urb_enqueue"])).replace("PLACE2" hex(ksyms["lookup_address"]))
KeyError: 'lookup_address'

I know that script isn't meant for use on Android anyway but maybe it can lead to a solution. The author of it does not know how to go about it at this time either, but believes an entire recompile of the kernel would be necessary. I am hoping that something like a systemless Magisk module would be the easiest solution for users but do not know if that is possible. I am only guessing it might be possible to create a Magisk module because of audio drivers like VIPER4Android. If indeed a custom kernel is needed, does anyone know how to go about it? It could be difficult to implement for everyone because not everyone has a device where the source to the kernel is available, etc. I am willing, however, to test anything on my tablet which is USB 2.0 and gives the error in the app. Any advice for how to go about this will be greatly appreciated.