This is a note to let you know that I've just added the patch titled
HID: cp2112: add HIDRAW dependency
to the 4.13-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
hid-cp2112-add-hidraw-dependency.patch
and it can be found in the queue-4.13 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From cde3076bdc38bf436e517a379759a9092c6ffd4f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?S=C3=A9bastien=20Szymanski?=
<sebastien.szymanski(a)armadeus.com>
Date: Thu, 2 Nov 2017 12:12:43 +0100
Subject: HID: cp2112: add HIDRAW dependency
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
From: Sébastien Szymanski <sebastien.szymanski(a)armadeus.com>
commit cde3076bdc38bf436e517a379759a9092c6ffd4f upstream.
Otherwise, with HIDRAW=n, the probe function crashes because of null
dereference of hdev->hidraw.
Fixes: 42cb6b35b9e6 ("HID: cp2112: use proper hidraw name with minor number")
Signed-off-by: Sébastien Szymanski <sebastien.szymanski(a)armadeus.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires(a)redhat.com>
Signed-off-by: Jiri Kosina <jkosina(a)suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/hid/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -230,7 +230,7 @@ config HID_CMEDIA
config HID_CP2112
tristate "Silicon Labs CP2112 HID USB-to-SMBus Bridge support"
- depends on USB_HID && I2C && GPIOLIB
+ depends on USB_HID && HIDRAW && I2C && GPIOLIB
select GPIOLIB_IRQCHIP
---help---
Support for Silicon Labs CP2112 HID USB to SMBus Master Bridge.
Patches currently in stable-queue which might be from sebastien.szymanski(a)armadeus.com are
queue-4.13/hid-cp2112-add-hidraw-dependency.patch
The patch below does not apply to the 4.13-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable(a)vger.kernel.org>.
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
>From cd6bf7741cf992306748db11e1888c741d16dd0f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= <ville.syrjala(a)linux.intel.com>
Date: Mon, 18 Sep 2017 23:00:59 +0300
Subject: [PATCH] platform/x86: fujitsu-laptop: Don't oops when FUJ02E3 is not
presnt
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
My Fujitsu-Siemens Lifebook S6120 doesn't have the FUJ02E3 device,
but it does have FUJ02B1. That means we do register the backlight
device (and it even seems to work), but the code will oops as soon
as we try to set the backlight brightness because it's trying to
call call_fext_func() with a NULL device. Let's just skip those
function calls when the FUJ02E3 device is not present.
Cc: Jonathan Woithe <jwoithe(a)just42.net>
Cc: Andy Shevchenko <andy(a)infradead.org>
Signed-off-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com>
Cc: <stable(a)vger.kernel.org> # 4.13.x
Signed-off-by: Darren Hart (VMware) <dvhart(a)infradead.org>
diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/fujitsu-laptop.c
index 85de30f93a9c..56a8195096a2 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -254,10 +254,12 @@ static int bl_update_status(struct backlight_device *b)
{
struct acpi_device *device = bl_get_data(b);
- if (b->props.power == FB_BLANK_POWERDOWN)
- call_fext_func(fext, FUNC_BACKLIGHT, 0x1, 0x4, 0x3);
- else
- call_fext_func(fext, FUNC_BACKLIGHT, 0x1, 0x4, 0x0);
+ if (fext) {
+ if (b->props.power == FB_BLANK_POWERDOWN)
+ call_fext_func(fext, FUNC_BACKLIGHT, 0x1, 0x4, 0x3);
+ else
+ call_fext_func(fext, FUNC_BACKLIGHT, 0x1, 0x4, 0x0);
+ }
return set_lcd_level(device, b->props.brightness);
}
This is a note to let you know that I've just added the patch titled
x86/MCE/AMD: Always give panic severity for UC errors in kernel context
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
x86-mce-amd-always-give-panic-severity-for-uc-errors-in-kernel-context.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From d65dfc81bb3894fdb68cbc74bbf5fb48d2354071 Mon Sep 17 00:00:00 2001
From: Yazen Ghannam <yazen.ghannam(a)amd.com>
Date: Mon, 6 Nov 2017 18:46:32 +0100
Subject: x86/MCE/AMD: Always give panic severity for UC errors in kernel context
From: Yazen Ghannam <yazen.ghannam(a)amd.com>
commit d65dfc81bb3894fdb68cbc74bbf5fb48d2354071 upstream.
The AMD severity grading function was introduced in kernel 4.1. The
current logic can possibly give MCE_AR_SEVERITY for uncorrectable
errors in kernel context. The system may then get stuck in a loop as
memory_failure() will try to handle the bad kernel memory and find it
busy.
Return MCE_PANIC_SEVERITY for all UC errors IN_KERNEL context on AMD
systems.
After:
b2f9d678e28c ("x86/mce: Check for faults tagged in EXTABLE_CLASS_FAULT exception table entries")
was accepted in v4.6, this issue was masked because of the tail-end attempt
at kernel mode recovery in the #MC handler.
However, uncorrectable errors IN_KERNEL context should always be considered
unrecoverable and cause a panic.
Signed-off-by: Yazen Ghannam <yazen.ghannam(a)amd.com>
Signed-off-by: Borislav Petkov <bp(a)suse.de>
Cc: Linus Torvalds <torvalds(a)linux-foundation.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Thomas Gleixner <tglx(a)linutronix.de>
Cc: Tony Luck <tony.luck(a)intel.com>
Cc: linux-edac <linux-edac(a)vger.kernel.org>
Fixes: bf80bbd7dcf5 (x86/mce: Add an AMD severities-grading function)
Link: http://lkml.kernel.org/r/20171106174633.13576-1-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
arch/x86/kernel/cpu/mcheck/mce-severity.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
--- a/arch/x86/kernel/cpu/mcheck/mce-severity.c
+++ b/arch/x86/kernel/cpu/mcheck/mce-severity.c
@@ -245,6 +245,9 @@ static int mce_severity_amd(struct mce *
if (m->status & MCI_STATUS_UC) {
+ if (ctx == IN_KERNEL)
+ return MCE_PANIC_SEVERITY;
+
/*
* On older systems where overflow_recov flag is not present, we
* should simply panic if an error overflow occurs. If
@@ -255,10 +258,6 @@ static int mce_severity_amd(struct mce *
if (mce_flags.smca)
return mce_severity_amd_smca(m, ctx);
- /* software can try to contain */
- if (!(m->mcgstatus & MCG_STATUS_RIPV) && (ctx == IN_KERNEL))
- return MCE_PANIC_SEVERITY;
-
/* kill current process */
return MCE_AR_SEVERITY;
} else {
Patches currently in stable-queue which might be from yazen.ghannam(a)amd.com are
queue-4.9/x86-mce-amd-always-give-panic-severity-for-uc-errors-in-kernel-context.patch
This is a note to let you know that I've just added the patch titled
USB: usbfs: compute urb->actual_length for isochronous
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-usbfs-compute-urb-actual_length-for-isochronous.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 2ef47001b3ee3ded579b7532ebdcf8680e4d8c54 Mon Sep 17 00:00:00 2001
From: Alan Stern <stern(a)rowland.harvard.edu>
Date: Wed, 8 Nov 2017 12:23:17 -0500
Subject: USB: usbfs: compute urb->actual_length for isochronous
From: Alan Stern <stern(a)rowland.harvard.edu>
commit 2ef47001b3ee3ded579b7532ebdcf8680e4d8c54 upstream.
The USB kerneldoc says that the actual_length field "is read in
non-iso completion functions", but the usbfs driver uses it for all
URB types in processcompl(). Since not all of the host controller
drivers set actual_length for isochronous URBs, programs using usbfs
with some host controllers don't work properly. For example, Minas
reports that a USB camera controlled by libusb doesn't work properly
with a dwc2 controller.
It doesn't seem worthwhile to change the HCDs and the documentation,
since the in-kernel USB class drivers evidently don't rely on
actual_length for isochronous transfers. The easiest solution is for
usbfs to calculate the actual_length value for itself, by adding up
the lengths of the individual packets in an isochronous transfer.
Signed-off-by: Alan Stern <stern(a)rowland.harvard.edu>
CC: Minas Harutyunyan <Minas.Harutyunyan(a)synopsys.com>
Reported-and-tested-by: wlf <wulf(a)rock-chips.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/devio.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
--- a/drivers/usb/core/devio.c
+++ b/drivers/usb/core/devio.c
@@ -1838,6 +1838,18 @@ static int proc_unlinkurb(struct usb_dev
return 0;
}
+static void compute_isochronous_actual_length(struct urb *urb)
+{
+ unsigned int i;
+
+ if (urb->number_of_packets > 0) {
+ urb->actual_length = 0;
+ for (i = 0; i < urb->number_of_packets; i++)
+ urb->actual_length +=
+ urb->iso_frame_desc[i].actual_length;
+ }
+}
+
static int processcompl(struct async *as, void __user * __user *arg)
{
struct urb *urb = as->urb;
@@ -1845,6 +1857,7 @@ static int processcompl(struct async *as
void __user *addr = as->userurb;
unsigned int i;
+ compute_isochronous_actual_length(urb);
if (as->userbuffer && urb->actual_length) {
if (copy_urb_data_to_user(as->userbuffer, urb))
goto err_out;
@@ -2019,6 +2032,7 @@ static int processcompl_compat(struct as
void __user *addr = as->userurb;
unsigned int i;
+ compute_isochronous_actual_length(urb);
if (as->userbuffer && urb->actual_length) {
if (copy_urb_data_to_user(as->userbuffer, urb))
return -EFAULT;
Patches currently in stable-queue which might be from stern(a)rowland.harvard.edu are
queue-4.9/usb-usbfs-compute-urb-actual_length-for-isochronous.patch
This is a note to let you know that I've just added the patch titled
USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-serial-qcserial-add-pid-vid-for-sierra-wireless-em7355-fw-update.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 771394a54148f18926ca86414e51c69eda27d0cd Mon Sep 17 00:00:00 2001
From: Douglas Fischer <douglas.fischer(a)outlook.com>
Date: Sun, 29 Oct 2017 23:29:55 +0000
Subject: USB: serial: qcserial: add pid/vid for Sierra Wireless EM7355 fw update
From: Douglas Fischer <douglas.fischer(a)outlook.com>
commit 771394a54148f18926ca86414e51c69eda27d0cd upstream.
Add USB PID/VID for Sierra Wireless EM7355 LTE modem QDL firmware update
mode.
Signed-off-by: Douglas Fischer <douglas.fischer(a)outlook.com>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/serial/qcserial.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/serial/qcserial.c
+++ b/drivers/usb/serial/qcserial.c
@@ -148,6 +148,7 @@ static const struct usb_device_id id_tab
{DEVICE_SWI(0x1199, 0x68a2)}, /* Sierra Wireless MC7710 */
{DEVICE_SWI(0x1199, 0x68c0)}, /* Sierra Wireless MC7304/MC7354 */
{DEVICE_SWI(0x1199, 0x901c)}, /* Sierra Wireless EM7700 */
+ {DEVICE_SWI(0x1199, 0x901e)}, /* Sierra Wireless EM7355 QDL */
{DEVICE_SWI(0x1199, 0x901f)}, /* Sierra Wireless EM7355 */
{DEVICE_SWI(0x1199, 0x9040)}, /* Sierra Wireless Modem */
{DEVICE_SWI(0x1199, 0x9041)}, /* Sierra Wireless MC7305/MC7355 */
Patches currently in stable-queue which might be from douglas.fischer(a)outlook.com are
queue-4.9/usb-serial-qcserial-add-pid-vid-for-sierra-wireless-em7355-fw-update.patch
This is a note to let you know that I've just added the patch titled
USB: serial: garmin_gps: fix memory leak on probe errors
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-serial-garmin_gps-fix-memory-leak-on-probe-errors.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 74d471b598444b7f2d964930f7234779c80960a0 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Wed, 11 Oct 2017 14:02:58 +0200
Subject: USB: serial: garmin_gps: fix memory leak on probe errors
From: Johan Hovold <johan(a)kernel.org>
commit 74d471b598444b7f2d964930f7234779c80960a0 upstream.
Make sure to free the port private data before returning after a failed
probe attempt.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/serial/garmin_gps.c | 6 ++++++
1 file changed, 6 insertions(+)
--- a/drivers/usb/serial/garmin_gps.c
+++ b/drivers/usb/serial/garmin_gps.c
@@ -1413,6 +1413,12 @@ static int garmin_port_probe(struct usb_
usb_set_serial_port_data(port, garmin_data_p);
status = garmin_init_session(port);
+ if (status)
+ goto err_free;
+
+ return 0;
+err_free:
+ kfree(garmin_data_p);
return status;
}
Patches currently in stable-queue which might be from johan(a)kernel.org are
queue-4.9/usb-serial-qcserial-add-pid-vid-for-sierra-wireless-em7355-fw-update.patch
queue-4.9/staging-greybus-add-host-device-function-pointer-checks.patch
queue-4.9/usb-serial-garmin_gps-fix-i-o-after-failed-probe-and-remove.patch
queue-4.9/usb-serial-garmin_gps-fix-memory-leak-on-probe-errors.patch
This is a note to let you know that I've just added the patch titled
USB: serial: garmin_gps: fix I/O after failed probe and remove
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-serial-garmin_gps-fix-i-o-after-failed-probe-and-remove.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 19a565d9af6e0d828bd0d521d3bafd5017f4ce52 Mon Sep 17 00:00:00 2001
From: Johan Hovold <johan(a)kernel.org>
Date: Wed, 11 Oct 2017 14:02:57 +0200
Subject: USB: serial: garmin_gps: fix I/O after failed probe and remove
From: Johan Hovold <johan(a)kernel.org>
commit 19a565d9af6e0d828bd0d521d3bafd5017f4ce52 upstream.
Make sure to stop any submitted interrupt and bulk-out URBs before
returning after failed probe and when the port is being unbound to avoid
later NULL-pointer dereferences in the completion callbacks.
Also fix up the related and broken I/O cancellation on failed open and
on close. (Note that port->write_urb was never submitted.)
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Reviewed-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Johan Hovold <johan(a)kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/serial/garmin_gps.c | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
--- a/drivers/usb/serial/garmin_gps.c
+++ b/drivers/usb/serial/garmin_gps.c
@@ -138,6 +138,7 @@ struct garmin_data {
__u8 privpkt[4*6];
spinlock_t lock;
struct list_head pktlist;
+ struct usb_anchor write_urbs;
};
@@ -905,7 +906,7 @@ static int garmin_init_session(struct us
sizeof(GARMIN_START_SESSION_REQ), 0);
if (status < 0)
- break;
+ goto err_kill_urbs;
}
if (status > 0)
@@ -913,6 +914,12 @@ static int garmin_init_session(struct us
}
return status;
+
+err_kill_urbs:
+ usb_kill_anchored_urbs(&garmin_data_p->write_urbs);
+ usb_kill_urb(port->interrupt_in_urb);
+
+ return status;
}
@@ -930,7 +937,6 @@ static int garmin_open(struct tty_struct
spin_unlock_irqrestore(&garmin_data_p->lock, flags);
/* shutdown any bulk reads that might be going on */
- usb_kill_urb(port->write_urb);
usb_kill_urb(port->read_urb);
if (garmin_data_p->state == STATE_RESET)
@@ -953,7 +959,7 @@ static void garmin_close(struct usb_seri
/* shutdown our urbs */
usb_kill_urb(port->read_urb);
- usb_kill_urb(port->write_urb);
+ usb_kill_anchored_urbs(&garmin_data_p->write_urbs);
/* keep reset state so we know that we must start a new session */
if (garmin_data_p->state != STATE_RESET)
@@ -1037,12 +1043,14 @@ static int garmin_write_bulk(struct usb_
}
/* send it down the pipe */
+ usb_anchor_urb(urb, &garmin_data_p->write_urbs);
status = usb_submit_urb(urb, GFP_ATOMIC);
if (status) {
dev_err(&port->dev,
"%s - usb_submit_urb(write bulk) failed with status = %d\n",
__func__, status);
count = status;
+ usb_unanchor_urb(urb);
kfree(buffer);
}
@@ -1401,6 +1409,7 @@ static int garmin_port_probe(struct usb_
garmin_data_p->state = 0;
garmin_data_p->flags = 0;
garmin_data_p->count = 0;
+ init_usb_anchor(&garmin_data_p->write_urbs);
usb_set_serial_port_data(port, garmin_data_p);
status = garmin_init_session(port);
@@ -1413,6 +1422,7 @@ static int garmin_port_remove(struct usb
{
struct garmin_data *garmin_data_p = usb_get_serial_port_data(port);
+ usb_kill_anchored_urbs(&garmin_data_p->write_urbs);
usb_kill_urb(port->interrupt_in_urb);
del_timer_sync(&garmin_data_p->timer);
kfree(garmin_data_p);
Patches currently in stable-queue which might be from johan(a)kernel.org are
queue-4.9/usb-serial-qcserial-add-pid-vid-for-sierra-wireless-em7355-fw-update.patch
queue-4.9/staging-greybus-add-host-device-function-pointer-checks.patch
queue-4.9/usb-serial-garmin_gps-fix-i-o-after-failed-probe-and-remove.patch
queue-4.9/usb-serial-garmin_gps-fix-memory-leak-on-probe-errors.patch
This is a note to let you know that I've just added the patch titled
usb: gadget: f_fs: Fix use-after-free in ffs_free_inst
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-gadget-f_fs-fix-use-after-free-in-ffs_free_inst.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From cdafb6d8b8da7fde266f79b3287ac221aa841879 Mon Sep 17 00:00:00 2001
From: Andrew Gabbasov <andrew_gabbasov(a)mentor.com>
Date: Wed, 8 Nov 2017 10:13:15 -0700
Subject: usb: gadget: f_fs: Fix use-after-free in ffs_free_inst
From: Andrew Gabbasov <andrew_gabbasov(a)mentor.com>
commit cdafb6d8b8da7fde266f79b3287ac221aa841879 upstream.
KASAN enabled configuration reports an error
BUG: KASAN: use-after-free in ffs_free_inst+... [usb_f_fs] at addr ...
Write of size 8 by task ...
This is observed after "ffs-test" is run and interrupted. If after that
functionfs is unmounted and g_ffs module is unloaded, that use-after-free
occurs during g_ffs module removal.
Although the report indicates ffs_free_inst() function, the actual
use-after-free condition occurs in _ffs_free_dev() function, which
is probably inlined into ffs_free_inst().
This happens due to keeping the ffs_data reference in device structure
during functionfs unmounting, while ffs_data itself is freed as no longer
needed. The fix is to clear that reference in ffs_closed() function,
which is a counterpart of ffs_ready(), where the reference is stored.
Fixes: 3262ad824307 ("usb: gadget: f_fs: Stop ffs_closed NULL pointer dereference")
Signed-off-by: Andrew Gabbasov <andrew_gabbasov(a)mentor.com>
Acked-by: Felipe Balbi <felipe.balbi(a)linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/gadget/function/f_fs.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -3698,6 +3698,7 @@ static void ffs_closed(struct ffs_data *
goto done;
ffs_obj->desc_ready = false;
+ ffs_obj->ffs_data = NULL;
if (test_and_clear_bit(FFS_FL_CALL_CLOSED_CALLBACK, &ffs->flags) &&
ffs_obj->ffs_closed_callback)
Patches currently in stable-queue which might be from andrew_gabbasov(a)mentor.com are
queue-4.9/usb-gadget-f_fs-fix-use-after-free-in-ffs_free_inst.patch
This is a note to let you know that I've just added the patch titled
USB: Add delay-init quirk for Corsair K70 LUX keyboards
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
usb-add-delay-init-quirk-for-corsair-k70-lux-keyboards.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From a0fea6027f19c62727315aba1a7fae75a9caa842 Mon Sep 17 00:00:00 2001
From: Bernhard Rosenkraenzer <bernhard.rosenkranzer(a)linaro.org>
Date: Fri, 3 Nov 2017 16:46:02 +0100
Subject: USB: Add delay-init quirk for Corsair K70 LUX keyboards
From: Bernhard Rosenkraenzer <bernhard.rosenkranzer(a)linaro.org>
commit a0fea6027f19c62727315aba1a7fae75a9caa842 upstream.
Without this patch, K70 LUX keyboards don't work, saying
usb 3-3: unable to read config index 0 descriptor/all
usb 3-3: can't read configurations, error -110
usb usb3-port3: unable to enumerate USB device
Signed-off-by: Bernhard Rosenkraenzer <Bernhard.Rosenkranzer(a)linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
drivers/usb/core/quirks.c | 3 +++
1 file changed, 3 insertions(+)
--- a/drivers/usb/core/quirks.c
+++ b/drivers/usb/core/quirks.c
@@ -221,6 +221,9 @@ static const struct usb_device_id usb_qu
/* Corsair Strafe RGB */
{ USB_DEVICE(0x1b1c, 0x1b20), .driver_info = USB_QUIRK_DELAY_INIT },
+ /* Corsair K70 LUX */
+ { USB_DEVICE(0x1b1c, 0x1b36), .driver_info = USB_QUIRK_DELAY_INIT },
+
/* MIDI keyboard WORLDE MINI */
{ USB_DEVICE(0x1c75, 0x0204), .driver_info =
USB_QUIRK_CONFIG_INTF_STRINGS },
Patches currently in stable-queue which might be from bernhard.rosenkranzer(a)linaro.org are
queue-4.9/usb-add-delay-init-quirk-for-corsair-k70-lux-keyboards.patch
This is a note to let you know that I've just added the patch titled
crypto: dh - Don't permit 'p' to be 0
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum…
The filename of the patch is:
crypto-dh-don-t-permit-p-to-be-0.patch
and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable(a)vger.kernel.org> know about it.
>From 199512b1234f09e44d592153ec82b44212b2f0c4 Mon Sep 17 00:00:00 2001
From: Eric Biggers <ebiggers(a)google.com>
Date: Sun, 5 Nov 2017 18:30:45 -0800
Subject: crypto: dh - Don't permit 'p' to be 0
From: Eric Biggers <ebiggers(a)google.com>
commit 199512b1234f09e44d592153ec82b44212b2f0c4 upstream.
If 'p' is 0 for the software Diffie-Hellman implementation, then
dh_max_size() returns 0. In the case of KEYCTL_DH_COMPUTE, this causes
ZERO_SIZE_PTR to be passed to sg_init_one(), which with
CONFIG_DEBUG_SG=y triggers the 'BUG_ON(!virt_addr_valid(buf));' in
sg_set_buf().
Fix this by making crypto_dh_decode_key() reject 0 for 'p'. p=0 makes
no sense for any DH implementation because 'p' is supposed to be a prime
number. Moreover, 'mod 0' is not mathematically defined.
Bug report:
kernel BUG at ./include/linux/scatterlist.h:140!
invalid opcode: 0000 [#1] SMP KASAN
CPU: 0 PID: 27112 Comm: syz-executor2 Not tainted 4.14.0-rc7-00010-gf5dbb5d0ce32-dirty #7
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.3-20171021_125229-anatol 04/01/2014
task: ffff88006caac0c0 task.stack: ffff88006c7c8000
RIP: 0010:sg_set_buf include/linux/scatterlist.h:140 [inline]
RIP: 0010:sg_init_one+0x1b3/0x240 lib/scatterlist.c:156
RSP: 0018:ffff88006c7cfb08 EFLAGS: 00010216
RAX: 0000000000010000 RBX: ffff88006c7cfe30 RCX: 00000000000064ee
RDX: ffffffff81cf64c3 RSI: ffffc90000d72000 RDI: ffffffff92e937e0
RBP: ffff88006c7cfb30 R08: ffffed000d8f9fab R09: ffff88006c7cfd30
R10: 0000000000000005 R11: ffffed000d8f9faa R12: ffff88006c7cfd30
R13: 0000000000000000 R14: 0000000000000010 R15: ffff88006c7cfc50
FS: 00007fce190fa700(0000) GS:ffff88003ea00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fffc6b33db8 CR3: 000000003cf64000 CR4: 00000000000006f0
Call Trace:
__keyctl_dh_compute+0xa95/0x19b0 security/keys/dh.c:360
keyctl_dh_compute+0xac/0x100 security/keys/dh.c:434
SYSC_keyctl security/keys/keyctl.c:1745 [inline]
SyS_keyctl+0x72/0x2c0 security/keys/keyctl.c:1641
entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x4585c9
RSP: 002b:00007fce190f9bd8 EFLAGS: 00000216 ORIG_RAX: 00000000000000fa
RAX: ffffffffffffffda RBX: 0000000000738020 RCX: 00000000004585c9
RDX: 000000002000d000 RSI: 0000000020000ff4 RDI: 0000000000000017
RBP: 0000000000000046 R08: 0000000020008000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000216 R12: 00007fff6e610cde
R13: 00007fff6e610cdf R14: 00007fce190fa700 R15: 0000000000000000
Code: 03 0f b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 04 84 d2 75 33 5b 45 89 6c 24 14 41 5c 41 5d 41 5e 41 5f 5d c3 e8 fd 8f 68 ff <0f> 0b e8 f6 8f 68 ff 0f 0b e8 ef 8f 68 ff 0f 0b e8 e8 8f 68 ff 20
RIP: sg_set_buf include/linux/scatterlist.h:140 [inline] RSP: ffff88006c7cfb08
RIP: sg_init_one+0x1b3/0x240 lib/scatterlist.c:156 RSP: ffff88006c7cfb08
Fixes: 802c7f1c84e4 ("crypto: dh - Add DH software implementation")
Reviewed-by: Tudor Ambarus <tudor.ambarus(a)microchip.com>
Signed-off-by: Eric Biggers <ebiggers(a)google.com>
Signed-off-by: Herbert Xu <herbert(a)gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org>
---
crypto/dh_helper.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/crypto/dh_helper.c
+++ b/crypto/dh_helper.c
@@ -90,6 +90,14 @@ int crypto_dh_decode_key(const char *buf
params->p = (void *)(ptr + params->key_size);
params->g = (void *)(ptr + params->key_size + params->p_size);
+ /*
+ * Don't permit 'p' to be 0. It's not a prime number, and it's subject
+ * to corner cases such as 'mod 0' being undefined or
+ * crypto_kpp_maxsize() returning 0.
+ */
+ if (memchr_inv(params->p, 0, params->p_size) == NULL)
+ return -EINVAL;
+
return 0;
}
EXPORT_SYMBOL_GPL(crypto_dh_decode_key);
Patches currently in stable-queue which might be from ebiggers(a)google.com are
queue-4.9/crypto-dh-don-t-permit-key-or-g-size-longer-than-p.patch
queue-4.9/arm-crypto-reduce-priority-of-bit-sliced-aes-cipher.patch
queue-4.9/crypto-dh-don-t-permit-p-to-be-0.patch