- Aug 07, 2019
-
-
Dave Stevenson authored
The details over when and how a driver is to service the vblank events are sketchy, and the fkms driver was triggering a kernel warning every time the crtc was enabled or disabled. Copy the event handling as used by the vc4-kms driver slightly more closely, and we avoid the warnings. https://github.com/raspberrypi/linux/issues/3020 Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.org>
-
- Aug 06, 2019
-
-
popcornmix authored
-
- Aug 05, 2019
-
-
Phil Elwell authored
Some combinations of Pi 4Bs and Ethernet switches don't reliably get a DCHP-assigned IP address, leaving the unit with a self=assigned 169.254 address. Forcing renegotiation has been found to be an effective workaround, so add an automatic renegotiation after the link comes up for the first time; enable it with genet.force_reneg=y - by default it is disabled. See: https://github.com/raspberrypi/linux/issues/3108 Signed-off-by:
Phil Elwell <phil@raspberrypi.org>
-
Phil Elwell authored
The overlays for enabling the new BCM2711 I2C interfaces were lacking the means to configure the baud/clock rate. Also explictly set the default pins, rather than relying on the values in the base DTB. Signed-off-by:
Phil Elwell <phil@raspberrypi.org>
-
James Hughes authored
For generic ALSA, all you need is the bcm2835.h change, but have also added structures for IEC958 HDMI. Not sure how to test those.
-
Chen-Yu Tsai authored
Instead of filling in the struct v4l2_capability device_caps field, fill in the struct video_device device_caps field. That way the V4L2 core knows what the capabilities of the video device are. This is similar to a cleanup series by Hans Verkuil [1]. [1] https://www.spinics.net/lists/linux-media/msg153313.html Signed-off-by:
Chen-Yu Tsai <wens@csie.org>
-
Chen-Yu Tsai authored
The stateful decoder specification shows an optional step for retrieving the miminum number of capture buffers required for the decoder to proceed. While not a required parameter, having it makes some applications happy. bcm2835-codec is a little different from other decoder implementations in that there is an intermediate format conversion between the hardware and V4L2 buffers. The number of capture buffers required is therefore independent of the stream and DPB etc. There are plans to remove the conversion, but it requires a fair amount of rework within the firmware. Until that is done, simply return a value of 1. Signed-off-by:
Chen-Yu Tsai <wens@csie.org>
-
Chen-Yu Tsai authored
There are two APIs for mem2mem devices, the older single-planar API and the newer multi-planar one. Without making things overly complex, the driver can only support one or the other. However the userspace libv4l2 library has a plugin that allows multi-planar API devices to service single-planar consumers. Chromium supports the multi-planar API exclusively, though this is currently limited to ChromiumOS. It would be possible to add support for generic Linux. Switching to the multi-planar API would allow usage of both APIs from userspace. Signed-off-by:
Chen-Yu Tsai <wens@csie.org>
-
Dave Stevenson authored
To allow for console rotation under DRM (where the firmware can't lie about geometry), add FRAMEBUFFER_CONSOLE_ROTATION so that the kernel can do it. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Dave Stevenson authored
Taken from the dri-devel mailing list (11/7/2019) to fixup the cmdline parsing, but requires changes as things have moved between 4.19 and 5.2. From: Dmitry Osipenko <digetx@gmail.com> The rotation mode from cmdline shouldn't be taken into account if it wasn't specified in the cmdline. This fixes ignored default display orientation when display mode is given using cmdline without the rotation being specified. Fixes: 1bf4e092 ("drm/modes: Allow to specify rotation and reflection on the commandline") Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Dave Stevenson authored
Now that the TV margins are properly parsed and filled into drm_cmdline_mode, we just need to initialise the first state at reset to get those values and start using them. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.org>
-
Maxime Ripard authored
Now that the TV margins are properly parsed and filled into drm_cmdline_mode, we just need to initialise the first state at reset to get those values and start using them. Acked-by:
Eric Anholt <eric@anholt.net> Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/44e24172e300be6a41578517021ef6a6e90ed682.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
Commit 731514b4 upstream. Reworked as functions have been moved from drm_atomic_helper.[c|h] to drm_atomic_state_helper.[c|h]. During the connector reset, if that connector has a TV property, it needs to be reset to the value provided on the command line. Provide a helper to do that. Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/84a7b657f09303a2850e1cc79e68f623547f3fdd.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
Commit 3d46a300 upstream. Properly configuring the overscan properties might be needed for the initial setup of the framebuffer for display that still have overscan. Let's allow for more properties on the kernel command line to setup each margin. Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/e481f1628e3768ca49226ec2115cfa4dfcbd5e4c.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
Commit 22045e8e upstream. The TV margins has been defined as a structure inside the drm_connector_state structure so far. However, we will need it in other structures as well, so let's move that structure definition so that it can be reused. Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/38b773b03f15ec7a135cdf8f7db669e5ada20cf2.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
Commit 1bf4e092 upstream. Minor conflict resolution as upstream has moved functions from drm_fb_helper.c to a new drm_client_modeset.c Rotations and reflections setup are needed in some scenarios to initialise properly the initial framebuffer. Some drivers already had a bunch of quirks to deal with this, such as either a private kernel command line parameter (omapdss) or on the device tree (various panels). In order to accomodate this, let's create a video mode parameter to deal with the rotation and reflexion. Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/777da16e42db757c1f5b414b5ca34507097fed5c.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
commit 3aeeb13d upstream. Minor conflict resolution as upstream has moved functions from drm_fb_helper.c to a new drm_client_modeset.c The drm subsystem also uses the video= kernel parameter, and in the documentation refers to the fbdev documentation for that parameter. However, that documentation also says that instead of giving the mode using its resolution we can also give a name. However, DRM doesn't handle that case at the moment. Even though in most case it shouldn't make any difference, it might be useful for analog modes, where different standards might have the same resolution, but still have a few different parameters that are not encoded in the modes (NTSC vs NTSC-J vs PAL-M for example). Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/18443e0c3bdbbd16cea4ec63bc7f2079b820b43b.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
commit e08ab74b upstream. Rewrite the command line parser in order to get away from the state machine parsing the video mode lines. Hopefully, this will allow to extend it more easily to support named modes and / or properties set directly on the command line. Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/e32cd4009153b184103554009135c7bf7c9975d7.1560783090.git-series.maxime.ripard@bootlin.com
-
Maxime Ripard authored
commit 772cd52c upstream. The struct drm_cmdline_mode holds the result of the command line parsers. However, it wasn't documented so far, so let's do that. Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Signed-off-by:
Maxime Ripard <maxime.ripard@bootlin.com> Link: https://patchwork.freedesktop.org/patch/msgid/963c893c16c6a25fc469b53c726f493d99bdc578.1560783090.git-series.maxime.ripard@bootlin.com
-
Dave Stevenson authored
Some HDMI monitors do not abide by the full or limited (16-235) range RGB flags in the AVI infoframe. This can result in images looking washed out (if given limited and interpreting as full), or detail disappearing at the extremes (given full and interpreting as limited). Copy the Intel i915 driver's approach of adding an override property ("Broadcast RGB") to force one mode or the other. Signed-off-by:
Dave Stevenson <dave.stevenson@raspberrypi.org>
-
- Aug 04, 2019
-
-
Greg Kroah-Hartman authored
-
Xin Long authored
commit 5684abf7 upstream. iptunnel_xmit() works as a common function, also used by a udp tunnel which doesn't have to have a tunnel device, like how TIPC works with udp media. In these cases, we should allow not to count pkts on dev's tstats, so that udp tunnel can work with no tunnel device safely. Signed-off-by:
Xin Long <lucien.xin@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Cc: Tommi Rantala <tommi.t.rantala@nokia.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bart Van Assche authored
commit 17605afa upstream. Since scsi_device_quiesce() skips SCSI devices that have another state than RUNNING, OFFLINE or TRANSPORT_OFFLINE, scsi_device_resume() should not complain about SCSI devices that have been skipped. Hence this patch. This patch avoids that the following warning appears during resume: WARNING: CPU: 3 PID: 1039 at blk_clear_pm_only+0x2a/0x30 CPU: 3 PID: 1039 Comm: kworker/u8:49 Not tainted 5.0.0+ #1 Hardware name: LENOVO 4180F42/4180F42, BIOS 83ET75WW (1.45 ) 05/10/2013 Workqueue: events_unbound async_run_entry_fn RIP: 0010:blk_clear_pm_only+0x2a/0x30 Call Trace: ? scsi_device_resume+0x28/0x50 ? scsi_dev_type_resume+0x2b/0x80 ? async_run_entry_fn+0x2c/0xd0 ? process_one_work+0x1f0/0x3f0 ? worker_thread+0x28/0x3c0 ? process_one_work+0x3f0/0x3f0 ? kthread+0x10c/0x130 ? __kthread_create_on_node+0x150/0x150 ? ret_from_fork+0x1f/0x30 Cc: Christoph Hellwig <hch@lst.de> Cc: Hannes Reinecke <hare@suse.com> Cc: Ming Lei <ming.lei@redhat.com> Cc: Johannes Thumshirn <jthumshirn@suse.de> Cc: Oleksandr Natalenko <oleksandr@natalenko.name> Cc: Martin Steigerwald <martin@lichtvoll.de> Cc: <stable@vger.kernel.org> Reported-by:
Jisheng Zhang <Jisheng.Zhang@synaptics.com> Tested-by:
Jisheng Zhang <Jisheng.Zhang@synaptics.com> Fixes: 3a0a5299 ("block, scsi: Make SCSI quiesce and resume work reliably") # v4.15 Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Bart Van Assche authored
commit cd84a62e upstream. The RQF_PREEMPT flag is used for three purposes: - In the SCSI core, for making sure that power management requests are executed even if a device is in the "quiesced" state. - For domain validation by SCSI drivers that use the parallel port. - In the IDE driver, for IDE preempt requests. Rename "preempt-only" into "pm-only" because the primary purpose of this mode is power management. Since the power management core may but does not have to resume a runtime suspended device before performing system-wide suspend and since a later patch will set "pm-only" mode as long as a block device is runtime suspended, make it possible to set "pm-only" mode from more than one context. Since with this change scsi_device_quiesce() is no longer idempotent, make that function return early if it is called for a quiesced queue. Signed-off-by:
Bart Van Assche <bvanassche@acm.org> Acked-by:
Martin K. Petersen <martin.petersen@oracle.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Reviewed-by:
Christoph Hellwig <hch@lst.de> Reviewed-by:
Ming Lei <ming.lei@redhat.com> Cc: Jianchao Wang <jianchao.w.wang@oracle.com> Cc: Johannes Thumshirn <jthumshirn@suse.de> Cc: Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Yan, Zheng authored
commit d6e47819 upstream. ceph_d_revalidate(, LOOKUP_RCU) may call __ceph_caps_issued_mask() on a freeing inode. Signed-off-by:
"Yan, Zheng" <zyan@redhat.com> Reviewed-by:
Jeff Layton <jlayton@redhat.com> Signed-off-by:
Ilya Dryomov <idryomov@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Yoshinori Sato authored
commit 1b496469 upstream. Conflict JCore-SoC and SolutionEngine 7619. Signed-off-by:
Yoshinori Sato <ysato@users.sourceforge.jp> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Miroslav Lichvar authored
commit 5515e9a6 upstream. The PPS assert/clear offset corrections are set by the PPS_SETPARAMS ioctl in the pps_ktime structs, which also contain flags. The flags are not initialized by applications (using the timepps.h header) and they are not used by the kernel for anything except returning them back in the PPS_GETPARAMS ioctl. Set the flags to zero to make it clear they are unused and avoid leaking uninitialized data of the PPS_SETPARAMS caller to other applications that have a read access to the PPS device. Link: http://lkml.kernel.org/r/20190702092251.24303-1-mlichvar@redhat.com Signed-off-by:
Miroslav Lichvar <mlichvar@redhat.com> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Acked-by:
Rodolfo Giometti <giometti@enneenne.com> Cc: Greg KH <greg@kroah.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Linus Torvalds authored
commit d26d0cd9 upstream. This makes the setproctitle() special case very explicit indeed, and handles it with a separate helper function entirely. In the process, it re-instates the original semantics of simply stopping at the first NUL character when the original last NUL character is no longer there. [ The original semantics can still be seen in mm/util.c: get_cmdline() that is limited to a fixed-size buffer ] This makes the logic about when we use the string lengths etc much more obvious, and makes it easier to see what we do and what the two very different cases are. Note that even when we allow walking past the end of the argument array (because the setproctitle() might have overwritten and overflowed the original argv[] strings), we only allow it when it overflows into the environment region if it is immediately adjacent. [ Fixed for missing 'count' checks noted by Alexey Izbyshev ] Link: https://lore.kernel.org/lkml/alpine.LNX.2.21.1904052326230.3249@kich.toxcorp.com/ Fixes: 5ab82718 ("fs/proc: simplify and clarify get_mm_cmdline() function") Cc: Jakub Jankowski <shasta@toxcorp.com> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Alexey Izbyshev <izbyshev@ispras.ru> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Linus Torvalds authored
commit 3d712546 upstream. Start off with a clean slate that only reads exactly from arg_start to arg_end, without any oddities. This simplifies the code and in the process removes the case that caused us to potentially leak an uninitialized byte from the temporary kernel buffer. Note that in order to start from scratch with an understandable base, this simplifies things _too_ much, and removes all the legacy logic to handle setproctitle() having changed the argument strings. We'll add back those special cases very differently in the next commit. Link: https://lore.kernel.org/lkml/20190712160913.17727-1-izbyshev@ispras.ru/ Fixes: f5b65348 ("proc: fix missing final NUL in get_mm_cmdline() rewrite") Cc: Alexey Izbyshev <izbyshev@ispras.ru> Cc: Alexey Dobriyan <adobriyan@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jann Horn authored
commit cb361d8c upstream. The old code used RCU annotations and accessors inconsistently for ->numa_group, which can lead to use-after-frees and NULL dereferences. Let all accesses to ->numa_group use proper RCU helpers to prevent such issues. Signed-off-by:
Jann Horn <jannh@google.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Petr Mladek <pmladek@suse.com> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will@kernel.org> Fixes: 8c8a743c ("sched/numa: Use {cpu, pid} to create task groups for shared faults") Link: https://lkml.kernel.org/r/20190716152047.14424-3-jannh@google.com Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jann Horn authored
commit 16d51a59 upstream. When going through execve(), zero out the NUMA fault statistics instead of freeing them. During execve, the task is reachable through procfs and the scheduler. A concurrent /proc/*/sched reader can read data from a freed ->numa_faults allocation (confirmed by KASAN) and write it back to userspace. I believe that it would also be possible for a use-after-free read to occur through a race between a NUMA fault and execve(): task_numa_fault() can lead to task_numa_compare(), which invokes task_weight() on the currently running task of a different CPU. Another way to fix this would be to make ->numa_faults RCU-managed or add extra locking, but it seems easier to wipe the NUMA fault statistics on execve. Signed-off-by:
Jann Horn <jannh@google.com> Signed-off-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Petr Mladek <pmladek@suse.com> Cc: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will@kernel.org> Fixes: 82727018 ("sched/numa: Call task_numa_free() from do_execve()") Link: https://lkml.kernel.org/r/20190716152047.14424-1-jannh@google.com Signed-off-by:
Ingo Molnar <mingo@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jason Wang authored
commit c1ea02f1 upstream. This patch will check the weight and exit the loop if we exceeds the weight. This is useful for preventing scsi kthread from hogging cpu which is guest triggerable. This addresses CVE-2019-3900. Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Stefan Hajnoczi <stefanha@redhat.com> Fixes: 057cbf49 ("tcm_vhost: Initial merge for vhost level target fabric driver") Signed-off-by:
Jason Wang <jasowang@redhat.com> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com> [jwang: backport to 4.19] Signed-off-by:
Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jason Wang authored
commit e79b431f upstream. This patch will check the weight and exit the loop if we exceeds the weight. This is useful for preventing vsock kthread from hogging cpu which is guest triggerable. The weight can help to avoid starving the request from on direction while another direction is being processed. The value of weight is picked from vhost-net. This addresses CVE-2019-3900. Cc: Stefan Hajnoczi <stefanha@redhat.com> Fixes: 433fc58e ("VSOCK: Introduce vhost_vsock.ko") Signed-off-by:
Jason Wang <jasowang@redhat.com> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jason Wang authored
commit e2412c07 upstream. When the rx buffer is too small for a packet, we will discard the vq descriptor and retry it for the next packet: while ((sock_len = vhost_net_rx_peek_head_len(net, sock->sk, &busyloop_intr))) { ... /* On overrun, truncate and discard */ if (unlikely(headcount > UIO_MAXIOV)) { iov_iter_init(&msg.msg_iter, READ, vq->iov, 1, 1); err = sock->ops->recvmsg(sock, &msg, 1, MSG_DONTWAIT | MSG_TRUNC); pr_debug("Discarded rx packet: len %zd\n", sock_len); continue; } ... } This makes it possible to trigger a infinite while..continue loop through the co-opreation of two VMs like: 1) Malicious VM1 allocate 1 byte rx buffer and try to slow down the vhost process as much as possible e.g using indirect descriptors or other. 2) Malicious VM2 generate packets to VM1 as fast as possible Fixing this by checking against weight at the end of RX and TX loop. This also eliminate other similar cases when: - userspace is consuming the packets in the meanwhile - theoretical TOCTOU attack if guest moving avail index back and forth to hit the continue after vhost find guest just add new buffers This addresses CVE-2019-3900. Fixes: d8316f39 ("vhost: fix total length when packets are too short") Fixes: 3a4d5c94 ("vhost_net: a kernel-level virtio server") Signed-off-by:
Jason Wang <jasowang@redhat.com> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> [jwang: backport to 4.19] Signed-off-by:
Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Jason Wang authored
commit e82b9b07 upstream. We used to have vhost_exceeds_weight() for vhost-net to: - prevent vhost kthread from hogging the cpu - balance the time spent between TX and RX This function could be useful for vsock and scsi as well. So move it to vhost.c. Device must specify a weight which counts the number of requests, or it can also specific a byte_weight which counts the number of bytes that has been processed. Signed-off-by:
Jason Wang <jasowang@redhat.com> Reviewed-by:
Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by:
Michael S. Tsirkin <mst@redhat.com> [jwang: backport to 4.19, fix conflict in net.c] Signed-off-by:
Jack Wang <jinpu.wang@cloud.ionos.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Vladis Dronov authored
commit b36a1552 upstream. Certain ttys operations (pty_unix98_ops) lack tiocmget() and tiocmset() functions which are called by the certain HCI UART protocols (hci_ath, hci_bcm, hci_intel, hci_mrvl, hci_qca) via hci_uart_set_flow_control() or directly. This leads to an execution at NULL and can be triggered by an unprivileged user. Fix this by adding a helper function and a check for the missing tty operations in the protocols code. This fixes CVE-2019-10207. The Fixes: lines list commits where calls to tiocm[gs]et() or hci_uart_set_flow_control() were added to the HCI UART protocols. Link: https://syzkaller.appspot.com/bug?id=1b42faa2848963564a5b1b7f8c837ea7b55ffa50 Reported-by:
<syzbot+79337b501d6aa974d0f6@syzkaller.appspotmail.com> Cc: stable@vger.kernel.org # v2.6.36+ Fixes: b3190df6 ("Bluetooth: Support for Atheros AR300x serial chip") Fixes: 118612fb ("Bluetooth: hci_bcm: Add suspend/resume PM functions") Fixes: ff289559 ("Bluetooth: hci_intel: Add Intel baudrate configuration support") Fixes: 162f812f ("Bluetooth: hci_uart: Add Marvell support") Fixes: fa9ad876 ("Bluetooth: hci_qca: Add support for Qualcomm Bluetooth chip wcn3990") Signed-off-by:
Vladis Dronov <vdronov@redhat.com> Signed-off-by:
Marcel Holtmann <marcel@holtmann.org> Reviewed-by:
Yu-Chen, Cho <acho@suse.com> Tested-by:
Yu-Chen, Cho <acho@suse.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Joerg Roedel authored
commit 201c1db9 upstream. The stub function for !CONFIG_IOMMU_IOVA needs to be 'static inline'. Fixes: effa4678 ('iommu/vt-d: Don't queue_iova() if there is no flush queue') Signed-off-by:
Joerg Roedel <jroedel@suse.de> Signed-off-by:
Dmitry Safonov <dima@arista.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dmitry Safonov authored
commit effa4678 upstream. Intel VT-d driver was reworked to use common deferred flushing implementation. Previously there was one global per-cpu flush queue, afterwards - one per domain. Before deferring a flush, the queue should be allocated and initialized. Currently only domains with IOMMU_DOMAIN_DMA type initialize their flush queue. It's probably worth to init it for static or unmanaged domains too, but it may be arguable - I'm leaving it to iommu folks. Prevent queuing an iova flush if the domain doesn't have a queue. The defensive check seems to be worth to keep even if queue would be initialized for all kinds of domains. And is easy backportable. On 4.19.43 stable kernel it has a user-visible effect: previously for devices in si domain there were crashes, on sata devices: BUG: spinlock bad magic on CPU#6, swapper/0/1 lock: 0xffff88844f582008, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 CPU: 6 PID: 1 Comm: swapper/0 Not tainted 4.19.43 #1 Call Trace: <IRQ> dump_stack+0x61/0x7e spin_bug+0x9d/0xa3 do_raw_spin_lock+0x22/0x8e _raw_spin_lock_irqsave+0x32/0x3a queue_iova+0x45/0x115 intel_unmap+0x107/0x113 intel_unmap_sg+0x6b/0x76 __ata_qc_complete+0x7f/0x103 ata_qc_complete+0x9b/0x26a ata_qc_complete_multiple+0xd0/0xe3 ahci_handle_port_interrupt+0x3ee/0x48a ahci_handle_port_intr+0x73/0xa9 ahci_single_level_irq_intr+0x40/0x60 __handle_irq_event_percpu+0x7f/0x19a handle_irq_event_percpu+0x32/0x72 handle_irq_event+0x38/0x56 handle_edge_irq+0x102/0x121 handle_irq+0x147/0x15c do_IRQ+0x66/0xf2 common_interrupt+0xf/0xf RIP: 0010:__do_softirq+0x8c/0x2df The same for usb devices that use ehci-pci: BUG: spinlock bad magic on CPU#0, swapper/0/1 lock: 0xffff88844f402008, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0 CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.19.43 #4 Call Trace: <IRQ> dump_stack+0x61/0x7e spin_bug+0x9d/0xa3 do_raw_spin_lock+0x22/0x8e _raw_spin_lock_irqsave+0x32/0x3a queue_iova+0x77/0x145 intel_unmap+0x107/0x113 intel_unmap_page+0xe/0x10 usb_hcd_unmap_urb_setup_for_dma+0x53/0x9d usb_hcd_unmap_urb_for_dma+0x17/0x100 unmap_urb_for_dma+0x22/0x24 __usb_hcd_giveback_urb+0x51/0xc3 usb_giveback_urb_bh+0x97/0xde tasklet_action_common.isra.4+0x5f/0xa1 tasklet_action+0x2d/0x30 __do_softirq+0x138/0x2df irq_exit+0x7d/0x8b smp_apic_timer_interrupt+0x10f/0x151 apic_timer_interrupt+0xf/0x20 </IRQ> RIP: 0010:_raw_spin_unlock_irqrestore+0x17/0x39 Cc: David Woodhouse <dwmw2@infradead.org> Cc: Joerg Roedel <joro@8bytes.org> Cc: Lu Baolu <baolu.lu@linux.intel.com> Cc: iommu@lists.linux-foundation.org Cc: <stable@vger.kernel.org> # 4.14+ Fixes: 13cf0174 ("iommu/vt-d: Make use of iova deferred flushing") Signed-off-by:
Dmitry Safonov <dima@arista.com> Reviewed-by:
Lu Baolu <baolu.lu@linux.intel.com> Signed-off-by:
Joerg Roedel <jroedel@suse.de> [v4.14-port notes: o minor conflict with untrusted IOMMU devices check under if-condition] Signed-off-by:
Dmitry Safonov <dima@arista.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Luke Nowakowski-Krijger authored
commit c666355e upstream. Change devm_k*alloc to k*alloc to manually allocate memory The manual allocation and freeing of memory is necessary because when the USB radio is disconnected, the memory associated with devm_k*alloc is freed. Meaning if we still have unresolved references to the radio device, then we get use-after-free errors. This patch fixes this by manually allocating memory, and freeing it in the v4l2.release callback that gets called when the last radio device exits. Reported-and-tested-by:
<syzbot+a4387f5b6b799f6becbf@syzkaller.appspotmail.com> Signed-off-by:
Luke Nowakowski-Krijger <lnowakow@eng.ucsd.edu> Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> [hverkuil-cisco@xs4all.nl: cleaned up two small checkpatch.pl warnings] [hverkuil-cisco@xs4all.nl: prefix subject with driver name] Signed-off-by:
Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Benjamin Coddington authored
commit 9f7761cf upstream. Don't bail out before cleaning up a new allocation if the wait for searching for a matching nfs client is interrupted. Memory leaks. Reported-by:
<syzbot+7fe11b49c1cc30e3fce2@syzkaller.appspotmail.com> Fixes: 950a578c ("NFS: make nfs_match_client killable") Signed-off-by:
Benjamin Coddington <bcodding@redhat.com> Signed-off-by:
Trond Myklebust <trond.myklebust@hammerspace.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-