From: Greg Kroah-Hartman Date: Thu, 8 Nov 2018 17:33:37 +0000 (-0800) Subject: 4.14-stable patches X-Git-Tag: v3.18.125~12 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=5f132fce8560723598750fdc1822dbd1d7ee8dd3;p=thirdparty%2Fkernel%2Fstable-queue.git 4.14-stable patches added patches: cachefiles-fix-the-race-between-cachefiles_bury_object-and-rmdir-2.patch cdc-acm-correct-counting-of-uart-states-in-serial-state-notification.patch cdc-acm-do-not-reset-notification-buffer-index-upon-urb-unlinking.patch cdc-acm-fix-race-between-reset-and-control-messaging.patch drm-edid-add-6-bpc-quirk-for-boe-panel-in-hp-pavilion-15-n233sl.patch drm-edid-vsdb-ycbcr420-deep-color-mode-bit-definitions.patch drm-fb-helper-reject-all-pixel-format-changing-requests.patch ib-ucm-fix-spectre-v1-vulnerability.patch input-elan_i2c-add-acpi-id-for-lenovo-ideapad-330-15igm.patch ptp-fix-spectre-v1-vulnerability.patch rdma-ucma-fix-spectre-v1-vulnerability.patch sched-fair-fix-throttle_list-starvation-with-low-cfs-quota.patch usb-fix-the-usbfs-flag-sanitization-for-control-transfers.patch usb-gadget-storage-fix-spectre-v1-vulnerability.patch usb-usbip-fix-bug-kasan-slab-out-of-bounds-in-vhci_hub_control.patch x86-fpu-fix-i486-no387-boot-crash-by-only-saving-fpu-registers-on-context-switch-if-there-is-an-fpu.patch x86-hibernate-fix-nosave_regions-setup-for-hibernation.patch x86-percpu-fix-this_cpu_read.patch x86-time-correct-the-attribute-on-jiffies-definition.patch x86-tsc-force-inlining-of-cyc2ns-bits.patch --- diff --git a/queue-4.14/cachefiles-fix-the-race-between-cachefiles_bury_object-and-rmdir-2.patch b/queue-4.14/cachefiles-fix-the-race-between-cachefiles_bury_object-and-rmdir-2.patch new file mode 100644 index 00000000000..9aeb3fca1f0 --- /dev/null +++ b/queue-4.14/cachefiles-fix-the-race-between-cachefiles_bury_object-and-rmdir-2.patch @@ -0,0 +1,42 @@ +From 169b803397499be85bdd1e3d07d6f5e3d4bd669e Mon Sep 17 00:00:00 2001 +From: Al Viro +Date: Wed, 17 Oct 2018 15:23:26 +0100 +Subject: cachefiles: fix the race between cachefiles_bury_object() and rmdir(2) + +From: Al Viro + +commit 169b803397499be85bdd1e3d07d6f5e3d4bd669e upstream. + +the victim might've been rmdir'ed just before the lock_rename(); +unlike the normal callers, we do not look the source up after the +parents are locked - we know it beforehand and just recheck that it's +still the child of what used to be its parent. Unfortunately, +the check is too weak - we don't spot a dead directory since its +->d_parent is unchanged, dentry is positive, etc. So we sail all +the way to ->rename(), with hosting filesystems _not_ expecting +to be asked renaming an rmdir'ed subdirectory. + +The fix is easy, fortunately - the lock on parent is sufficient for +making IS_DEADDIR() on child safe. + +Cc: stable@vger.kernel.org +Fixes: 9ae326a69004 (CacheFiles: A cache that backs onto a mounted filesystem) +Signed-off-by: Al Viro +Signed-off-by: David Howells +Signed-off-by: Greg Kroah-Hartman + +--- + fs/cachefiles/namei.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/fs/cachefiles/namei.c ++++ b/fs/cachefiles/namei.c +@@ -340,7 +340,7 @@ try_again: + trap = lock_rename(cache->graveyard, dir); + + /* do some checks before getting the grave dentry */ +- if (rep->d_parent != dir) { ++ if (rep->d_parent != dir || IS_DEADDIR(d_inode(rep))) { + /* the entry was probably culled when we dropped the parent dir + * lock */ + unlock_rename(cache->graveyard, dir); diff --git a/queue-4.14/cdc-acm-correct-counting-of-uart-states-in-serial-state-notification.patch b/queue-4.14/cdc-acm-correct-counting-of-uart-states-in-serial-state-notification.patch new file mode 100644 index 00000000000..ab469be648a --- /dev/null +++ b/queue-4.14/cdc-acm-correct-counting-of-uart-states-in-serial-state-notification.patch @@ -0,0 +1,55 @@ +From f976d0e5747ca65ccd0fb2a4118b193d70aa1836 Mon Sep 17 00:00:00 2001 +From: Tobias Herzog +Date: Sat, 22 Sep 2018 22:11:11 +0200 +Subject: cdc-acm: correct counting of UART states in serial state notification + +From: Tobias Herzog + +commit f976d0e5747ca65ccd0fb2a4118b193d70aa1836 upstream. + +The usb standard ("Universal Serial Bus Class Definitions for Communication +Devices") distiguishes between "consistent signals" (DSR, DCD), and +"irregular signals" (break, ring, parity error, framing error, overrun). +The bits of "irregular signals" are set, if this error/event occurred on +the device side and are immeadeatly unset, if the serial state notification +was sent. +Like other drivers of real serial ports do, just the occurence of those +events should be counted in serial_icounter_struct (but no 1->0 +transitions). + +Signed-off-by: Tobias Herzog +Acked-by: Oliver Neukum +Cc: stable +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/class/cdc-acm.c | 14 +++++++------- + 1 file changed, 7 insertions(+), 7 deletions(-) + +--- a/drivers/usb/class/cdc-acm.c ++++ b/drivers/usb/class/cdc-acm.c +@@ -322,17 +322,17 @@ static void acm_process_notification(str + + if (difference & ACM_CTRL_DSR) + acm->iocount.dsr++; +- if (difference & ACM_CTRL_BRK) +- acm->iocount.brk++; +- if (difference & ACM_CTRL_RI) +- acm->iocount.rng++; + if (difference & ACM_CTRL_DCD) + acm->iocount.dcd++; +- if (difference & ACM_CTRL_FRAMING) ++ if (newctrl & ACM_CTRL_BRK) ++ acm->iocount.brk++; ++ if (newctrl & ACM_CTRL_RI) ++ acm->iocount.rng++; ++ if (newctrl & ACM_CTRL_FRAMING) + acm->iocount.frame++; +- if (difference & ACM_CTRL_PARITY) ++ if (newctrl & ACM_CTRL_PARITY) + acm->iocount.parity++; +- if (difference & ACM_CTRL_OVERRUN) ++ if (newctrl & ACM_CTRL_OVERRUN) + acm->iocount.overrun++; + spin_unlock(&acm->read_lock); + diff --git a/queue-4.14/cdc-acm-do-not-reset-notification-buffer-index-upon-urb-unlinking.patch b/queue-4.14/cdc-acm-do-not-reset-notification-buffer-index-upon-urb-unlinking.patch new file mode 100644 index 00000000000..5b75b057fa8 --- /dev/null +++ b/queue-4.14/cdc-acm-do-not-reset-notification-buffer-index-upon-urb-unlinking.patch @@ -0,0 +1,35 @@ +From dae3ddba36f8c337fb59cef07d564da6fc9b7551 Mon Sep 17 00:00:00 2001 +From: Tobias Herzog +Date: Sat, 22 Sep 2018 22:11:10 +0200 +Subject: cdc-acm: do not reset notification buffer index upon urb unlinking + +From: Tobias Herzog + +commit dae3ddba36f8c337fb59cef07d564da6fc9b7551 upstream. + +Resetting the write index of the notification buffer on urb unlink (e.g. +closing a cdc-acm device from userspace) may lead to wrong interpretation +of further received notifications, in case the index is not 0 when urb +unlink happens (i.e. when parts of a notification already have been +transferred). On the device side there is no "reset" of the notification +transimission and thus we would get out of sync with the device. + +Signed-off-by: Tobias Herzog +Acked-by: Oliver Neukum +Cc: stable +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/class/cdc-acm.c | 1 - + 1 file changed, 1 deletion(-) + +--- a/drivers/usb/class/cdc-acm.c ++++ b/drivers/usb/class/cdc-acm.c +@@ -367,7 +367,6 @@ static void acm_ctrl_irq(struct urb *urb + case -ENOENT: + case -ESHUTDOWN: + /* this urb is terminated, clean up */ +- acm->nb_index = 0; + dev_dbg(&acm->control->dev, + "%s - urb shutting down with status: %d\n", + __func__, status); diff --git a/queue-4.14/cdc-acm-fix-race-between-reset-and-control-messaging.patch b/queue-4.14/cdc-acm-fix-race-between-reset-and-control-messaging.patch new file mode 100644 index 00000000000..9f86a4b0331 --- /dev/null +++ b/queue-4.14/cdc-acm-fix-race-between-reset-and-control-messaging.patch @@ -0,0 +1,32 @@ +From 9397940ed812b942c520e0c25ed4b2c64d57e8b9 Mon Sep 17 00:00:00 2001 +From: Oliver Neukum +Date: Thu, 4 Oct 2018 15:49:06 +0200 +Subject: cdc-acm: fix race between reset and control messaging + +From: Oliver Neukum + +commit 9397940ed812b942c520e0c25ed4b2c64d57e8b9 upstream. + +If a device splits up a control message and a reset() happens +between the parts, the message is lost and already recieved parts +must be dropped. + +Signed-off-by: Oliver Neukum +Fixes: 1aba579f3cf51 ("cdc-acm: handle read pipe errors") +Cc: stable +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/class/cdc-acm.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/usb/class/cdc-acm.c ++++ b/drivers/usb/class/cdc-acm.c +@@ -1654,6 +1654,7 @@ static int acm_pre_reset(struct usb_inte + struct acm *acm = usb_get_intfdata(intf); + + clear_bit(EVENT_RX_STALL, &acm->flags); ++ acm->nb_index = 0; /* pending control transfers are lost */ + + return 0; + } diff --git a/queue-4.14/drm-edid-add-6-bpc-quirk-for-boe-panel-in-hp-pavilion-15-n233sl.patch b/queue-4.14/drm-edid-add-6-bpc-quirk-for-boe-panel-in-hp-pavilion-15-n233sl.patch new file mode 100644 index 00000000000..4f2f379820a --- /dev/null +++ b/queue-4.14/drm-edid-add-6-bpc-quirk-for-boe-panel-in-hp-pavilion-15-n233sl.patch @@ -0,0 +1,37 @@ +From 0711a43b6d84ff9189adfbf83c8bbf56eef794bf Mon Sep 17 00:00:00 2001 +From: Kai-Heng Feng +Date: Tue, 2 Oct 2018 23:29:11 +0800 +Subject: drm/edid: Add 6 bpc quirk for BOE panel in HP Pavilion 15-n233sl + +From: Kai-Heng Feng + +commit 0711a43b6d84ff9189adfbf83c8bbf56eef794bf upstream. + +There's another panel that reports "DFP 1.x compliant TMDS" but it +supports 6bpc instead of 8 bpc. + +Apply 6 bpc quirk for the panel to fix it. + +BugLink: https://bugs.launchpad.net/bugs/1794387 +Cc: # v4.8+ +Signed-off-by: Kai-Heng Feng +Signed-off-by: Daniel Vetter +Link: https://patchwork.freedesktop.org/patch/msgid/20181002152911.4370-1-kai.heng.feng@canonical.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/drm_edid.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/gpu/drm/drm_edid.c ++++ b/drivers/gpu/drm/drm_edid.c +@@ -111,6 +111,9 @@ static const struct edid_quirk { + /* AEO model 0 reports 8 bpc, but is a 6 bpc panel */ + { "AEO", 0, EDID_QUIRK_FORCE_6BPC }, + ++ /* BOE model on HP Pavilion 15-n233sl reports 8 bpc, but is a 6 bpc panel */ ++ { "BOE", 0x78b, EDID_QUIRK_FORCE_6BPC }, ++ + /* CPT panel of Asus UX303LA reports 8 bpc, but is a 6 bpc panel */ + { "CPT", 0x17df, EDID_QUIRK_FORCE_6BPC }, + diff --git a/queue-4.14/drm-edid-vsdb-ycbcr420-deep-color-mode-bit-definitions.patch b/queue-4.14/drm-edid-vsdb-ycbcr420-deep-color-mode-bit-definitions.patch new file mode 100644 index 00000000000..382da970b39 --- /dev/null +++ b/queue-4.14/drm-edid-vsdb-ycbcr420-deep-color-mode-bit-definitions.patch @@ -0,0 +1,53 @@ +From 9068e02f58740778d8270840657f1e250a2cc60f Mon Sep 17 00:00:00 2001 +From: Clint Taylor +Date: Fri, 5 Oct 2018 14:52:15 -0700 +Subject: drm/edid: VSDB yCBCr420 Deep Color mode bit definitions + +From: Clint Taylor + +commit 9068e02f58740778d8270840657f1e250a2cc60f upstream. + +HDMI Forum VSDB YCBCR420 deep color capability bits are 2:0. Correct +definitions in the header for the mask to work correctly. + +Fixes: e6a9a2c3dc43 ("drm/edid: parse ycbcr 420 deep color information") +Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107893 +Cc: # v4.14+ +Signed-off-by: Clint Taylor +Reviewed-by: Jani Nikula +Reviewed-by: Shashank Sharma +Signed-off-by: Jani Nikula +Link: https://patchwork.freedesktop.org/patch/msgid/1538776335-12569-1-git-send-email-clinton.a.taylor@intel.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/drm_edid.c | 2 +- + include/drm/drm_edid.h | 6 +++--- + 2 files changed, 4 insertions(+), 4 deletions(-) + +--- a/drivers/gpu/drm/drm_edid.c ++++ b/drivers/gpu/drm/drm_edid.c +@@ -4223,7 +4223,7 @@ static void drm_parse_ycbcr420_deep_colo + struct drm_hdmi_info *hdmi = &connector->display_info.hdmi; + + dc_mask = db[7] & DRM_EDID_YCBCR420_DC_MASK; +- hdmi->y420_dc_modes |= dc_mask; ++ hdmi->y420_dc_modes = dc_mask; + } + + static void drm_parse_hdmi_forum_vsdb(struct drm_connector *connector, +--- a/include/drm/drm_edid.h ++++ b/include/drm/drm_edid.h +@@ -214,9 +214,9 @@ struct detailed_timing { + #define DRM_EDID_HDMI_DC_Y444 (1 << 3) + + /* YCBCR 420 deep color modes */ +-#define DRM_EDID_YCBCR420_DC_48 (1 << 6) +-#define DRM_EDID_YCBCR420_DC_36 (1 << 5) +-#define DRM_EDID_YCBCR420_DC_30 (1 << 4) ++#define DRM_EDID_YCBCR420_DC_48 (1 << 2) ++#define DRM_EDID_YCBCR420_DC_36 (1 << 1) ++#define DRM_EDID_YCBCR420_DC_30 (1 << 0) + #define DRM_EDID_YCBCR420_DC_MASK (DRM_EDID_YCBCR420_DC_48 | \ + DRM_EDID_YCBCR420_DC_36 | \ + DRM_EDID_YCBCR420_DC_30) diff --git a/queue-4.14/drm-fb-helper-reject-all-pixel-format-changing-requests.patch b/queue-4.14/drm-fb-helper-reject-all-pixel-format-changing-requests.patch new file mode 100644 index 00000000000..8c8c3ca9b4a --- /dev/null +++ b/queue-4.14/drm-fb-helper-reject-all-pixel-format-changing-requests.patch @@ -0,0 +1,142 @@ +From db05c481977599236f12a85e55de9f5ab37b0a2c Mon Sep 17 00:00:00 2001 +From: Eugeniy Paltsev +Date: Wed, 3 Oct 2018 19:45:38 +0300 +Subject: drm: fb-helper: Reject all pixel format changing requests +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Eugeniy Paltsev + +commit db05c481977599236f12a85e55de9f5ab37b0a2c upstream. + +drm fbdev emulation doesn't support changing the pixel format at all, +so reject all pixel format changing requests. + +Cc: stable@vger.kernel.org +Signed-off-by: Eugeniy Paltsev +Reviewed-by: Ville Syrjälä +Signed-off-by: Daniel Vetter +Link: https://patchwork.freedesktop.org/patch/msgid/20181003164538.5534-1-Eugeniy.Paltsev@synopsys.com +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/gpu/drm/drm_fb_helper.c | 91 +++++++++++----------------------------- + 1 file changed, 26 insertions(+), 65 deletions(-) + +--- a/drivers/gpu/drm/drm_fb_helper.c ++++ b/drivers/gpu/drm/drm_fb_helper.c +@@ -1490,6 +1490,25 @@ unlock: + } + EXPORT_SYMBOL(drm_fb_helper_ioctl); + ++static bool drm_fb_pixel_format_equal(const struct fb_var_screeninfo *var_1, ++ const struct fb_var_screeninfo *var_2) ++{ ++ return var_1->bits_per_pixel == var_2->bits_per_pixel && ++ var_1->grayscale == var_2->grayscale && ++ var_1->red.offset == var_2->red.offset && ++ var_1->red.length == var_2->red.length && ++ var_1->red.msb_right == var_2->red.msb_right && ++ var_1->green.offset == var_2->green.offset && ++ var_1->green.length == var_2->green.length && ++ var_1->green.msb_right == var_2->green.msb_right && ++ var_1->blue.offset == var_2->blue.offset && ++ var_1->blue.length == var_2->blue.length && ++ var_1->blue.msb_right == var_2->blue.msb_right && ++ var_1->transp.offset == var_2->transp.offset && ++ var_1->transp.length == var_2->transp.length && ++ var_1->transp.msb_right == var_2->transp.msb_right; ++} ++ + /** + * drm_fb_helper_check_var - implementation for &fb_ops.fb_check_var + * @var: screeninfo to check +@@ -1500,7 +1519,6 @@ int drm_fb_helper_check_var(struct fb_va + { + struct drm_fb_helper *fb_helper = info->par; + struct drm_framebuffer *fb = fb_helper->fb; +- int depth; + + if (var->pixclock != 0 || in_dbg_master()) + return -EINVAL; +@@ -1520,72 +1538,15 @@ int drm_fb_helper_check_var(struct fb_va + return -EINVAL; + } + +- switch (var->bits_per_pixel) { +- case 16: +- depth = (var->green.length == 6) ? 16 : 15; +- break; +- case 32: +- depth = (var->transp.length > 0) ? 32 : 24; +- break; +- default: +- depth = var->bits_per_pixel; +- break; +- } +- +- switch (depth) { +- case 8: +- var->red.offset = 0; +- var->green.offset = 0; +- var->blue.offset = 0; +- var->red.length = 8; +- var->green.length = 8; +- var->blue.length = 8; +- var->transp.length = 0; +- var->transp.offset = 0; +- break; +- case 15: +- var->red.offset = 10; +- var->green.offset = 5; +- var->blue.offset = 0; +- var->red.length = 5; +- var->green.length = 5; +- var->blue.length = 5; +- var->transp.length = 1; +- var->transp.offset = 15; +- break; +- case 16: +- var->red.offset = 11; +- var->green.offset = 5; +- var->blue.offset = 0; +- var->red.length = 5; +- var->green.length = 6; +- var->blue.length = 5; +- var->transp.length = 0; +- var->transp.offset = 0; +- break; +- case 24: +- var->red.offset = 16; +- var->green.offset = 8; +- var->blue.offset = 0; +- var->red.length = 8; +- var->green.length = 8; +- var->blue.length = 8; +- var->transp.length = 0; +- var->transp.offset = 0; +- break; +- case 32: +- var->red.offset = 16; +- var->green.offset = 8; +- var->blue.offset = 0; +- var->red.length = 8; +- var->green.length = 8; +- var->blue.length = 8; +- var->transp.length = 8; +- var->transp.offset = 24; +- break; +- default: ++ /* ++ * drm fbdev emulation doesn't support changing the pixel format at all, ++ * so reject all pixel format changing requests. ++ */ ++ if (!drm_fb_pixel_format_equal(var, &info->var)) { ++ DRM_DEBUG("fbdev emulation doesn't support changing the pixel format\n"); + return -EINVAL; + } ++ + return 0; + } + EXPORT_SYMBOL(drm_fb_helper_check_var); diff --git a/queue-4.14/ib-ucm-fix-spectre-v1-vulnerability.patch b/queue-4.14/ib-ucm-fix-spectre-v1-vulnerability.patch new file mode 100644 index 00000000000..9dfb8b61b0e --- /dev/null +++ b/queue-4.14/ib-ucm-fix-spectre-v1-vulnerability.patch @@ -0,0 +1,54 @@ +From 0295e39595e1146522f2722715dba7f7fba42217 Mon Sep 17 00:00:00 2001 +From: "Gustavo A. R. Silva" +Date: Tue, 16 Oct 2018 16:32:40 +0200 +Subject: IB/ucm: Fix Spectre v1 vulnerability + +From: Gustavo A. R. Silva + +commit 0295e39595e1146522f2722715dba7f7fba42217 upstream. + +hdr.cmd 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/infiniband/core/ucm.c:1127 ib_ucm_write() warn: potential +spectre issue 'ucm_cmd_table' [r] (local cap) + +Fix this by sanitizing hdr.cmd before using it to index +ucm_cmd_table. + +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 +Signed-off-by: Doug Ledford +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/core/ucm.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/infiniband/core/ucm.c ++++ b/drivers/infiniband/core/ucm.c +@@ -46,6 +46,8 @@ + #include + #include + ++#include ++ + #include + + #include +@@ -1118,6 +1120,7 @@ static ssize_t ib_ucm_write(struct file + + if (hdr.cmd >= ARRAY_SIZE(ucm_cmd_table)) + return -EINVAL; ++ hdr.cmd = array_index_nospec(hdr.cmd, ARRAY_SIZE(ucm_cmd_table)); + + if (hdr.in + sizeof(hdr) > len) + return -EINVAL; diff --git a/queue-4.14/input-elan_i2c-add-acpi-id-for-lenovo-ideapad-330-15igm.patch b/queue-4.14/input-elan_i2c-add-acpi-id-for-lenovo-ideapad-330-15igm.patch new file mode 100644 index 00000000000..f2bd049fdad --- /dev/null +++ b/queue-4.14/input-elan_i2c-add-acpi-id-for-lenovo-ideapad-330-15igm.patch @@ -0,0 +1,31 @@ +From 13c1c5e4d7f887cba36c5e3df3faa22071c1469f Mon Sep 17 00:00:00 2001 +From: Mikhail Nikiforov +Date: Mon, 15 Oct 2018 11:17:56 -0700 +Subject: Input: elan_i2c - add ACPI ID for Lenovo IdeaPad 330-15IGM + +From: Mikhail Nikiforov + +commit 13c1c5e4d7f887cba36c5e3df3faa22071c1469f upstream. + +Add ELAN061C to the ACPI table to support Elan touchpad found in Lenovo +IdeaPad 330-15IGM. + +Signed-off-by: Mikhail Nikiforov +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Torokhov +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/input/mouse/elan_i2c_core.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/input/mouse/elan_i2c_core.c ++++ b/drivers/input/mouse/elan_i2c_core.c +@@ -1262,6 +1262,7 @@ static const struct acpi_device_id elan_ + { "ELAN0611", 0 }, + { "ELAN0612", 0 }, + { "ELAN0618", 0 }, ++ { "ELAN061C", 0 }, + { "ELAN061D", 0 }, + { "ELAN0622", 0 }, + { "ELAN1000", 0 }, diff --git a/queue-4.14/ptp-fix-spectre-v1-vulnerability.patch b/queue-4.14/ptp-fix-spectre-v1-vulnerability.patch new file mode 100644 index 00000000000..1eb6053ac8e --- /dev/null +++ b/queue-4.14/ptp-fix-spectre-v1-vulnerability.patch @@ -0,0 +1,65 @@ +From efa61c8cf2950ab5c0e66cff3cabe2a2b24e81ba Mon Sep 17 00:00:00 2001 +From: "Gustavo A. R. Silva" +Date: Tue, 16 Oct 2018 15:06:41 +0200 +Subject: ptp: fix Spectre v1 vulnerability + +From: Gustavo A. R. Silva + +commit efa61c8cf2950ab5c0e66cff3cabe2a2b24e81ba upstream. + +pin_index 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/ptp/ptp_chardev.c:253 ptp_ioctl() warn: potential spectre issue +'ops->pin_config' [r] (local cap) + +Fix this by sanitizing pin_index before using it to index +ops->pin_config, and before passing it as an argument to +function ptp_set_pinfunc(), in which it is used to index +info->pin_config. + +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: Richard Cochran +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/ptp/ptp_chardev.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/ptp/ptp_chardev.c ++++ b/drivers/ptp/ptp_chardev.c +@@ -24,6 +24,8 @@ + #include + #include + ++#include ++ + #include "ptp_private.h" + + static int ptp_disable_pinfunc(struct ptp_clock_info *ops, +@@ -248,6 +250,7 @@ long ptp_ioctl(struct posix_clock *pc, u + err = -EINVAL; + break; + } ++ pin_index = array_index_nospec(pin_index, ops->n_pins); + if (mutex_lock_interruptible(&ptp->pincfg_mux)) + return -ERESTARTSYS; + pd = ops->pin_config[pin_index]; +@@ -266,6 +269,7 @@ long ptp_ioctl(struct posix_clock *pc, u + err = -EINVAL; + break; + } ++ pin_index = array_index_nospec(pin_index, ops->n_pins); + if (mutex_lock_interruptible(&ptp->pincfg_mux)) + return -ERESTARTSYS; + err = ptp_set_pinfunc(ptp, pin_index, pd.func, pd.chan); diff --git a/queue-4.14/rdma-ucma-fix-spectre-v1-vulnerability.patch b/queue-4.14/rdma-ucma-fix-spectre-v1-vulnerability.patch new file mode 100644 index 00000000000..92d6c01a13e --- /dev/null +++ b/queue-4.14/rdma-ucma-fix-spectre-v1-vulnerability.patch @@ -0,0 +1,54 @@ +From a3671a4f973ee9d9621d60166cc3b037c397d604 Mon Sep 17 00:00:00 2001 +From: "Gustavo A. R. Silva" +Date: Tue, 16 Oct 2018 16:59:01 +0200 +Subject: RDMA/ucma: Fix Spectre v1 vulnerability + +From: Gustavo A. R. Silva + +commit a3671a4f973ee9d9621d60166cc3b037c397d604 upstream. + +hdr.cmd 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/infiniband/core/ucma.c:1686 ucma_write() warn: potential +spectre issue 'ucma_cmd_table' [r] (local cap) + +Fix this by sanitizing hdr.cmd before using it to index +ucm_cmd_table. + +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 +Signed-off-by: Doug Ledford +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/infiniband/core/ucma.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/infiniband/core/ucma.c ++++ b/drivers/infiniband/core/ucma.c +@@ -44,6 +44,8 @@ + #include + #include + ++#include ++ + #include + #include + #include +@@ -1659,6 +1661,7 @@ static ssize_t ucma_write(struct file *f + + if (hdr.cmd >= ARRAY_SIZE(ucma_cmd_table)) + return -EINVAL; ++ hdr.cmd = array_index_nospec(hdr.cmd, ARRAY_SIZE(ucma_cmd_table)); + + if (hdr.in + sizeof(hdr) > len) + return -EINVAL; diff --git a/queue-4.14/sched-fair-fix-throttle_list-starvation-with-low-cfs-quota.patch b/queue-4.14/sched-fair-fix-throttle_list-starvation-with-low-cfs-quota.patch new file mode 100644 index 00000000000..77a391f40c7 --- /dev/null +++ b/queue-4.14/sched-fair-fix-throttle_list-starvation-with-low-cfs-quota.patch @@ -0,0 +1,175 @@ +From baa9be4ffb55876923dc9716abc0a448e510ba30 Mon Sep 17 00:00:00 2001 +From: Phil Auld +Date: Mon, 8 Oct 2018 10:36:40 -0400 +Subject: sched/fair: Fix throttle_list starvation with low CFS quota + +From: Phil Auld + +commit baa9be4ffb55876923dc9716abc0a448e510ba30 upstream. + +With a very low cpu.cfs_quota_us setting, such as the minimum of 1000, +distribute_cfs_runtime may not empty the throttled_list before it runs +out of runtime to distribute. In that case, due to the change from +c06f04c7048 to put throttled entries at the head of the list, later entries +on the list will starve. Essentially, the same X processes will get pulled +off the list, given CPU time and then, when expired, get put back on the +head of the list where distribute_cfs_runtime will give runtime to the same +set of processes leaving the rest. + +Fix the issue by setting a bit in struct cfs_bandwidth when +distribute_cfs_runtime is running, so that the code in throttle_cfs_rq can +decide to put the throttled entry on the tail or the head of the list. The +bit is set/cleared by the callers of distribute_cfs_runtime while they hold +cfs_bandwidth->lock. + +This is easy to reproduce with a handful of CPU consumers. I use 'crash' on +the live system. In some cases you can simply look at the throttled list and +see the later entries are not changing: + + crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3 + 1 ffff90b56cb2d200 -976050 + 2 ffff90b56cb2cc00 -484925 + 3 ffff90b56cb2bc00 -658814 + 4 ffff90b56cb2ba00 -275365 + 5 ffff90b166a45600 -135138 + 6 ffff90b56cb2da00 -282505 + 7 ffff90b56cb2e000 -148065 + 8 ffff90b56cb2fa00 -872591 + 9 ffff90b56cb2c000 -84687 + 10 ffff90b56cb2f000 -87237 + 11 ffff90b166a40a00 -164582 + + crash> list cfs_rq.throttled_list -H 0xffff90b54f6ade40 -s cfs_rq.runtime_remaining | paste - - | awk '{print $1" "$4}' | pr -t -n3 + 1 ffff90b56cb2d200 -994147 + 2 ffff90b56cb2cc00 -306051 + 3 ffff90b56cb2bc00 -961321 + 4 ffff90b56cb2ba00 -24490 + 5 ffff90b166a45600 -135138 + 6 ffff90b56cb2da00 -282505 + 7 ffff90b56cb2e000 -148065 + 8 ffff90b56cb2fa00 -872591 + 9 ffff90b56cb2c000 -84687 + 10 ffff90b56cb2f000 -87237 + 11 ffff90b166a40a00 -164582 + +Sometimes it is easier to see by finding a process getting starved and looking +at the sched_info: + + crash> task ffff8eb765994500 sched_info + PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest" + sched_info = { + pcount = 8, + run_delay = 697094208, + last_arrival = 240260125039, + last_queued = 240260327513 + }, + crash> task ffff8eb765994500 sched_info + PID: 7800 TASK: ffff8eb765994500 CPU: 16 COMMAND: "cputest" + sched_info = { + pcount = 8, + run_delay = 697094208, + last_arrival = 240260125039, + last_queued = 240260327513 + }, + +Signed-off-by: Phil Auld +Reviewed-by: Ben Segall +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: stable@vger.kernel.org +Fixes: c06f04c70489 ("sched: Fix potential near-infinite distribute_cfs_runtime() loop") +Link: http://lkml.kernel.org/r/20181008143639.GA4019@pauld.bos.csb +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + kernel/sched/fair.c | 22 +++++++++++++++++++--- + kernel/sched/sched.h | 2 ++ + 2 files changed, 21 insertions(+), 3 deletions(-) + +--- a/kernel/sched/fair.c ++++ b/kernel/sched/fair.c +@@ -4299,9 +4299,13 @@ static void throttle_cfs_rq(struct cfs_r + + /* + * Add to the _head_ of the list, so that an already-started +- * distribute_cfs_runtime will not see us ++ * distribute_cfs_runtime will not see us. If disribute_cfs_runtime is ++ * not running add to the tail so that later runqueues don't get starved. + */ +- list_add_rcu(&cfs_rq->throttled_list, &cfs_b->throttled_cfs_rq); ++ if (cfs_b->distribute_running) ++ list_add_rcu(&cfs_rq->throttled_list, &cfs_b->throttled_cfs_rq); ++ else ++ list_add_tail_rcu(&cfs_rq->throttled_list, &cfs_b->throttled_cfs_rq); + + /* + * If we're the first throttled task, make sure the bandwidth +@@ -4445,14 +4449,16 @@ static int do_sched_cfs_period_timer(str + * in us over-using our runtime if it is all used during this loop, but + * only by limited amounts in that extreme case. + */ +- while (throttled && cfs_b->runtime > 0) { ++ while (throttled && cfs_b->runtime > 0 && !cfs_b->distribute_running) { + runtime = cfs_b->runtime; ++ cfs_b->distribute_running = 1; + raw_spin_unlock(&cfs_b->lock); + /* we can't nest cfs_b->lock while distributing bandwidth */ + runtime = distribute_cfs_runtime(cfs_b, runtime, + runtime_expires); + raw_spin_lock(&cfs_b->lock); + ++ cfs_b->distribute_running = 0; + throttled = !list_empty(&cfs_b->throttled_cfs_rq); + + cfs_b->runtime -= min(runtime, cfs_b->runtime); +@@ -4563,6 +4569,11 @@ static void do_sched_cfs_slack_timer(str + + /* confirm we're still not at a refresh boundary */ + raw_spin_lock(&cfs_b->lock); ++ if (cfs_b->distribute_running) { ++ raw_spin_unlock(&cfs_b->lock); ++ return; ++ } ++ + if (runtime_refresh_within(cfs_b, min_bandwidth_expiration)) { + raw_spin_unlock(&cfs_b->lock); + return; +@@ -4572,6 +4583,9 @@ static void do_sched_cfs_slack_timer(str + runtime = cfs_b->runtime; + + expires = cfs_b->runtime_expires; ++ if (runtime) ++ cfs_b->distribute_running = 1; ++ + raw_spin_unlock(&cfs_b->lock); + + if (!runtime) +@@ -4582,6 +4596,7 @@ static void do_sched_cfs_slack_timer(str + raw_spin_lock(&cfs_b->lock); + if (expires == cfs_b->runtime_expires) + cfs_b->runtime -= min(runtime, cfs_b->runtime); ++ cfs_b->distribute_running = 0; + raw_spin_unlock(&cfs_b->lock); + } + +@@ -4690,6 +4705,7 @@ void init_cfs_bandwidth(struct cfs_bandw + cfs_b->period_timer.function = sched_cfs_period_timer; + hrtimer_init(&cfs_b->slack_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); + cfs_b->slack_timer.function = sched_cfs_slack_timer; ++ cfs_b->distribute_running = 0; + } + + static void init_cfs_rq_runtime(struct cfs_rq *cfs_rq) +--- a/kernel/sched/sched.h ++++ b/kernel/sched/sched.h +@@ -288,6 +288,8 @@ struct cfs_bandwidth { + /* statistics */ + int nr_periods, nr_throttled; + u64 throttled_time; ++ ++ bool distribute_running; + #endif + }; + diff --git a/queue-4.14/series b/queue-4.14/series index e68aeae31eb..e3d96245647 100644 --- a/queue-4.14/series +++ b/queue-4.14/series @@ -8,3 +8,23 @@ clk-tegra-add-quirk-for-getting-cdev1-2-clocks-on-te.patch fsnotify-fix-ignore-mask-logic-in-fsnotify.patch gpio-mxs-get-rid-of-external-api-call.patch xfs-truncate-transaction-does-not-modify-the-inobt.patch +cachefiles-fix-the-race-between-cachefiles_bury_object-and-rmdir-2.patch +ptp-fix-spectre-v1-vulnerability.patch +drm-edid-add-6-bpc-quirk-for-boe-panel-in-hp-pavilion-15-n233sl.patch +drm-edid-vsdb-ycbcr420-deep-color-mode-bit-definitions.patch +drm-fb-helper-reject-all-pixel-format-changing-requests.patch +rdma-ucma-fix-spectre-v1-vulnerability.patch +ib-ucm-fix-spectre-v1-vulnerability.patch +cdc-acm-do-not-reset-notification-buffer-index-upon-urb-unlinking.patch +cdc-acm-correct-counting-of-uart-states-in-serial-state-notification.patch +cdc-acm-fix-race-between-reset-and-control-messaging.patch +usb-usbip-fix-bug-kasan-slab-out-of-bounds-in-vhci_hub_control.patch +usb-gadget-storage-fix-spectre-v1-vulnerability.patch +usb-fix-the-usbfs-flag-sanitization-for-control-transfers.patch +input-elan_i2c-add-acpi-id-for-lenovo-ideapad-330-15igm.patch +sched-fair-fix-throttle_list-starvation-with-low-cfs-quota.patch +x86-tsc-force-inlining-of-cyc2ns-bits.patch +x86-hibernate-fix-nosave_regions-setup-for-hibernation.patch +x86-percpu-fix-this_cpu_read.patch +x86-time-correct-the-attribute-on-jiffies-definition.patch +x86-fpu-fix-i486-no387-boot-crash-by-only-saving-fpu-registers-on-context-switch-if-there-is-an-fpu.patch diff --git a/queue-4.14/usb-fix-the-usbfs-flag-sanitization-for-control-transfers.patch b/queue-4.14/usb-fix-the-usbfs-flag-sanitization-for-control-transfers.patch new file mode 100644 index 00000000000..69e1b83b610 --- /dev/null +++ b/queue-4.14/usb-fix-the-usbfs-flag-sanitization-for-control-transfers.patch @@ -0,0 +1,52 @@ +From 665c365a77fbfeabe52694aedf3446d5f2f1ce42 Mon Sep 17 00:00:00 2001 +From: Alan Stern +Date: Mon, 15 Oct 2018 16:55:04 -0400 +Subject: USB: fix the usbfs flag sanitization for control transfers + +From: Alan Stern + +commit 665c365a77fbfeabe52694aedf3446d5f2f1ce42 upstream. + +Commit 7a68d9fb8510 ("USB: usbdevfs: sanitize flags more") checks the +transfer flags for URBs submitted from userspace via usbfs. However, +the check for whether the USBDEVFS_URB_SHORT_NOT_OK flag should be +allowed for a control transfer was added in the wrong place, before +the code has properly determined the direction of the control +transfer. (Control transfers are special because for them, the +direction is set by the bRequestType byte of the Setup packet rather +than direction bit of the endpoint address.) + +This patch moves code which sets up the allow_short flag for control +transfers down after is_in has been set to the correct value. + +Signed-off-by: Alan Stern +Reported-and-tested-by: syzbot+24a30223a4b609bb802e@syzkaller.appspotmail.com +Fixes: 7a68d9fb8510 ("USB: usbdevfs: sanitize flags more") +CC: Oliver Neukum +CC: +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/core/devio.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/usb/core/devio.c ++++ b/drivers/usb/core/devio.c +@@ -1491,8 +1491,6 @@ static int proc_do_submiturb(struct usb_ + u = 0; + switch (uurb->type) { + case USBDEVFS_URB_TYPE_CONTROL: +- if (is_in) +- allow_short = true; + if (!usb_endpoint_xfer_control(&ep->desc)) + return -EINVAL; + /* min 8 byte setup packet */ +@@ -1522,6 +1520,8 @@ static int proc_do_submiturb(struct usb_ + is_in = 0; + uurb->endpoint &= ~USB_DIR_IN; + } ++ if (is_in) ++ allow_short = true; + snoop(&ps->dev->dev, "control urb: bRequestType=%02x " + "bRequest=%02x wValue=%04x " + "wIndex=%04x wLength=%04x\n", diff --git a/queue-4.14/usb-gadget-storage-fix-spectre-v1-vulnerability.patch b/queue-4.14/usb-gadget-storage-fix-spectre-v1-vulnerability.patch new file mode 100644 index 00000000000..13befa18365 --- /dev/null +++ b/queue-4.14/usb-gadget-storage-fix-spectre-v1-vulnerability.patch @@ -0,0 +1,54 @@ +From 9ae24af3669111d418242caec8dd4ebd9ba26860 Mon Sep 17 00:00:00 2001 +From: "Gustavo A. R. Silva" +Date: Tue, 16 Oct 2018 12:16:45 +0200 +Subject: usb: gadget: storage: Fix Spectre v1 vulnerability + +From: Gustavo A. R. Silva + +commit 9ae24af3669111d418242caec8dd4ebd9ba26860 upstream. + +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 + +--- + drivers/usb/gadget/function/f_mass_storage.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/drivers/usb/gadget/function/f_mass_storage.c ++++ b/drivers/usb/gadget/function/f_mass_storage.c +@@ -221,6 +221,8 @@ + #include + #include + ++#include ++ + #include "configfs.h" + + +@@ -3170,6 +3172,7 @@ static struct config_group *fsg_lun_make + fsg_opts = to_fsg_opts(&group->cg_item); + if (num >= FSG_MAX_LUNS) + return ERR_PTR(-ERANGE); ++ num = array_index_nospec(num, FSG_MAX_LUNS); + + mutex_lock(&fsg_opts->lock); + if (fsg_opts->refcnt || fsg_opts->common->luns[num]) { diff --git a/queue-4.14/usb-usbip-fix-bug-kasan-slab-out-of-bounds-in-vhci_hub_control.patch b/queue-4.14/usb-usbip-fix-bug-kasan-slab-out-of-bounds-in-vhci_hub_control.patch new file mode 100644 index 00000000000..bdb5feb3abd --- /dev/null +++ b/queue-4.14/usb-usbip-fix-bug-kasan-slab-out-of-bounds-in-vhci_hub_control.patch @@ -0,0 +1,180 @@ +From 81f7567c51ad97668d1c3a48e8ecc482e64d4161 Mon Sep 17 00:00:00 2001 +From: "Shuah Khan (Samsung OSG)" +Date: Fri, 5 Oct 2018 16:17:44 -0600 +Subject: usb: usbip: Fix BUG: KASAN: slab-out-of-bounds in vhci_hub_control() + +From: Shuah Khan (Samsung OSG) + +commit 81f7567c51ad97668d1c3a48e8ecc482e64d4161 upstream. + +vhci_hub_control() accesses port_status array with out of bounds port +value. Fix it to reference port_status[] only with a valid rhport value +when invalid_rhport flag is true. + +The invalid_rhport flag is set early on after detecting in port value +is within the bounds or not. + +The following is used reproduce the problem and verify the fix: +C reproducer: https://syzkaller.appspot.com/x/repro.c?x=14ed8ab6400000 + +Reported-by: syzbot+bccc1fe10b70fadc78d0@syzkaller.appspotmail.com +Cc: stable +Signed-off-by: Shuah Khan (Samsung OSG) +Signed-off-by: Greg Kroah-Hartman + +--- + drivers/usb/usbip/vhci_hcd.c | 57 +++++++++++++++++++++++++++++++------------ + 1 file changed, 42 insertions(+), 15 deletions(-) + +--- a/drivers/usb/usbip/vhci_hcd.c ++++ b/drivers/usb/usbip/vhci_hcd.c +@@ -332,8 +332,9 @@ static int vhci_hub_control(struct usb_h + struct vhci_hcd *vhci_hcd; + struct vhci *vhci; + int retval = 0; +- int rhport; ++ int rhport = -1; + unsigned long flags; ++ bool invalid_rhport = false; + + u32 prev_port_status[VHCI_HC_PORTS]; + +@@ -348,9 +349,19 @@ static int vhci_hub_control(struct usb_h + usbip_dbg_vhci_rh("typeReq %x wValue %x wIndex %x\n", typeReq, wValue, + wIndex); + +- if (wIndex > VHCI_HC_PORTS) +- pr_err("invalid port number %d\n", wIndex); +- rhport = wIndex - 1; ++ /* ++ * wIndex can be 0 for some request types (typeReq). rhport is ++ * in valid range when wIndex >= 1 and < VHCI_HC_PORTS. ++ * ++ * Reference port_status[] only with valid rhport when ++ * invalid_rhport is false. ++ */ ++ if (wIndex < 1 || wIndex > VHCI_HC_PORTS) { ++ invalid_rhport = true; ++ if (wIndex > VHCI_HC_PORTS) ++ pr_err("invalid port number %d\n", wIndex); ++ } else ++ rhport = wIndex - 1; + + vhci_hcd = hcd_to_vhci_hcd(hcd); + vhci = vhci_hcd->vhci; +@@ -359,8 +370,9 @@ static int vhci_hub_control(struct usb_h + + /* store old status and compare now and old later */ + if (usbip_dbg_flag_vhci_rh) { +- memcpy(prev_port_status, vhci_hcd->port_status, +- sizeof(prev_port_status)); ++ if (!invalid_rhport) ++ memcpy(prev_port_status, vhci_hcd->port_status, ++ sizeof(prev_port_status)); + } + + switch (typeReq) { +@@ -368,8 +380,10 @@ static int vhci_hub_control(struct usb_h + usbip_dbg_vhci_rh(" ClearHubFeature\n"); + break; + case ClearPortFeature: +- if (rhport < 0) ++ if (invalid_rhport) { ++ pr_err("invalid port number %d\n", wIndex); + goto error; ++ } + switch (wValue) { + case USB_PORT_FEAT_SUSPEND: + if (hcd->speed == HCD_USB3) { +@@ -429,9 +443,10 @@ static int vhci_hub_control(struct usb_h + break; + case GetPortStatus: + usbip_dbg_vhci_rh(" GetPortStatus port %x\n", wIndex); +- if (wIndex < 1) { ++ if (invalid_rhport) { + pr_err("invalid port number %d\n", wIndex); + retval = -EPIPE; ++ goto error; + } + + /* we do not care about resume. */ +@@ -527,16 +542,20 @@ static int vhci_hub_control(struct usb_h + goto error; + } + +- if (rhport < 0) ++ if (invalid_rhport) { ++ pr_err("invalid port number %d\n", wIndex); + goto error; ++ } + + vhci_hcd->port_status[rhport] |= USB_PORT_STAT_SUSPEND; + break; + case USB_PORT_FEAT_POWER: + usbip_dbg_vhci_rh( + " SetPortFeature: USB_PORT_FEAT_POWER\n"); +- if (rhport < 0) ++ if (invalid_rhport) { ++ pr_err("invalid port number %d\n", wIndex); + goto error; ++ } + if (hcd->speed == HCD_USB3) + vhci_hcd->port_status[rhport] |= USB_SS_PORT_STAT_POWER; + else +@@ -545,8 +564,10 @@ static int vhci_hub_control(struct usb_h + case USB_PORT_FEAT_BH_PORT_RESET: + usbip_dbg_vhci_rh( + " SetPortFeature: USB_PORT_FEAT_BH_PORT_RESET\n"); +- if (rhport < 0) ++ if (invalid_rhport) { ++ pr_err("invalid port number %d\n", wIndex); + goto error; ++ } + /* Applicable only for USB3.0 hub */ + if (hcd->speed != HCD_USB3) { + pr_err("USB_PORT_FEAT_BH_PORT_RESET req not " +@@ -557,8 +578,10 @@ static int vhci_hub_control(struct usb_h + case USB_PORT_FEAT_RESET: + usbip_dbg_vhci_rh( + " SetPortFeature: USB_PORT_FEAT_RESET\n"); +- if (rhport < 0) ++ if (invalid_rhport) { ++ pr_err("invalid port number %d\n", wIndex); + goto error; ++ } + /* if it's already enabled, disable */ + if (hcd->speed == HCD_USB3) { + vhci_hcd->port_status[rhport] = 0; +@@ -579,8 +602,10 @@ static int vhci_hub_control(struct usb_h + default: + usbip_dbg_vhci_rh(" SetPortFeature: default %d\n", + wValue); +- if (rhport < 0) ++ if (invalid_rhport) { ++ pr_err("invalid port number %d\n", wIndex); + goto error; ++ } + if (hcd->speed == HCD_USB3) { + if ((vhci_hcd->port_status[rhport] & + USB_SS_PORT_STAT_POWER) != 0) { +@@ -622,7 +647,7 @@ error: + if (usbip_dbg_flag_vhci_rh) { + pr_debug("port %d\n", rhport); + /* Only dump valid port status */ +- if (rhport >= 0) { ++ if (!invalid_rhport) { + dump_port_status_diff(prev_port_status[rhport], + vhci_hcd->port_status[rhport], + hcd->speed == HCD_USB3); +@@ -632,8 +657,10 @@ error: + + spin_unlock_irqrestore(&vhci->lock, flags); + +- if ((vhci_hcd->port_status[rhport] & PORT_C_MASK) != 0) ++ if (!invalid_rhport && ++ (vhci_hcd->port_status[rhport] & PORT_C_MASK) != 0) { + usb_hcd_poll_rh_status(hcd); ++ } + + return retval; + } diff --git a/queue-4.14/x86-fpu-fix-i486-no387-boot-crash-by-only-saving-fpu-registers-on-context-switch-if-there-is-an-fpu.patch b/queue-4.14/x86-fpu-fix-i486-no387-boot-crash-by-only-saving-fpu-registers-on-context-switch-if-there-is-an-fpu.patch new file mode 100644 index 00000000000..48bcd6f64f2 --- /dev/null +++ b/queue-4.14/x86-fpu-fix-i486-no387-boot-crash-by-only-saving-fpu-registers-on-context-switch-if-there-is-an-fpu.patch @@ -0,0 +1,54 @@ +From 2224d616528194b02424c91c2ee254b3d29942c3 Mon Sep 17 00:00:00 2001 +From: Sebastian Andrzej Siewior +Date: Tue, 16 Oct 2018 22:25:25 +0200 +Subject: x86/fpu: Fix i486 + no387 boot crash by only saving FPU registers on context switch if there is an FPU + +From: Sebastian Andrzej Siewior + +commit 2224d616528194b02424c91c2ee254b3d29942c3 upstream. + +Booting an i486 with "no387 nofxsr" ends with with the following crash: + + math_emulate: 0060:c101987d + Kernel panic - not syncing: Math emulation needed in kernel + +on the first context switch in user land. + +The reason is that copy_fpregs_to_fpstate() tries FNSAVE which does not work +as the FPU is turned off. + +This bug was introduced in: + + f1c8cd0176078 ("x86/fpu: Change fpu->fpregs_active users to fpu->fpstate_active") + +Add a check for X86_FEATURE_FPU before trying to save FPU registers (we +have such a check in switch_fpu_finish() already). + +Signed-off-by: Sebastian Andrzej Siewior +Reviewed-by: Andy Lutomirski +Cc: Borislav Petkov +Cc: Dave Hansen +Cc: Linus Torvalds +Cc: Peter Zijlstra +Cc: Thomas Gleixner +Cc: stable@vger.kernel.org +Fixes: f1c8cd0176078 ("x86/fpu: Change fpu->fpregs_active users to fpu->fpstate_active") +Link: http://lkml.kernel.org/r/20181016202525.29437-4-bigeasy@linutronix.de +Signed-off-by: Ingo Molnar +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/include/asm/fpu/internal.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/include/asm/fpu/internal.h ++++ b/arch/x86/include/asm/fpu/internal.h +@@ -528,7 +528,7 @@ static inline void fpregs_activate(struc + static inline void + switch_fpu_prepare(struct fpu *old_fpu, int cpu) + { +- if (old_fpu->initialized) { ++ if (static_cpu_has(X86_FEATURE_FPU) && old_fpu->initialized) { + if (!copy_fpregs_to_fpstate(old_fpu)) + old_fpu->last_cpu = -1; + else diff --git a/queue-4.14/x86-hibernate-fix-nosave_regions-setup-for-hibernation.patch b/queue-4.14/x86-hibernate-fix-nosave_regions-setup-for-hibernation.patch new file mode 100644 index 00000000000..25338730e31 --- /dev/null +++ b/queue-4.14/x86-hibernate-fix-nosave_regions-setup-for-hibernation.patch @@ -0,0 +1,83 @@ +From cc55f7537db6af371e9c1c6a71161ee40f918824 Mon Sep 17 00:00:00 2001 +From: Zhimin Gu +Date: Fri, 21 Sep 2018 14:26:24 +0800 +Subject: x86, hibernate: Fix nosave_regions setup for hibernation + +From: Zhimin Gu + +commit cc55f7537db6af371e9c1c6a71161ee40f918824 upstream. + +On 32bit systems, nosave_regions(non RAM areas) located between +max_low_pfn and max_pfn are not excluded from hibernation snapshot +currently, which may result in a machine check exception when +trying to access these unsafe regions during hibernation: + +[ 612.800453] Disabling lock debugging due to kernel taint +[ 612.805786] mce: [Hardware Error]: CPU 0: Machine Check Exception: 5 Bank 6: fe00000000801136 +[ 612.814344] mce: [Hardware Error]: RIP !INEXACT! 60:<00000000d90be566> {swsusp_save+0x436/0x560} +[ 612.823167] mce: [Hardware Error]: TSC 1f5939fe276 ADDR dd000000 MISC 30e0000086 +[ 612.830677] mce: [Hardware Error]: PROCESSOR 0:306c3 TIME 1529487426 SOCKET 0 APIC 0 microcode 24 +[ 612.839581] mce: [Hardware Error]: Run the above through 'mcelog --ascii' +[ 612.846394] mce: [Hardware Error]: Machine check: Processor context corrupt +[ 612.853380] Kernel panic - not syncing: Fatal machine check +[ 612.858978] Kernel Offset: 0x18000000 from 0xc1000000 (relocation range: 0xc0000000-0xf7ffdfff) + +This is because on 32bit systems, pages above max_low_pfn are regarded +as high memeory, and accessing unsafe pages might cause expected MCE. +On the problematic 32bit system, there are reserved memory above low +memory, which triggered the MCE: + +e820 memory mapping: +[ 0.000000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d7ff] usable +[ 0.000000] BIOS-e820: [mem 0x000000000009d800-0x000000000009ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000000100000-0x00000000d160cfff] usable +[ 0.000000] BIOS-e820: [mem 0x00000000d160d000-0x00000000d1613fff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x00000000d1614000-0x00000000d1a44fff] usable +[ 0.000000] BIOS-e820: [mem 0x00000000d1a45000-0x00000000d1ecffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000d1ed0000-0x00000000d7eeafff] usable +[ 0.000000] BIOS-e820: [mem 0x00000000d7eeb000-0x00000000d7ffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000d8000000-0x00000000d875ffff] usable +[ 0.000000] BIOS-e820: [mem 0x00000000d8760000-0x00000000d87fffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000d8800000-0x00000000d8fadfff] usable +[ 0.000000] BIOS-e820: [mem 0x00000000d8fae000-0x00000000d8ffffff] ACPI data +[ 0.000000] BIOS-e820: [mem 0x00000000d9000000-0x00000000da71bfff] usable +[ 0.000000] BIOS-e820: [mem 0x00000000da71c000-0x00000000da7fffff] ACPI NVS +[ 0.000000] BIOS-e820: [mem 0x00000000da800000-0x00000000dbb8bfff] usable +[ 0.000000] BIOS-e820: [mem 0x00000000dbb8c000-0x00000000dbffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000dd000000-0x00000000df1fffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000f8000000-0x00000000fbffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fec00000-0x00000000fec00fff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fed00000-0x00000000fed03fff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fed1c000-0x00000000fed1ffff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved +[ 0.000000] BIOS-e820: [mem 0x00000000ff000000-0x00000000ffffffff] reserved +[ 0.000000] BIOS-e820: [mem 0x0000000100000000-0x000000041edfffff] usable + +Fix this problem by changing pfn limit from max_low_pfn to max_pfn. +This fix does not impact 64bit system because on 64bit max_low_pfn +is the same as max_pfn. + +Signed-off-by: Zhimin Gu +Acked-by: Pavel Machek +Signed-off-by: Chen Yu +Acked-by: Thomas Gleixner +Cc: All applicable +Signed-off-by: Rafael J. Wysocki +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/setup.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/setup.c ++++ b/arch/x86/kernel/setup.c +@@ -1287,7 +1287,7 @@ void __init setup_arch(char **cmdline_p) + kvm_guest_init(); + + e820__reserve_resources(); +- e820__register_nosave_regions(max_low_pfn); ++ e820__register_nosave_regions(max_pfn); + + x86_init.resources.reserve_resources(); + diff --git a/queue-4.14/x86-percpu-fix-this_cpu_read.patch b/queue-4.14/x86-percpu-fix-this_cpu_read.patch new file mode 100644 index 00000000000..603a334eece --- /dev/null +++ b/queue-4.14/x86-percpu-fix-this_cpu_read.patch @@ -0,0 +1,59 @@ +From b59167ac7bafd804c91e49ad53c6d33a7394d4c8 Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Thu, 11 Oct 2018 12:38:27 +0200 +Subject: x86/percpu: Fix this_cpu_read() + +From: Peter Zijlstra + +commit b59167ac7bafd804c91e49ad53c6d33a7394d4c8 upstream. + +Eric reported that a sequence count loop using this_cpu_read() got +optimized out. This is wrong, this_cpu_read() must imply READ_ONCE() +because the interface is IRQ-safe, therefore an interrupt can have +changed the per-cpu value. + +Fixes: 7c3576d261ce ("[PATCH] i386: Convert PDA into the percpu section") +Reported-by: Eric Dumazet +Signed-off-by: Peter Zijlstra (Intel) +Signed-off-by: Thomas Gleixner +Acked-by: Eric Dumazet +Cc: hpa@zytor.com +Cc: eric.dumazet@gmail.com +Cc: bp@alien8.de +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20181011104019.748208519@infradead.org +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/include/asm/percpu.h | 8 ++++---- + 1 file changed, 4 insertions(+), 4 deletions(-) + +--- a/arch/x86/include/asm/percpu.h ++++ b/arch/x86/include/asm/percpu.h +@@ -185,22 +185,22 @@ do { \ + typeof(var) pfo_ret__; \ + switch (sizeof(var)) { \ + case 1: \ +- asm(op "b "__percpu_arg(1)",%0" \ ++ asm volatile(op "b "__percpu_arg(1)",%0"\ + : "=q" (pfo_ret__) \ + : "m" (var)); \ + break; \ + case 2: \ +- asm(op "w "__percpu_arg(1)",%0" \ ++ asm volatile(op "w "__percpu_arg(1)",%0"\ + : "=r" (pfo_ret__) \ + : "m" (var)); \ + break; \ + case 4: \ +- asm(op "l "__percpu_arg(1)",%0" \ ++ asm volatile(op "l "__percpu_arg(1)",%0"\ + : "=r" (pfo_ret__) \ + : "m" (var)); \ + break; \ + case 8: \ +- asm(op "q "__percpu_arg(1)",%0" \ ++ asm volatile(op "q "__percpu_arg(1)",%0"\ + : "=r" (pfo_ret__) \ + : "m" (var)); \ + break; \ diff --git a/queue-4.14/x86-time-correct-the-attribute-on-jiffies-definition.patch b/queue-4.14/x86-time-correct-the-attribute-on-jiffies-definition.patch new file mode 100644 index 00000000000..5fdf78a7a10 --- /dev/null +++ b/queue-4.14/x86-time-correct-the-attribute-on-jiffies-definition.patch @@ -0,0 +1,61 @@ +From 53c13ba8ed39e89f21a0b98f4c8a241bb44e483d Mon Sep 17 00:00:00 2001 +From: Nathan Chancellor +Date: Fri, 12 Oct 2018 17:53:12 -0700 +Subject: x86/time: Correct the attribute on jiffies' definition + +From: Nathan Chancellor + +commit 53c13ba8ed39e89f21a0b98f4c8a241bb44e483d upstream. + +Clang warns that the declaration of jiffies in include/linux/jiffies.h +doesn't match the definition in arch/x86/time/kernel.c: + +arch/x86/kernel/time.c:29:42: warning: section does not match previous declaration [-Wsection] +__visible volatile unsigned long jiffies __cacheline_aligned = INITIAL_JIFFIES; + ^ +./include/linux/cache.h:49:4: note: expanded from macro '__cacheline_aligned' + __section__(".data..cacheline_aligned"))) + ^ +./include/linux/jiffies.h:81:31: note: previous attribute is here +extern unsigned long volatile __cacheline_aligned_in_smp __jiffy_arch_data jiffies; + ^ +./arch/x86/include/asm/cache.h:20:2: note: expanded from macro '__cacheline_aligned_in_smp' + __page_aligned_data + ^ +./include/linux/linkage.h:39:29: note: expanded from macro '__page_aligned_data' +#define __page_aligned_data __section(.data..page_aligned) __aligned(PAGE_SIZE) + ^ +./include/linux/compiler_attributes.h:233:56: note: expanded from macro '__section' +#define __section(S) __attribute__((__section__(#S))) + ^ +1 warning generated. + +The declaration was changed in commit 7c30f352c852 ("jiffies.h: declare +jiffies and jiffies_64 with ____cacheline_aligned_in_smp") but wasn't +updated here. Make them match so Clang no longer warns. + +Fixes: 7c30f352c852 ("jiffies.h: declare jiffies and jiffies_64 with ____cacheline_aligned_in_smp") +Signed-off-by: Nathan Chancellor +Signed-off-by: Thomas Gleixner +Cc: Borislav Petkov +Cc: "H. Peter Anvin" +Cc: Nick Desaulniers +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20181013005311.28617-1-natechancellor@gmail.com +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/time.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/x86/kernel/time.c ++++ b/arch/x86/kernel/time.c +@@ -25,7 +25,7 @@ + #include + + #ifdef CONFIG_X86_64 +-__visible volatile unsigned long jiffies __cacheline_aligned = INITIAL_JIFFIES; ++__visible volatile unsigned long jiffies __cacheline_aligned_in_smp = INITIAL_JIFFIES; + #endif + + unsigned long profile_pc(struct pt_regs *regs) diff --git a/queue-4.14/x86-tsc-force-inlining-of-cyc2ns-bits.patch b/queue-4.14/x86-tsc-force-inlining-of-cyc2ns-bits.patch new file mode 100644 index 00000000000..a7f3aadf8e6 --- /dev/null +++ b/queue-4.14/x86-tsc-force-inlining-of-cyc2ns-bits.patch @@ -0,0 +1,57 @@ +From 4907c68abd3f60f650f98d5a69d4ec77c0bde44f Mon Sep 17 00:00:00 2001 +From: Peter Zijlstra +Date: Thu, 11 Oct 2018 12:38:26 +0200 +Subject: x86/tsc: Force inlining of cyc2ns bits + +From: Peter Zijlstra + +commit 4907c68abd3f60f650f98d5a69d4ec77c0bde44f upstream. + +Looking at the asm for native_sched_clock() I noticed we don't inline +enough. Mostly caused by sharing code with cyc2ns_read_begin(), which +we didn't used to do. So mark all that __force_inline to make it DTRT. + +Fixes: 59eaef78bfea ("x86/tsc: Remodel cyc2ns to use seqcount_latch()") +Reported-by: Eric Dumazet +Signed-off-by: Peter Zijlstra (Intel) +Signed-off-by: Thomas Gleixner +Cc: hpa@zytor.com +Cc: eric.dumazet@gmail.com +Cc: bp@alien8.de +Cc: stable@vger.kernel.org +Link: https://lkml.kernel.org/r/20181011104019.695196158@infradead.org +Signed-off-by: Greg Kroah-Hartman + +--- + arch/x86/kernel/tsc.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/arch/x86/kernel/tsc.c ++++ b/arch/x86/kernel/tsc.c +@@ -60,7 +60,7 @@ struct cyc2ns { + + static DEFINE_PER_CPU_ALIGNED(struct cyc2ns, cyc2ns); + +-void cyc2ns_read_begin(struct cyc2ns_data *data) ++void __always_inline cyc2ns_read_begin(struct cyc2ns_data *data) + { + int seq, idx; + +@@ -77,7 +77,7 @@ void cyc2ns_read_begin(struct cyc2ns_dat + } while (unlikely(seq != this_cpu_read(cyc2ns.seq.sequence))); + } + +-void cyc2ns_read_end(void) ++void __always_inline cyc2ns_read_end(void) + { + preempt_enable_notrace(); + } +@@ -123,7 +123,7 @@ static void cyc2ns_init(int cpu) + seqcount_init(&c2n->seq); + } + +-static inline unsigned long long cycles_2_ns(unsigned long long cyc) ++static __always_inline unsigned long long cycles_2_ns(unsigned long long cyc) + { + struct cyc2ns_data data; + unsigned long long ns;