If platform code returns a NULL pointer to the FDT, initial_boot_params
will not get set to a valid pointer and attempting to find the /chosen
node in it will cause a NULL pointer dereference and the kernel to crash
immediately on startup - with no output to the console.
Fix this by checking that initial_boot_params is valid before using it.
Fixes: 405bc8fd12 ("MIPS: Kernel: Implement KASLR using CONFIG_RELOCATABLE")
Cc: stable@vger.kernel.org # 4.7+
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/14414/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Commit 10b6ea0959 ("MIPS: Malta: Use syscon-reboot driver to reboot")
converted the Malta board to use the generic syscon-reboot driver to
handle reboots, but incorrectly used the value 0x4d rather than 0x42 as
the magic to write to the reboot register.
I also incorrectly believed that syscon/regmap would default to native
endianness, but this isn't the case. Force this by specifying with a
native-endian property in the devicetree.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Fixes: 10b6ea0959 ("MIPS: Malta: Use syscon-reboot driver to reboot")
Reported-by: Guenter Roeck <linux@roeck-us.net>
Cc: linux-mips@linux-mips.org
Tested-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Maciej W. Rozycki <macro@imgtec.com>
Patchwork: https://patchwork.linux-mips.org/patch/14396/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Provide a default implementation of mips_cpc_default_phys_base() which
simply returns 0, and adjust mips_cpc_phys_base() to allow for
mips_cpc_default_phys_base() returning 0. This allows kernels which
include CPC support to be built without platform code & simply ignore
the CPC if it wasn't already enabled by the bootloader.
This fixes link failures such as the following from generic defconfigs:
arch/mips/built-in.o: In function `mips_cpc_phys_base':
arch/mips/kernel/mips-cpc.c:47: undefined reference to `mips_cpc_default_phys_base'
[ralf@linux-mips.org: changed prototype for coding style compliance.]
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/14401/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
Like many similar devices it needs a quirk to work.
Issuing the request gets the device into an irrecoverable state.
Signed-off-by: Oliver Neukum <oneukum@suse.com>
CC: stable@vger.kernel.org
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Fix
drivers/hid/intel-ish-hid/ipc/pci-ish.c:247:12: warning: ‘ish_suspend’ defined but not used [-Wunused-function]
static int ish_suspend(struct device *device)
^
drivers/hid/intel-ish-hid/ipc/pci-ish.c:282:12: warning: ‘ish_resume’ defined but not used [-Wunused-function]
static int ish_resume(struct device *device)
^
by sticking them in the CONFIG_PM range too.
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Jiri Kosina <jikos@kernel.org>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: Wei Yongjun <weiyongjun1@huawei.com>
Cc: linux-input@vger.kernel.org
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
When report count is more than one and report size is not 4 bytes, then we
need some packing into result buffer from the caller of function
sensor_hub_get_feature.
By default the value extracted from a field is 4 bytes from hid core
(using hid_hw_request(hsdev->hdev, report, HID_REQ_GET_REPORT)), even
if report size if less than 4 byte. So when we copy data to user buffer in
sensor_hub_get_feature, we need to only copy report size bytes even
when report count is more than 1. This is
not an issue for most of the sensor hub fields as report count will be 1
where we already copy only report size bytes, but some string fields
like description, it is a problem as the report count will be more than 1.
For example:
Field(6)
Physical(Sensor.OtherCustom)
Application(Sensor.Sensor)
Usage(11)
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Sensor.0306
Report Size(16)
Report Count(11)
Here since the report size is 2 bytes, we will have 2 additional bytes of
0s copied into user buffer, if we directly copy to user buffer from
report->field[]->value
This change will copy report size bytes into the buffer of caller for each
usage report->field[]->value. So for example without this change, the
data displayed for a custom sensor field "sensor-model":
76 00 101 00 110 00 111 00 118 00 111
(truncated to report count of 11)
With change
76 101 110 111 118 111 32 89 111 103 97
("Lenovo Yoga" in ASCII )
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
RFC 2734 defines the datagram_size field in fragment encapsulation
headers thus:
datagram_size: The encoded size of the entire IP datagram. The
value of datagram_size [...] SHALL be one less than the value of
Total Length in the datagram's IP header (see STD 5, RFC 791).
Accordingly, the eth1394 driver of Linux 2.6.36 and older set and got
this field with a -/+1 offset:
ether1394_tx() /* transmit */
ether1394_encapsulate_prep()
hdr->ff.dg_size = dg_size - 1;
ether1394_data_handler() /* receive */
if (hdr->common.lf == ETH1394_HDR_LF_FF)
dg_size = hdr->ff.dg_size + 1;
else
dg_size = hdr->sf.dg_size + 1;
Likewise, I observe OS X 10.4 and Windows XP Pro SP3 to transmit 1500
byte sized datagrams in fragments with datagram_size=1499 if link
fragmentation is required.
Only firewire-net sets and gets datagram_size without this offset. The
result is lacking interoperability of firewire-net with OS X, Windows
XP, and presumably Linux' eth1394. (I did not test with the latter.)
For example, FTP data transfers to a Linux firewire-net box with max_rec
smaller than the 1500 bytes MTU
- from OS X fail entirely,
- from Win XP start out with a bunch of fragmented datagrams which
time out, then continue with unfragmented datagrams because Win XP
temporarily reduces the MTU to 576 bytes.
So let's fix firewire-net's datagram_size accessors.
Note that firewire-net thereby loses interoperability with unpatched
firewire-net, but only if link fragmentation is employed. (This happens
with large broadcast datagrams, and with large datagrams on several
FireWire CardBus cards with smaller max_rec than equivalent PCI cards,
and it can be worked around by setting a small enough MTU.)
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
The IP-over-1394 driver firewire-net lacked input validation when
handling incoming fragmented datagrams. A maliciously formed fragment
with a respectively large datagram_offset would cause a memcpy past the
datagram buffer.
So, drop any packets carrying a fragment with offset + length larger
than datagram_size.
In addition, ensure that
- GASP header, unfragmented encapsulation header, or fragment
encapsulation header actually exists before we access it,
- the encapsulated datagram or fragment is of nonzero size.
Reported-by: Eyal Itkin <eyal.itkin@gmail.com>
Reviewed-by: Eyal Itkin <eyal.itkin@gmail.com>
Fixes: CVE 2016-8633
Cc: stable@vger.kernel.org
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
When CONFIG_THREAD_INFO_IN_TASK=y, it is possible that an exited thread
remains in the task list after its stack pointer was already set to NULL.
Therefore, thread_saved_pc() and stack_not_used() in sched_show_task()
will trigger NULL pointer dereference if an attempt to dump such thread's
traces (e.g. SysRq-t, khungtaskd) is made.
Since show_stack() in sched_show_task() calls try_get_task_stack() and
sched_show_task() is called from interrupt context, calling
try_get_task_stack() from sched_show_task() will be safe as well.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Acked-by: Andy Lutomirski <luto@kernel.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: bp@alien8.de
Cc: brgerst@gmail.com
Cc: jann@thejh.net
Cc: keescook@chromium.org
Cc: linux-api@vger.kernel.org
Cc: tycho.andersen@canonical.com
Link: http://lkml.kernel.org/r/201611021950.FEJ34368.HFFJOOMLtQOVSF@I-love.SAKURA.ne.jp
Signed-off-by: Ingo Molnar <mingo@kernel.org>
batch of scattered i915 fixes.
* tag 'drm-intel-fixes-2016-11-01' of git://anongit.freedesktop.org/drm-intel:
drm/i915: Fix SKL+ 90/270 degree rotated plane coordinate computation
drm/i915: Remove two invalid warns
drm/i915: Rotated view does not need a fence
drm/i915/fbc: fix CFB size calculation for gen8+
drm: i915: Wait for fences on new fb, not old
drm/i915: Clean up DDI DDC/AUX CH sanitation
drm/i915: Respect alternate_aux_channel for all DDI ports
drm/i915/gen9: fix watermarks when using the pipe scaler
drm/i915: Fix mismatched INIT power domain disabling during suspend
drm/i915: fix a read size argument
drm/i915: Use fence_write() from rpm resume
drm/i915/gen9: fix DDB partitioning for multi-screen cases
drm/i915: workaround sparse warning on variable length arrays
drm/i915: keep declarations in i915_drv.h
- some fixes for active plane reconfiguration support
- hide unused label in case of disabled CONFIG_DRM_FBDEV_EMULATION,
which caused a build warning
- fixed error handling in imx_drm_bind
- disallow odd x/y plane offsets for chroma subsampled formats
- disable local alpha when switching from a format with alpha
channel to an opaque format
-----BEGIN PGP SIGNATURE-----
iQI0BAABCAAeBQJYCbk/FxxwLnphYmVsQHBlbmd1dHJvbml4LmRlAAoJEFDCiBxw
nmDrGMYQAJMx6LoCTJ7hfr59R4IvmST0tRcVTKO4Grux8JPfu7WtDaFNhfew4ltA
Nt38lbawzBBJ3jmbayGzpHmeEDdZh8T0LbYqzqWNRjergQ5V0qCXcxLKuvrRW9NC
H0QmJmbiZm9EDani7Xh1yOF51n1g37FVq7+qROr9J7oHz/xjJw523XwSiLAR9pgs
QMmw5zrPNqu93pRCLtm5/4puVMOYQfHmE8l8WYV2zIvjck1D+rkRFv5+DJwpDZjO
jpvq3ZrHSFHM12wk0S5jsLUwFs2cqHb16ETitGP9gB7MnkPZ7qwgTTfio3JDpuL8
orKpTcjDPVxPfVmbS5Hv/iNNq8YMz1VrJNp7y/ZCgTqNl/877f9nmeHKXdolMWMc
xN5gDrd0atzHJKhsxp6bOYDhp861C1Nm+gtuNs2lRHsKANUa9SKh+gcyEC+CfqaU
PdKx0E0lQcjjWjW2UYseQmjePjIclPzgCw1V6PHJOkOFBz8wQm8EHH4BcqBsx2zP
v/ew3s/dk00IWi6e6/M7/hDM2vgXGIvw1AV8FHqMcBgSs/4GqVbGxJF+HIDqTX5s
257nDdm+23eA8yvg+XbtYqlP0G7r7XV1KQLiMoFNJEj8+OjFfHPotphhX0kh8eWu
quhY4yKlrOrzrm7wrCEOXhfwSfKhO4BF1lgh3jzqKzfWYtckgXOh
=lgaf
-----END PGP SIGNATURE-----
Merge tag 'imx-drm-fixes-20161021' of git://git.pengutronix.de/pza/linux into drm-fixes
imx-drm plane, build warning, and error handling fixes
- some fixes for active plane reconfiguration support
- hide unused label in case of disabled CONFIG_DRM_FBDEV_EMULATION,
which caused a build warning
- fixed error handling in imx_drm_bind
- disallow odd x/y plane offsets for chroma subsampled formats
- disable local alpha when switching from a format with alpha
channel to an opaque format
* tag 'imx-drm-fixes-20161021' of git://git.pengutronix.de/pza/linux:
drm/imx: ipuv3-plane: disable local alpha for planes without alpha channel
drm/imx: ipuv3-plane: make sure x/y offsets are even in case of chroma subsampling
drm/imx: ipuv3-plane: Access old u/vbo properly in ->atomic_check for YU12/YV12
drm/imx: drm_dev_alloc() returns error pointers
drm/imx: ipuv3-plane: Skip setting u/vbo only when we don't need modeset
drm/imx: ipuv3-plane: Switch EBA buffer only when we don't need modeset
gpu: ipu-v3: Use ERR_CAST instead of ERR_PTR(PTR_ERR())
drm/imx: hide an unused label
virtio-gpu sends vblank events in virtio_gpu_crtc_atomic_flush, and
because of that it must be called for disabled planes too. Ask
drm_atomic_helper_commit_planes to do that.
v2: update to use new drm_atomic_helper_commit_planes() API.
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
We have one critical section in the syscall entry path in which we switch from
the userspace stack to kernel stack. In the event of an external interrupt, the
interrupt code distinguishes between those two states by analyzing the value of
sr7. If sr7 is zero, it uses the kernel stack. Therefore it's important, that
the value of sr7 is in sync with the currently enabled stack.
This patch now disables interrupts while executing the critical section. This
prevents the interrupt handler to possibly see an inconsistent state which in
the worst case can lead to crashes.
Interestingly, in the syscall exit path interrupts were already disabled in the
critical section which switches back to the userspace stack.
Cc: <stable@vger.kernel.org>
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
There is no need to trash sr2 and sr3 in the Light-weight syscall (LWS). sr2
already points to kernel space (it's zero in userspace, otherwise syscalls
wouldn't work), and since the LWS code is executed in userspace, we can simply
ignore to preload sr3.
Signed-off-by: John David Anglin <dave.anglin@bell.net>
Signed-off-by: Helge Deller <deller@gmx.de>
Recent changes to printk require KERN_CONT uses to continue logging messages.
So add KERN_CONT to output of device inventory.
Signed-off-by: Helge Deller <deller@gmx.de>
Commit 41061cdb98 ("KVM: emulate: do not initialize memopp") removes a
check for non-NULL under incorrect assumptions. An undefined instruction
with a ModR/M byte with Mod=0 and R/M-5 (e.g. 0xc7 0x15) will attempt
to dereference a null pointer here.
Fixes: 41061cdb98
Message-Id: <1477592752-126650-2-git-send-email-osh@google.com>
Signed-off-by: Owen Hofmann <osh@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
After a successful VM-entry with the "VMCS shadowing" VM-execution
control set, the shadow VMCS referenced by the VMCS link pointer field
in the current VMCS becomes active on the logical processor.
A VMCS that is made active on more than one logical processor may become
corrupted. Therefore, before an active VMCS can be migrated to another
logical processor, the first logical processor must execute a VMCLEAR
for the active VMCS. VMCLEAR both ensures that all VMCS data are written
to memory and makes the VMCS inactive.
Signed-off-by: Jim Mattson <jmattson@google.com>
Reviewed-By: David Matlack <dmatlack@google.com>
Message-Id: <1477668579-22555-1-git-send-email-jmattson@google.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Since commit a545ab6a00 ("kvm: x86: add tsc_offset field to struct
kvm_vcpu_arch", 2016-09-07) the offset between host and L1 TSC is
cached and need not be fished out of the VMCS or VMCB. This means
that we can implement adjust_tsc_offset_guest and read_l1_tsc
entirely in generic code. The simplification is particularly
significant for VMX code, where vmx->nested.vmcs01_tsc_offset
was duplicating what is now in vcpu->arch.tsc_offset. Therefore
the vmcs01_tsc_offset can be dropped completely.
More importantly, this fixes KVM_GET_CLOCK/KVM_SET_CLOCK
which, after commit 108b249c45 ("KVM: x86: introduce get_kvmclock_ns",
2016-09-01) called read_l1_tsc while the VMCS was not loaded.
It thus returned bogus values on Intel CPUs.
Fixes: 108b249c45
Reported-by: Roman Kagan <rkagan@virtuozzo.com>
Reviewed-by: Radim Krčmář <rkrcmar@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Just minor tweaks, there's nothing major in this cycle.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAABAgAGBQJYFnb+AAoJECgfDbjSjVRpBD4IAKjmFLG6rcswWwYVSNwxMcEX
6gxStyojtx9jTdQhjYUeC4KJmPozGn9mxEyHuWHNAqWWP/nASbViXYDwVm9xv/14
TxuApiOJ9tFB0DYlduGDQbS5D6m3WSk7U2s71pwC0g2YPx1EQc8jHbeT09Jn5qVw
6A099BILekts/lN6s9ST+6CAHBLTkZGB6iyAb+zAh+KN+VRX3ikpOjebgUjzO1+P
hLJc+lgfls+cwuhwO5A+Pg1PMrJ455A/gdEVUfMbbj8BAkihueUHPUzkc702Y5h2
j3AfCLJdCBIR/k3+R9Du0IcK0mXioZtiBPfREGQ+kI0ukauFDhtKgjaOd0bmU4s=
=ASeM
-----END PGP SIGNATURE-----
Merge tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost
Pull virtio updates from Michael Tsirkin:
"Tests, fixes and cleanups.
Just minor tweaks, there's nothing major in this cycle"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
virtio_ring: mark vring_dma_dev inline
virtio/vhost: add Jason to list of maintainers
virtio_blk: Delete an unnecessary initialisation in init_vq()
virtio_blk: Use kmalloc_array() in init_vq()
virtio: remove config.c
virtio: console: Unlock vqs while freeing buffers
ringtest: poll for new buffers once before updating event index
ringtest: commonize implementation of poll_avail/poll_used
ringtest: use link-time optimization
virtio: update balloon size in balloon "probe"
virtio_ring: Make interrupt suppression spec compliant
virtio_pci: Limit DMA mask to 44 bits for legacy virtio devices
The underlying transport releases the page pointed to by rq_buffer
during xprt_rdma_bc_send_request. When the backchannel reply arrives,
rq_rbuffer then points to freed memory.
Fixes: 68778945e4 ('SUNRPC: Separate buffer pointers for RPC ...')
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Cc: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
This fixes the irq allocation in this driver to not print:
irq: Cannot allocate irq_descs @ IRQ34, assuming pre-allocated
irq: Cannot allocate irq_descs @ IRQ66, assuming pre-allocated
Which happens because the driver already called irq_alloc_descs()
and so the change to use irq_domain_add_simple resulted in calling
irq_alloc_descs() twice.
Modernize the irq allocation in this driver to use the
irq_domain_add_linear flow directly and eliminate the use of
irq_domain_add_simple/legacy
Fixes: ce931f571b ("gpio/mvebu: convert to use irq_domain_add_simple()")
Signed-off-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
If something goes wrong with task stack refcounting and a stack
refcount hits zero too early, warn and leak it rather than
potentially freeing it early (and silently).
Signed-off-by: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/f29119c783a9680a4b4656e751b6123917ace94b.1477926663.git.luto@kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Check whether the kernel really supports power resources for a device,
otherwise the power might not be removed when the device is runtime
suspended (DSM should still work in these cases where PR does not).
This is a workaround for a problem where ACPICA and Windows 10 differ in
behavior. ACPICA does not correctly enumerate power resources within a
conditional block (due to delayed execution of such blocks) and as a
result power_resources is set to false even if _PR3 exists.
Fixes: 692a17dcc2 ("drm/nouveau/acpi: fix lockup with PCIe runtime PM")
Link: https://bugs.freedesktop.org/show_bug.cgi?id=98398
Reported-and-tested-by: Rick Kerkhof <rick.2889@gmail.com>
Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Peter Wu <peter@lekensteyn.nl>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Sylvain Lemieux reports the LPC32xx GPIO driver is broken since
commit 762c2e46c0 ("gpio: of: remove of_gpiochip_and_xlate() and
struct gg_data"). Probably, gpio-etraxfs.c and gpio-davinci.c are
broken too.
Those drivers register multiple gpio_chip that are associated to a
single OF node, and their own .of_xlate() checks if the passed
gpio_chip is valid.
Now, the problem is of_find_gpiochip_by_node() returns the first
gpio_chip found to match the given node. So, .of_xlate() fails,
except for the first GPIO bank.
Reverting the commit could be a solution, but I do not want to go
back to the mess of struct gg_data. Another solution here is to
take the match by a node pointer and the success of .of_xlate().
It is a bit clumsy to call .of_xlate twice; for gpio_chip matching
and for really getting the gpio_desc index. Perhaps, our long-term
goal might be to convert the drivers to single chip registration,
but this commit will solve the problem until then.
Fixes: 762c2e46c0 ("gpio: of: remove of_gpiochip_and_xlate() and struct gg_data")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reported-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Tested-by: David Lechner <david@lechnology.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
When allocating a new line handle or event a file is allocated that it is
associated to. The file is attached to a file descriptor of the current
process and the file descriptor is returned to userspace using
copy_to_user(). If this copy operation fails the line handle or event
allocation is aborted, all acquired resources are freed and an error is
returned.
But the file struct is not freed and left attached to the userspace
application and even though the file descriptor number was not copied it is
trivial to guess. If a userspace application performs a IOCTL on such a
left over file descriptor it will trigger a use-after-free and if the file
descriptor is closed (latest when the application exits) a double-free is
triggered.
anon_inode_getfd() performs 3 tasks, allocate a file struct, allocate a
file descriptor for the current process and install the file struct in the
file descriptor. As soon as the file struct is installed in the file
descriptor it is accessible by userspace (even if the IOCTL itself hasn't
completed yet), this means uninstalling the fd on the error path is not an
option, since userspace might already got a reference to the file.
Instead anon_inode_getfd() needs to be broken into its individual steps.
The allocation of the file struct and file descriptor is done first, then
the copy_to_user() is executed and only if it succeeds the file is
installed.
Since the file struct is reference counted it can not be just freed, but
its reference needs to be dropped, which will also call the release()
callback, which will free the state attached to the file. So in this case
the normal error cleanup path should not be taken.
Cc: stable@vger.kernel.org
Fixes: d932cd4918 ("gpio: free handles in fringe cases")
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
A few small fixes for SPI, one core fix that only applies in cases where
we're handling DT overlays and a couple of driver specific fixes:
- Fix handling of error cases when instantiating DT overlays so we
don't end up just ignoring devices that encountered an error during
instantiation.
- Avoid reading uninitialized data when handing spurious interrupts
in the espi driver.
- A driver specific fix for the dspi driver to fix a bad interaction
with u-boot.
-----BEGIN PGP SIGNATURE-----
iQEwBAABCAAaBQJYF4M5Exxicm9vbmllQGtlcm5lbC5vcmcACgkQJNaLcl1Uh9BF
yAf+KC6vYTX8ySbfie5vAjCezUoujdHhjy8uO5dKX4OLGz3UhFZ0bpCgBlGx5XGw
KBllfiA+fkKrxBvJCPIvRW33UDXLTRDAiCTw4nT9FoYEsSotApJ62kElRulz850c
3l1n8/+WuAw2khq89r+MYDVLZZ1ssUNkj4hug+EKipibBHNV/z1P0GPRthGzRzmV
VcQ/JBPhKhqF1+N2gGS099N5+vic7pPQUGxVpjdrFColyuRtwmXJfynZYxHM7GjD
UcmgzOwN7EuKZZgkBG2bZAyDZSNFTkNljOxiDeVCkJVyK4Oj1YPkQ6NWjGtIVNAW
AtmptgxAcqqhA+tAPyhpFeHG+Q==
=zMqg
-----END PGP SIGNATURE-----
Merge tag 'spi-fix-v4.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown: "A few small fixes for SPI, one core fix
that only applies in cases where we're handling DT overlays and a
couple of driver specific fixes:
- Fix handling of error cases when instantiating DT overlays so we
don't end up just ignoring devices that encountered an error during
instantiation.
- Avoid reading uninitialized data when handing spurious interrupts
in the espi driver.
- A driver specific fix for the dspi driver to fix a bad interaction
with u-boot"
* tag 'spi-fix-v4.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: dspi: clear SPI_SR before enable interrupt
spi: fsl-espi: avoid processing uninitalized data on error
spi: mark device nodes only in case of successful instantiation
The stack frame size could grow too large when the plugin used long long
on 32-bit architectures when the given function had too many basic blocks.
The gcc warning was:
drivers/pci/hotplug/ibmphp_ebda.c: In function 'ibmphp_access_ebda':
drivers/pci/hotplug/ibmphp_ebda.c:409:1: warning: the frame size of 1108 bytes is larger than 1024 bytes [-Wframe-larger-than=]
This switches latent_entropy from u64 to unsigned long.
Thanks to PaX Team and Emese Revfy for the patch.
Signed-off-by: Kees Cook <keescook@chromium.org>
A new warning was introduced for missing information about the time that
regulators take to power on in v4.9. This is in theory a real issue but
for most practical regulators the communication overhead of talking to
the device is greater than the ramp time so a lot of drivers don't set
it and the warning is far too noisy without identifying practical
issues. Just remove the warning for now.
-----BEGIN PGP SIGNATURE-----
iQEwBAABCAAaBQJYF3a0Exxicm9vbmllQGtlcm5lbC5vcmcACgkQJNaLcl1Uh9DF
Jwf/dnH06enDvPjUvoqX+V6eT++FUI7DeIoMVNGCEYiJtqUmpLWSvbJ2IT68AEks
4IroBUEA57JE7sQ+gd0H6ZiXCq7Pk2QPD+bpnH5aJIdRpLGn9ew4o0p/3DGjS43q
V0A6N83BeWHeDAeyu6NSo9aAdTwD5ENCuy1XqhEVMFSPpUqutyfDgqSzFtCO4Cl9
MnoTv7be37YNFb+JsFlTdOmThfmtLoJJGd8E4/bUqBb36FoYLyGVNvEE0Xwagc8Q
dcUZXYqfw8qMWipCxBM2wdv/lXJQAFpAbuftACnaz+jmpAbOsWRZ2QmcBPQOxDhn
oif0/hccYoIcW0knMbhEx6yERQ==
=7KoE
-----END PGP SIGNATURE-----
Merge tag 'regulator-fix-v4.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
Pull regulator fix from Mark Brown:
"Fix ramp_delay warnings for v4.9
A new warning was introduced for missing information about the time
that regulators take to power on in v4.9. This is in theory a real
issue but for most practical regulators the communication overhead of
talking to the device is greater than the ramp time so a lot of
drivers don't set it and the warning is far too noisy without
identifying practical issues.
Just remove the warning for now"
* tag 'regulator-fix-v4.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
regulator: core: silence warning: "VDD1: ramp_delay not set"
A couple of small build fixes here, nothing major. The missing include
is triggered in some configurations and the renaming of ret is defensive
for the benefit of some drivers people are in the process of mainlining.
-----BEGIN PGP SIGNATURE-----
iQEwBAABCAAaBQJYF3OfExxicm9vbmllQGtlcm5lbC5vcmcACgkQJNaLcl1Uh9DY
Dgf/VDYO5Br2+73lMZUS2oZFY9PtdapCSr0u02gZsMhphioV7k+WcKrdd22IuNQB
dsk5vJPjcb6ElUmC9Aj2q4AcuVK5RHcjgADj40uqVoWXf7kBiyZlbBn2Om8D24+I
ribzAGZO1V9CtnSkTtrRIqMgzM9LsZvkPWRRyACNBwKaWxriqIwgI7mhEwGDy3gf
xRq2Qqunt0A3s2vrqkfQBVo1HZ2hrruVkcCG6TzOaiuqOpmgkevmDuwFuknQe6+T
zpqHU6SQNeV11C9GJS094iM91lKnFu920BGk/tonM+paEFtAxx5ovZ0GjJMQPaY4
kouLDJePoJ+LKRClP9qRvZwDmw==
=kSKf
-----END PGP SIGNATURE-----
Merge tag 'regmap-fix-v4.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap fixes from Mark Brown:
"A couple of small build fixes here, nothing major.
The missing include is triggered in some configurations and the
renaming of ret is defensive for the benefit of some drivers people
are in the process of mainlining"
* tag 'regmap-fix-v4.9-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: Rename ret variable in regmap_read_poll_timeout
regmap: include <linux/delay.h> from include/linux/regmap.h
Pull TPM fix from James Morris.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security:
tpm: remove invalid min length check from tpm_do_selftest()
Removal of this check was not properly amended to the original commit.
Cc: stable@vger.kernel.org
Fixes: 0c54133223 ("tpm: use tpm_pcr_read_dev() in tpm_do_selftest()")
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
Pull ARM fixes from Russell King:
"A fix for a regression on ARMv4T CPUs, and wiring up the new pkey
syscalls for ARM"
* 'fixes' of git://git.armlinux.org.uk/~rmk/linux-arm:
ARM: wire up new pkey syscalls
ARM: fix oops when using older ARMv4T CPUs
Pull sparc fixes from David Miller:
"Several sparc64 bug fixes here:
1) Make the user copy routines on sparc64 return a properly accurate
residual length when an exception occurs.
2) We can get enormous kernel TLB range flush requests from vmalloc
unmaps, so handle these more gracefully by doing full flushes
instead of going page-by-page.
3) Cope properly with negative branch offsets in sparc jump-label
support, from James Clarke.
4) Some old-style decl GCC warning fixups from Tobias Klauser"
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc:
sparc64: Handle extremely large kernel TLB range flushes more gracefully.
sparc64: Fix illegal relative branches in hypervisor patched TLB cross-call code.
sparc64: Fix instruction count in comment for __hypervisor_flush_tlb_pending.
sparc64: Handle extremely large kernel TSB range flushes sanely.
sparc: Handle negative offsets in arch_jump_label_transform
sparc64: Fix illegal relative branches in hypervisor patched TLB code.
sparc64: Delete now unused user copy fixup functions.
sparc64: Delete now unused user copy assembler helpers.
sparc64: Convert U3copy_{from,to}_user to accurate exception reporting.
sparc64: Convert NG2copy_{from,to}_user to accurate exception reporting.
sparc64: Convert NGcopy_{from,to}_user to accurate exception reporting.
sparc64: Convert NG4copy_{from,to}_user to accurate exception reporting.
sparc64: Convert U1copy_{from,to}_user to accurate exception reporting.
sparc64: Convert GENcopy_{from,to}_user to accurate exception reporting.
sparc64: Convert copy_in_user to accurate exception reporting.
sparc64: Prepare to move to more saner user copy exception handling.
sparc64: Delete __ret_efault.
sparc32: Fix old style declaration GCC warnings
sparc64: Fix old style declaration GCC warnings
sparc64: Setup a scheduling domain for highest level cache.
Make sure the copied up file hits the disk before renaming to the final
destination. If this is not done then the copy-up may corrupt the data in
the file in case of a crash.
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Cc: <stable@vger.kernel.org>
tmpfs doesn't have ->get_acl() because it only uses cached acls.
This fixes the acl tests in pjdfstest when tmpfs is used as the upper layer
of the overlay.
Reported-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Fixes: 39a25b2b37 ("ovl: define ->get_acl() for overlay inodes")
Cc: <stable@vger.kernel.org> # v4.8
This change fixes xfstest generic/375, which failed to clear the
setgid bit in the following test case on overlayfs:
touch $testfile
chown 100:100 $testfile
chmod 2755 $testfile
_runas -u 100 -g 101 -- setfacl -m u::rwx,g::rwx,o::rwx $testfile
Reported-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Tested-by: Amir Goldstein <amir73il@gmail.com>
Fixes: d837a49bd5 ("ovl: fix POSIX ACL setting")
Cc: <stable@vger.kernel.org> # v4.8
This inline function is unused on configurations
where dma_map/unmap are empty macros.
Make the function inline to avoid gcc errors because
of an unused static function.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Jason's been one of the mst active contributors
to virtio and vhost, it will help to formalize this
and list him as co-maintainer.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
The local variable "err" will be set to an appropriate value
by a following statement.
Thus omit the explicit initialisation at the beginning.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Multiplications for the size determination of memory allocations
indicated that array data structures should be processed.
Thus use the corresponding function "kmalloc_array".
This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Commit c6017e793b ("virtio: console: add locks around buffer removal
in port unplug path") added locking around the freeing of buffers in the
vq. However, when free_buf() is called with can_sleep = true and rproc
is enabled, it calls dma_free_coherent() directly, requiring interrupts
to be enabled. Currently a WARNING is triggered due to the spin locking
around free_buf, with a call stack like this:
WARNING: CPU: 3 PID: 121 at ./include/linux/dma-mapping.h:433
free_buf+0x1a8/0x288
Call Trace:
[<8040c538>] show_stack+0x74/0xc0
[<80757240>] dump_stack+0xd0/0x110
[<80430d98>] __warn+0xfc/0x130
[<80430ee0>] warn_slowpath_null+0x2c/0x3c
[<807e7c6c>] free_buf+0x1a8/0x288
[<807ea590>] remove_port_data+0x50/0xac
[<807ea6a0>] unplug_port+0xb4/0x1bc
[<807ea858>] virtcons_remove+0xb0/0xfc
[<807b6734>] virtio_dev_remove+0x58/0xc0
[<807f918c>] __device_release_driver+0xac/0x134
[<807f924c>] device_release_driver+0x38/0x50
[<807f7edc>] bus_remove_device+0xfc/0x130
[<807f4b74>] device_del+0x17c/0x21c
[<807f4c38>] device_unregister+0x24/0x38
[<807b6b50>] unregister_virtio_device+0x28/0x44
Fix this by restructuring the loops to allow the locks to only be taken
where it is necessary to protect the vqs, and release it while the
buffer is being freed.
Fixes: c6017e793b ("virtio: console: add locks around buffer removal in port unplug path")
Cc: stable@vger.kernel.org
Signed-off-by: Matt Redfearn <matt.redfearn@imgtec.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Matt Redfearn