- 14 Jan, 2020 33 commits
-
-
Sudip Mukherjee authored
commit fb2b9001 upstream. There seems to be a race condition in tty drivers and I could see on many boot cycles a NULL pointer dereference as tty_init_dev() tries to do 'tty->port->itty = tty' even though tty->port is NULL. 'tty->port' will be set by the driver and if the driver has not yet done it before we open the tty device we can get to this situation. By adding some extra debug prints, I noticed that: 6.650130: uart_add_one_port 6.663849: register_console 6.664846: tty_open 6.674391: tty_init_dev 6.675456: tty_port_link_device uart_add_one_port() registers the console, as soon as it registers, the userspace tries to use it and that leads to tty_open() but uart_add_one_port() has not yet done tty_port_link_device() and so tty->port is not yet configured when control reaches tty_init_dev(). Further look into the code and tty_port_link_device() is done by uart_add_one_port(). After registering the console uart_add_one_port() will call tty_port_register_device_attr_serdev() and tty_port_link_device() is called from this. Call add tty_port_link_device() before uart_configure_port() is done and add a check in tty_port_link_device() so that it only links the port if it has not been done yet. Suggested-by:
Jiri Slaby <jslaby@suse.com> Signed-off-by:
Sudip Mukherjee <sudipm.mukherjee@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191212131602.29504-1-sudipm.mukherjee@gmail.comSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Punit Agrawal authored
commit c5ee0b31 upstream. Serdev sub-system claims all ACPI serial devices that are not already initialised. As a result, no device node is created for serial ports on certain boards such as the Apollo Lake based UP2. This has the unintended consequence of not being able to raise the login prompt via serial connection. Introduce a blacklist to reject ACPI serial devices that should not be claimed by serdev sub-system. Add the peripheral ids for Intel HS UART to the blacklist to bring back serial port on SoCs carrying them. Cc: stable@vger.kernel.org Signed-off-by:
Punit Agrawal <punit1.agrawal@toshiba.co.jp> Acked-by:
Hans de Goede <hdegoede@redhat.com> Acked-by:
Johan Hovold <johan@kernel.org> Cc: Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20191219100345.911093-1-punit1.agrawal@toshiba.co.jpSigned-off-by:
-
Michael Straube authored
commit 58dcc5bf upstream. This device was added to the stand-alone driver on github. Add it to the staging driver as well. Link: https://github.com/lwfinger/rtl8188eu/commit/b9b537aa25a8Signed-off-by:
Michael Straube <straube.linux@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191228143725.24455-1-straube.linux@gmail.comSigned-off-by:
-
Ian Abbott authored
commit a9d3a9ce upstream. The Advantech PCI-1713 has 32 analog input channels, but an incorrect bit-mask in the definition of the `PCI171X_MUX_CHANH(x)` and PCI171X_MUX_CHANL(x)` macros is causing channels 16 to 31 to be aliases of channels 0 to 15. Change the bit-mask value from 0xf to 0xff to fix it. Note that the channel numbers will have been range checked already, so the bit-mask isn't really needed. Fixes: 92c65e55 ("staging: comedi: adv_pci1710: define the mux control register bits") Reported-by:
Dmytro Fil <monkdaf@gmail.com> Cc: <stable@vger.kernel.org> # v4.5+ Signed-off-by:
Ian Abbott <abbotti@mev.co.uk> Link: https://lore.kernel.org/r/20191227170054.32051-1-abbotti@mev.co.ukSigned-off-by:
-
Paul Cercueil authored
commit c80d0f44 upstream. The IRQ handler was passed a pointer to a struct dma_controller, but the argument was then casted to a pointer to a struct musb_dma_controller. Fixes: 427c4f33 ("usb: struct device - replace bus_id with dev_name(), dev_set_name()") Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Tested-by:
Artur Rojek <contact@artur-rojek.eu> Cc: stable@vger.kernel.org Signed-off-by:
Bin Liu <b-liu@ti.com> Link: https://lore.kernel.org/r/20191216161844.772-2-b-liu@ti.comSigned-off-by:
-
Paul Cercueil authored
commit 96a0c128 upstream. The pullup may be already enabled before the driver is initialized. This happens for instance on JZ4740. It has to be disabled at init time, as we cannot guarantee that a gadget driver will be bound to the UDC. Signed-off-by:
-
Tony Lindgren authored
commit 5fbf7a25 upstream. When disconnected as USB B-device, suspend interrupt should come before diconnect interrupt, because the DP/DM pins are shorter than the VBUS/GND pins on the USB connectors. But we sometimes get a suspend interrupt after disconnect interrupt. In that case we have devctl set to 99 with VBUS still valid and musb_pm_runtime_check_session() wrongly thinks we have an active session. We have no other interrupts after disconnect coming in this case at least with the omap2430 glue. Let's fix the issue by checking the interrupt status again with delayed work for the devctl 99 case. In the suspend after disconnect case the devctl session bit has cleared by then and musb can idle. For a typical USB B-device connect case we just continue with normal interrupts. Fixes: 467d5c98 ("usb: musb: Implement session bit based runtime PM for musb-core") Cc: Merlijn Wajer <merlijn@wizzup.org> Cc: Pavel Machek <pavel@ucw.cz> Cc: Sebastian Reichel <sre@kernel.org> Cc: stable@vger.kernel.org Signed-off-by:
Tony Lindgren <tony@atomide.com> Signed-off-by:
-
Daniele Palmas authored
commit 2438c3a1 upstream. Telit FN980 flashing device 0x1bc7/0x9010 requires zero packet to be sent if out data size is is equal to the endpoint max size. Signed-off-by:
Daniele Palmas <dnlplm@gmail.com> [ johan: switch operands in conditional ] Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Malcolm Priestley authored
commit c0bcf9f3 upstream. intfdata will contain stale pointer when the device is detached after failed initialization when referenced in vt6656_disconnect Provide driver access to it here and NULL it. Cc: stable <stable@vger.kernel.org> Signed-off-by:
Malcolm Priestley <tvboxspy@gmail.com> Link: https://lore.kernel.org/r/6de448d7-d833-ef2e-dd7b-3ef9992fee0e@gmail.comSigned-off-by:
-
Hans de Goede authored
commit aa23ca3d upstream. On some laptops enabling wakeup on the GPIO interrupts used for ACPI _AEI event handling causes spurious wakeups. This commit adds a new honor_wakeup option, defaulting to true (our current behavior), which can be used to disable wakeup on troublesome hardware to avoid these spurious wakeups. This is a workaround for an architectural problem with s2idle under Linux where we do not have any mechanism to immediately go back to sleep after wakeup events, other then for embedded-controller events using the standard ACPI EC interface, for details see: https://lore.kernel.org/linux-acpi/61450f9b-cbc6-0c09-8b3a-aff6bf9a0b3c@redhat.com/ One series of laptops which is not able to suspend without this workaround is the HP x2 10 Cherry Trail models, this commit adds a DMI based quirk which makes sets honor_wakeup to false on these models. Cc: stable@vger.kernel.org Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by:
Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Hans de Goede authored
commit 1ad1b540 upstream. Turn the existing run_edge_events_on_boot_blacklist dmi_system_id table into a generic quirk table, storing the quirks in the driver_data ptr. This is a preparation patch for adding other types of (DMI based) quirks. Cc: stable@vger.kernel.org Reviewed-by:
-
Oliver Hartkopp authored
commit e7153bf7 upstream. KMSAN sysbot detected a read access to an untinitialized value in the headroom of an outgoing CAN related sk_buff. When using CAN sockets this area is filled appropriately - but when using a packet socket this initialization is missing. The problematic read access occurs in the CAN receive path which can only be triggered when the sk_buff is sent through a (virtual) CAN interface. So we check in the sending path whether we need to perform the missing initializations. Fixes: d3b58c47 ("can: replace timestamp as unique skb attribute") Reported-by: syzbot+b02ff0707a97e4e79ebb@syzkaller.appspotmail.com Signed-off-by:
Oliver Hartkopp <socketcan@hartkopp.net> Tested-by:
Marc Kleine-Budde <mkl@pengutronix.de> Signed-off-by:
-
Florian Faber authored
commit 2d77bd61 upstream. Under load, the RX side of the mscan driver can get stuck while TX still works. Restarting the interface locks up the system. This behaviour could be reproduced reliably on a MPC5121e based system. The patch fixes the return value of the NAPI polling function (should be the number of processed packets, not constant 1) and the condition under which IRQs are enabled again after polling is finished. With this patch, no more lockups were observed over a test period of ten days. Fixes: afa17a50 ("net/can: add driver for mscan family & mpc52xx_mscan") Signed-off-by:
Florian Faber <faber@faberman.de> Cc: linux-stable <stable@vger.kernel.org> Signed-off-by:
-
Johan Hovold authored
commit 2f361cd9 upstream. Make sure to always use the descriptors of the current alternate setting to avoid future issues when accessing fields that may differ between settings. Signed-off-by:
-
Johan Hovold authored
commit 5660493c upstream. Make sure to use the current alternate setting when verifying the interface descriptors to avoid binding to an invalid interface. Failing to do so could cause the driver to misbehave or trigger a WARN() in usb_submit_urb() that kernels with panic_on_warn set would choke on. Fixes: aec5fb22 ("can: kvaser_usb: Add support for Kvaser USB hydra family") Cc: stable <stable@vger.kernel.org> # 4.19 Cc: Jimmy Assarsson <extja@kvaser.com> Cc: Christer Beskow <chbe@kvaser.com> Cc: Nicklas Johansson <extnj@kvaser.com> Cc: Martin Henriksson <mh@kvaser.com> Signed-off-by:
-
Wayne Lin authored
commit c4e4fccc upstream. [Why] According to DP spec, it should shift left 4 digits for NO_STOP_BIT in REMOTE_I2C_READ message. Not 5 digits. In current code, NO_STOP_BIT is always set to zero which means I2C master is always generating a I2C stop at the end of each I2C write transaction while handling REMOTE_I2C_READ sideband message. This issue might have the generated I2C signal not meeting the requirement. Take random read in I2C for instance, I2C master should generate a repeat start to start to read data after writing the read address. This issue will cause the I2C master to generate a stop-start rather than a re-start which is not expected in I2C random read. [How] Correct the shifting value of NO_STOP_BIT for DP_REMOTE_I2C_READ case in drm_dp_encode_sideband_req(). Changes since v1:(https://patchwork.kernel.org/patch/11312667/) * Add more descriptions in commit and cc to stable Fixes: ad7f8a1f ("drm/helper: add Displayport multi-stream helper (v0.6)") Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Wayne Lin <Wayne.Lin@amd.com> Cc: stable@vger.kernel.org Signed-off-by:
Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200103055001.10287-1-Wayne.Lin@amd.comSigned-off-by:
-
Geert Uytterhoeven authored
commit f30e2777 upstream. When userspace requests a video mode parameter value that is not supported, frame buffer device drivers should round it up to a supported value, if possible, instead of just rejecting it. This allows applications to quickly scan for supported video modes. Currently this rule is not followed for the number of bits per pixel, causing e.g. "fbset -depth N" to fail, if N is smaller than the current number of bits per pixel. Fix this by returning an error only if bits per pixel is too large, and setting it to the current value otherwise. See also Documentation/fb/framebuffer.rst, Section 2 (Programmer's View of /dev/fb*"). Fixes: 865afb11 ("drm/fb-helper: reject any changes to the fbdev") Cc: stable@vger.kernel.org Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20191230132734.4538-1-geert+renesas@glider.beSigned-off-by:
-
Chen-Yu Tsai authored
commit 4396393f upstream. In commit 0b8e7bbd ("drm/sun4i: tcon: Set min division of TCON0_DCLK to 1.") it was assumed that all TCON variants support a minimum divider of 1 if only DCLK was used. However, the oldest generation of hardware only supports minimum divider of 4 if only DCLK is used. If a divider of 1 was used on this old hardware, some scrolling artifact would appear. A divider of 2 seemed OK, but a divider of 3 had artifacts as well. Set the minimum divider when outputing to parallel RGB based on the hardware model, with a minimum of 4 for the oldest (A10/A10s/A13/A20) hardware, and a minimum of 1 for the rest. A value is not set for the TCON variants lacking channel 0. This fixes the scrolling artifacts seen on my A13 tablet. Fixes: 0b8e7bbd ("drm/sun4i: tcon: Set min division of TCON0_DCLK to 1.") Cc: <stable@vger.kernel.org> # 5.4.x Signed-off-by:
Chen-Yu Tsai <wens@csie.org> Signed-off-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20200107070113.28951-1-wens@kernel.orgSigned-off-by:
-
Arnd Bergmann authored
commit f729a1b0 upstream. Going through all uses of timeval, I noticed that we screwed up input_event in the previous attempts to fix it: The time fields now match between kernel and user space, but all following fields are in the wrong place. Add the required padding that is implied by the glibc timeval definition to fix the layout, and use a struct initializer to avoid leaking kernel stack data. Fixes: 141e5dca ("Input: input_event - fix the CONFIG_SPARC64 mixup") Fixes: 2e746942 ("Input: input_event - provide override for sparc64") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Link: https://lore.kernel.org/r/20191213204936.3643476-2-arnd@arndb.de Cc: stable@vger.kernel.org Signed-off-by:
Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by:
-
Dmitry Torokhov authored
commit cb222aed upstream. If we happen to have a garbage in input device's keycode table with values too big we'll end up doing clear_bit() with offset way outside of our bitmaps, damaging other objects within an input device or even outside of it. Let's add sanity checks to the returned old keycodes. Reported-by: syzbot+c769968809f9359b07aa@syzkaller.appspotmail.com Reported-by: syzbot+76f3a30e88d256644c78@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20191207212757.GA245964@dtor-wsSigned-off-by:
-
Dmitry Torokhov authored
commit 4f388217 upstream. We should not be leaving half-mapped usages with potentially invalid keycodes, as that may confuse hidinput_find_key() when the key is located by index, which may end up feeding way too large keycode into the VT keyboard handler and cause OOB write there: BUG: KASAN: global-out-of-bounds in clear_bit include/asm-generic/bitops-instrumented.h:56 [inline] BUG: KASAN: global-out-of-bounds in kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline] BUG: KASAN: global-out-of-bounds in kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495 Write of size 8 at addr ffffffff89a1b2d8 by task syz-executor108/1722 ... kbd_keycode drivers/tty/vt/keyboard.c:1411 [inline] kbd_event+0xe6b/0x3790 drivers/tty/vt/keyboard.c:1495 input_to_handler+0x3b6/0x4c0 drivers/input/input.c:118 input_pass_values.part.0+0x2e3/0x720 drivers/input/input.c:145 input_pass_values drivers/input/input.c:949 [inline] input_set_keycode+0x290/0x320 drivers/input/input.c:954 evdev_handle_set_keycode_v2+0xc4/0x120 drivers/input/evdev.c:882 evdev_do_ioctl drivers/input/evdev.c:1150 [inline] Cc: stable@vger.kernel.org Reported-by: syzbot+19340dff067c2d3835c0@syzkaller.appspotmail.com Signed-off-by:
Benjamin Tissoires <benjamin.tissoires@redhat.com> Signed-off-by:
Jiri Kosina <jkosina@suse.cz> Signed-off-by:
-
Marcel Holtmann authored
commit be54e746 upstream. Always return EPOLLOUT from uhid_char_poll to allow polling /dev/uhid for writable state. Fixes: 1f9dec1e ("HID: uhid: allow poll()'ing on uhid devices") Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Cc: stable@vger.kernel.org Signed-off-by:
-
Alan Stern authored
commit 8ec321e9 upstream. The syzbot fuzzer found a slab-out-of-bounds bug in the HID report handler. The bug was caused by a report descriptor which included a field with size 12 bits and count 4899, for a total size of 7349 bytes. The usbhid driver uses at most a single-page 4-KB buffer for reports. In the test there wasn't any problem about overflowing the buffer, since only one byte was received from the device. Rather, the bug occurred when the HID core tried to extract the data from the report fields, which caused it to try reading data beyond the end of the allocated buffer. This patch fixes the problem by rejecting any report whose total length exceeds the HID_MAX_BUFFER_SIZE limit (minus one byte to allow for a possible report index). In theory a device could have a report longer than that, but if there was such a thing we wouldn't handle it correctly anyway. Reported-and-tested-by: syzbot+09ef48aa58261464b621@syzkaller.appspotmail.com Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> CC: <stable@vger.kernel.org> Signed-off-by:
-
Joel Fernandes (Google) authored
commit bf44f488 upstream. Discussion in the below link reported that symbols in modules can appear to be before _stext on ARM architecture, causing wrapping with the offsets of this tracepoint. Change the offset type to s32 to fix this. Link: http://lore.kernel.org/r/20191127154428.191095-1-antonio.borneo@st.com Link: http://lkml.kernel.org/r/20200102194625.226436-1-joel@joelfernandes.org Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: David Sterba <dsterba@suse.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Antonio Borneo <antonio.borneo@st.com> Cc: stable@vger.kernel.org Fixes: d5915816 ("tracing: Add support for preempt and irq enable/disable events") Signed-off-by:
Joel Fernandes (Google) <joel@joelfernandes.org> Signed-off-by:
Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by:
-
Steven Rostedt (VMware) authored
commit b8299d36 upstream. On some archs with some configurations, MCOUNT_INSN_SIZE is not defined, and this makes the stack tracer fail to compile. Just define it to zero in this case. Link: https://lore.kernel.org/r/202001020219.zvE3vsty%lkp@intel.com Cc: stable@vger.kernel.org Fixes: 4df29712 ("tracing: Remove most or all of stack tracer stack size from stack_max_size") Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
-
Kaitao Cheng authored
commit 50f9ad60 upstream. In the function, if register_trace_sched_migrate_task() returns error, sched_switch/sched_wakeup_new/sched_wakeup won't unregister. That is why fail_deprobe_sched_switch was added. Link: http://lkml.kernel.org/r/20191231133530.2794-1-pilgrimtao@gmail.com Cc: stable@vger.kernel.org Fixes: 478142c3 ("tracing: do not grab lock in wakeup latency function tracing") Signed-off-by:
Kaitao Cheng <pilgrimtao@gmail.com> Signed-off-by:
-
Kailang Yang authored
commit 54a6a7dc upstream. Add quirk to ALC285_FIXUP_SPEAKER2_TO_DAC1, which is the same fixup applied for X1 Carbon 7th gen in commit d2cd795c ("ALSA: hda - fixup for the bass speaker on Lenovo Carbon X1 7th gen"). Signed-off-by:
Kailang Yang <kailang@realtek.com> Reviewed-by:
Jaroslav Kysela <perex@perex.cz> Cc: <stable@vger.kernel.org> Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Kailang Yang authored
commit 9194a1eb upstream. Set EAPD control to verb control. Signed-off-by:
-
Kailang Yang authored
commit 6d9ffcff upstream. Add ALCS1200A supported. It was similar as ALC900. Signed-off-by:
-
Takashi Iwai authored
commit 51d4efab upstream. Bose Companion 5 (with USB ID 05a7:1020) doesn't seem supporting reading back the sample rate, so the existing quirk is needed. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206063 Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200104110936.14288-1-tiwai@suse.deSigned-off-by:
-
Guenter Roeck authored
commit c1ffba30 upstream. On shutdown, ehci_power_off() is called unconditionally to power off each port, even if it was never called to power on the port. For chipidea, this results in a call to ehci_ci_portpower() with a request to power off ports even if the port was never powered on. This results in the following warning from the regulator code. WARNING: CPU: 0 PID: 182 at drivers/regulator/core.c:2596 _regulator_disable+0x1a8/0x210 unbalanced disables for usb_otg2_vbus Modules linked in: CPU: 0 PID: 182 Comm: init Not tainted 5.4.6 #1 Hardware name: Freescale i.MX7 Dual (Device Tree) [<c0313658>] (unwind_backtrace) from [<c030d698>] (show_stack+0x10/0x14) [<c030d698>] (show_stack) from [<c1133afc>] (dump_stack+0xe0/0x10c) [<c1133afc>] (dump_stack) from [<c0349098>] (__warn+0xf4/0x10c) [<c0349098>] (__warn) from [<c0349128>] (warn_slowpath_fmt+0x78/0xbc) [<c0349128>] (warn_slowpath_fmt) from [<c09f36ac>] (_regulator_disable+0x1a8/0x210) [<c09f36ac>] (_regulator_disable) from [<c09f374c>] (regulator_disable+0x38/0xe8) [<c09f374c>] (regulator_disable) from [<c0df7bac>] (ehci_ci_portpower+0x38/0xdc) [<c0df7bac>] (ehci_ci_portpower) from [<c0db4fa4>] (ehci_port_power+0x50/0xa4) [<c0db4fa4>] (ehci_port_power) from [<c0db5420>] (ehci_silence_controller+0x5c/0xc4) [<c0db5420>] (ehci_silence_controller) from [<c0db7644>] (ehci_stop+0x3c/0xcc) [<c0db7644>] (ehci_stop) from [<c0d5bdc4>] (usb_remove_hcd+0xe0/0x19c) [<c0d5bdc4>] (usb_remove_hcd) from [<c0df7638>] (host_stop+0x38/0xa8) [<c0df7638>] (host_stop) from [<c0df2f34>] (ci_hdrc_remove+0x44/0xe4) ... Keeping track of the power enable state avoids the warning and traceback. Fixes: c8679a2f ("usb: chipidea: host: add portpower override") Cc: Michael Grzeschik <m.grzeschik@pengutronix.de> Cc: Peter Chen <peter.chen@freescale.com> Cc: stable@vger.kernel.org Signed-off-by:
Guenter Roeck <linux@roeck-us.net> Acked-by:
Peter Chen <peter.chen@nxp.com> Link: https://lore.kernel.org/r/20191226155754.25451-1-linux@roeck-us.netSigned-off-by:
-
Russell King authored
commit cf8ce8b8 upstream. The I2C specification states that tsu:sto for standard mode timing must be at minimum 4us. Pictographically, this is: SCL: ____/~~~~~~~~~ SDA: _________/~~~~ ->| |<- 4us minimum We are currently waiting 2.5us between asserting SCL and SDA, which is in violation of the standard. Adjust the timings to ensure that we meet what is stipulated as the minimum timings to ensure that all devices correctly interpret the STOP bus transition. This is more important than trying to generate a square wave with even duty cycle. Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
Wolfram Sang <wsa@the-dreams.de> Signed-off-by:
-
Will Deacon authored
commit 68faa679 upstream. 'chrdev_open()' calls 'cdev_get()' to obtain a reference to the 'struct cdev *' stashed in the 'i_cdev' field of the target inode structure. If the pointer is NULL, then it is initialised lazily by looking up the kobject in the 'cdev_map' and so the whole procedure is protected by the 'cdev_lock' spinlock to serialise initialisation of the shared pointer. Unfortunately, it is possible for the initialising thread to fail *after* installing the new pointer, for example if the subsequent '->open()' call on the file fails. In this case, 'cdev_put()' is called, the reference count on the kobject is dropped and, if nobody else has taken a reference, the release function is called which finally clears 'inode->i_cdev' from 'cdev_purge()' before potentially freeing the object. The problem here is that a racing thread can happily take the 'cdev_lock' and see the non-NULL pointer in the inode, which can result in a refcount increment from zero and a warning: | ------------[ cut here ]------------ | refcount_t: addition on 0; use-after-free. | WARNING: CPU: 2 PID: 6385 at lib/refcount.c:25 refcount_warn_saturate+0x6d/0xf0 | Modules linked in: | CPU: 2 PID: 6385 Comm: repro Not tainted 5.5.0-rc2+ #22 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 | RIP: 0010:refcount_warn_saturate+0x6d/0xf0 | Code: 05 55 9a 15 01 01 e8 9d aa c8 ff 0f 0b c3 80 3d 45 9a 15 01 00 75 ce 48 c7 c7 00 9c 62 b3 c6 08 | RSP: 0018:ffffb524c1b9bc70 EFLAGS: 00010282 | RAX: 0000000000000000 RBX: ffff9e9da1f71390 RCX: 0000000000000000 | RDX: ffff9e9dbbd27618 RSI: ffff9e9dbbd18798 RDI: ffff9e9dbbd18798 | RBP: 0000000000000000 R08: 000000000000095f R09: 0000000000000039 | R10: 0000000000000000 R11: ffffb524c1b9bb20 R12: ffff9e9da1e8c700 | R13: ffffffffb25ee8b0 R14: 0000000000000000 R15: ffff9e9da1e8c700 | FS: 00007f3b87d26700(0000) GS:ffff9e9dbbd00000(0000) knlGS:0000000000000000 | CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 | CR2: 00007fc16909c000 CR3: 000000012df9c000 CR4: 00000000000006e0 | DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 | DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 | Call Trace: | kobject_get+0x5c/0x60 | cdev_get+0x2b/0x60 | chrdev_open+0x55/0x220 | ? cdev_put.part.3+0x20/0x20 | do_dentry_open+0x13a/0x390 | path_openat+0x2c8/0x1470 | do_filp_open+0x93/0x100 | ? selinux_file_ioctl+0x17f/0x220 | do_sys_open+0x186/0x220 | do_syscall_64+0x48/0x150 | entry_SYSCALL_64_after_hwframe+0x44/0xa9 | RIP: 0033:0x7f3b87efcd0e | Code: 89 54 24 08 e8 a3 f4 ff ff 8b 74 24 0c 48 8b 3c 24 41 89 c0 44 8b 54 24 08 b8 01 01 00 00 89 f4 | RSP: 002b:00007f3b87d259f0 EFLAGS: 00000293 ORIG_RAX: 0000000000000101 | RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f3b87efcd0e | RDX: 0000000000000000 RSI: 00007f3b87d25a80 RDI: 00000000ffffff9c | RBP: 00007f3b87d25e90 R08: 0000000000000000 R09: 0000000000000000 | R10: 0000000000000000 R11: 0000000000000293 R12: 00007ffe188f504e | R13: 00007ffe188f504f R14: 00007f3b87d26700 R15: 0000000000000000 | ---[ end trace 24f53ca58db8180a ]--- Since 'cdev_get()' can already fail to obtain a reference, simply move it over to use 'kobject_get_unless_zero()' instead of 'kobject_get()', which will cause the racing thread to return -ENXIO if the initialising thread fails unexpectedly. Cc: Hillf Danton <hdanton@sina.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Reported-by: syzbot+82defefbbd8527e1c2cb@syzkaller.appspotmail.com Signed-off-by:
Will Deacon <will@kernel.org> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20191219120203.32691-1-will@kernel.orgSigned-off-by:
-
- 12 Jan, 2020 7 commits
-
-
Greg Kroah-Hartman authored
-
Qi Zhou authored
commit 1530f6f5 upstream. According to bd0e6c96 ("usb: hub: try old enumeration scheme first for high speed devices") the kernel will try the old enumeration scheme first for high speed devices. This can happen when a high speed device is plugged in. But due to missing parentheses in the USE_NEW_SCHEME define, this logic can get messed up and the incorrect result happens. Acked-by:
Qi Zhou <atmgnd@outlook.com> Link: https://lore.kernel.org/r/ht4mtag8ZP-HKEhD0KkJhcFnVlOFV8N8eNjJVRD9pDkkLUNhmEo8_cL_sl7xy9mdajdH-T8J3TFQsjvoYQT61NFjQXy469Ed_BbBw_x4S1E=@protonmail.com [ fixup changelog text - gregkh] Cc: stable <stable@vger.kernel.org> Fixes: bd0e6c96 ("usb: hub: try old enumeration scheme first for high speed devices") Signed-off-by:
-
Daniele Palmas authored
commit 0d3010fa upstream. This patch adds the following Telit ME910G1 composition: 0x110a: tty, tty, tty, rmnet Signed-off-by:
-
Johan Hovold authored
commit 3e4f8e21 upstream. Amend the endpoint-descriptor sanity checks to detect all duplicate endpoint addresses in a configuration. Commit 0a8fd134 ("USB: fix problems with duplicate endpoint addresses") added a check for duplicate endpoint addresses within a single alternate setting, but did not look for duplicate addresses in other interfaces. The current check would also not detect all duplicate addresses when one endpoint is as a (bi-directional) control endpoint. This specifically avoids overwriting the endpoint entries in struct usb_device when enabling a duplicate endpoint, something which could potentially lead to crashes or leaks, for example, when endpoints are later disabled. Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Thinh Nguyen authored
commit ea0d7627 upstream. We can only check for IN direction if the request had completed. For OUT direction, it's perfectly fine that the host can send less than the setup length. Let's return true fall all cases of OUT direction. Fixes: e0c42ce5 ("usb: dwc3: gadget: simplify IOC handling") Cc: stable@vger.kernel.org Signed-off-by:
Thinh Nguyen <thinhn@synopsys.com> Link: https://lore.kernel.org/r/ac5a3593a94fdaa3d92e6352356b5f7a01ccdc7c.1576291140.git.thinhn@synopsys.comSigned-off-by:
-
Petr Machata authored
[ Upstream commit 240ce7f6 ] When a child Qdisc is removed from one of the PRIO Qdisc's bands, it is replaced unconditionally by a NOOP qdisc. As a result, any traffic hitting that band gets dropped. That is incorrect--no Qdisc was explicitly added when PRIO was created, and after removal, none should have to be added either. Fix PRIO by first attempting to create a default Qdisc and only falling back to noop when that fails. This pattern of attempting to create an invisible FIFO, using NOOP only as a fallback, is also seen in other Qdiscs. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Petr Machata <petrm@mellanox.com> Acked-by:
Jiri Pirko <jiri@mellanox.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Petr Machata authored
[ Upstream commit 3971a535 ] The following patch will change PRIO to replace a removed Qdisc with an invisible FIFO, instead of NOOP. mlxsw will see this replacement due to the graft message that is generated. But because FIFO does not issue its own REPLACE message, when the graft operation takes place, the Qdisc that mlxsw tracks under the indicated band is still the old one. The child handle (0:0) therefore does not match, and mlxsw rejects the graft operation, which leads to an extack message: Warning: Offloading graft operation failed. Fix by ignoring the invisible children in the PRIO graft handler. The DESTROY message of the removed Qdisc is going to follow shortly and handle the removal. Fixes: 32dc5efc ("mlxsw: spectrum: qdiscs: prio: Handle graft command") Signed-off-by:
-
