From: Greg Kroah-Hartman Date: Sun, 5 May 2019 13:41:53 +0000 (+0200) Subject: 4.14-stable patches X-Git-Tag: v4.9.174~35 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=337e81c931dc6b44c86ebcc602aa1bb9ee2a3f33;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: alsa-hda-realtek-add-new-dell-platform-for-headset-mode.patch alsa-hda-realtek-fixed-dell-aio-speaker-noise.patch mm-do-not-stall-register_shrinker.patch usb-core-fix-bug-caused-by-duplicate-interface-pm-usage-counter.patch usb-core-fix-unterminated-string-returned-by-usb_string.patch usb-usbip-fix-isoc-packet-num-validation-in-get_pipe.patch usb-w1-ds2490-fix-bug-caused-by-improper-use-of-altsetting-array.patch usb-yurex-fix-protection-fault-after-device-removal.patch --- diff --git a/queue-4.14/alsa-hda-realtek-add-new-dell-platform-for-headset-mode.patch b/queue-4.14/alsa-hda-realtek-add-new-dell-platform-for-headset-mode.patch new file mode 100644 index 00000000000..36382ae53ef --- /dev/null +++ b/queue-4.14/alsa-hda-realtek-add-new-dell-platform-for-headset-mode.patch @@ -0,0 +1,48 @@ +From 0a29c57b76624723b6b00c027e0e992d130ace49 Mon Sep 17 00:00:00 2001 +From: Kailang Yang +Date: Wed, 24 Apr 2019 16:34:25 +0800 +Subject: ALSA: hda/realtek - Add new Dell platform for headset mode + +From: Kailang Yang + +commit 0a29c57b76624723b6b00c027e0e992d130ace49 upstream. + +Add two Dell platform for headset mode. + +[ Note: this is a further correction / addition of the previous + pin-based quirks for Dell machines; another entry for ALC236 with + the d-mic pin 0x12 and an entry for ALC295 -- tiwai ] + +Fixes: b26e36b7ef36 ("ALSA: hda/realtek - add two more pin configuration sets to quirk table") +Signed-off-by: Kailang Yang +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_realtek.c | 7 +++++++ + 1 file changed, 7 insertions(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -6745,6 +6745,10 @@ static const struct snd_hda_pin_quirk al + {0x21, 0x02211020}), + SND_HDA_PIN_QUIRK(0x10ec0236, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, + {0x21, 0x02211020}), ++ SND_HDA_PIN_QUIRK(0x10ec0236, 0x1028, "Dell", ALC255_FIXUP_DELL1_MIC_NO_PRESENCE, ++ {0x12, 0x40000000}, ++ {0x14, 0x90170110}, ++ {0x21, 0x02211020}), + SND_HDA_PIN_QUIRK(0x10ec0255, 0x1028, "Dell", ALC255_FIXUP_DELL2_MIC_NO_PRESENCE, + {0x14, 0x90170110}, + {0x21, 0x02211020}), +@@ -6986,6 +6990,9 @@ static const struct snd_hda_pin_quirk al + ALC292_STANDARD_PINS, + {0x13, 0x90a60140}), + SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE, ++ {0x14, 0x90170110}, ++ {0x21, 0x04211020}), ++ SND_HDA_PIN_QUIRK(0x10ec0295, 0x1028, "Dell", ALC269_FIXUP_DELL1_MIC_NO_PRESENCE, + ALC295_STANDARD_PINS, + {0x17, 0x21014020}, + {0x18, 0x21a19030}), diff --git a/queue-4.14/alsa-hda-realtek-fixed-dell-aio-speaker-noise.patch b/queue-4.14/alsa-hda-realtek-fixed-dell-aio-speaker-noise.patch new file mode 100644 index 00000000000..d9dce561dc9 --- /dev/null +++ b/queue-4.14/alsa-hda-realtek-fixed-dell-aio-speaker-noise.patch @@ -0,0 +1,36 @@ +From 0700d3d117a7f110ddddbd83873e13652f69c54b Mon Sep 17 00:00:00 2001 +From: Kailang Yang +Date: Fri, 26 Apr 2019 16:13:54 +0800 +Subject: ALSA: hda/realtek - Fixed Dell AIO speaker noise + +From: Kailang Yang + +commit 0700d3d117a7f110ddddbd83873e13652f69c54b upstream. + +Fixed Dell AIO speaker noise. +spec->gen.auto_mute_via_amp = 1, this option was solved speaker white +noise at boot. +codec->power_save_node = 0, this option was solved speaker noise at +resume back. + +Fixes: 9226665159f0 ("ALSA: hda/realtek - Fix Dell AIO LineOut issue") +Signed-off-by: Kailang Yang +Cc: +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman + +--- + sound/pci/hda/patch_realtek.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/sound/pci/hda/patch_realtek.c ++++ b/sound/pci/hda/patch_realtek.c +@@ -5294,6 +5294,8 @@ static void alc274_fixup_bind_dacs(struc + return; + + spec->gen.preferred_dacs = preferred_pairs; ++ spec->gen.auto_mute_via_amp = 1; ++ codec->power_save_node = 0; + } + + static void alc_fixup_disable_mic_vref(struct hda_codec *codec, diff --git a/queue-4.14/mm-do-not-stall-register_shrinker.patch b/queue-4.14/mm-do-not-stall-register_shrinker.patch new file mode 100644 index 00000000000..a4e7eb035af --- /dev/null +++ b/queue-4.14/mm-do-not-stall-register_shrinker.patch @@ -0,0 +1,63 @@ +From e496612c5130567fc9d5f1969ca4b86665aa3cbb Mon Sep 17 00:00:00 2001 +From: Minchan Kim +Date: Wed, 31 Jan 2018 16:16:55 -0800 +Subject: mm: do not stall register_shrinker() + +From: Minchan Kim + +commit e496612c5130567fc9d5f1969ca4b86665aa3cbb upstream. + +Shakeel Butt reported he has observed in production systems that the job +loader gets stuck for 10s of seconds while doing a mount operation. It +turns out that it was stuck in register_shrinker() because some +unrelated job was under memory pressure and was spending time in +shrink_slab(). Machines have a lot of shrinkers registered and jobs +under memory pressure have to traverse all of those memcg-aware +shrinkers and affect unrelated jobs which want to register their own +shrinkers. + +To solve the issue, this patch simply bails out slab shrinking if it is +found that someone wants to register a shrinker in parallel. A downside +is it could cause unfair shrinking between shrinkers. However, it +should be rare and we can add compilcated logic if we find it's not +enough. + +[akpm@linux-foundation.org: tweak code comment] +Link: http://lkml.kernel.org/r/20171115005602.GB23810@bbox +Link: http://lkml.kernel.org/r/1511481899-20335-1-git-send-email-minchan@kernel.org +Signed-off-by: Minchan Kim +Signed-off-by: Shakeel Butt +Reported-by: Shakeel Butt +Tested-by: Shakeel Butt +Acked-by: Johannes Weiner +Acked-by: Michal Hocko +Cc: Tetsuo Handa +Cc: Anshuman Khandual +Signed-off-by: Andrew Morton +Signed-off-by: Linus Torvalds +[rkolchmeyer: Backported to 4.14: adjusted context] +Signed-off-by: Robert Kolchmeyer +Signed-off-by: Greg Kroah-Hartman + +--- + mm/vmscan.c | 9 +++++++++ + 1 file changed, 9 insertions(+) + +--- a/mm/vmscan.c ++++ b/mm/vmscan.c +@@ -502,6 +502,15 @@ static unsigned long shrink_slab(gfp_t g + sc.nid = 0; + + freed += do_shrink_slab(&sc, shrinker, nr_scanned, nr_eligible); ++ /* ++ * Bail out if someone want to register a new shrinker to ++ * prevent the regsitration from being stalled for long periods ++ * by parallel ongoing shrinking. ++ */ ++ if (rwsem_is_contended(&shrinker_rwsem)) { ++ freed = freed ? : 1; ++ break; ++ } + } + + up_read(&shrinker_rwsem); diff --git a/queue-4.14/series b/queue-4.14/series index 76a74272d76..fa3a3890c4f 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -14,3 +14,11 @@ kasan-prevent-compiler-from-optimizing-away-memset-in-tests.patch arm64-fix-single-stepping-in-kernel-traps.patch arm64-only-advance-singlestep-for-user-instruction-traps.patch caif-reduce-stack-size-with-kasan.patch +alsa-hda-realtek-add-new-dell-platform-for-headset-mode.patch +alsa-hda-realtek-fixed-dell-aio-speaker-noise.patch +usb-yurex-fix-protection-fault-after-device-removal.patch +usb-w1-ds2490-fix-bug-caused-by-improper-use-of-altsetting-array.patch +usb-usbip-fix-isoc-packet-num-validation-in-get_pipe.patch +usb-core-fix-unterminated-string-returned-by-usb_string.patch +usb-core-fix-bug-caused-by-duplicate-interface-pm-usage-counter.patch +mm-do-not-stall-register_shrinker.patch diff --git a/queue-4.14/usb-core-fix-bug-caused-by-duplicate-interface-pm-usage-counter.patch b/queue-4.14/usb-core-fix-bug-caused-by-duplicate-interface-pm-usage-counter.patch new file mode 100644 index 00000000000..b37cfc9b677 --- /dev/null +++ b/queue-4.14/usb-core-fix-bug-caused-by-duplicate-interface-pm-usage-counter.patch @@ -0,0 +1,211 @@ +From c2b71462d294cf517a0bc6e4fd6424d7cee5596f Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Fri, 19 Apr 2019 13:52:38 -0400 +Subject: USB: core: Fix bug caused by duplicate interface PM usage counter + +From: Alan Stern + +commit c2b71462d294cf517a0bc6e4fd6424d7cee5596f upstream. + +The syzkaller fuzzer reported a bug in the USB hub driver which turned +out to be caused by a negative runtime-PM usage counter. This allowed +a hub to be runtime suspended at a time when the driver did not expect +it. The symptom is a WARNING issued because the hub's status URB is +submitted while it is already active: + + URB 0000000031fb463e submitted while active + WARNING: CPU: 0 PID: 2917 at drivers/usb/core/urb.c:363 + +The negative runtime-PM usage count was caused by an unfortunate +design decision made when runtime PM was first implemented for USB. +At that time, USB class drivers were allowed to unbind from their +interfaces without balancing the usage counter (i.e., leaving it with +a positive count). The core code would take care of setting the +counter back to 0 before allowing another driver to bind to the +interface. + +Later on when runtime PM was implemented for the entire kernel, the +opposite decision was made: Drivers were required to balance their +runtime-PM get and put calls. In order to maintain backward +compatibility, however, the USB subsystem adapted to the new +implementation by keeping an independent usage counter for each +interface and using it to automatically adjust the normal usage +counter back to 0 whenever a driver was unbound. + +This approach involves duplicating information, but what is worse, it +doesn't work properly in cases where a USB class driver delays +decrementing the usage counter until after the driver's disconnect() +routine has returned and the counter has been adjusted back to 0. +Doing so would cause the usage counter to become negative. There's +even a warning about this in the USB power management documentation! + +As it happens, this is exactly what the hub driver does. The +kick_hub_wq() routine increments the runtime-PM usage counter, and the +corresponding decrement is carried out by hub_event() in the context +of the hub_wq work-queue thread. This work routine may sometimes run +after the driver has been unbound from its interface, and when it does +it causes the usage counter to go negative. + +It is not possible for hub_disconnect() to wait for a pending +hub_event() call to finish, because hub_disconnect() is called with +the device lock held and hub_event() acquires that lock. The only +feasible fix is to reverse the original design decision: remove the +duplicate interface-specific usage counter and require USB drivers to +balance their runtime PM gets and puts. As far as I know, all +existing drivers currently do this. + +Signed-off-by: Alan Stern +Reported-and-tested-by: syzbot+7634edaea4d0b341c625@syzkaller.appspotmail.com +CC: +Signed-off-by: Greg Kroah-Hartman + +--- + Documentation/driver-api/usb/power-management.rst | 14 +++++++++----- + drivers/usb/core/driver.c | 13 ------------- + drivers/usb/storage/realtek_cr.c | 13 +++++-------- + include/linux/usb.h | 2 -- + 4 files changed, 14 insertions(+), 28 deletions(-) + +--- a/Documentation/driver-api/usb/power-management.rst ++++ b/Documentation/driver-api/usb/power-management.rst +@@ -370,11 +370,15 @@ autosuspend the interface's device. Whe + then the interface is considered to be idle, and the kernel may + autosuspend the device. + +-Drivers need not be concerned about balancing changes to the usage +-counter; the USB core will undo any remaining "get"s when a driver +-is unbound from its interface. As a corollary, drivers must not call +-any of the ``usb_autopm_*`` functions after their ``disconnect`` +-routine has returned. ++Drivers must be careful to balance their overall changes to the usage ++counter. Unbalanced "get"s will remain in effect when a driver is ++unbound from its interface, preventing the device from going into ++runtime suspend should the interface be bound to a driver again. On ++the other hand, drivers are allowed to achieve this balance by calling ++the ``usb_autopm_*`` functions even after their ``disconnect`` routine ++has returned -- say from within a work-queue routine -- provided they ++retain an active reference to the interface (via ``usb_get_intf`` and ++``usb_put_intf``). + + Drivers using the async routines are responsible for their own + synchronization and mutual exclusion. +--- a/drivers/usb/core/driver.c ++++ b/drivers/usb/core/driver.c +@@ -473,11 +473,6 @@ static int usb_unbind_interface(struct d + pm_runtime_disable(dev); + pm_runtime_set_suspended(dev); + +- /* Undo any residual pm_autopm_get_interface_* calls */ +- for (r = atomic_read(&intf->pm_usage_cnt); r > 0; --r) +- usb_autopm_put_interface_no_suspend(intf); +- atomic_set(&intf->pm_usage_cnt, 0); +- + if (!error) + usb_autosuspend_device(udev); + +@@ -1628,7 +1623,6 @@ void usb_autopm_put_interface(struct usb + int status; + + usb_mark_last_busy(udev); +- atomic_dec(&intf->pm_usage_cnt); + status = pm_runtime_put_sync(&intf->dev); + dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n", + __func__, atomic_read(&intf->dev.power.usage_count), +@@ -1657,7 +1651,6 @@ void usb_autopm_put_interface_async(stru + int status; + + usb_mark_last_busy(udev); +- atomic_dec(&intf->pm_usage_cnt); + status = pm_runtime_put(&intf->dev); + dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n", + __func__, atomic_read(&intf->dev.power.usage_count), +@@ -1679,7 +1672,6 @@ void usb_autopm_put_interface_no_suspend + struct usb_device *udev = interface_to_usbdev(intf); + + usb_mark_last_busy(udev); +- atomic_dec(&intf->pm_usage_cnt); + pm_runtime_put_noidle(&intf->dev); + } + EXPORT_SYMBOL_GPL(usb_autopm_put_interface_no_suspend); +@@ -1710,8 +1702,6 @@ int usb_autopm_get_interface(struct usb_ + status = pm_runtime_get_sync(&intf->dev); + if (status < 0) + pm_runtime_put_sync(&intf->dev); +- else +- atomic_inc(&intf->pm_usage_cnt); + dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n", + __func__, atomic_read(&intf->dev.power.usage_count), + status); +@@ -1745,8 +1735,6 @@ int usb_autopm_get_interface_async(struc + status = pm_runtime_get(&intf->dev); + if (status < 0 && status != -EINPROGRESS) + pm_runtime_put_noidle(&intf->dev); +- else +- atomic_inc(&intf->pm_usage_cnt); + dev_vdbg(&intf->dev, "%s: cnt %d -> %d\n", + __func__, atomic_read(&intf->dev.power.usage_count), + status); +@@ -1770,7 +1758,6 @@ void usb_autopm_get_interface_no_resume( + struct usb_device *udev = interface_to_usbdev(intf); + + usb_mark_last_busy(udev); +- atomic_inc(&intf->pm_usage_cnt); + pm_runtime_get_noresume(&intf->dev); + } + EXPORT_SYMBOL_GPL(usb_autopm_get_interface_no_resume); +--- a/drivers/usb/storage/realtek_cr.c ++++ b/drivers/usb/storage/realtek_cr.c +@@ -775,18 +775,16 @@ static void rts51x_suspend_timer_fn(unsi + break; + case RTS51X_STAT_IDLE: + case RTS51X_STAT_SS: +- usb_stor_dbg(us, "RTS51X_STAT_SS, intf->pm_usage_cnt:%d, power.usage:%d\n", +- atomic_read(&us->pusb_intf->pm_usage_cnt), ++ usb_stor_dbg(us, "RTS51X_STAT_SS, power.usage:%d\n", + atomic_read(&us->pusb_intf->dev.power.usage_count)); + +- if (atomic_read(&us->pusb_intf->pm_usage_cnt) > 0) { ++ if (atomic_read(&us->pusb_intf->dev.power.usage_count) > 0) { + usb_stor_dbg(us, "Ready to enter SS state\n"); + rts51x_set_stat(chip, RTS51X_STAT_SS); + /* ignore mass storage interface's children */ + pm_suspend_ignore_children(&us->pusb_intf->dev, true); + usb_autopm_put_interface_async(us->pusb_intf); +- usb_stor_dbg(us, "RTS51X_STAT_SS 01, intf->pm_usage_cnt:%d, power.usage:%d\n", +- atomic_read(&us->pusb_intf->pm_usage_cnt), ++ usb_stor_dbg(us, "RTS51X_STAT_SS 01, power.usage:%d\n", + atomic_read(&us->pusb_intf->dev.power.usage_count)); + } + break; +@@ -819,11 +817,10 @@ static void rts51x_invoke_transport(stru + int ret; + + if (working_scsi(srb)) { +- usb_stor_dbg(us, "working scsi, intf->pm_usage_cnt:%d, power.usage:%d\n", +- atomic_read(&us->pusb_intf->pm_usage_cnt), ++ usb_stor_dbg(us, "working scsi, power.usage:%d\n", + atomic_read(&us->pusb_intf->dev.power.usage_count)); + +- if (atomic_read(&us->pusb_intf->pm_usage_cnt) <= 0) { ++ if (atomic_read(&us->pusb_intf->dev.power.usage_count) <= 0) { + ret = usb_autopm_get_interface(us->pusb_intf); + usb_stor_dbg(us, "working scsi, ret=%d\n", ret); + } +--- a/include/linux/usb.h ++++ b/include/linux/usb.h +@@ -200,7 +200,6 @@ usb_find_last_int_out_endpoint(struct us + * @dev: driver model's view of this device + * @usb_dev: if an interface is bound to the USB major, this will point + * to the sysfs representation for that device. +- * @pm_usage_cnt: PM usage counter for this interface + * @reset_ws: Used for scheduling resets from atomic context. + * @resetting_device: USB core reset the device, so use alt setting 0 as + * current; needs bandwidth alloc after reset. +@@ -257,7 +256,6 @@ struct usb_interface { + + struct device dev; /* interface specific device info */ + struct device *usb_dev; +- atomic_t pm_usage_cnt; /* usage counter for autosuspend */ + struct work_struct reset_ws; /* for resets in atomic context */ + }; + #define to_usb_interface(d) container_of(d, struct usb_interface, dev) diff --git a/queue-4.14/usb-core-fix-unterminated-string-returned-by-usb_string.patch b/queue-4.14/usb-core-fix-unterminated-string-returned-by-usb_string.patch new file mode 100644 index 00000000000..eb3868547f8 --- /dev/null +++ b/queue-4.14/usb-core-fix-unterminated-string-returned-by-usb_string.patch @@ -0,0 +1,49 @@ +From c01c348ecdc66085e44912c97368809612231520 Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Mon, 15 Apr 2019 11:51:38 -0400 +Subject: USB: core: Fix unterminated string returned by usb_string() + +From: Alan Stern + +commit c01c348ecdc66085e44912c97368809612231520 upstream. + +Some drivers (such as the vub300 MMC driver) expect usb_string() to +return a properly NUL-terminated string, even when an error occurs. +(In fact, vub300's probe routine doesn't bother to check the return +code from usb_string().) When the driver goes on to use an +unterminated string, it leads to kernel errors such as +stack-out-of-bounds, as found by the syzkaller USB fuzzer. + +An out-of-range string index argument is not at all unlikely, given +that some devices don't provide string descriptors and therefore list +0 as the value for their string indexes. This patch makes +usb_string() return a properly terminated empty string along with the +-EINVAL error code when an out-of-range index is encountered. + +And since a USB string index is a single-byte value, indexes >= 256 +are just as invalid as values of 0 or below. + +Signed-off-by: Alan Stern +Reported-by: syzbot+b75b85111c10b8d680f1@syzkaller.appspotmail.com +CC: +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/core/message.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/drivers/usb/core/message.c ++++ b/drivers/usb/core/message.c +@@ -818,9 +818,11 @@ int usb_string(struct usb_device *dev, i + + if (dev->state == USB_STATE_SUSPENDED) + return -EHOSTUNREACH; +- if (size <= 0 || !buf || !index) ++ if (size <= 0 || !buf) + return -EINVAL; + buf[0] = 0; ++ if (index <= 0 || index >= 256) ++ return -EINVAL; + tbuf = kmalloc(256, GFP_NOIO); + if (!tbuf) + return -ENOMEM; diff --git a/queue-4.14/usb-usbip-fix-isoc-packet-num-validation-in-get_pipe.patch b/queue-4.14/usb-usbip-fix-isoc-packet-num-validation-in-get_pipe.patch new file mode 100644 index 00000000000..f982ee3b53a --- /dev/null +++ b/queue-4.14/usb-usbip-fix-isoc-packet-num-validation-in-get_pipe.patch @@ -0,0 +1,77 @@ +From c409ca3be3c6ff3a1eeb303b191184e80d412862 Mon Sep 17 00:00:00 2001 +From: Malte Leip +Date: Sun, 14 Apr 2019 12:00:12 +0200 +Subject: usb: usbip: fix isoc packet num validation in get_pipe + +From: Malte Leip + +commit c409ca3be3c6ff3a1eeb303b191184e80d412862 upstream. + +Change the validation of number_of_packets in get_pipe to compare the +number of packets to a fixed maximum number of packets allowed, set to +be 1024. This number was chosen due to it being used by other drivers as +well, for example drivers/usb/host/uhci-q.c + +Background/reason: +The get_pipe function in stub_rx.c validates the number of packets in +isochronous mode and aborts with an error if that number is too large, +in order to prevent malicious input from possibly triggering large +memory allocations. This was previously done by checking whether +pdu->u.cmd_submit.number_of_packets is bigger than the number of packets +that would be needed for pdu->u.cmd_submit.transfer_buffer_length bytes +if all except possibly the last packet had maximum length, given by +usb_endpoint_maxp(epd) * usb_endpoint_maxp_mult(epd). This leads to an +error if URBs with packets shorter than the maximum possible length are +submitted, which is allowed according to +Documentation/driver-api/usb/URB.rst and occurs for example with the +snd-usb-audio driver. + +Fixes: c6688ef9f297 ("usbip: fix stub_rx: harden CMD_SUBMIT path to handle malicious input") +Signed-off-by: Malte Leip +Cc: stable +Acked-by: Shuah Khan +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/usbip/stub_rx.c | 12 +++--------- + drivers/usb/usbip/usbip_common.h | 7 +++++++ + 2 files changed, 10 insertions(+), 9 deletions(-) + +--- a/drivers/usb/usbip/stub_rx.c ++++ b/drivers/usb/usbip/stub_rx.c +@@ -383,16 +383,10 @@ static int get_pipe(struct stub_device * + } + + if (usb_endpoint_xfer_isoc(epd)) { +- /* validate packet size and number of packets */ +- unsigned int maxp, packets, bytes; +- +- maxp = usb_endpoint_maxp(epd); +- maxp *= usb_endpoint_maxp_mult(epd); +- bytes = pdu->u.cmd_submit.transfer_buffer_length; +- packets = DIV_ROUND_UP(bytes, maxp); +- ++ /* validate number of packets */ + if (pdu->u.cmd_submit.number_of_packets < 0 || +- pdu->u.cmd_submit.number_of_packets > packets) { ++ pdu->u.cmd_submit.number_of_packets > ++ USBIP_MAX_ISO_PACKETS) { + dev_err(&sdev->udev->dev, + "CMD_SUBMIT: isoc invalid num packets %d\n", + pdu->u.cmd_submit.number_of_packets); +--- a/drivers/usb/usbip/usbip_common.h ++++ b/drivers/usb/usbip/usbip_common.h +@@ -135,6 +135,13 @@ extern struct device_attribute dev_attr_ + #define USBIP_DIR_OUT 0x00 + #define USBIP_DIR_IN 0x01 + ++/* ++ * Arbitrary limit for the maximum number of isochronous packets in an URB, ++ * compare for example the uhci_submit_isochronous function in ++ * drivers/usb/host/uhci-q.c ++ */ ++#define USBIP_MAX_ISO_PACKETS 1024 ++ + /** + * struct usbip_header_basic - data pertinent to every request + * @command: the usbip request type diff --git a/queue-4.14/usb-w1-ds2490-fix-bug-caused-by-improper-use-of-altsetting-array.patch b/queue-4.14/usb-w1-ds2490-fix-bug-caused-by-improper-use-of-altsetting-array.patch new file mode 100644 index 00000000000..1ca1b17371d --- /dev/null +++ b/queue-4.14/usb-w1-ds2490-fix-bug-caused-by-improper-use-of-altsetting-array.patch @@ -0,0 +1,50 @@ +From c114944d7d67f24e71562fcfc18d550ab787e4d4 Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Mon, 22 Apr 2019 11:16:04 -0400 +Subject: USB: w1 ds2490: Fix bug caused by improper use of altsetting array + +From: Alan Stern + +commit c114944d7d67f24e71562fcfc18d550ab787e4d4 upstream. + +The syzkaller USB fuzzer spotted a slab-out-of-bounds bug in the +ds2490 driver. This bug is caused by improper use of the altsetting +array in the usb_interface structure (the array's entries are not +always stored in numerical order), combined with a naive assumption +that all interfaces probed by the driver will have the expected number +of altsettings. + +The bug can be fixed by replacing references to the possibly +non-existent intf->altsetting[alt] entry with the guaranteed-to-exist +intf->cur_altsetting entry. + +Signed-off-by: Alan Stern +Reported-and-tested-by: syzbot+d65f673b847a1a96cdba@syzkaller.appspotmail.com +CC: +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/w1/masters/ds2490.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/w1/masters/ds2490.c ++++ b/drivers/w1/masters/ds2490.c +@@ -1018,15 +1018,15 @@ static int ds_probe(struct usb_interface + /* alternative 3, 1ms interrupt (greatly speeds search), 64 byte bulk */ + alt = 3; + err = usb_set_interface(dev->udev, +- intf->altsetting[alt].desc.bInterfaceNumber, alt); ++ intf->cur_altsetting->desc.bInterfaceNumber, alt); + if (err) { + dev_err(&dev->udev->dev, "Failed to set alternative setting %d " + "for %d interface: err=%d.\n", alt, +- intf->altsetting[alt].desc.bInterfaceNumber, err); ++ intf->cur_altsetting->desc.bInterfaceNumber, err); + goto err_out_clear; + } + +- iface_desc = &intf->altsetting[alt]; ++ iface_desc = intf->cur_altsetting; + if (iface_desc->desc.bNumEndpoints != NUM_EP-1) { + pr_info("Num endpoints=%d. It is not DS9490R.\n", + iface_desc->desc.bNumEndpoints); diff --git a/queue-4.14/usb-yurex-fix-protection-fault-after-device-removal.patch b/queue-4.14/usb-yurex-fix-protection-fault-after-device-removal.patch new file mode 100644 index 00000000000..d764782f142 --- /dev/null +++ b/queue-4.14/usb-yurex-fix-protection-fault-after-device-removal.patch @@ -0,0 +1,40 @@ +From ef61eb43ada6c1d6b94668f0f514e4c268093ff3 Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Tue, 23 Apr 2019 14:48:29 -0400 +Subject: USB: yurex: Fix protection fault after device removal + +From: Alan Stern + +commit ef61eb43ada6c1d6b94668f0f514e4c268093ff3 upstream. + +The syzkaller USB fuzzer found a general-protection-fault bug in the +yurex driver. The fault occurs when a device has been unplugged; the +driver's interrupt-URB handler logs an error message referring to the +device by name, after the device has been unregistered and its name +deallocated. + +This problem is caused by the fact that the interrupt URB isn't +cancelled until the driver's private data structure is released, which +can happen long after the device is gone. The cure is to make sure +that the interrupt URB is killed before yurex_disconnect() returns; +this is exactly the sort of thing that usb_poison_urb() was meant for. + +Signed-off-by: Alan Stern +Reported-and-tested-by: syzbot+2eb9121678bdb36e6d57@syzkaller.appspotmail.com +CC: +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/misc/yurex.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/usb/misc/yurex.c ++++ b/drivers/usb/misc/yurex.c +@@ -318,6 +318,7 @@ static void yurex_disconnect(struct usb_ + usb_deregister_dev(interface, &yurex_class); + + /* prevent more I/O from starting */ ++ usb_poison_urb(dev->urb); + mutex_lock(&dev->io_mutex); + dev->interface = NULL; + mutex_unlock(&dev->io_mutex);