- 25 Mar, 2020 40 commits
-
-
Johan Hovold authored
commit 8f3675be upstream. A scripted conversion from userland POLL* to kernel EPOLL* constants mistakingly replaced the poll flags in the loopback_test tool, which therefore no longer builds. Fixes: a9a08845 ("vfs: do bulk POLL* -> EPOLL* replacement") Cc: stable <stable@vger.kernel.org> # 4.16 Signed-off-by:
Johan Hovold <johan@kernel.org> Link: https://lore.kernel.org/r/20200312110151.22028-2-johan@kernel.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Michael Straube authored
commit bb5786b9 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/2141f244c3e7 Signed-off-by:
Michael Straube <straube.linux@gmail.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200312093652.13918-1-straube.linux@gmail.com Signed-off-by:
-
Nathan Chancellor authored
commit 82f2bc2f upstream. Clang's -Wpointer-to-int-cast deviates from GCC in that it warns when casting to enums. The kernel does this in certain places, such as device tree matches to set the version of the device being used, which allows the kernel to avoid using a gigantic union. https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L428 https://elixir.bootlin.com/linux/v5.5.8/source/drivers/ata/ahci_brcm.c#L402 https://elixir.bootlin.com/linux/v5.5.8/source/include/linux/mod_devicetable.h#L264 To avoid a ton of false positive warnings, disable this particular part of the warning, which has been split off into a separate diagnostic so that the entire warning does not need to be turned off for clang. It will be visible under W=1 in case people want to go about fixing these easily and enabling the warning treewide. Cc: stable@vger.kernel.org Link: https://github.com/ClangBuiltLinux/linux/issues/887 Link: https://github.com/llvm/llvm-project/commit/2a41b31fcdfcb67ab7038fc2ffb606fd50b83a84 Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
-
Murphy Zhou authored
commit 979a2665 upstream. If we call fiemap on a truncated file with none blocks allocated, it makes sense we get nothing from this call. No output means no blocks have been counted, but the call succeeded. It's a valid response. Simple example reproducer: xfs_io -f 'truncate 2M' -c 'fiemap -v' /cifssch/testfile xfs_io: ioctl(FS_IOC_FIEMAP) ["/cifssch/testfile"]: Invalid argument Signed-off-by:
Murphy Zhou <jencce.kernel@gmail.com> Signed-off-by:
Steve French <stfrench@microsoft.com> Reviewed-by:
Pavel Shilovsky <pshilov@microsoft.com> CC: Stable <stable@vger.kernel.org> Signed-off-by:
-
Masahiro Yamada authored
commit 18b587b4 upstream. The SDHCI_PRESET_FOR_* registers are not set for the UniPhier platform integration. (They are all read as zeros). Set the SDHCI_QUIRK2_PRESET_VALUE_BROKEN quirk flag. Otherwise, the High Speed DDR mode on the eMMC controller (MMC_TIMING_MMC_DDR52) would not work. I split the platform data to give no impact to other platforms, although the UniPhier platform is currently only the upstream user of this IP. The SDHCI_QUIRK2_PRESET_VALUE_BROKEN flag is set if the compatible string matches to "socionext,uniphier-sd4hc". Signed-off-by:
Masahiro Yamada <yamada.masahiro@socionext.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200312104257.21017-1-yamada.masahiro@socionext.com Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Michał Mirosław authored
commit 53dd0a7c upstream. SAMA5D2x doesn't drive CMD line if GPIO is used as CD line (at least SAMA5D27 doesn't). Fix this by forcing card-detect in the module if module-controlled CD is not used. Fixed commit addresses the problem only for non-removable cards. This amends it to also cover gpio-cd case. Cc: stable@vger.kernel.org Fixes: 7a1e3f14 ("mmc: sdhci-of-at91: force card detect value for non removable devices") Signed-off-by:
Michał Mirosław <mirq-linux@rere.qmqm.pl> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Link: https://lore.kernel.org/r/8d10950d9940468577daef4772b82a071b204716.1584290561.git.mirq-linux@rere.qmqm.pl Signed-off-by:
-
Ricky Wu authored
commit 4686392c upstream. The TX/RX register should not be treated the same way to allow for better support of tuning. Fix this by using a default initial value for TX. Signed-off-by:
Ricky Wu <ricky_wu@realtek.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200316025232.1167-1-ricky_wu@realtek.com [Ulf: Updated changelog] Signed-off-by:
-
Tomas Novotny authored
commit 2ca5a879 upstream. Vishay has published a new version of "Designing the VCNL4200 Into an Application" application note in October 2019. The new version specifies that there is +-20% of part to part tolerance. Although the application note is related to vcnl4200, according to support the vcnl4040's "ASIC is quite similar to that one for the VCNL4200". So update the sampling periods (and comment), including the correct sampling period for proximity. Both sampling periods are lower. Users relying on the blocking behaviour of reading will get proximity measurements much earlier. Fixes: 5a441aad ("iio: light: vcnl4000 add support for the VCNL4040 proximity and light sensor") Reviewed-by:
Guido Günther <agx@sigxcpu.org> Tested-by:
Tomas Novotny <tomas@novotny.cz> Cc: <Stable@vger.kernel.org> Signed-off-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Signed-off-by:
-
Tomas Novotny authored
commit b42aa97e upstream. Vishay has published a new version of "Designing the VCNL4200 Into an Application" application note in October 2019. The new version specifies that there is +-20% of part to part tolerance. This explains the drift seen during experiments. The proximity pulse width is also changed from 32us to 30us. According to the support, the tolerance also applies to ambient light. So update the sampling periods. As the reading is blocking, current users may notice slightly longer response time. Fixes: be38866f ("iio: vcnl4000: add support for VCNL4200") Reviewed-by:
-
Eugen Hristev authored
commit a500f3bd upstream. The differential channels require writing the channel offset register (COR). Otherwise they do not work in differential mode. The configuration of COR is missing in triggered mode. Fixes: 5e1a1da0 ("iio: adc: at91-sama5d2_adc: add hw trigger and buffer support") Signed-off-by:
Eugen Hristev <eugen.hristev@microchip.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Olivier Moysan authored
commit e19ac9d9 upstream. This commit fixes the error message: "BUG: sleeping function called from invalid context at kernel/irq/chip.c" Suppress the trigger irq handler. Make the buffer transfers directly in DMA callback, instead. Push buffers without timestamps, as timestamps are not supported in DFSDM driver. Fixes: 11646e81 ("iio: adc: stm32-dfsdm: add support for buffer modes") Signed-off-by:
Olivier Moysan <olivier.moysan@st.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Stephan Gerhold authored
commit b500c086 upstream. At the moment, reading from in_magn_*_raw in sysfs tends to return large values around 65000, even though the output of ak8974 is actually limited to ±32768. This happens because the value is never converted to the signed 16-bit integer variant. Add an explicit cast to s16 to fix this. Fixes: 7c94a8b2 ("iio: magn: add a driver for AK8974") Signed-off-by:
Stephan Gerhold <stephan@gerhold.net> Reviewed-by:
Linus Waleij <linus.walleij@linaro.org> Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Alexandru Tachici authored
commit cb2116ff upstream. Data stored in the iio-buffer is BE and this should be specified in the iio_chan_spec struct. Fixes: f4f55ce3 ("iio:adxl372: Add FIFO and interrupts support") Signed-off-by:
Alexandru Tachici <alexandru.tachici@analog.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Fabrice Gasnier authored
commit 29e8c825 upstream. Master mode should be disabled when stopping. This mainly impacts possible other use-case after timer has been stopped. Currently, master mode remains set (from start routine). Fixes: 6fb34812 ("iio: stm32 trigger: Add support for TRGO2 triggers") Signed-off-by:
Fabrice Gasnier <fabrice.gasnier@st.com> Cc: <Stable@vger.kernel.org> Signed-off-by:
-
Wen-chien Jesse Sung authored
commit e43d110c upstream. According to ST, the HID is for LIS2DH12. Fixes: 3d56e198 ("iio: accel: st_accel: Add support for the SMO8840 ACPI id") Signed-off-by:
Wen-chien Jesse Sung <jesse.sung@canonical.com> Tested-by:
Hans de Goede <hdegoede@redhat.com> Reviewed-by:
-
Petr Štetiar authored
commit 016a8845 upstream. SPS30 uses triggered buffer, but the dependency is not specified in the Kconfig file. Fix this by selecting IIO_BUFFER and IIO_TRIGGERED_BUFFER config symbols. Cc: stable@vger.kernel.org Fixes: 232e0f6d ("iio: chemical: add support for Sensirion SPS30 sensor") Signed-off-by:
Petr Štetiar <ynezz@true.cz> Signed-off-by:
-
Eric Biggers authored
commit 6e622cd8 upstream. Commit 77654350 ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()") changed the compat version of TIOCGSERIAL to start checking for the presence of the ->set_serial function pointer rather than ->get_serial. This appears to be a copy-and-paste error, since ->get_serial is the function pointer that is called as well as the pointer that is checked by the non-compat version of TIOCGSERIAL. Fix this by checking the correct function pointer. Fixes: 77654350 ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by:
Eric Biggers <ebiggers@google.com> Acked-by:
Jiri Slaby <jslaby@suse.cz> Link: https://lore.kernel.org/r/20200224182044.234553-3-ebiggers@kernel.org Signed-off-by:
-
Eric Biggers authored
commit 17329563 upstream. Commit 77654350 ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()") changed the compat version of TIOCGSERIAL to start copying a whole 'serial_struct32' to userspace rather than individual fields, but failed to initialize all padding and fields -- namely the hole after the 'iomem_reg_shift' field, and the 'reserved' field. Fix this by initializing the struct to zero. [v2: use sizeof, and convert the adjacent line for consistency.] Reported-by: syzbot+8da9175e28eadcb203ce@syzkaller.appspotmail.com Fixes: 77654350 ("take compat TIOC[SG]SERIAL treatment into tty_compat_ioctl()") Cc: <stable@vger.kernel.org> # v4.20+ Signed-off-by:
-
Takashi Iwai authored
commit 5461e053 upstream. The return value checks in snd_pcm_plug_alloc() are covered with snd_BUG_ON() macro that may trigger a kernel WARNING depending on the kconfig. But since the error condition can be triggered by a weird user space parameter passed to OSS layer, we shouldn't give the kernel stack trace just for that. As it's a normal error condition, let's remove snd_BUG_ON() macro usage there. Reported-by: syzbot+2a59ee7a9831b264f45e@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200312155730.7520-1-tiwai@suse.de Signed-off-by:
Takashi Iwai <tiwai@suse.de> Signed-off-by:
-
Takashi Iwai authored
commit f2ecf903 upstream. Each OSS PCM plugins allocate its internal buffer per pre-calculation of the max buffer size through the chain of plugins (calling src_frames and dst_frames callbacks). This works for most plugins, but the rate plugin might behave incorrectly. The calculation in the rate plugin involves with the fractional position, i.e. it may vary depending on the input position. Since the buffer size pre-calculation is always done with the offset zero, it may return a shorter size than it might be; this may result in the out-of-bound access as spotted by fuzzer. This patch addresses those possible buffer overflow accesses by simply setting the upper limit per the given buffer size for each plugin before src_frames() and after dst_frames() calls. Reported-by: syzbot+e1fe9f44fb8ecf4fb5dd@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/000000000000b25ea005a02bcf21@google.com Link: https://lore.kernel.org/r/20200309082148.19855-1-tiwai@suse.de Signed-off-by:
-
Takashi Iwai authored
commit 6c3171ef upstream. This is a similar bug like the previous case for virmidi: the invalid running status is kept after receiving a sysex message. Again the fix is to clear the running status after handling the sysex. Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/3b4a4e0f232b7afbaf0a843f63d0e538e3029bfd.camel@domdv.de Link: https://lore.kernel.org/r/20200316090506.23966-3-tiwai@suse.de Signed-off-by:
-
Takashi Iwai authored
commit 4384f167 upstream. The virmidi driver handles sysex event exceptionally in a short-cut snd_seq_dump_var_event() call, but this missed the reset of the running status. As a result, it may lead to an incomplete command right after the sysex when an event with the same running status was queued. Fix it by clearing the running status properly via alling snd_midi_event_reset_decode() for that code path. Reported-by:
Andreas Steinmetz <ast@domdv.de> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/3b4a4e0f232b7afbaf0a843f63d0e538e3029bfd.camel@domdv.de Link: https://lore.kernel.org/r/20200316090506.23966-2-tiwai@suse.de Signed-off-by:
-
Jian-Hong Pan authored
commit a124458a upstream. A headset on the desktop like Acer N50-600 does not work, until quirk ALC662_FIXUP_ACER_NITRO_HEADSET_MODE is applied. Signed-off-by:
Jian-Hong Pan <jian-hong@endlessm.com> Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200317082806.73194-3-jian-hong@endlessm.com Signed-off-by:
-
Jian-Hong Pan authored
commit d858c706 upstream. The Acer desktop X2660G with ALC662 can't detect the headset microphone until ALC662_FIXUP_ACER_X2660G_HEADSET_MODE quirk applied. Signed-off-by:
-
Takashi Iwai authored
commit d683469b upstream. The MIDI input event parser of the LINE6 driver may enter into an endless loop when the unexpected data sequence is given, as it tries to continue the secondary bytes without termination. Also, when the input data is too short, the parser returns a negative error, while the caller doesn't handle it properly. This would lead to the unexpected behavior as well. This patch addresses those issues by checking the return value correctly and handling the one-byte event in the parser properly. The bug was reported by syzkaller. Reported-by: syzbot+cce32521ee0a824c21f7@syzkaller.appspotmail.com Cc: <stable@vger.kernel.org> Link: https://lore.kernel.org/r/000000000000033087059f8f8fa3@google.com Link: https://lore.kernel.org/r/20200309095922.30269-1-tiwai@suse.de Signed-off-by:
-
Anthony Mallet authored
commit b401f8c4 upstream. By default, tty_port_init() initializes those parameters to a multiple of HZ. For instance in line 69 of tty_port.c: port->close_delay = (50 * HZ) / 100; https://github.com/torvalds/linux/blob/master/drivers/tty/tty_port.c#L69 With e.g. CONFIG_HZ = 250 (as this is the case for Ubuntu 18.04 linux-image-4.15.0-37-generic), the default setting for close_delay is thus 125. When ioctl(fd, TIOCGSERIAL, &s) is executed, the setting returned in user space is '12' (125/10). When ioctl(fd, TIOCSSERIAL, &s) is then executed with the same setting '12', the value is interpreted as '120' which is different from the current setting and a EPERM error may be raised by set_serial_info() if !CAP_SYS_ADMIN. https://github.com/torvalds/linux/blob/master/drivers/usb/class/cdc-acm.c#L919 Fixes: ba2d8ce9 ("cdc-acm: implement TIOCSSERIAL to avoid blocking close(2)") Signed-off-by:
Anthony Mallet <anthony.mallet@laas.fr> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200312133101.7096-2-anthony.mallet@laas.fr Signed-off-by:
-
Anthony Mallet authored
commit 633e2b2d upstream. close_delay and closing_wait are specified in hundredth of a second but stored internally in jiffies. Use the jiffies_to_msecs() and msecs_to_jiffies() functions to convert from each other. Signed-off-by:
-
Heikki Krogerus authored
commit 081da132 upstream. Locking the connector in ucsi_register_displayport() to make sure that nothing can access the displayport alternate mode before the function has finished and the alternate mode is actually ready. Fixes: af8622f6 ("usb: typec: ucsi: Support for DisplayPort alt mode") Cc: stable@vger.kernel.org Signed-off-by:
Heikki Krogerus <heikki.krogerus@linux.intel.com> Link: https://lore.kernel.org/r/20200311130006.41288-3-heikki.krogerus@linux.intel.com Signed-off-by:
-
Heikki Krogerus authored
commit d16e7b62 upstream. If the registration of the DisplayPort was not successful, or if the port does not support DisplayPort alt mode in the first place, the function ucsi_displayport_remove_partner() will fail with NULL pointer dereference when it attempts to access the driver data. Adding a check to the function to make sure there really is driver data for the device before modifying it. Fixes: af8622f6 ("usb: typec: ucsi: Support for DisplayPort alt mode") Reported-by:
Andrea Gagliardi La Gala <andrea.lagala@gmail.com> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206365 Cc: stable@vger.kernel.org Signed-off-by:
-
Alberto Mattea authored
commit 16263abc upstream. This controller timeouts during suspend (S3) with [ 240.521724] xhci_hcd 0000:30:00.3: WARN: xHC save state timeout [ 240.521729] xhci_hcd 0000:30:00.3: ERROR mismatched command completion event thus preventing the system from entering S3. Moreover it remains in an undefined state where some connected devices stop working until a reboot. Apply the XHCI_SUSPEND_DELAY quirk to make it suspend properly. CC: stable@vger.kernel.org Signed-off-by:
Alberto Mattea <alberto@mattea.info> Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20200306150858.21904-3-mathias.nyman@linux.intel.com Signed-off-by:
-
Scott Chen authored
commit cecc113c upstream. Add a device id for HP LD381 Display LD381: 03f0:0f7f Signed-off-by:
Scott Chen <scott@labau.com.tw> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Ran Wang authored
commit b433e340 upstream. When loading new kernel via kexec, we need to shutdown host controller to avoid any un-expected memory accessing during new kernel boot. Signed-off-by:
Ran Wang <ran.wang_1@nxp.com> Cc: stable <stable@vger.kernel.org> Tested-by:
Stephen Boyd <swboyd@chromium.org> Reviewed-by:
Peter Chen <peter.chen@nxp.com> Link: https://lore.kernel.org/r/20200306092328.41253-1-ran.wang_1@nxp.com Signed-off-by:
-
Daniele Palmas authored
commit 8e852a79 upstream. Add ME910G1 ECM composition 0x110b: tty, tty, tty, ecm Signed-off-by:
Daniele Palmas <dnlplm@gmail.com> Link: https://lore.kernel.org/r/20200304104310.2938-1-dnlplm@gmail.com Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Hans de Goede authored
commit 75d7676e upstream. We have been receiving bug reports that ethernet connections over RTL8153 based ethernet adapters stops working after a while with errors like these showing up in dmesg when the ethernet stops working: [12696.189484] r8152 6-1:1.0 enp10s0u1: Tx timeout [12702.333456] r8152 6-1:1.0 enp10s0u1: Tx timeout [12707.965422] r8152 6-1:1.0 enp10s0u1: Tx timeout This has been reported on Dell WD15 docks, Belkin USB-C Express Dock 3.1 docks and with generic USB to ethernet dongles using the RTL8153 chipsets. Some users have tried adding usbcore.quirks=0bda:8153:k to the kernel commandline and all users who have tried this report that this fixes this. Also note that we already have an existing NO_LPM quirk for the RTL8153 used in the Microsoft Surface Dock (where it uses a different usb-id). This commit adds a NO_LPM quirk for the generic Realtek RTL8153 0bda:8153 usb-id, fixing the Tx timeout errors on these devices. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=198931 Cc: stable@vger.kernel.org Cc: russianneuromancer@ya.ru Signed-off-by:
-
Kai-Heng Feng authored
commit b63e48fb upstream. Realtek Hub (0bda:0x0487) used in Dell Dock WD19 sometimes drops off the bus when bringing underlying ports from U3 to U0. Disabling LPM on the hub during setting link state is not enough, so let's disable LPM completely for this hub. Acked-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Kai-Heng Feng <kai.heng.feng@canonical.com> Cc: stable <stable@vger.kernel.org> Link: https://lore.kernel.org/r/20200205112633.25995-3-kai.heng.feng@canonical.com Signed-off-by:
-
Sasha Levin authored
[ Upstream commit f053c83a ] This reverts commit f25c7a00 ("drm/fbdev: Fallback to non tiled mode if all tiles not present"). The commit causes flip done timeouts in CI. Below are the sample errors thrown in logs: [IGT] core_getversion: executing [IGT] core_getversion: exiting, ret=0 Setting dangerous option reset - tainting kernel drm:drm_atomic_helper_wait_for_dependencies] ERROR [CRTC:152:pipe B] flip_done timed out drm:drm_atomic_helper_wait_for_dependencies] ERROR [CONNECTOR:299:DP-2] flip_done timed out drm:drm_atomic_helper_wait_for_dependencies] ERROR [PLANE:92:plane 1B] flip_done timed out [drm:drm_atomic_helper_wait_for_flip_done] ERROR [CRTC:152:pipe B] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] ERROR [CRTC:152:pipe B] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] ERROR [CONNECTOR:299:DP-2] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] ERROR [PLANE:92:plane 1B] flip_done timed out [drm:drm_atomic_helper_wait_for_flip_done] ERROR [CRTC:152:pipe B] flip_done timed out Console: switching to colour frame buffer device 480x135 [drm:drm_atomic_helper_wait_for_dependencies] ERROR [CRTC:152:pipe B] flip_done timed out [drm:drm_atomic_helper_wait_for_dependencies] ERROR [CONNECTOR:299:DP-2] flip_done timed out Reverting the change for now to unblock CI execution. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Uma Shankar <uma.shankar@intel.com> Fixes: f25c7a00 ("drm/fbdev: Fallback to non tiled mode if all tiles not present") Closes: https://gitlab.freedesktop.org/drm/intel/issues/6 Acked-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191123091840.32382-1-uma.shankar@intel.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Christian Brauner authored
[ Upstream commit 211b64e4 ] Binderfs binder-control devices are cleaned up via binderfs_evict_inode too() which will use refcount_dec_and_test(). However, we missed to set the refcount for binderfs binder-control devices and so we underflowed when the binderfs instance got unmounted. Pretty obvious oversight and should have been part of the more general UAF fix. The good news is that having test cases (suprisingly) helps. Technically, we could detect that we're about to cleanup the binder-control dentry in binderfs_evict_inode() and then simply clean it up. But that makes the assumption that the binder driver itself will never make use of a binderfs binder-control device after the binderfs instance it belongs to has been unmounted and the superblock for it been destroyed. While it is unlikely to ever come to this let's be on the safe side. Performance-wise this also really doesn't matter since the binder-control device is only every really when creating the binderfs filesystem or creating additional binder devices. Both operations are pretty rare. Fixes: f0fe2c0f ("binder: prevent UAF for binderfs devices II") Link: https://lore.kernel.org/r/CA+G9fYusdfg7PMfC9Xce-xLT7NiyKSbgojpK35GOm=Pf9jXXrA@mail.gmail.com Reported-by:
Naresh Kamboju <naresh.kamboju@linaro.org> Cc: stable@vger.kernel.org Signed-off-by:
Christian Brauner <christian.brauner@ubuntu.com> Acked-by:
Todd Kjos <tkjos@google.com> Link: https://lore.kernel.org/r/20200311105309.1742827-1-christian.brauner@ubuntu.com Signed-off-by:
-
Jonathan Neuschäfer authored
[ Upstream commit 611d61f9 ] This makes the script more convenient to run. Signed-off-by:
Jonathan Neuschäfer <j.neuschaefer@gmx.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
-
Carlo Nonato authored
[ Upstream commit 14afc593 ] The bfq_find_set_group() function takes as input a blkcg (which represents a cgroup) and retrieves the corresponding bfq_group, then it updates the bfq internal group hierarchy (see comments inside the function for why this is needed) and finally it returns the bfq_group. In the hierarchy update cycle, the pointer holding the correct bfq_group that has to be returned is mistakenly used to traverse the hierarchy bottom to top, meaning that in each iteration it gets overwritten with the parent of the current group. Since the update cycle stops at root's children (depth = 2), the overwrite becomes a problem only if the blkcg describes a cgroup at a hierarchy level deeper than that (depth > 2). In this case the root's child that happens to be also an ancestor of the correct bfq_group is returned. The main consequence is that processes contained in a cgroup at depth greater than 2 are wrongly placed in the group described above by BFQ. This commits fixes this problem by using a different bfq_group pointer in the update cycle in order to avoid the overwrite of the variable holding the original group reference. Reported-by:
Kwon Je Oh <kwonje.oh2@gmail.com> Signed-off-by:
Carlo Nonato <carlo.nonato95@gmail.com> Signed-off-by:
Paolo Valente <paolo.valente@linaro.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Dongli Zhang authored
[ Upstream commit 8130b9d5 ] This patch adds the barrier to guarantee that req->err is always updated before req->state. Otherwise, read_reply() would not return ERR_PTR(req->err) but req->body, when process_writes()->xb_write() is failed. Signed-off-by:
Dongli Zhang <dongli.zhang@oracle.com> Link: https://lore.kernel.org/r/20200303221423.21962-2-dongli.zhang@oracle.com Reviewed-by:
Julien Grall <jgrall@amazon.com> Signed-off-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Signed-off-by:
-
