OSDN Git Service
Greg Kroah-Hartman [Fri, 18 Oct 2019 01:13:43 +0000 (18:13 -0700)]
Merge 4.4.197 into android-4.4-p
Changes in 4.4.197
KVM: s390: Test for bad access register and size at the start of S390_MEM_OP
s390/topology: avoid firing events before kobjs are created
s390/cio: avoid calling strlen on null pointer
s390/cio: exclude subchannels with no parent from pseudo check
KVM: nVMX: handle page fault in vmread fix
ASoC: Define a set of DAPM pre/post-up events
powerpc/powernv: Restrict OPAL symbol map to only be readable by root
can: mcp251x: mcp251x_hw_reset(): allow more time after a reset
crypto: qat - Silence smp_processor_id() warning
ieee802154: atusb: fix use-after-free at disconnect
cfg80211: initialize on-stack chandefs
ima: always return negative code for error
fs: nfs: Fix possible null-pointer dereferences in encode_attrs()
9p: avoid attaching writeback_fid on mmap with type PRIVATE
xen/pci: reserve MCFG areas earlier
ceph: fix directories inode i_blkbits initialization
drm/amdgpu: Check for valid number of registers to read
thermal: Fix use-after-free when unregistering thermal zone device
fuse: fix memleak in cuse_channel_open
kernel/elfcore.c: include proper prototypes
tools lib traceevent: Do not free tep->cmdlines in add_new_comm() on failure
perf stat: Fix a segmentation fault when using repeat forever
crypto: caam - fix concurrency issue in givencrypt descriptor
cfg80211: add and use strongly typed element iteration macros
cfg80211: Use const more consistently in for_each_element macros
nl80211: validate beacon head
ASoC: sgtl5000: Improve VAG power and mute control
panic: ensure preemption is disabled during panic()
USB: rio500: Remove Rio 500 kernel driver
USB: yurex: Don't retry on unexpected errors
USB: yurex: fix NULL-derefs on disconnect
USB: usb-skeleton: fix runtime PM after driver unbind
USB: usb-skeleton: fix NULL-deref on disconnect
xhci: Prevent device initiated U1/U2 link pm if exit latency is too long
xhci: Check all endpoints for LPM timeout
usb: xhci: wait for CNR controller not ready bit in xhci resume
xhci: Increase STS_SAVE timeout in xhci_suspend()
USB: adutux: remove redundant variable minor
USB: adutux: fix use-after-free on disconnect
USB: adutux: fix NULL-derefs on disconnect
USB: adutux: fix use-after-free on release
USB: iowarrior: fix use-after-free on disconnect
USB: iowarrior: fix use-after-free on release
USB: iowarrior: fix use-after-free after driver unbind
USB: usblp: fix runtime PM after driver unbind
USB: chaoskey: fix use-after-free on release
USB: ldusb: fix NULL-derefs on driver unbind
serial: uartlite: fix exit path null pointer
USB: serial: keyspan: fix NULL-derefs on open() and write()
USB: serial: ftdi_sio: add device IDs for Sienna and Echelon PL-20
USB: serial: option: add Telit FN980 compositions
USB: serial: option: add support for Cinterion CLS8 devices
USB: serial: fix runtime PM after driver unbind
USB: usblcd: fix I/O after disconnect
USB: microtek: fix info-leak at probe
USB: dummy-hcd: fix power budget for SuperSpeed mode
usb: renesas_usbhs: gadget: Do not discard queues in usb_ep_set_{halt,wedge}()
usb: renesas_usbhs: gadget: Fix usb_ep_set_{halt,wedge}() behavior
USB: legousbtower: fix slab info leak at probe
USB: legousbtower: fix deadlock on disconnect
USB: legousbtower: fix potential NULL-deref on disconnect
USB: legousbtower: fix open after failed reset request
USB: legousbtower: fix use-after-free on release
staging: vt6655: Fix memory leak in vt6655_probe
iio: adc: ad799x: fix probe error handling
iio: light: opt3001: fix mutex unlock race
perf llvm: Don't access out-of-scope array
CIFS: Gracefully handle QueryInfo errors during open
CIFS: Force reval dentry if LOOKUP_REVAL flag is set
kernel/sysctl.c: do not override max_threads provided by userspace
arm64: capabilities: Handle sign of the feature bit
arm64: Rename cpuid_feature field extract routines
Staging: fbtft: fix memory leak in fbtft_framebuffer_alloc
cifs: Check uniqueid for SMB2+ and return -ESTALE if necessary
CIFS: Force revalidate inode when dentry is stale
media: stkwebcam: fix runtime PM after driver unbind
tracing: Get trace_array reference for available_tracers files
x86/asm: Fix MWAITX C-state hint value
xfs: clear sb->s_fs_info on mount failure
Linux 4.4.197
Change-Id: I0879b08629040431c71dae0d8b5474863d5e0391
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Greg Kroah-Hartman [Thu, 17 Oct 2019 20:41:06 +0000 (13:41 -0700)]
Linux 4.4.197
Dave Chinner [Fri, 11 May 2018 04:50:23 +0000 (21:50 -0700)]
xfs: clear sb->s_fs_info on mount failure
commit
c9fbd7bbc23dbdd73364be4d045e5d3612cf6e82 upstream.
We recently had an oops reported on a 4.14 kernel in
xfs_reclaim_inodes_count() where sb->s_fs_info pointed to garbage
and so the m_perag_tree lookup walked into lala land.
Essentially, the machine was under memory pressure when the mount
was being run, xfs_fs_fill_super() failed after allocating the
xfs_mount and attaching it to sb->s_fs_info. It then cleaned up and
freed the xfs_mount, but the sb->s_fs_info field still pointed to
the freed memory. Hence when the superblock shrinker then ran
it fell off the bad pointer.
With the superblock shrinker problem fixed at teh VFS level, this
stale s_fs_info pointer is still a problem - we use it
unconditionally in ->put_super when the superblock is being torn
down, and hence we can still trip over it after a ->fill_super
call failure. Hence we need to clear s_fs_info if
xfs-fs_fill_super() fails, and we need to check if it's valid in
the places it can potentially be dereferenced after a ->fill_super
failure.
Signed-Off-By: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Ajay Kaher <akaher@vmware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Janakarajan Natarajan [Mon, 7 Oct 2019 19:00:22 +0000 (19:00 +0000)]
x86/asm: Fix MWAITX C-state hint value
commit
454de1e7d970d6bc567686052329e4814842867c upstream.
As per "AMD64 Architecture Programmer's Manual Volume 3: General-Purpose
and System Instructions", MWAITX EAX[7:4]+1 specifies the optional hint
of the optimized C-state. For C0 state, EAX[7:4] should be set to 0xf.
Currently, a value of 0xf is set for EAX[3:0] instead of EAX[7:4]. Fix
this by changing MWAITX_DISABLE_CSTATES from 0xf to 0xf0.
This hasn't had any implications so far because setting reserved bits in
EAX is simply ignored by the CPU.
[ bp: Fixup comment in delay_mwaitx() and massage. ]
Signed-off-by: Janakarajan Natarajan <Janakarajan.Natarajan@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Frederic Weisbecker <frederic@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "x86@kernel.org" <x86@kernel.org>
Cc: Zhenzhong Duan <zhenzhong.duan@oracle.com>
Cc: <stable@vger.kernel.org>
Link: https://lkml.kernel.org/r/20191007190011.4859-1-Janakarajan.Natarajan@amd.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Steven Rostedt (VMware) [Fri, 11 Oct 2019 22:19:17 +0000 (18:19 -0400)]
tracing: Get trace_array reference for available_tracers files
commit
194c2c74f5532e62c218adeb8e2b683119503907 upstream.
As instances may have different tracers available, we need to look at the
trace_array descriptor that shows the list of the available tracers for the
instance. But there's a race between opening the file and an admin
deleting the instance. The trace_array_get() needs to be called before
accessing the trace_array.
Cc: stable@vger.kernel.org
Fixes:
607e2ea167e56 ("tracing: Set up infrastructure to allow tracers for instances")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 1 Oct 2019 08:49:08 +0000 (10:49 +0200)]
media: stkwebcam: fix runtime PM after driver unbind
commit
30045f2174aab7fb4db7a9cf902d0aa6c75856a7 upstream.
Since commit
c2b71462d294 ("USB: core: Fix bug caused by duplicate
interface PM usage counter") USB drivers must always balance their
runtime PM gets and puts, including when the driver has already been
unbound from the interface.
Leaving the interface with a positive PM usage counter would prevent a
later bound driver from suspending the device.
Note that runtime PM has never actually been enabled for this driver
since the support_autosuspend flag in its usb_driver struct is not set.
Fixes:
c2b71462d294 ("USB: core: Fix bug caused by duplicate interface PM usage counter")
Cc: stable <stable@vger.kernel.org>
Acked-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20191001084908.2003-5-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pavel Shilovsky [Mon, 30 Sep 2019 17:06:19 +0000 (10:06 -0700)]
CIFS: Force revalidate inode when dentry is stale
[ Upstream commit
c82e5ac7fe3570a269c0929bf7899f62048e7dbc ]
Currently the client indicates that a dentry is stale when inode
numbers or type types between a local inode and a remote file
don't match. If this is the case attributes is not being copied
from remote to local, so, it is already known that the local copy
has stale metadata. That's why the inode needs to be marked for
revalidation in order to tell the VFS to lookup the dentry again
before openning a file. This prevents unexpected stale errors
to be returned to the user space when openning a file.
Cc: <stable@vger.kernel.org>
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ross Lagerwall [Wed, 2 Dec 2015 14:46:08 +0000 (14:46 +0000)]
cifs: Check uniqueid for SMB2+ and return -ESTALE if necessary
[ Upstream commit
a108471b5730b52017e73b58c9f486319d2ac308 ]
Commit
7196ac113a4f ("Fix to check Unique id and FileType when client
refer file directly.") checks whether the uniqueid of an inode has
changed when getting the inode info, but only when using the UNIX
extensions. Add a similar check for SMB2+, since this can be done
without an extra network roundtrip.
Signed-off-by: Ross Lagerwall <ross.lagerwall@citrix.com>
Signed-off-by: Steve French <smfrench@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Navid Emamdoost [Mon, 30 Sep 2019 03:09:45 +0000 (22:09 -0500)]
Staging: fbtft: fix memory leak in fbtft_framebuffer_alloc
[ Upstream commit
5bdea6060618cfcf1459dca137e89aee038ac8b9 ]
In fbtft_framebuffer_alloc the error handling path should take care of
releasing frame buffer after it is allocated via framebuffer_alloc, too.
Therefore, in two failure cases the goto destination is changed to
address this issue.
Fixes:
c296d5f9957c ("staging: fbtft: core support")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190930030949.28615-1-navid.emamdoost@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Suzuki K Poulose [Mon, 14 Oct 2019 12:32:54 +0000 (13:32 +0100)]
arm64: Rename cpuid_feature field extract routines
commit
28c5dcb22f90113dea101b0421bc6971bccb7a74 upstream
Now that we have a clear understanding of the sign of a feature,
rename the routines to reflect the sign, so that it is not misused.
The cpuid_feature_extract_field() now accepts a 'sign' parameter.
This makes sure that the arm64_ftr_value() extracts the feature
field properly for signed fields.
Cc: stable@vger.kernel.org # v4.4
Signed-off-by: Suzuki K. Poulose <suzuki.poulose@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Suzuki K Poulose [Mon, 14 Oct 2019 12:32:53 +0000 (13:32 +0100)]
arm64: capabilities: Handle sign of the feature bit
commit
ff96f7bc7bf6393eef8ff2bde1279715ce13343a usptream
Use the appropriate accessor for the feature bit by keeping
track of the sign of the feature.
This is a pre-requisite for the commit
28c5dcb22f90 upstream,
which fixes the arm64_ftr_value() for signed feature fields.
Cc: stable@vger.kernel.org # v4.4
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michal Hocko [Mon, 7 Oct 2019 00:58:19 +0000 (17:58 -0700)]
kernel/sysctl.c: do not override max_threads provided by userspace
commit
b0f53dbc4bc4c371f38b14c391095a3bb8a0bb40 upstream.
Partially revert
16db3d3f1170 ("kernel/sysctl.c: threads-max observe
limits") because the patch is causing a regression to any workload which
needs to override the auto-tuning of the limit provided by kernel.
set_max_threads is implementing a boot time guesstimate to provide a
sensible limit of the concurrently running threads so that runaways will
not deplete all the memory. This is a good thing in general but there
are workloads which might need to increase this limit for an application
to run (reportedly WebSpher MQ is affected) and that is simply not
possible after the mentioned change. It is also very dubious to
override an admin decision by an estimation that doesn't have any direct
relation to correctness of the kernel operation.
Fix this by dropping set_max_threads from sysctl_max_threads so any
value is accepted as long as it fits into MAX_THREADS which is important
to check because allowing more threads could break internal robust futex
restriction. While at it, do not use MIN_THREADS as the lower boundary
because it is also only a heuristic for automatic estimation and admin
might have a good reason to stop new threads to be created even when
below this limit.
This became more severe when we switched x86 from 4k to 8k kernel
stacks. Starting since
6538b8ea886e ("x86_64: expand kernel stack to
16K") (3.16) we use THREAD_SIZE_ORDER = 2 and that halved the auto-tuned
value.
In the particular case
3.12
kernel.threads-max = 515561
4.4
kernel.threads-max = 200000
Neither of the two values is really insane on 32GB machine.
I am not sure we want/need to tune the max_thread value further. If
anything the tuning should be removed altogether if proven not useful in
general. But we definitely need a way to override this auto-tuning.
Link: http://lkml.kernel.org/r/20190922065801.GB18814@dhcp22.suse.cz
Fixes:
16db3d3f1170 ("kernel/sysctl.c: threads-max observe limits")
Signed-off-by: Michal Hocko <mhocko@suse.com>
Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: <stable@vger.kernel.org>
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>
Pavel Shilovsky [Mon, 30 Sep 2019 17:06:20 +0000 (10:06 -0700)]
CIFS: Force reval dentry if LOOKUP_REVAL flag is set
commit
0b3d0ef9840f7be202393ca9116b857f6f793715 upstream.
Mark inode for force revalidation if LOOKUP_REVAL flag is set.
This tells the client to actually send a QueryInfo request to
the server to obtain the latest metadata in case a directory
or a file were changed remotely. Only do that if the client
doesn't have a lease for the file to avoid unneeded round
trips to the server.
Cc: <stable@vger.kernel.org>
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pavel Shilovsky [Mon, 30 Sep 2019 17:06:18 +0000 (10:06 -0700)]
CIFS: Gracefully handle QueryInfo errors during open
commit
30573a82fb179420b8aac30a3a3595aa96a93156 upstream.
Currently if the client identifies problems when processing
metadata returned in CREATE response, the open handle is being
leaked. This causes multiple problems like a file missing a lease
break by that client which causes high latencies to other clients
accessing the file. Another side-effect of this is that the file
can't be deleted.
Fix this by closing the file after the client hits an error after
the file was opened and the open descriptor wasn't returned to
the user space. Also convert -ESTALE to -EOPENSTALE to allow
the VFS to revalidate a dentry and retry the open.
Cc: <stable@vger.kernel.org>
Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ian Rogers [Thu, 26 Sep 2019 22:00:18 +0000 (15:00 -0700)]
perf llvm: Don't access out-of-scope array
commit
7d4c85b7035eb2f9ab217ce649dcd1bfaf0cacd3 upstream.
The 'test_dir' variable is assigned to the 'release' array which is
out-of-scope 3 lines later.
Extend the scope of the 'release' array so that an out-of-scope array
isn't accessed.
Bug detected by clang's address sanitizer.
Fixes:
07bc5c699a3d ("perf tools: Make fetch_kernel_version() publicly available")
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Ian Rogers <irogers@google.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lore.kernel.org/lkml/20190926220018.25402-1-irogers@google.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
David Frey [Thu, 19 Sep 2019 22:54:18 +0000 (15:54 -0700)]
iio: light: opt3001: fix mutex unlock race
commit
82f3015635249a8c8c45bac303fd84905066f04f upstream.
When an end-of-conversion interrupt is received after performing a
single-shot reading of the light sensor, the driver was waking up the
result ready queue before checking opt->ok_to_ignore_lock to determine
if it should unlock the mutex. The problem occurred in the case where
the other thread woke up and changed the value of opt->ok_to_ignore_lock
to false prior to the interrupt thread performing its read of the
variable. In this case, the mutex would be unlocked twice.
Signed-off-by: David Frey <dpfrey@gmail.com>
Reviewed-by: Andreas Dannenberg <dannenberg@ti.com>
Fixes:
94a9b7b1809f ("iio: light: add support for TI's opt3001 light sensor")
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marco Felsch [Tue, 17 Sep 2019 16:09:23 +0000 (18:09 +0200)]
iio: adc: ad799x: fix probe error handling
commit
c62dd44901cfff12acc5792bf3d2dec20bcaf392 upstream.
Since commit
0f7ddcc1bff1 ("iio:adc:ad799x: Write default config on probe
and reset alert status on probe") the error path is wrong since it
leaves the vref regulator on. Fix this by disabling both regulators.
Fixes:
0f7ddcc1bff1 ("iio:adc:ad799x: Write default config on probe and reset alert status on probe")
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Reviewed-by: Alexandru Ardelean <alexandru.ardelean@analog.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Navid Emamdoost [Fri, 4 Oct 2019 20:03:15 +0000 (15:03 -0500)]
staging: vt6655: Fix memory leak in vt6655_probe
commit
80b15db5e1e9c3300de299b2d43d1aafb593e6ac upstream.
In vt6655_probe, if vnt_init() fails the cleanup code needs to be called
like other error handling cases. The call to device_free_info() is
added.
Fixes:
67013f2c0e58 ("staging: vt6655: mac80211 conversion add main mac80211 functions")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20191004200319.22394-1-navid.emamdoost@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 9 Oct 2019 15:38:47 +0000 (17:38 +0200)]
USB: legousbtower: fix use-after-free on release
commit
726b55d0e22ca72c69c947af87785c830289ddbc upstream.
The driver was accessing its struct usb_device in its release()
callback without holding a reference. This would lead to a
use-after-free whenever the device was disconnected while the character
device was still open.
Fixes:
fef526cae700 ("USB: legousbtower: remove custom debug macro")
Cc: stable <stable@vger.kernel.org> # 3.12
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20191009153848.8664-5-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 19 Sep 2019 08:30:39 +0000 (10:30 +0200)]
USB: legousbtower: fix open after failed reset request
commit
0b074f6986751361ff442bc1127c1648567aa8d6 upstream.
The driver would return with a nonzero open count in case the reset
control request failed. This would prevent any further attempts to open
the char dev until the device was disconnected.
Fix this by incrementing the open count only on successful open.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Johan Hovold <johan@kernel.org>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20190919083039.30898-5-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 19 Sep 2019 08:30:38 +0000 (10:30 +0200)]
USB: legousbtower: fix potential NULL-deref on disconnect
commit
cd81e6fa8e033e7bcd59415b4a65672b4780030b upstream.
The driver is using its struct usb_device pointer as an inverted
disconnected flag, but was setting it to NULL before making sure all
completion handlers had run. This could lead to a NULL-pointer
dereference in a number of dev_dbg and dev_err statements in the
completion handlers which relies on said pointer.
Fix this by unconditionally stopping all I/O and preventing
resubmissions by poisoning the interrupt URBs at disconnect and using a
dedicated disconnected flag.
This also makes sure that all I/O has completed by the time the
disconnect callback returns.
Fixes:
9d974b2a06e3 ("USB: legousbtower.c: remove err() usage")
Fixes:
fef526cae700 ("USB: legousbtower: remove custom debug macro")
Fixes:
4dae99638097 ("USB: legotower: remove custom debug macro and module parameter")
Cc: stable <stable@vger.kernel.org> # 3.5
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20190919083039.30898-4-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 19 Sep 2019 08:30:37 +0000 (10:30 +0200)]
USB: legousbtower: fix deadlock on disconnect
commit
33a7813219f208f4952ece60ee255fd983272dec upstream.
Fix a potential deadlock if disconnect races with open.
Since commit
d4ead16f50f9 ("USB: prevent char device open/deregister
race") core holds an rw-semaphore while open is called and when
releasing the minor number during deregistration. This can lead to an
ABBA deadlock if a driver takes a lock in open which it also holds
during deregistration.
This effectively reverts commit
78663ecc344b ("USB: disconnect open race
in legousbtower") which needlessly introduced this issue after a generic
fix for this race had been added to core by commit
d4ead16f50f9 ("USB:
prevent char device open/deregister race").
Fixes:
78663ecc344b ("USB: disconnect open race in legousbtower")
Cc: stable <stable@vger.kernel.org> # 2.6.24
Reported-by: syzbot+f9549f5ee8a5416f0b95@syzkaller.appspotmail.com
Tested-by: syzbot+f9549f5ee8a5416f0b95@syzkaller.appspotmail.com
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20190919083039.30898-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 19 Sep 2019 08:30:36 +0000 (10:30 +0200)]
USB: legousbtower: fix slab info leak at probe
commit
1d427be4a39defadda6dd8f4659bc17f7591740f upstream.
Make sure to check for short transfers when retrieving the version
information at probe to avoid leaking uninitialised slab data when
logging it.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20190919083039.30898-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yoshihiro Shimoda [Tue, 1 Oct 2019 10:10:33 +0000 (19:10 +0900)]
usb: renesas_usbhs: gadget: Fix usb_ep_set_{halt,wedge}() behavior
commit
4d599cd3a097a85a5c68a2c82b9a48cddf9953ec upstream.
According to usb_ep_set_halt()'s description,
__usbhsg_ep_set_halt_wedge() should return -EAGAIN if the IN endpoint
has any queue or data. Otherwise, this driver is possible to cause
just STALL without sending a short packet data on g_mass_storage driver,
and then a few resetting a device happens on a host side during
a usb enumaration.
Fixes:
2f98382dcdfe ("usb: renesas_usbhs: Add Renesas USBHS Gadget")
Cc: <stable@vger.kernel.org> # v3.0+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/1569924633-322-3-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yoshihiro Shimoda [Tue, 1 Oct 2019 10:10:32 +0000 (19:10 +0900)]
usb: renesas_usbhs: gadget: Do not discard queues in usb_ep_set_{halt,wedge}()
commit
1aae1394294cb71c6aa0bc904a94a7f2f1e75936 upstream.
The commit
97664a207bc2 ("usb: renesas_usbhs: shrink spin lock area")
had added a usbhsg_pipe_disable() calling into
__usbhsg_ep_set_halt_wedge() accidentally. But, this driver should
not call the usbhsg_pipe_disable() because the function discards
all queues. So, this patch removes it.
Fixes:
97664a207bc2 ("usb: renesas_usbhs: shrink spin lock area")
Cc: <stable@vger.kernel.org> # v3.1+
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/1569924633-322-2-git-send-email-yoshihiro.shimoda.uh@renesas.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jacky.Cao@sony.com [Thu, 5 Sep 2019 04:11:57 +0000 (04:11 +0000)]
USB: dummy-hcd: fix power budget for SuperSpeed mode
commit
2636d49b64671d3d90ecc4daf971b58df3956519 upstream.
The power budget for SuperSpeed mode should be 900 mA
according to USB specification, so set the power budget
to 900mA for dummy_start_ss which is only used for
SuperSpeed mode.
If the max power consumption of SuperSpeed device is
larger than 500 mA, insufficient available bus power
error happens in usb_choose_configuration function
when the device connects to dummy hcd.
Signed-off-by: Jacky Cao <Jacky.Cao@sony.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/16EA1F625E922C43B00B9D82250220500871CDE5@APYOKXMS108.ap.sony.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 3 Oct 2019 07:09:31 +0000 (09:09 +0200)]
USB: microtek: fix info-leak at probe
commit
177238c3d47d54b2ed8f0da7a4290db492f4a057 upstream.
Add missing bulk-in endpoint sanity check to prevent uninitialised stack
data from being reported to the system log and used as endpoint
addresses.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable <stable@vger.kernel.org>
Reported-by: syzbot+5630ca7c3b2be5c9da5e@syzkaller.appspotmail.com
Signed-off-by: Johan Hovold <johan@kernel.org>
Acked-by: Oliver Neukum <oneukum@suse.com>
Link: https://lore.kernel.org/r/20191003070931.17009-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 26 Sep 2019 09:12:25 +0000 (11:12 +0200)]
USB: usblcd: fix I/O after disconnect
commit
eb7f5a490c5edfe8126f64bc58b9ba2edef0a425 upstream.
Make sure to stop all I/O on disconnect by adding a disconnected flag
which is used to prevent new I/O from being started and by stopping all
ongoing I/O before returning.
This also fixes a potential use-after-free on driver unbind in case the
driver data is freed before the completion handler has run.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable <stable@vger.kernel.org> # 7bbe990c989e
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20190926091228.24634-7-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 1 Oct 2019 08:49:07 +0000 (10:49 +0200)]
USB: serial: fix runtime PM after driver unbind
commit
d51bdb93ca7e71d7fb30a572c7b47ed0194bf3fe upstream.
Since commit
c2b71462d294 ("USB: core: Fix bug caused by duplicate
interface PM usage counter") USB drivers must always balance their
runtime PM gets and puts, including when the driver has already been
unbound from the interface.
Leaving the interface with a positive PM usage counter would prevent a
later bound driver from suspending the device.
Fixes:
c2b71462d294 ("USB: core: Fix bug caused by duplicate interface PM usage counter")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20191001084908.2003-4-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reinhard Speyerer [Thu, 3 Oct 2019 16:53:21 +0000 (18:53 +0200)]
USB: serial: option: add support for Cinterion CLS8 devices
commit
dfbac2f4da6a0c4a8f6b4d715a4077a7b8df53ad upstream.
Add support for the serial ports of Cinterion CLS8 devices.
T: Bus=01 Lev=03 Prnt=05 Port=01 Cnt=02 Dev#= 25 Spd=480 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=1e2d ProdID=00b0 Rev= 3.18
S: Manufacturer=GEMALTO
S: Product=USB Modem
C:* #Ifs= 5 Cfg#= 1 Atr=80 MxPwr=500mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=42 Prot=01 Driver=(none)
E: Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=82(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=84(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=option
E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=86(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=qmi_wwan
E: Ad=89(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
E: Ad=88(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E: Ad=05(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
Signed-off-by: Reinhard Speyerer <rspmn@arcor.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Daniele Palmas [Mon, 23 Sep 2019 10:23:28 +0000 (12:23 +0200)]
USB: serial: option: add Telit FN980 compositions
commit
5eb3f4b87a0e7e949c976f32f296176a06d1a93b upstream.
This patch adds the following Telit FN980 compositions:
0x1050: tty, adb, rmnet, tty, tty, tty, tty
0x1051: tty, adb, mbim, tty, tty, tty, tty
0x1052: rndis, tty, adb, tty, tty, tty, tty
0x1053: tty, adb, ecm, tty, tty, tty, tty
Signed-off-by: Daniele Palmas <dnlplm@gmail.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Beni Mahler [Wed, 4 Sep 2019 22:26:20 +0000 (00:26 +0200)]
USB: serial: ftdi_sio: add device IDs for Sienna and Echelon PL-20
commit
357f16d9e0194cdbc36531ff88b453481560b76a upstream.
Both devices added here have a FTDI chip inside. The device from Echelon
is called 'Network Interface' it is actually a LON network gateway.
ID 0403:8348 Future Technology Devices International, Ltd
https://www.eltako.com/fileadmin/downloads/de/datenblatt/Datenblatt_PL-SW-PROF.pdf
ID 0920:7500 Network Interface
https://www.echelon.com/products/u20-usb-network-interface
Signed-off-by: Beni Mahler <beni.mahler@gmx.net>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 3 Oct 2019 13:49:58 +0000 (15:49 +0200)]
USB: serial: keyspan: fix NULL-derefs on open() and write()
commit
7d7e21fafdbc7fcf0854b877bd0975b487ed2717 upstream.
Fix NULL-pointer dereferences on open() and write() which can be
triggered by a malicious USB device.
The current URB allocation helper would fail to initialise the newly
allocated URB if the device has unexpected endpoint descriptors,
something which could lead NULL-pointer dereferences in a number of
open() and write() paths when accessing the URB. For example:
BUG: kernel NULL pointer dereference, address:
0000000000000000
...
RIP: 0010:usb_clear_halt+0x11/0xc0
...
Call Trace:
? tty_port_open+0x4d/0xd0
keyspan_open+0x70/0x160 [keyspan]
serial_port_activate+0x5b/0x80 [usbserial]
tty_port_open+0x7b/0xd0
? check_tty_count+0x43/0xa0
tty_open+0xf1/0x490
BUG: kernel NULL pointer dereference, address:
0000000000000000
...
RIP: 0010:keyspan_write+0x14e/0x1f3 [keyspan]
...
Call Trace:
serial_write+0x43/0xa0 [usbserial]
n_tty_write+0x1af/0x4f0
? do_wait_intr_irq+0x80/0x80
? process_echoes+0x60/0x60
tty_write+0x13f/0x2f0
BUG: kernel NULL pointer dereference, address:
0000000000000000
...
RIP: 0010:keyspan_usa26_send_setup+0x298/0x305 [keyspan]
...
Call Trace:
keyspan_open+0x10f/0x160 [keyspan]
serial_port_activate+0x5b/0x80 [usbserial]
tty_port_open+0x7b/0xd0
? check_tty_count+0x43/0xa0
tty_open+0xf1/0x490
Fixes:
fdcba53e2d58 ("fix for bugzilla #7544 (keyspan USB-to-serial converter)")
Cc: stable <stable@vger.kernel.org> # 2.6.21
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Randy Dunlap [Mon, 16 Sep 2019 23:12:23 +0000 (16:12 -0700)]
serial: uartlite: fix exit path null pointer
commit
a553add0846f355a28ed4e81134012e4a1e280c2 upstream.
Call uart_unregister_driver() conditionally instead of
unconditionally, only if it has been previously registered.
This uses driver.state, just as the sh-sci.c driver does.
Fixes this null pointer dereference in tty_unregister_driver(),
since the 'driver' argument is null:
general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI
RIP: 0010:tty_unregister_driver+0x25/0x1d0
Fixes:
238b8721a554 ("[PATCH] serial uartlite driver")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Cc: stable <stable@vger.kernel.org>
Cc: Peter Korsgaard <jacmet@sunsite.dk>
Link: https://lore.kernel.org/r/9c8e6581-6fcc-a595-0897-4d90f5d710df@infradead.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 9 Oct 2019 15:38:46 +0000 (17:38 +0200)]
USB: ldusb: fix NULL-derefs on driver unbind
commit
58ecf131e74620305175a7aa103f81350bb37570 upstream.
The driver was using its struct usb_interface pointer as an inverted
disconnected flag, but was setting it to NULL before making sure all
completion handlers had run. This could lead to a NULL-pointer
dereference in a number of dev_dbg, dev_warn and dev_err statements in
the completion handlers which relies on said pointer.
Fix this by unconditionally stopping all I/O and preventing
resubmissions by poisoning the interrupt URBs at disconnect and using a
dedicated disconnected flag.
This also makes sure that all I/O has completed by the time the
disconnect callback returns.
Fixes:
2824bd250f0b ("[PATCH] USB: add ldusb driver")
Cc: stable <stable@vger.kernel.org> # 2.6.13
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20191009153848.8664-4-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 9 Oct 2019 15:38:45 +0000 (17:38 +0200)]
USB: chaoskey: fix use-after-free on release
commit
93ddb1f56ae102f14f9e46a9a9c8017faa970003 upstream.
The driver was accessing its struct usb_interface in its release()
callback without holding a reference. This would lead to a
use-after-free whenever the device was disconnected while the character
device was still open.
Fixes:
66e3e591891d ("usb: Add driver for Altus Metrum ChaosKey device (v2)")
Cc: stable <stable@vger.kernel.org> # 4.1
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20191009153848.8664-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 1 Oct 2019 08:49:06 +0000 (10:49 +0200)]
USB: usblp: fix runtime PM after driver unbind
commit
9a31535859bfd8d1c3ed391f5e9247cd87bb7909 upstream.
Since commit
c2b71462d294 ("USB: core: Fix bug caused by duplicate
interface PM usage counter") USB drivers must always balance their
runtime PM gets and puts, including when the driver has already been
unbound from the interface.
Leaving the interface with a positive PM usage counter would prevent a
later bound driver from suspending the device.
Fixes:
c2b71462d294 ("USB: core: Fix bug caused by duplicate interface PM usage counter")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20191001084908.2003-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 9 Oct 2019 10:48:43 +0000 (12:48 +0200)]
USB: iowarrior: fix use-after-free after driver unbind
commit
b5f8d46867ca233d773408ffbe691a8062ed718f upstream.
Make sure to stop also the asynchronous write URBs on disconnect() to
avoid use-after-free in the completion handler after driver unbind.
Fixes:
946b960d13c1 ("USB: add driver for iowarrior devices.")
Cc: stable <stable@vger.kernel.org> # 2.6.21: 51a2f077c44e ("USB: introduce usb_anchor")
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20191009104846.5925-4-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 9 Oct 2019 10:48:42 +0000 (12:48 +0200)]
USB: iowarrior: fix use-after-free on release
commit
80cd5479b525093a56ef768553045741af61b250 upstream.
The driver was accessing its struct usb_interface from its release()
callback without holding a reference. This would lead to a
use-after-free whenever debugging was enabled and the device was
disconnected while its character device was open.
Fixes:
549e83500b80 ("USB: iowarrior: Convert local dbg macro to dev_dbg")
Cc: stable <stable@vger.kernel.org> # 3.16
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20191009104846.5925-3-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 9 Oct 2019 10:48:41 +0000 (12:48 +0200)]
USB: iowarrior: fix use-after-free on disconnect
commit
edc4746f253d907d048de680a621e121517f484b upstream.
A recent fix addressing a deadlock on disconnect introduced a new bug
by moving the present flag out of the critical section protected by the
driver-data mutex. This could lead to a racing release() freeing the
driver data before disconnect() is done with it.
Due to insufficient locking a related use-after-free could be triggered
also before the above mentioned commit. Specifically, the driver needs
to hold the driver-data mutex also while checking the opened flag at
disconnect().
Fixes:
c468a8aa790e ("usb: iowarrior: fix deadlock on disconnect")
Fixes:
946b960d13c1 ("USB: add driver for iowarrior devices.")
Cc: stable <stable@vger.kernel.org> # 2.6.21
Reported-by: syzbot+0761012cebf7bdb38137@syzkaller.appspotmail.com
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20191009104846.5925-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 9 Oct 2019 15:38:44 +0000 (17:38 +0200)]
USB: adutux: fix use-after-free on release
commit
123a0f125fa3d2104043697baa62899d9e549272 upstream.
The driver was accessing its struct usb_device in its release()
callback without holding a reference. This would lead to a
use-after-free whenever the device was disconnected while the character
device was still open.
Fixes:
66d4bc30d128 ("USB: adutux: remove custom debug macro")
Cc: stable <stable@vger.kernel.org> # 3.12
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20191009153848.8664-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 25 Sep 2019 09:29:13 +0000 (11:29 +0200)]
USB: adutux: fix NULL-derefs on disconnect
commit
b2fa7baee744fde746c17bc1860b9c6f5c2eebb7 upstream.
The driver was using its struct usb_device pointer as an inverted
disconnected flag, but was setting it to NULL before making sure all
completion handlers had run. This could lead to a NULL-pointer
dereference in a number of dev_dbg statements in the completion handlers
which relies on said pointer.
The pointer was also dereferenced unconditionally in a dev_dbg statement
release() something which would lead to a NULL-deref whenever a device
was disconnected before the final character-device close if debugging
was enabled.
Fix this by unconditionally stopping all I/O and preventing
resubmissions by poisoning the interrupt URBs at disconnect and using a
dedicated disconnected flag.
This also makes sure that all I/O has completed by the time the
disconnect callback returns.
Fixes:
1ef37c6047fe ("USB: adutux: remove custom debug macro and module parameter")
Fixes:
66d4bc30d128 ("USB: adutux: remove custom debug macro")
Cc: stable <stable@vger.kernel.org> # 3.12
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20190925092913.8608-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 25 Sep 2019 09:29:12 +0000 (11:29 +0200)]
USB: adutux: fix use-after-free on disconnect
commit
44efc269db7929f6275a1fa927ef082e533ecde0 upstream.
The driver was clearing its struct usb_device pointer, which it used as
an inverted disconnected flag, before deregistering the character device
and without serialising against racing release().
This could lead to a use-after-free if a racing release() callback
observes the cleared pointer and frees the driver data before
disconnect() is finished with it.
This could also lead to NULL-pointer dereferences in a racing open().
Fixes:
f08812d5eb8f ("USB: FIx locks and urb->status in adutux (updated)")
Cc: stable <stable@vger.kernel.org> # 2.6.24
Reported-by: syzbot+0243cb250a51eeefb8cc@syzkaller.appspotmail.com
Tested-by: syzbot+0243cb250a51eeefb8cc@syzkaller.appspotmail.com
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20190925092913.8608-1-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Colin Ian King [Tue, 7 Nov 2017 11:45:27 +0000 (11:45 +0000)]
USB: adutux: remove redundant variable minor
commit
8444efc4a052332d643ed5c8aebcca148c7de032 upstream.
Variable minor is being assigned but never read, hence it is redundant
and can be removed. Cleans up clang warning:
drivers/usb/misc/adutux.c:770:2: warning: Value stored to 'minor' is
never read
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Kai-Heng Feng [Fri, 4 Oct 2019 11:59:32 +0000 (14:59 +0300)]
xhci: Increase STS_SAVE timeout in xhci_suspend()
commit
ac343366846a445bb81f0a0e8f16abb8bd5d5d88 upstream.
After commit
f7fac17ca925 ("xhci: Convert xhci_handshake() to use
readl_poll_timeout_atomic()"), ASMedia xHCI may fail to suspend.
Although the algorithms are essentially the same, the old max timeout is
(usec + usec * time of doing readl()), and the new max timeout is just
usec, which is much less than the old one.
Increase the timeout to make ASMedia xHCI able to suspend again.
BugLink: https://bugs.launchpad.net/bugs/1844021
Fixes:
f7fac17ca925 ("xhci: Convert xhci_handshake() to use readl_poll_timeout_atomic()")
Cc: <stable@vger.kernel.org> # v5.2+
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/1570190373-30684-8-git-send-email-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Rick Tseng [Fri, 4 Oct 2019 11:59:30 +0000 (14:59 +0300)]
usb: xhci: wait for CNR controller not ready bit in xhci resume
commit
a70bcbc322837eda1ab5994d12db941dc9733a7d upstream.
NVIDIA 3.1 xHCI card would lose power when moving power state into D3Cold.
Thus we need to wait for CNR bit to clear in xhci resume, just as in
xhci init.
[Minor changes to comment and commit message -Mathias]
Cc: <stable@vger.kernel.org>
Signed-off-by: Rick Tseng <rtseng@nvidia.com>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/1570190373-30684-6-git-send-email-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jan Schmidt [Fri, 4 Oct 2019 11:59:28 +0000 (14:59 +0300)]
xhci: Check all endpoints for LPM timeout
commit
d500c63f80f2ea08ee300e57da5f2af1c13875f5 upstream.
If an endpoint is encountered that returns USB3_LPM_DEVICE_INITIATED, keep
checking further endpoints, as there might be periodic endpoints later
that return USB3_LPM_DISABLED due to shorter service intervals.
Without this, the code can set too high a maximum-exit-latency and
prevent the use of multiple USB3 cameras that should be able to work.
Cc: <stable@vger.kernel.org>
Signed-off-by: Jan Schmidt <jan@centricular.com>
Tested-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/1570190373-30684-4-git-send-email-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mathias Nyman [Fri, 4 Oct 2019 11:59:27 +0000 (14:59 +0300)]
xhci: Prevent device initiated U1/U2 link pm if exit latency is too long
commit
cd9d9491e835a845c1a98b8471f88d26285e0bb9 upstream.
If host/hub initiated link pm is prevented by a driver flag we still must
ensure that periodic endpoints have longer service intervals than link pm
exit latency before allowing device initiated link pm.
Fix this by continue walking and checking endpoint service interval if
xhci_get_timeout_no_hub_lpm() returns anything else than USB3_LPM_DISABLED
While at it fix the split line error message
Tested-by: Jan Schmidt <jan@centricular.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/1570190373-30684-3-git-send-email-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 9 Oct 2019 17:09:42 +0000 (19:09 +0200)]
USB: usb-skeleton: fix NULL-deref on disconnect
commit
bed5ef230943863b9abf5eae226a20fad9a8ff71 upstream.
The driver was using its struct usb_interface pointer as an inverted
disconnected flag and was setting it to NULL before making sure all
completion handlers had run. This could lead to NULL-pointer
dereferences in the dev_err() statements in the completion handlers
which relies on said pointer.
Fix this by using a dedicated disconnected flag.
Note that this is also addresses a NULL-pointer dereference at release()
and a struct usb_interface reference leak introduced by a recent runtime
PM fix, which depends on and should have been submitted together with
this patch.
Fixes:
4212cd74ca6f ("USB: usb-skeleton.c: remove err() usage")
Fixes:
5c290a5e42c3 ("USB: usb-skeleton: fix runtime PM after driver unbind")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20191009170944.30057-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 1 Oct 2019 08:49:05 +0000 (10:49 +0200)]
USB: usb-skeleton: fix runtime PM after driver unbind
commit
5c290a5e42c3387e82de86965784d30e6c5270fd upstream.
Since commit
c2b71462d294 ("USB: core: Fix bug caused by duplicate
interface PM usage counter") USB drivers must always balance their
runtime PM gets and puts, including when the driver has already been
unbound from the interface.
Leaving the interface with a positive PM usage counter would prevent a
later bound driver from suspending the device.
Fixes:
c2b71462d294 ("USB: core: Fix bug caused by duplicate interface PM usage counter")
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20191001084908.2003-2-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Wed, 9 Oct 2019 15:38:48 +0000 (17:38 +0200)]
USB: yurex: fix NULL-derefs on disconnect
commit
aafb00a977cf7d81821f7c9d12e04c558c22dc3c upstream.
The driver was using its struct usb_interface pointer as an inverted
disconnected flag, but was setting it to NULL without making sure all
code paths that used it were done with it.
Before commit
ef61eb43ada6 ("USB: yurex: Fix protection fault after
device removal") this included the interrupt-in completion handler, but
there are further accesses in dev_err and dev_dbg statements in
yurex_write() and the driver-data destructor (sic!).
Fix this by unconditionally stopping also the control URB at disconnect
and by using a dedicated disconnected flag.
Note that we need to take a reference to the struct usb_interface to
avoid a use-after-free in the destructor whenever the device was
disconnected while the character device was still open.
Fixes:
aadd6472d904 ("USB: yurex.c: remove dbg() usage")
Fixes:
45714104b9e8 ("USB: yurex.c: remove err() usage")
Cc: stable <stable@vger.kernel.org> # 3.5: ef61eb43ada6
Signed-off-by: Johan Hovold <johan@kernel.org>
Link: https://lore.kernel.org/r/20191009153848.8664-6-johan@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alan Stern [Tue, 17 Sep 2019 16:47:23 +0000 (12:47 -0400)]
USB: yurex: Don't retry on unexpected errors
commit
32a0721c6620b77504916dac0cea8ad497c4878a upstream.
According to Greg KH, it has been generally agreed that when a USB
driver encounters an unknown error (or one it can't handle directly),
it should just give up instead of going into a potentially infinite
retry loop.
The three codes -EPROTO, -EILSEQ, and -ETIME fall into this category.
They can be caused by bus errors such as packet loss or corruption,
attempting to communicate with a disconnected device, or by malicious
firmware. Nowadays the extent of packet loss or corruption is
negligible, so it should be safe for a driver to give up whenever one
of these errors occurs.
Although the yurex driver handles -EILSEQ errors in this way, it
doesn't do the same for -EPROTO (as discovered by the syzbot fuzzer)
or other unrecognized errors. This patch adjusts the driver so that
it doesn't log an error message for -EPROTO or -ETIME, and it doesn't
retry after any errors.
Reported-and-tested-by: syzbot+b24d736f18a1541ad550@syzkaller.appspotmail.com
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Tomoki Sekiyama <tomoki.sekiyama@gmail.com>
CC: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/Pine.LNX.4.44L0.1909171245410.1590-100000@iolanthe.rowland.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Bastien Nocera [Mon, 23 Sep 2019 16:18:43 +0000 (18:18 +0200)]
USB: rio500: Remove Rio 500 kernel driver
commit
015664d15270a112c2371d812f03f7c579b35a73 upstream.
The Rio500 kernel driver has not been used by Rio500 owners since 2001
not long after the rio500 project added support for a user-space USB stack
through the very first versions of usbdevfs and then libusb.
Support for the kernel driver was removed from the upstream utilities
in 2008:
https://gitlab.freedesktop.org/hadess/rio500/commit/
943f624ab721eb8281c287650fcc9e2026f6f5db
Cc: Cesar Miquel <miquel@df.uba.ar>
Signed-off-by: Bastien Nocera <hadess@hadess.net>
Cc: stable <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/6251c17584d220472ce882a3d9c199c401a51a71.camel@hadess.net
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Will Deacon [Mon, 7 Oct 2019 00:58:00 +0000 (17:58 -0700)]
panic: ensure preemption is disabled during panic()
commit
20bb759a66be52cf4a9ddd17fddaf509e11490cd upstream.
Calling 'panic()' on a kernel with CONFIG_PREEMPT=y can leave the
calling CPU in an infinite loop, but with interrupts and preemption
enabled. From this state, userspace can continue to be scheduled,
despite the system being "dead" as far as the kernel is concerned.
This is easily reproducible on arm64 when booting with "nosmp" on the
command line; a couple of shell scripts print out a periodic "Ping"
message whilst another triggers a crash by writing to
/proc/sysrq-trigger:
| sysrq: Trigger a crash
| Kernel panic - not syncing: sysrq triggered crash
| CPU: 0 PID: 1 Comm: init Not tainted 5.2.15 #1
| Hardware name: linux,dummy-virt (DT)
| Call trace:
| dump_backtrace+0x0/0x148
| show_stack+0x14/0x20
| dump_stack+0xa0/0xc4
| panic+0x140/0x32c
| sysrq_handle_reboot+0x0/0x20
| __handle_sysrq+0x124/0x190
| write_sysrq_trigger+0x64/0x88
| proc_reg_write+0x60/0xa8
| __vfs_write+0x18/0x40
| vfs_write+0xa4/0x1b8
| ksys_write+0x64/0xf0
| __arm64_sys_write+0x14/0x20
| el0_svc_common.constprop.0+0xb0/0x168
| el0_svc_handler+0x28/0x78
| el0_svc+0x8/0xc
| Kernel Offset: disabled
| CPU features: 0x0002,
24002004
| Memory Limit: none
| ---[ end Kernel panic - not syncing: sysrq triggered crash ]---
| Ping 2!
| Ping 1!
| Ping 1!
| Ping 2!
The issue can also be triggered on x86 kernels if CONFIG_SMP=n,
otherwise local interrupts are disabled in 'smp_send_stop()'.
Disable preemption in 'panic()' before re-enabling interrupts.
Link: http://lkml.kernel.org/r/20191002123538.22609-1-will@kernel.org
Link: https://lore.kernel.org/r/BX1W47JXPMR8.58IYW53H6M5N@dragonstone
Signed-off-by: Will Deacon <will@kernel.org>
Reported-by: Xogium <contact@xogium.me>
Reviewed-by: Kees Cook <keescook@chromium.org>
Cc: Russell King <linux@armlinux.org.uk>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Feng Tang <feng.tang@intel.com>
Cc: <stable@vger.kernel.org>
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>
Oleksandr Suvorov [Wed, 9 Oct 2019 14:29:41 +0000 (14:29 +0000)]
ASoC: sgtl5000: Improve VAG power and mute control
[ Upstream commit
b1f373a11d25fc9a5f7679c9b85799fe09b0dc4a ]
VAG power control is improved to fit the manual [1]. This patch fixes as
minimum one bug: if customer muxes Headphone to Line-In right after boot,
the VAG power remains off that leads to poor sound quality from line-in.
I.e. after boot:
- Connect sound source to Line-In jack;
- Connect headphone to HP jack;
- Run following commands:
$ amixer set 'Headphone' 80%
$ amixer set 'Headphone Mux' LINE_IN
Change VAG power on/off control according to the following algorithm:
- turn VAG power ON on the 1st incoming event.
- keep it ON if there is any active VAG consumer (ADC/DAC/HP/Line-In).
- turn VAG power OFF when there is the latest consumer's pre-down event
come.
- always delay after VAG power OFF to avoid pop.
- delay after VAG power ON if the initiative consumer is Line-In, this
prevents pop during line-in muxing.
According to the data sheet [1], to avoid any pops/clicks,
the outputs should be muted during input/output
routing changes.
[1] https://www.nxp.com/docs/en/data-sheet/SGTL5000.pdf
Cc: stable@vger.kernel.org
Fixes:
9b34e6cc3bc2 ("ASoC: Add Freescale SGTL5000 codec support")
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Reviewed-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20190719100524.23300-3-oleksandr.suvorov@toradex.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johannes Berg [Fri, 20 Sep 2019 19:54:17 +0000 (21:54 +0200)]
nl80211: validate beacon head
commit
f88eb7c0d002a67ef31aeb7850b42ff69abc46dc upstream.
We currently don't validate the beacon head, i.e. the header,
fixed part and elements that are to go in front of the TIM
element. This means that the variable elements there can be
malformed, e.g. have a length exceeding the buffer size, but
most downstream code from this assumes that this has already
been checked.
Add the necessary checks to the netlink policy.
Cc: stable@vger.kernel.org
Fixes:
ed1b6cc7f80f ("cfg80211/nl80211: add beacon settings")
Link: https://lore.kernel.org/r/1569009255-I7ac7fbe9436e9d8733439eab8acbbd35e55c74ef@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jouni Malinen [Mon, 11 Feb 2019 14:29:04 +0000 (16:29 +0200)]
cfg80211: Use const more consistently in for_each_element macros
commit
7388afe09143210f555bdd6c75035e9acc1fab96 upstream.
Enforce the first argument to be a correct type of a pointer to struct
element and avoid unnecessary typecasts from const to non-const pointers
(the change in validate_ie_attr() is needed to make this part work). In
addition, avoid signed/unsigned comparison within for_each_element() and
mark struct element packed just in case.
Signed-off-by: Jouni Malinen <j@w1.fi>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johannes Berg [Thu, 7 Feb 2019 20:44:41 +0000 (21:44 +0100)]
cfg80211: add and use strongly typed element iteration macros
commit
0f3b07f027f87a38ebe5c436490095df762819be upstream.
Rather than always iterating elements from frames with pure
u8 pointers, add a type "struct element" that encapsulates
the id/datalen/data format of them.
Then, add the element iteration macros
* for_each_element
* for_each_element_id
* for_each_element_extid
which take, as their first 'argument', such a structure and
iterate through a given u8 array interpreting it as elements.
While at it and since we'll need it, also add
* for_each_subelement
* for_each_subelement_id
* for_each_subelement_extid
which instead of taking data/length just take an outer element
and use its data/datalen.
Also add for_each_element_completed() to determine if any of
the loops above completed, i.e. it was able to parse all of
the elements successfully and no data remained.
Use for_each_element_id() in cfg80211_find_ie_match() as the
first user of this.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Horia Geantă [Tue, 30 Jul 2019 05:48:33 +0000 (08:48 +0300)]
crypto: caam - fix concurrency issue in givencrypt descriptor
commit
48f89d2a2920166c35b1c0b69917dbb0390ebec7 upstream.
IV transfer from ofifo to class2 (set up at [29][30]) is not guaranteed
to be scheduled before the data transfer from ofifo to external memory
(set up at [38]:
[29]
10FA0004 ld: ind-nfifo (len=4) imm
[30]
81F00010 <nfifo_entry: ofifo->class2 type=msg len=16>
[31]
14820004 ld: ccb2-datasz len=4 offs=0 imm
[32]
00000010 data:0x00000010
[33]
8210010D operation: cls1-op aes cbc init-final enc
[34]
A8080B04 math: (seqin + math0)->vseqout len=4
[35]
28000010 seqfifold: skip len=16
[36]
A8080A04 math: (seqin + math0)->vseqin len=4
[37]
2F1E0000 seqfifold: both msg1->2-last2-last1 len=vseqinsz
[38]
69300000 seqfifostr: msg len=vseqoutsz
[39]
5C20000C seqstr: ccb2 ctx len=12 offs=0
If ofifo -> external memory transfer happens first, DECO will hang
(issuing a Watchdog Timeout error, if WDOG is enabled) waiting for
data availability in ofifo for the ofifo -> c2 ififo transfer.
Make sure IV transfer happens first by waiting for all CAAM internal
transfers to end before starting payload transfer.
New descriptor with jump command inserted at [37]:
[..]
[36]
A8080A04 math: (seqin + math0)->vseqin len=4
[37]
A1000401 jump: jsl1 all-match[!nfifopend] offset=[01] local->[38]
[38]
2F1E0000 seqfifold: both msg1->2-last2-last1 len=vseqinsz
[39]
69300000 seqfifostr: msg len=vseqoutsz
[40]
5C20000C seqstr: ccb2 ctx len=12 offs=0
[Note: the issue is present in the descriptor from the very beginning
(cf. Fixes tag). However I've marked it v4.19+ since it's the oldest
maintained kernel that the patch applies clean against.]
Cc: <stable@vger.kernel.org> # v4.19+
Fixes:
1acebad3d8db8 ("crypto: caam - faster aead implementation")
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
[Horia: backport to v4.4, v4.9]
Signed-off-by: Horia Geantă <horia.geanta@nxp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Srikar Dronamraju [Wed, 4 Sep 2019 09:47:38 +0000 (15:17 +0530)]
perf stat: Fix a segmentation fault when using repeat forever
[ Upstream commit
443f2d5ba13d65ccfd879460f77941875159d154 ]
Observe a segmentation fault when 'perf stat' is asked to repeat forever
with the interval option.
Without fix:
# perf stat -r 0 -I 5000 -e cycles -a sleep 10
# time counts unit events
5.
000211692 3,13,89,82,34,157 cycles
10.
000380119 1,53,98,52,22,294 cycles
10.
040467280 17,16,79,265 cycles
Segmentation fault
This problem was only observed when we use forever option aka -r 0 and
works with limited repeats. Calling print_counter with ts being set to
NULL, is not a correct option when interval is set. Hence avoid
print_counter(NULL,..) if interval is set.
With fix:
# perf stat -r 0 -I 5000 -e cycles -a sleep 10
# time counts unit events
5.
019866622 3,15,14,43,08,697 cycles
10.
039865756 3,15,16,31,95,261 cycles
10.
059950628 1,26,05,47,158 cycles
5.
009902655 3,14,52,62,33,932 cycles
10.
019880228 3,14,52,22,89,154 cycles
10.
030543876 66,90,18,333 cycles
5.
009848281 3,14,51,98,25,437 cycles
10.
029854402 3,15,14,93,04,918 cycles
5.
009834177 3,14,51,95,92,316 cycles
Committer notes:
Did the 'git bisect' to find the cset introducing the problem to add the
Fixes tag below, and at that time the problem reproduced as:
(gdb) run stat -r0 -I500 sleep 1
<SNIP>
Program received signal SIGSEGV, Segmentation fault.
print_interval (prefix=prefix@entry=0x7fffffffc8d0 "", ts=ts@entry=0x0) at builtin-stat.c:866
866 sprintf(prefix, "%6lu.%09lu%s", ts->tv_sec, ts->tv_nsec, csv_sep);
(gdb) bt
#0 print_interval (prefix=prefix@entry=0x7fffffffc8d0 "", ts=ts@entry=0x0) at builtin-stat.c:866
#1 0x000000000041860a in print_counters (ts=ts@entry=0x0, argc=argc@entry=2, argv=argv@entry=0x7fffffffd640) at builtin-stat.c:938
#2 0x0000000000419a7f in cmd_stat (argc=2, argv=0x7fffffffd640, prefix=<optimized out>) at builtin-stat.c:1411
#3 0x000000000045c65a in run_builtin (p=p@entry=0x6291b8 <commands+216>, argc=argc@entry=5, argv=argv@entry=0x7fffffffd640) at perf.c:370
#4 0x000000000045c893 in handle_internal_command (argc=5, argv=0x7fffffffd640) at perf.c:429
#5 0x000000000045c8f1 in run_argv (argcp=argcp@entry=0x7fffffffd4ac, argv=argv@entry=0x7fffffffd4a0) at perf.c:473
#6 0x000000000045cac9 in main (argc=<optimized out>, argv=<optimized out>) at perf.c:588
(gdb)
Mostly the same as just before this patch:
Program received signal SIGSEGV, Segmentation fault.
0x00000000005874a7 in print_interval (config=0xa1f2a0 <stat_config>, evlist=0xbc9b90, prefix=0x7fffffffd1c0 "`", ts=0x0) at util/stat-display.c:964
964 sprintf(prefix, "%6lu.%09lu%s", ts->tv_sec, ts->tv_nsec, config->csv_sep);
(gdb) bt
#0 0x00000000005874a7 in print_interval (config=0xa1f2a0 <stat_config>, evlist=0xbc9b90, prefix=0x7fffffffd1c0 "`", ts=0x0) at util/stat-display.c:964
#1 0x0000000000588047 in perf_evlist__print_counters (evlist=0xbc9b90, config=0xa1f2a0 <stat_config>, _target=0xa1f0c0 <target>, ts=0x0, argc=2, argv=0x7fffffffd670)
at util/stat-display.c:1172
#2 0x000000000045390f in print_counters (ts=0x0, argc=2, argv=0x7fffffffd670) at builtin-stat.c:656
#3 0x0000000000456bb5 in cmd_stat (argc=2, argv=0x7fffffffd670) at builtin-stat.c:1960
#4 0x00000000004dd2e0 in run_builtin (p=0xa30e00 <commands+288>, argc=5, argv=0x7fffffffd670) at perf.c:310
#5 0x00000000004dd54d in handle_internal_command (argc=5, argv=0x7fffffffd670) at perf.c:362
#6 0x00000000004dd694 in run_argv (argcp=0x7fffffffd4cc, argv=0x7fffffffd4c0) at perf.c:406
#7 0x00000000004dda11 in main (argc=5, argv=0x7fffffffd670) at perf.c:531
(gdb)
Fixes:
d4f63a4741a8 ("perf stat: Introduce print_counters function")
Signed-off-by: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
Acked-by: Jiri Olsa <jolsa@kernel.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Tested-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: stable@vger.kernel.org # v4.2+
Link: http://lore.kernel.org/lkml/20190904094738.9558-3-srikar@linux.vnet.ibm.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Steven Rostedt (VMware) [Wed, 28 Aug 2019 19:05:28 +0000 (15:05 -0400)]
tools lib traceevent: Do not free tep->cmdlines in add_new_comm() on failure
[ Upstream commit
e0d2615856b2046c2e8d5bfd6933f37f69703b0b ]
If the re-allocation of tep->cmdlines succeeds, then the previous
allocation of tep->cmdlines will be freed. If we later fail in
add_new_comm(), we must not free cmdlines, and also should assign
tep->cmdlines to the new allocation. Otherwise when freeing tep, the
tep->cmdlines will be pointing to garbage.
Fixes:
a6d2a61ac653a ("tools lib traceevent: Remove some die() calls")
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: linux-trace-devel@vger.kernel.org
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20190828191819.970121417@goodmis.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Valdis Kletnieks [Wed, 25 Sep 2019 23:45:59 +0000 (16:45 -0700)]
kernel/elfcore.c: include proper prototypes
[ Upstream commit
0f74914071ab7e7b78731ed62bf350e3a344e0a5 ]
When building with W=1, gcc properly complains that there's no prototypes:
CC kernel/elfcore.o
kernel/elfcore.c:7:17: warning: no previous prototype for 'elf_core_extra_phdrs' [-Wmissing-prototypes]
7 | Elf_Half __weak elf_core_extra_phdrs(void)
| ^~~~~~~~~~~~~~~~~~~~
kernel/elfcore.c:12:12: warning: no previous prototype for 'elf_core_write_extra_phdrs' [-Wmissing-prototypes]
12 | int __weak elf_core_write_extra_phdrs(struct coredump_params *cprm, loff_t offset)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
kernel/elfcore.c:17:12: warning: no previous prototype for 'elf_core_write_extra_data' [-Wmissing-prototypes]
17 | int __weak elf_core_write_extra_data(struct coredump_params *cprm)
| ^~~~~~~~~~~~~~~~~~~~~~~~~
kernel/elfcore.c:22:15: warning: no previous prototype for 'elf_core_extra_data_size' [-Wmissing-prototypes]
22 | size_t __weak elf_core_extra_data_size(void)
| ^~~~~~~~~~~~~~~~~~~~~~~~
Provide the include file so gcc is happy, and we don't have potential code drift
Link: http://lkml.kernel.org/r/29875.1565224705@turing-police
Signed-off-by: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
zhengbin [Wed, 14 Aug 2019 07:59:09 +0000 (15:59 +0800)]
fuse: fix memleak in cuse_channel_open
[ Upstream commit
9ad09b1976c562061636ff1e01bfc3a57aebe56b ]
If cuse_send_init fails, need to fuse_conn_put cc->fc.
cuse_channel_open->fuse_conn_init->refcount_set(&fc->count, 1)
->fuse_dev_alloc->fuse_conn_get
->fuse_dev_free->fuse_conn_put
Fixes:
cc080e9e9be1 ("fuse: introduce per-instance fuse_dev structure")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: zhengbin <zhengbin13@huawei.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ido Schimmel [Wed, 10 Jul 2019 10:14:52 +0000 (13:14 +0300)]
thermal: Fix use-after-free when unregistering thermal zone device
[ Upstream commit
1851799e1d2978f68eea5d9dff322e121dcf59c1 ]
thermal_zone_device_unregister() cancels the delayed work that polls the
thermal zone, but it does not wait for it to finish. This is racy with
respect to the freeing of the thermal zone device, which can result in a
use-after-free [1].
Fix this by waiting for the delayed work to finish before freeing the
thermal zone device. Note that thermal_zone_device_set_polling() is
never invoked from an atomic context, so it is safe to call
cancel_delayed_work_sync() that can block.
[1]
[ +0.002221] ==================================================================
[ +0.000064] BUG: KASAN: use-after-free in __mutex_lock+0x1076/0x11c0
[ +0.000016] Read of size 8 at addr
ffff8881e48e0450 by task kworker/1:0/17
[ +0.000023] CPU: 1 PID: 17 Comm: kworker/1:0 Not tainted
5.2.0-rc6-custom-02495-g8e73ca3be4af #1701
[ +0.000010] Hardware name: Mellanox Technologies Ltd. MSN2100-CB2FO/SA001017, BIOS 5.6.5 06/07/2016
[ +0.000016] Workqueue: events_freezable_power_ thermal_zone_device_check
[ +0.000012] Call Trace:
[ +0.000021] dump_stack+0xa9/0x10e
[ +0.000020] print_address_description.cold.2+0x9/0x25e
[ +0.000018] __kasan_report.cold.3+0x78/0x9d
[ +0.000016] kasan_report+0xe/0x20
[ +0.000016] __mutex_lock+0x1076/0x11c0
[ +0.000014] step_wise_throttle+0x72/0x150
[ +0.000018] handle_thermal_trip+0x167/0x760
[ +0.000019] thermal_zone_device_update+0x19e/0x5f0
[ +0.000019] process_one_work+0x969/0x16f0
[ +0.000017] worker_thread+0x91/0xc40
[ +0.000014] kthread+0x33d/0x400
[ +0.000015] ret_from_fork+0x3a/0x50
[ +0.000020] Allocated by task 1:
[ +0.000015] save_stack+0x19/0x80
[ +0.000015] __kasan_kmalloc.constprop.4+0xc1/0xd0
[ +0.000014] kmem_cache_alloc_trace+0x152/0x320
[ +0.000015] thermal_zone_device_register+0x1b4/0x13a0
[ +0.000015] mlxsw_thermal_init+0xc92/0x23d0
[ +0.000014] __mlxsw_core_bus_device_register+0x659/0x11b0
[ +0.000013] mlxsw_core_bus_device_register+0x3d/0x90
[ +0.000013] mlxsw_pci_probe+0x355/0x4b0
[ +0.000014] local_pci_probe+0xc3/0x150
[ +0.000013] pci_device_probe+0x280/0x410
[ +0.000013] really_probe+0x26a/0xbb0
[ +0.000013] driver_probe_device+0x208/0x2e0
[ +0.000013] device_driver_attach+0xfe/0x140
[ +0.000013] __driver_attach+0x110/0x310
[ +0.000013] bus_for_each_dev+0x14b/0x1d0
[ +0.000013] driver_register+0x1c0/0x400
[ +0.000015] mlxsw_sp_module_init+0x5d/0xd3
[ +0.000014] do_one_initcall+0x239/0x4dd
[ +0.000013] kernel_init_freeable+0x42b/0x4e8
[ +0.000012] kernel_init+0x11/0x18b
[ +0.000013] ret_from_fork+0x3a/0x50
[ +0.000015] Freed by task 581:
[ +0.000013] save_stack+0x19/0x80
[ +0.000014] __kasan_slab_free+0x125/0x170
[ +0.000013] kfree+0xf3/0x310
[ +0.000013] thermal_release+0xc7/0xf0
[ +0.000014] device_release+0x77/0x200
[ +0.000014] kobject_put+0x1a8/0x4c0
[ +0.000014] device_unregister+0x38/0xc0
[ +0.000014] thermal_zone_device_unregister+0x54e/0x6a0
[ +0.000014] mlxsw_thermal_fini+0x184/0x35a
[ +0.000014] mlxsw_core_bus_device_unregister+0x10a/0x640
[ +0.000013] mlxsw_devlink_core_bus_device_reload+0x92/0x210
[ +0.000015] devlink_nl_cmd_reload+0x113/0x1f0
[ +0.000014] genl_family_rcv_msg+0x700/0xee0
[ +0.000013] genl_rcv_msg+0xca/0x170
[ +0.000013] netlink_rcv_skb+0x137/0x3a0
[ +0.000012] genl_rcv+0x29/0x40
[ +0.000013] netlink_unicast+0x49b/0x660
[ +0.000013] netlink_sendmsg+0x755/0xc90
[ +0.000013] __sys_sendto+0x3de/0x430
[ +0.000013] __x64_sys_sendto+0xe2/0x1b0
[ +0.000013] do_syscall_64+0xa4/0x4d0
[ +0.000013] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ +0.000017] The buggy address belongs to the object at
ffff8881e48e0008
which belongs to the cache kmalloc-2k of size 2048
[ +0.000012] The buggy address is located 1096 bytes inside of
2048-byte region [
ffff8881e48e0008,
ffff8881e48e0808)
[ +0.000007] The buggy address belongs to the page:
[ +0.000012] page:
ffffea0007923800 refcount:1 mapcount:0 mapping:
ffff88823680d0c0 index:0x0 compound_mapcount: 0
[ +0.000020] flags: 0x200000000010200(slab|head)
[ +0.000019] raw:
0200000000010200 ffffea0007682008 ffffea00076ab808 ffff88823680d0c0
[ +0.000016] raw:
0000000000000000 00000000000d000d 00000001ffffffff 0000000000000000
[ +0.000007] page dumped because: kasan: bad access detected
[ +0.000012] Memory state around the buggy address:
[ +0.000012]
ffff8881e48e0300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ +0.000012]
ffff8881e48e0380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ +0.000012] >
ffff8881e48e0400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ +0.000008] ^
[ +0.000012]
ffff8881e48e0480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ +0.000012]
ffff8881e48e0500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ +0.000007] ==================================================================
Fixes:
b1569e99c795 ("ACPI: move thermal trip handling to generic thermal layer")
Reported-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Trek [Sat, 31 Aug 2019 19:25:36 +0000 (21:25 +0200)]
drm/amdgpu: Check for valid number of registers to read
[ Upstream commit
73d8e6c7b841d9bf298c8928f228fb433676635c ]
Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15 (0x2644-0x2673).
Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111273
Signed-off-by: Trek <trek00@inbox.ru>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Luis Henriques [Tue, 23 Jul 2019 15:50:20 +0000 (16:50 +0100)]
ceph: fix directories inode i_blkbits initialization
[ Upstream commit
750670341a24cb714e624e0fd7da30900ad93752 ]
When filling an inode with info from the MDS, i_blkbits is being
initialized using fl_stripe_unit, which contains the stripe unit in
bytes. Unfortunately, this doesn't make sense for directories as they
have fl_stripe_unit set to '0'. This means that i_blkbits will be set
to 0xff, causing an UBSAN undefined behaviour in i_blocksize():
UBSAN: Undefined behaviour in ./include/linux/fs.h:731:12
shift exponent 255 is too large for 32-bit type 'int'
Fix this by initializing i_blkbits to CEPH_BLOCK_SHIFT if fl_stripe_unit
is zero.
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Igor Druzhinin [Thu, 12 Sep 2019 18:31:51 +0000 (19:31 +0100)]
xen/pci: reserve MCFG areas earlier
[ Upstream commit
a4098bc6eed5e31e0391bcc068e61804c98138df ]
If MCFG area is not reserved in E820, Xen by default will defer its usage
until Dom0 registers it explicitly after ACPI parser recognizes it as
a reserved resource in DSDT. Having it reserved in E820 is not
mandatory according to "PCI Firmware Specification, rev 3.2" (par. 4.1.2)
and firmware is free to keep a hole in E820 in that place. Xen doesn't know
what exactly is inside this hole since it lacks full ACPI view of the
platform therefore it's potentially harmful to access MCFG region
without additional checks as some machines are known to provide
inconsistent information on the size of the region.
Now xen_mcfg_late() runs after acpi_init() which is too late as some basic
PCI enumeration starts exactly there as well. Trying to register a device
prior to MCFG reservation causes multiple problems with PCIe extended
capability initializations in Xen (e.g. SR-IOV VF BAR sizing). There are
no convenient hooks for us to subscribe to so register MCFG areas earlier
upon the first invocation of xen_add_device(). It should be safe to do once
since all the boot time buses must have their MCFG areas in MCFG table
already and we don't support PCI bus hot-plug.
Signed-off-by: Igor Druzhinin <igor.druzhinin@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chengguang Xu [Tue, 20 Aug 2019 10:03:25 +0000 (18:03 +0800)]
9p: avoid attaching writeback_fid on mmap with type PRIVATE
[ Upstream commit
c87a37ebd40b889178664c2c09cc187334146292 ]
Currently on mmap cache policy, we always attach writeback_fid
whether mmap type is SHARED or PRIVATE. However, in the use case
of kata-container which combines 9p(Guest OS) with overlayfs(Host OS),
this behavior will trigger overlayfs' copy-up when excute command
inside container.
Link: http://lkml.kernel.org/r/20190820100325.10313-1-cgxu519@zoho.com.cn
Signed-off-by: Chengguang Xu <cgxu519@zoho.com.cn>
Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jia-Ju Bai [Fri, 26 Jul 2019 07:48:53 +0000 (15:48 +0800)]
fs: nfs: Fix possible null-pointer dereferences in encode_attrs()
[ Upstream commit
e2751463eaa6f9fec8fea80abbdc62dbc487b3c5 ]
In encode_attrs(), there is an if statement on line 1145 to check
whether label is NULL:
if (label && (attrmask[2] & FATTR4_WORD2_SECURITY_LABEL))
When label is NULL, it is used on lines 1178-1181:
*p++ = cpu_to_be32(label->lfs);
*p++ = cpu_to_be32(label->pi);
*p++ = cpu_to_be32(label->len);
p = xdr_encode_opaque_fixed(p, label->label, label->len);
To fix these bugs, label is checked before being used.
These bugs are found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sascha Hauer [Tue, 2 Jul 2019 08:00:40 +0000 (10:00 +0200)]
ima: always return negative code for error
[ Upstream commit
f5e1040196dbfe14c77ce3dfe3b7b08d2d961e88 ]
integrity_kernel_read() returns the number of bytes read. If this is
a short read then this positive value is returned from
ima_calc_file_hash_atfm(). Currently this is only indirectly called from
ima_calc_file_hash() and this function only tests for the return value
being zero or nonzero and also doesn't forward the return value.
Nevertheless there's no point in returning a positive value as an error,
so translate a short read into -EINVAL.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Signed-off-by: Mimi Zohar <zohar@linux.ibm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johannes Berg [Mon, 23 Sep 2019 11:51:16 +0000 (13:51 +0200)]
cfg80211: initialize on-stack chandefs
commit
f43e5210c739fe76a4b0ed851559d6902f20ceb1 upstream.
In a few places we don't properly initialize on-stack chandefs,
resulting in EDMG data to be non-zero, which broke things.
Additionally, in a few places we rely on the driver to init the
data completely, but perhaps we shouldn't as non-EDMG drivers
may not initialize the EDMG data, also initialize it there.
Cc: stable@vger.kernel.org
Fixes:
2a38075cd0be ("nl80211: Add support for EDMG channels")
Reported-by: Dmitry Osipenko <digetx@gmail.com>
Tested-by: Dmitry Osipenko <digetx@gmail.com>
Link: https://lore.kernel.org/r/1569239475-I2dcce394ecf873376c386a78f31c2ec8b538fa25@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Thu, 19 Sep 2019 12:12:34 +0000 (14:12 +0200)]
ieee802154: atusb: fix use-after-free at disconnect
commit
7fd25e6fc035f4b04b75bca6d7e8daa069603a76 upstream.
The disconnect callback was accessing the hardware-descriptor private
data after having having freed it.
Fixes:
7490b008d123 ("ieee802154: add support for atusb transceiver")
Cc: stable <stable@vger.kernel.org> # 4.2
Cc: Alexander Aring <alex.aring@gmail.com>
Reported-by: syzbot+f4509a9138a1472e7e80@syzkaller.appspotmail.com
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Stefan Schmidt <stefan@datenfreihafen.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Alexander Sverdlin [Tue, 23 Jul 2019 07:24:01 +0000 (07:24 +0000)]
crypto: qat - Silence smp_processor_id() warning
commit
1b82feb6c5e1996513d0fb0bbb475417088b4954 upstream.
It seems that smp_processor_id() is only used for a best-effort
load-balancing, refer to qat_crypto_get_instance_node(). It's not feasible
to disable preemption for the duration of the crypto requests. Therefore,
just silence the warning. This commit is similar to
e7a9b05ca4
("crypto: cavium - Fix smp_processor_id() warnings").
Silences the following splat:
BUG: using smp_processor_id() in preemptible [
00000000] code: cryptomgr_test/2904
caller is qat_alg_ablkcipher_setkey+0x300/0x4a0 [intel_qat]
CPU: 1 PID: 2904 Comm: cryptomgr_test Tainted: P O 4.14.69 #1
...
Call Trace:
dump_stack+0x5f/0x86
check_preemption_disabled+0xd3/0xe0
qat_alg_ablkcipher_setkey+0x300/0x4a0 [intel_qat]
skcipher_setkey_ablkcipher+0x2b/0x40
__test_skcipher+0x1f3/0xb20
? cpumask_next_and+0x26/0x40
? find_busiest_group+0x10e/0x9d0
? preempt_count_add+0x49/0xa0
? try_module_get+0x61/0xf0
? crypto_mod_get+0x15/0x30
? __kmalloc+0x1df/0x1f0
? __crypto_alloc_tfm+0x116/0x180
? crypto_skcipher_init_tfm+0xa6/0x180
? crypto_create_tfm+0x4b/0xf0
test_skcipher+0x21/0xa0
alg_test_skcipher+0x3f/0xa0
alg_test.part.6+0x126/0x2a0
? finish_task_switch+0x21b/0x260
? __schedule+0x1e9/0x800
? __wake_up_common+0x8d/0x140
cryptomgr_test+0x40/0x50
kthread+0xff/0x130
? cryptomgr_notify+0x540/0x540
? kthread_create_on_node+0x70/0x70
ret_from_fork+0x24/0x50
Fixes:
ed8ccaef52 ("crypto: qat - Add support for SRIOV")
Cc: stable@vger.kernel.org
Signed-off-by: Alexander Sverdlin <alexander.sverdlin@nokia.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Marc Kleine-Budde [Tue, 13 Aug 2019 14:01:02 +0000 (16:01 +0200)]
can: mcp251x: mcp251x_hw_reset(): allow more time after a reset
commit
d84ea2123f8d27144e3f4d58cd88c9c6ddc799de upstream.
Some boards take longer than 5ms to power up after a reset, so allow
some retries attempts before giving up.
Fixes:
ff06d611a31c ("can: mcp251x: Improve mcp251x_hw_reset()")
Cc: linux-stable <stable@vger.kernel.org>
Tested-by: Sean Nyekjaer <sean@geanix.com>
Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrew Donnellan [Fri, 3 May 2019 07:52:53 +0000 (17:52 +1000)]
powerpc/powernv: Restrict OPAL symbol map to only be readable by root
commit
e7de4f7b64c23e503a8c42af98d56f2a7462bd6d upstream.
Currently the OPAL symbol map is globally readable, which seems bad as
it contains physical addresses.
Restrict it to root.
Fixes:
c8742f85125d ("powerpc/powernv: Expose OPAL firmware symbol map")
Cc: stable@vger.kernel.org # v3.19+
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20190503075253.22798-1-ajd@linux.ibm.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Oleksandr Suvorov [Fri, 19 Jul 2019 10:05:30 +0000 (10:05 +0000)]
ASoC: Define a set of DAPM pre/post-up events
commit
cfc8f568aada98f9608a0a62511ca18d647613e2 upstream.
Prepare to use SND_SOC_DAPM_PRE_POST_PMU definition to
reduce coming code size and make it more readable.
Cc: stable@vger.kernel.org
Signed-off-by: Oleksandr Suvorov <oleksandr.suvorov@toradex.com>
Reviewed-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Reviewed-by: Igor Opaniuk <igor.opaniuk@toradex.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Link: https://lore.kernel.org/r/20190719100524.23300-2-oleksandr.suvorov@toradex.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jack Wang [Mon, 7 Oct 2019 12:36:53 +0000 (14:36 +0200)]
KVM: nVMX: handle page fault in vmread fix
During backport
f7eea636c3d5 ("KVM: nVMX: handle page fault in vmread"),
there was a mistake the exception reference should be passed to function
kvm_write_guest_virt_system, instead of NULL, other wise, we will get
NULL pointer deref, eg
kvm-unit-test triggered a NULL pointer deref below:
[ 948.518437] kvm [24114]: vcpu0, guest rIP: 0x407ef9 kvm_set_msr_common: MSR_IA32_DEBUGCTLMSR 0x3, nop
[ 949.106464] BUG: unable to handle kernel NULL pointer dereference at
0000000000000000
[ 949.106707] PGD 0 P4D 0
[ 949.106872] Oops: 0002 [#1] SMP
[ 949.107038] CPU: 2 PID: 24126 Comm: qemu-2.7 Not tainted 4.19.77-pserver #4.19.77-1+feature+daily+update+
20191005.1625+
a4168bb~deb9
[ 949.107283] Hardware name: Dell Inc. Precision Tower 3620/09WH54, BIOS 2.7.3 01/31/2018
[ 949.107549] RIP: 0010:kvm_write_guest_virt_system+0x12/0x40 [kvm]
[ 949.107719] Code: c0 5d 41 5c 41 5d 41 5e 83 f8 03 41 0f 94 c0 41 c1 e0 02 e9 b0 ed ff ff 0f 1f 44 00 00 48 89 f0 c6 87 59 56 00 00 01 48 89 d6 <49> c7 00 00 00 00 00 89 ca 49 c7 40 08 00 00 00 00 49 c7 40 10 00
[ 949.108044] RSP: 0018:
ffffb31b0a953cb0 EFLAGS:
00010202
[ 949.108216] RAX:
000000000046b4d8 RBX:
ffff9e9f415b0000 RCX:
0000000000000008
[ 949.108389] RDX:
ffffb31b0a953cc0 RSI:
ffffb31b0a953cc0 RDI:
ffff9e9f415b0000
[ 949.108562] RBP:
00000000d2e14928 R08:
0000000000000000 R09:
0000000000000000
[ 949.108733] R10:
0000000000000000 R11:
0000000000000000 R12:
ffffffffffffffc8
[ 949.108907] R13:
0000000000000002 R14:
ffff9e9f4f26f2e8 R15:
0000000000000000
[ 949.109079] FS:
00007eff8694c700(0000) GS:
ffff9e9f51a80000(0000) knlGS:
0000000031415928
[ 949.109318] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 949.109495] CR2:
0000000000000000 CR3:
00000003be53b002 CR4:
00000000003626e0
[ 949.109671] DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
[ 949.109845] DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
[ 949.110017] Call Trace:
[ 949.110186] handle_vmread+0x22b/0x2f0 [kvm_intel]
[ 949.110356] ? vmexit_fill_RSB+0xc/0x30 [kvm_intel]
[ 949.110549] kvm_arch_vcpu_ioctl_run+0xa98/0x1b30 [kvm]
[ 949.110725] ? kvm_vcpu_ioctl+0x388/0x5d0 [kvm]
[ 949.110901] kvm_vcpu_ioctl+0x388/0x5d0 [kvm]
[ 949.111072] do_vfs_ioctl+0xa2/0x620
Signed-off-by: Jack Wang <jinpu.wang@cloud.ionos.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Vasily Gorbik [Thu, 19 Sep 2019 13:55:17 +0000 (15:55 +0200)]
s390/cio: exclude subchannels with no parent from pseudo check
commit
ab5758848039de9a4b249d46e4ab591197eebaf2 upstream.
ccw console is created early in start_kernel and used before css is
initialized or ccw console subchannel is registered. Until then console
subchannel does not have a parent. For that reason assume subchannels
with no parent are not pseudo subchannels. This fixes the following
kasan finding:
BUG: KASAN: global-out-of-bounds in sch_is_pseudo_sch+0x8e/0x98
Read of size 8 at addr
00000000000005e8 by task swapper/0/0
CPU: 0 PID: 0 Comm: swapper/0 Not tainted
5.3.0-rc8-07370-g6ac43dd12538 #2
Hardware name: IBM 2964 NC9 702 (z/VM 6.4.0)
Call Trace:
([<
000000000012cd76>] show_stack+0x14e/0x1e0)
[<
0000000001f7fb44>] dump_stack+0x1a4/0x1f8
[<
00000000007d7afc>] print_address_description+0x64/0x3c8
[<
00000000007d75f6>] __kasan_report+0x14e/0x180
[<
00000000018a2986>] sch_is_pseudo_sch+0x8e/0x98
[<
000000000189b950>] cio_enable_subchannel+0x1d0/0x510
[<
00000000018cac7c>] ccw_device_recognition+0x12c/0x188
[<
0000000002ceb1a8>] ccw_device_enable_console+0x138/0x340
[<
0000000002cf1cbe>] con3215_init+0x25e/0x300
[<
0000000002c8770a>] console_init+0x68a/0x9b8
[<
0000000002c6a3d6>] start_kernel+0x4fe/0x728
[<
0000000000100070>] startup_continue+0x70/0xd0
Cc: stable@vger.kernel.org
Reviewed-by: Sebastian Ott <sebott@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vasily Gorbik [Tue, 17 Sep 2019 18:04:04 +0000 (20:04 +0200)]
s390/cio: avoid calling strlen on null pointer
commit
ea298e6ee8b34b3ed4366be7eb799d0650ebe555 upstream.
Fix the following kasan finding:
BUG: KASAN: global-out-of-bounds in ccwgroup_create_dev+0x850/0x1140
Read of size 1 at addr
0000000000000000 by task systemd-udevd.r/561
CPU: 30 PID: 561 Comm: systemd-udevd.r Tainted: G B
Hardware name: IBM 3906 M04 704 (LPAR)
Call Trace:
([<
0000000231b3db7e>] show_stack+0x14e/0x1a8)
[<
0000000233826410>] dump_stack+0x1d0/0x218
[<
000000023216fac4>] print_address_description+0x64/0x380
[<
000000023216f5a8>] __kasan_report+0x138/0x168
[<
00000002331b8378>] ccwgroup_create_dev+0x850/0x1140
[<
00000002332b618a>] group_store+0x3a/0x50
[<
00000002323ac706>] kernfs_fop_write+0x246/0x3b8
[<
00000002321d409a>] vfs_write+0x132/0x450
[<
00000002321d47da>] ksys_write+0x122/0x208
[<
0000000233877102>] system_call+0x2a6/0x2c8
Triggered by:
openat(AT_FDCWD, "/sys/bus/ccwgroup/drivers/qeth/group",
O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 16
write(16, "0.0.bd00,0.0.bd01,0.0.bd02", 26) = 26
The problem is that __get_next_id in ccwgroup_create_dev might set "buf"
buffer pointer to NULL and explicit check for that is required.
Cc: stable@vger.kernel.org
Reviewed-by: Sebastian Ott <sebott@linux.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Vasily Gorbik [Tue, 17 Sep 2019 20:59:03 +0000 (22:59 +0200)]
s390/topology: avoid firing events before kobjs are created
commit
f3122a79a1b0a113d3aea748e0ec26f2cb2889de upstream.
arch_update_cpu_topology is first called from:
kernel_init_freeable->sched_init_smp->sched_init_domains
even before cpus has been registered in:
kernel_init_freeable->do_one_initcall->s390_smp_init
Do not trigger kobject_uevent change events until cpu devices are
actually created. Fixes the following kasan findings:
BUG: KASAN: global-out-of-bounds in kobject_uevent_env+0xb40/0xee0
Read of size 8 at addr
0000000000000020 by task swapper/0/1
BUG: KASAN: global-out-of-bounds in kobject_uevent_env+0xb36/0xee0
Read of size 8 at addr
0000000000000018 by task swapper/0/1
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G B
Hardware name: IBM 3906 M04 704 (LPAR)
Call Trace:
([<
0000000143c6db7e>] show_stack+0x14e/0x1a8)
[<
0000000145956498>] dump_stack+0x1d0/0x218
[<
000000014429fb4c>] print_address_description+0x64/0x380
[<
000000014429f630>] __kasan_report+0x138/0x168
[<
0000000145960b96>] kobject_uevent_env+0xb36/0xee0
[<
0000000143c7c47c>] arch_update_cpu_topology+0x104/0x108
[<
0000000143df9e22>] sched_init_domains+0x62/0xe8
[<
000000014644c94a>] sched_init_smp+0x3a/0xc0
[<
0000000146433a20>] kernel_init_freeable+0x558/0x958
[<
000000014599002a>] kernel_init+0x22/0x160
[<
00000001459a71d4>] ret_from_fork+0x28/0x30
[<
00000001459a71dc>] kernel_thread_starter+0x0/0x10
Cc: stable@vger.kernel.org
Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Huth [Thu, 29 Aug 2019 12:25:17 +0000 (14:25 +0200)]
KVM: s390: Test for bad access register and size at the start of S390_MEM_OP
commit
a13b03bbb4575b350b46090af4dfd30e735aaed1 upstream.
If the KVM_S390_MEM_OP ioctl is called with an access register >= 16,
then there is certainly a bug in the calling userspace application.
We check for wrong access registers, but only if the vCPU was already
in the access register mode before (i.e. the SIE block has recorded
it). The check is also buried somewhere deep in the calling chain (in
the function ar_translation()), so this is somewhat hard to find.
It's better to always report an error to the userspace in case this
field is set wrong, and it's safer in the KVM code if we block wrong
values here early instead of relying on a check somewhere deep down
the calling chain, so let's add another check to kvm_s390_guest_mem_op()
directly.
We also should check that the "size" is non-zero here (thanks to Janosch
Frank for the hint!). If we do not check the size, we could call vmalloc()
with this 0 value, and this will cause a kernel warning.
Signed-off-by: Thomas Huth <thuth@redhat.com>
Link: https://lkml.kernel.org/r/20190829122517.31042-1-thuth@redhat.com
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Janosch Frank <frankja@linux.ibm.com>
Reviewed-by: David Hildenbrand <david@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Mon, 7 Oct 2019 19:22:12 +0000 (21:22 +0200)]
Merge 4.4.196 into android-4.4-p
Changes in 4.4.196
video: ssd1307fb: Start page range at page_offset
gpu: drm: radeon: Fix a possible null-pointer dereference in radeon_connector_set_property()
ipmi_si: Only schedule continuously in the thread in maintenance mode
clk: qoriq: Fix -Wunused-const-variable
clk: sirf: Don't reference clk_init_data after registration
powerpc/rtas: use device model APIs and serialization during LPM
powerpc/futex: Fix warning: 'oldval' may be used uninitialized in this function
powerpc/pseries/mobility: use cond_resched when updating device tree
pinctrl: tegra: Fix write barrier placement in pmx_writel
vfio_pci: Restore original state on release
powerpc/64s/exception: machine check use correct cfar for late handler
powerpc/pseries: correctly track irq state in default idle
scsi: core: Reduce memory required for SCSI logging
mfd: intel-lpss: Remove D3cold delay
ARM: 8898/1: mm: Don't treat faults reported from cache maintenance as writes
HID: apple: Fix stuck function keys when using FN
security: smack: Fix possible null-pointer dereferences in smack_socket_sock_rcv_skb()
fat: work around race with userspace's read via blockdev while mounting
hypfs: Fix error number left in struct pointer member
ocfs2: wait for recovering done after direct unlock request
kmemleak: increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE default to 16K
ANDROID: binder: remove waitqueue when thread exits.
ANDROID: binder: synchronize_rcu() when using POLLFREE.
hso: fix NULL-deref on tty open
ipv6: drop incoming packets having a v4mapped source address
net: ipv4: avoid mixed n_redirects and rate_tokens usage
net: qlogic: Fix memory leak in ql_alloc_large_buffers
nfc: fix memory leak in llcp_sock_bind()
sch_dsmark: fix potential NULL deref in dsmark_init()
xen-netfront: do not use ~0U as error return value for xennet_fill_frags()
net/rds: Fix error handling in rds_ib_add_one()
sch_cbq: validate TCA_CBQ_WRROPT to avoid crash
Smack: Don't ignore other bprm->unsafe flags if LSM_UNSAFE_PTRACE is set
smack: use GFP_NOFS while holding inode_smack::smk_lock
NFC: fix attrs checks in netlink interface
Linux 4.4.196
Change-Id: I7e03bb3ca1865988df014b8e38336b76430842a9
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Greg Kroah-Hartman [Mon, 7 Oct 2019 19:01:07 +0000 (21:01 +0200)]
Linux 4.4.196
Andrey Konovalov [Mon, 29 Jul 2019 13:35:01 +0000 (16:35 +0300)]
NFC: fix attrs checks in netlink interface
commit
18917d51472fe3b126a3a8f756c6b18085eb8130 upstream.
nfc_genl_deactivate_target() relies on the NFC_ATTR_TARGET_INDEX
attribute being present, but doesn't check whether it is actually
provided by the user. Same goes for nfc_genl_fw_download() and
NFC_ATTR_FIRMWARE_NAME.
This patch adds appropriate checks.
Found with syzkaller.
Signed-off-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Biggers [Thu, 22 Aug 2019 05:54:41 +0000 (22:54 -0700)]
smack: use GFP_NOFS while holding inode_smack::smk_lock
commit
e5bfad3d7acc5702f32aafeb388362994f4d7bd0 upstream.
inode_smack::smk_lock is taken during smack_d_instantiate(), which is
called during a filesystem transaction when creating a file on ext4.
Therefore to avoid a deadlock, all code that takes this lock must use
GFP_NOFS, to prevent memory reclaim from waiting for the filesystem
transaction to complete.
Reported-by: syzbot+0eefc1e06a77d327a056@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jann Horn [Thu, 4 Jul 2019 18:44:44 +0000 (20:44 +0200)]
Smack: Don't ignore other bprm->unsafe flags if LSM_UNSAFE_PTRACE is set
commit
3675f052b43ba51b99b85b073c7070e083f3e6fb upstream.
There is a logic bug in the current smack_bprm_set_creds():
If LSM_UNSAFE_PTRACE is set, but the ptrace state is deemed to be
acceptable (e.g. because the ptracer detached in the meantime), the other
->unsafe flags aren't checked. As far as I can tell, this means that
something like the following could work (but I haven't tested it):
- task A: create task B with fork()
- task B: set NO_NEW_PRIVS
- task B: install a seccomp filter that makes open() return 0 under some
conditions
- task B: replace fd 0 with a malicious library
- task A: attach to task B with PTRACE_ATTACH
- task B: execve() a file with an SMACK64EXEC extended attribute
- task A: while task B is still in the middle of execve(), exit (which
destroys the ptrace relationship)
Make sure that if any flags other than LSM_UNSAFE_PTRACE are set in
bprm->unsafe, we reject the execve().
Cc: stable@vger.kernel.org
Fixes:
5663884caab1 ("Smack: unify all ptrace accesses in the smack")
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Fri, 27 Sep 2019 01:24:43 +0000 (18:24 -0700)]
sch_cbq: validate TCA_CBQ_WRROPT to avoid crash
[ Upstream commit
e9789c7cc182484fc031fd88097eb14cb26c4596 ]
syzbot reported a crash in cbq_normalize_quanta() caused
by an out of range cl->priority.
iproute2 enforces this check, but malicious users do not.
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN PTI
Modules linked in:
CPU: 1 PID: 26447 Comm: syz-executor.1 Not tainted 5.3+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:cbq_normalize_quanta.part.0+0x1fd/0x430 net/sched/sch_cbq.c:902
RSP: 0018:
ffff8801a5c333b0 EFLAGS:
00010206
RAX:
0000000020000003 RBX:
00000000fffffff8 RCX:
ffffc9000712f000
RDX:
00000000000043bf RSI:
ffffffff83be8962 RDI:
0000000100000018
RBP:
ffff8801a5c33420 R08:
000000000000003a R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000000 R12:
00000000000002ef
R13:
ffff88018da95188 R14:
dffffc0000000000 R15:
0000000000000015
FS:
00007f37d26b1700(0000) GS:
ffff8801dad00000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
00000000004c7cec CR3:
00000001bcd0a006 CR4:
00000000001626f0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Call Trace:
[<
ffffffff83be9d57>] cbq_normalize_quanta include/net/pkt_sched.h:27 [inline]
[<
ffffffff83be9d57>] cbq_addprio net/sched/sch_cbq.c:1097 [inline]
[<
ffffffff83be9d57>] cbq_set_wrr+0x2d7/0x450 net/sched/sch_cbq.c:1115
[<
ffffffff83bee8a7>] cbq_change_class+0x987/0x225b net/sched/sch_cbq.c:1537
[<
ffffffff83b96985>] tc_ctl_tclass+0x555/0xcd0 net/sched/sch_api.c:2329
[<
ffffffff83a84655>] rtnetlink_rcv_msg+0x485/0xc10 net/core/rtnetlink.c:5248
[<
ffffffff83cadf0a>] netlink_rcv_skb+0x17a/0x460 net/netlink/af_netlink.c:2510
[<
ffffffff83a7db6d>] rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5266
[<
ffffffff83cac2c6>] netlink_unicast_kernel net/netlink/af_netlink.c:1324 [inline]
[<
ffffffff83cac2c6>] netlink_unicast+0x536/0x720 net/netlink/af_netlink.c:1350
[<
ffffffff83cacd4a>] netlink_sendmsg+0x89a/0xd50 net/netlink/af_netlink.c:1939
[<
ffffffff8399d46e>] sock_sendmsg_nosec net/socket.c:673 [inline]
[<
ffffffff8399d46e>] sock_sendmsg+0x12e/0x170 net/socket.c:684
[<
ffffffff8399f1fd>] ___sys_sendmsg+0x81d/0x960 net/socket.c:2359
[<
ffffffff839a2d05>] __sys_sendmsg+0x105/0x1d0 net/socket.c:2397
[<
ffffffff839a2df9>] SYSC_sendmsg net/socket.c:2406 [inline]
[<
ffffffff839a2df9>] SyS_sendmsg+0x29/0x30 net/socket.c:2404
[<
ffffffff8101ccc8>] do_syscall_64+0x528/0x770 arch/x86/entry/common.c:305
[<
ffffffff84400091>] entry_SYSCALL_64_after_hwframe+0x42/0xb7
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dotan Barak [Tue, 1 Oct 2019 17:21:02 +0000 (10:21 -0700)]
net/rds: Fix error handling in rds_ib_add_one()
[ Upstream commit
d64bf89a75b65f83f06be9fb8f978e60d53752db ]
rds_ibdev:ipaddr_list and rds_ibdev:conn_list are initialized
after allocation some resources such as protection domain.
If allocation of such resources fail, then these uninitialized
variables are accessed in rds_ib_dev_free() in failure path. This
can potentially crash the system. The code has been updated to
initialize these variables very early in the function.
Signed-off-by: Dotan Barak <dotanb@dev.mellanox.co.il>
Signed-off-by: Sudhakar Dindukurti <sudhakar.dindukurti@oracle.com>
Acked-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dongli Zhang [Tue, 1 Oct 2019 13:56:41 +0000 (21:56 +0800)]
xen-netfront: do not use ~0U as error return value for xennet_fill_frags()
[ Upstream commit
a761129e3625688310aecf26e1be9e98e85f8eb5 ]
xennet_fill_frags() uses ~0U as return value when the sk_buff is not able
to cache extra fragments. This is incorrect because the return type of
xennet_fill_frags() is RING_IDX and 0xffffffff is an expected value for
ring buffer index.
In the situation when the rsp_cons is approaching 0xffffffff, the return
value of xennet_fill_frags() may become 0xffffffff which xennet_poll() (the
caller) would regard as error. As a result, queue->rx.rsp_cons is set
incorrectly because it is updated only when there is error. If there is no
error, xennet_poll() would be responsible to update queue->rx.rsp_cons.
Finally, queue->rx.rsp_cons would point to the rx ring buffer entries whose
queue->rx_skbs[i] and queue->grant_rx_ref[i] are already cleared to NULL.
This leads to NULL pointer access in the next iteration to process rx ring
buffer entries.
The symptom is similar to the one fixed in
commit
00b368502d18 ("xen-netfront: do not assume sk_buff_head list is
empty in error handling").
This patch changes the return type of xennet_fill_frags() to indicate
whether it is successful or failed. The queue->rx.rsp_cons will be
always updated inside this function.
Fixes:
ad4f15dc2c70 ("xen/netfront: don't bug in case of too many frags")
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Fri, 4 Oct 2019 17:34:45 +0000 (10:34 -0700)]
sch_dsmark: fix potential NULL deref in dsmark_init()
[ Upstream commit
474f0813a3002cb299bb73a5a93aa1f537a80ca8 ]
Make sure TCA_DSMARK_INDICES was provided by the user.
syzbot reported :
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 8799 Comm: syz-executor235 Not tainted 5.3.0+ #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:nla_get_u16 include/net/netlink.h:1501 [inline]
RIP: 0010:dsmark_init net/sched/sch_dsmark.c:364 [inline]
RIP: 0010:dsmark_init+0x193/0x640 net/sched/sch_dsmark.c:339
Code: 85 db 58 0f 88 7d 03 00 00 e8 e9 1a ac fb 48 8b 9d 70 ff ff ff 48 b8 00 00 00 00 00 fc ff df 48 8d 7b 04 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 01 38 d0 7c 08 84 d2 0f 85 ca
RSP: 0018:
ffff88809426f3b8 EFLAGS:
00010247
RAX:
dffffc0000000000 RBX:
0000000000000000 RCX:
ffffffff85c6eb09
RDX:
0000000000000000 RSI:
ffffffff85c6eb17 RDI:
0000000000000004
RBP:
ffff88809426f4b0 R08:
ffff88808c4085c0 R09:
ffffed1015d26159
R10:
ffffed1015d26158 R11:
ffff8880ae930ac7 R12:
ffff8880a7e96940
R13:
dffffc0000000000 R14:
ffff88809426f8c0 R15:
0000000000000000
FS:
0000000001292880(0000) GS:
ffff8880ae900000(0000) knlGS:
0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
CR2:
0000000020000080 CR3:
000000008ca1b000 CR4:
00000000001406e0
DR0:
0000000000000000 DR1:
0000000000000000 DR2:
0000000000000000
DR3:
0000000000000000 DR6:
00000000fffe0ff0 DR7:
0000000000000400
Call Trace:
qdisc_create+0x4ee/0x1210 net/sched/sch_api.c:1237
tc_modify_qdisc+0x524/0x1c50 net/sched/sch_api.c:1653
rtnetlink_rcv_msg+0x463/0xb00 net/core/rtnetlink.c:5223
netlink_rcv_skb+0x177/0x450 net/netlink/af_netlink.c:2477
rtnetlink_rcv+0x1d/0x30 net/core/rtnetlink.c:5241
netlink_unicast_kernel net/netlink/af_netlink.c:1302 [inline]
netlink_unicast+0x531/0x710 net/netlink/af_netlink.c:1328
netlink_sendmsg+0x8a5/0xd60 net/netlink/af_netlink.c:1917
sock_sendmsg_nosec net/socket.c:637 [inline]
sock_sendmsg+0xd7/0x130 net/socket.c:657
___sys_sendmsg+0x803/0x920 net/socket.c:2311
__sys_sendmsg+0x105/0x1d0 net/socket.c:2356
__do_sys_sendmsg net/socket.c:2365 [inline]
__se_sys_sendmsg net/socket.c:2363 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2363
do_syscall_64+0xfa/0x760 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x440369
Fixes:
758cc43c6d73 ("[PKT_SCHED]: Fix dsmark to apply changes consistent")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Fri, 4 Oct 2019 18:08:34 +0000 (11:08 -0700)]
nfc: fix memory leak in llcp_sock_bind()
[ Upstream commit
a0c2dc1fe63e2869b74c1c7f6a81d1745c8a695d ]
sysbot reported a memory leak after a bind() has failed.
While we are at it, abort the operation if kmemdup() has failed.
BUG: memory leak
unreferenced object 0xffff888105d83ec0 (size 32):
comm "syz-executor067", pid 7207, jiffies
4294956228 (age 19.430s)
hex dump (first 32 bytes):
00 69 6c 65 20 72 65 61 64 00 6e 65 74 3a 5b 34 .ile read.net:[4
30 32 36 35 33 33 30 39 37 5d 00 00 00 00 00 00
026533097]......
backtrace:
[<
0000000036bac473>] kmemleak_alloc_recursive /./include/linux/kmemleak.h:43 [inline]
[<
0000000036bac473>] slab_post_alloc_hook /mm/slab.h:522 [inline]
[<
0000000036bac473>] slab_alloc /mm/slab.c:3319 [inline]
[<
0000000036bac473>] __do_kmalloc /mm/slab.c:3653 [inline]
[<
0000000036bac473>] __kmalloc_track_caller+0x169/0x2d0 /mm/slab.c:3670
[<
000000000cd39d07>] kmemdup+0x27/0x60 /mm/util.c:120
[<
000000008e57e5fc>] kmemdup /./include/linux/string.h:432 [inline]
[<
000000008e57e5fc>] llcp_sock_bind+0x1b3/0x230 /net/nfc/llcp_sock.c:107
[<
000000009cb0b5d3>] __sys_bind+0x11c/0x140 /net/socket.c:1647
[<
00000000492c3bbc>] __do_sys_bind /net/socket.c:1658 [inline]
[<
00000000492c3bbc>] __se_sys_bind /net/socket.c:1656 [inline]
[<
00000000492c3bbc>] __x64_sys_bind+0x1e/0x30 /net/socket.c:1656
[<
0000000008704b2a>] do_syscall_64+0x76/0x1a0 /arch/x86/entry/common.c:296
[<
000000009f4c57a4>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
Fixes:
30cc4587659e ("NFC: Move LLCP code to the NFC top level diirectory")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Navid Emamdoost [Fri, 4 Oct 2019 20:24:39 +0000 (15:24 -0500)]
net: qlogic: Fix memory leak in ql_alloc_large_buffers
[ Upstream commit
1acb8f2a7a9f10543868ddd737e37424d5c36cf4 ]
In ql_alloc_large_buffers, a new skb is allocated via netdev_alloc_skb.
This skb should be released if pci_dma_mapping_error fails.
Fixes:
0f8ab89e825f ("qla3xxx: Check return code from pci_map_single() in ql_release_to_lrg_buf_free_list(), ql_populate_free_queue(), ql_alloc_large_buffers(), and ql3xxx_send()")
Signed-off-by: Navid Emamdoost <navid.emamdoost@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Paolo Abeni [Fri, 4 Oct 2019 13:11:17 +0000 (15:11 +0200)]
net: ipv4: avoid mixed n_redirects and rate_tokens usage
[ Upstream commit
b406472b5ad79ede8d10077f0c8f05505ace8b6d ]
Since commit
c09551c6ff7f ("net: ipv4: use a dedicated counter
for icmp_v4 redirect packets") we use 'n_redirects' to account
for redirect packets, but we still use 'rate_tokens' to compute
the redirect packets exponential backoff.
If the device sent to the relevant peer any ICMP error packet
after sending a redirect, it will also update 'rate_token' according
to the leaking bucket schema; typically 'rate_token' will raise
above BITS_PER_LONG and the redirect packets backoff algorithm
will produce undefined behavior.
Fix the issue using 'n_redirects' to compute the exponential backoff
in ip_rt_send_redirect().
Note that we still clear rate_tokens after a redirect silence period,
to avoid changing an established behaviour.
The root cause predates git history; before the mentioned commit in
the critical scenario, the kernel stopped sending redirects, after
the mentioned commit the behavior more randomic.
Reported-by: Xiumei Mu <xmu@redhat.com>
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Fixes:
c09551c6ff7f ("net: ipv4: use a dedicated counter for icmp_v4 redirect packets")
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Acked-by: Lorenzo Bianconi <lorenzo.bianconi@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Dumazet [Wed, 2 Oct 2019 16:38:55 +0000 (09:38 -0700)]
ipv6: drop incoming packets having a v4mapped source address
[ Upstream commit
6af1799aaf3f1bc8defedddfa00df3192445bbf3 ]
This began with a syzbot report. syzkaller was injecting
IPv6 TCP SYN packets having a v4mapped source address.
After an unsuccessful 4-tuple lookup, TCP creates a request
socket (SYN_RECV) and calls reqsk_queue_hash_req()
reqsk_queue_hash_req() calls sk_ehashfn(sk)
At this point we have AF_INET6 sockets, and the heuristic
used by sk_ehashfn() to either hash the IPv4 or IPv6 addresses
is to use ipv6_addr_v4mapped(&sk->sk_v6_daddr)
For the particular spoofed packet, we end up hashing V4 addresses
which were not initialized by the TCP IPv6 stack, so KMSAN fired
a warning.
I first fixed sk_ehashfn() to test both source and destination addresses,
but then faced various problems, including user-space programs
like packetdrill that had similar assumptions.
Instead of trying to fix the whole ecosystem, it is better
to admit that we have a dual stack behavior, and that we
can not build linux kernels without V4 stack anyway.
The dual stack API automatically forces the traffic to be IPv4
if v4mapped addresses are used at bind() or connect(), so it makes
no sense to allow IPv6 traffic to use the same v4mapped class.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Florian Westphal <fw@strlen.de>
Cc: Hannes Frederic Sowa <hannes@stressinduktion.org>
Reported-by: syzbot <syzkaller@googlegroups.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Mon, 30 Sep 2019 15:12:41 +0000 (17:12 +0200)]
hso: fix NULL-deref on tty open
[ Upstream commit
8353da9fa69722b54cba82b2ec740afd3d438748 ]
Fix NULL-pointer dereference on tty open due to a failure to handle a
missing interrupt-in endpoint when probing modem ports:
BUG: kernel NULL pointer dereference, address:
0000000000000006
...
RIP: 0010:tiocmget_submit_urb+0x1c/0xe0 [hso]
...
Call Trace:
hso_start_serial_device+0xdc/0x140 [hso]
hso_serial_open+0x118/0x1b0 [hso]
tty_open+0xf1/0x490
Fixes:
542f54823614 ("tty: Modem functions for the HSO driver")
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martijn Coenen [Fri, 16 Feb 2018 08:47:15 +0000 (09:47 +0100)]
ANDROID: binder: synchronize_rcu() when using POLLFREE.
commit
5eeb2ca02a2f6084fc57ae5c244a38baab07033a upstream.
To prevent races with ep_remove_waitqueue() removing the
waitqueue at the same time.
Reported-by: syzbot+a2a3c4909716e271487e@syzkaller.appspotmail.com
Signed-off-by: Martijn Coenen <maco@android.com>
Cc: stable <stable@vger.kernel.org> # 4.14+
Signed-off-by: Mattias Nissler <mnissler@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Martijn Coenen [Fri, 5 Jan 2018 10:27:07 +0000 (11:27 +0100)]
ANDROID: binder: remove waitqueue when thread exits.
commit
f5cb779ba16334b45ba8946d6bfa6d9834d1527f upstream.
binder_poll() passes the thread->wait waitqueue that
can be slept on for work. When a thread that uses
epoll explicitly exits using BINDER_THREAD_EXIT,
the waitqueue is freed, but it is never removed
from the corresponding epoll data structure. When
the process subsequently exits, the epoll cleanup
code tries to access the waitlist, which results in
a use-after-free.
Prevent this by using POLLFREE when the thread exits.
Signed-off-by: Martijn Coenen <maco@android.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
Cc: stable <stable@vger.kernel.org> # 4.14
[backport BINDER_LOOPER_STATE_POLL logic as well]
Signed-off-by: Mattias Nissler <mnissler@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Nicolas Boichat [Mon, 23 Sep 2019 22:33:55 +0000 (15:33 -0700)]
kmemleak: increase DEBUG_KMEMLEAK_EARLY_LOG_SIZE default to 16K
[ Upstream commit
b751c52bb587ae66f773b15204ef7a147467f4c7 ]
The current default value (400) is too low on many systems (e.g. some
ARM64 platform takes up 1000+ entries).
syzbot uses 16000 as default value, and has proved to be enough on beefy
configurations, so let's pick that value.
This consumes more RAM on boot (each entry is 160 bytes, so in total
~2.5MB of RAM), but the memory would later be freed (early_log is
__initdata).
Link: http://lkml.kernel.org/r/20190730154027.101525-1-drinkcat@chromium.org
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Suggested-by: Dmitry Vyukov <dvyukov@google.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Dmitry Vyukov <dvyukov@google.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Petr Mladek <pmladek@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Joe Lawrence <joe.lawrence@redhat.com>
Cc: Uladzislau Rezki <urezki@gmail.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Changwei Ge [Mon, 23 Sep 2019 22:33:37 +0000 (15:33 -0700)]
ocfs2: wait for recovering done after direct unlock request
[ Upstream commit
0a3775e4f883912944481cf2ef36eb6383a9cc74 ]
There is a scenario causing ocfs2 umount hang when multiple hosts are
rebooting at the same time.
NODE1 NODE2 NODE3
send unlock requset to NODE2
dies
become recovery master
recover NODE2
find NODE2 dead
mark resource RECOVERING
directly remove lock from grant list
calculate usage but RECOVERING marked
**miss the window of purging
clear RECOVERING
To reproduce this issue, crash a host and then umount ocfs2
from another node.
To solve this, just let unlock progress wait for recovery done.
Link: http://lkml.kernel.org/r/1550124866-20367-1-git-send-email-gechangwei@live.cn
Signed-off-by: Changwei Ge <gechangwei@live.cn>
Reviewed-by: Joseph Qi <joseph.qi@linux.alibaba.com>
Cc: Mark Fasheh <mark@fasheh.com>
Cc: Joel Becker <jlbec@evilplan.org>
Cc: Junxiao Bi <junxiao.bi@oracle.com>
Cc: Changwei Ge <gechangwei@live.cn>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
David Howells [Thu, 21 Mar 2019 10:08:08 +0000 (10:08 +0000)]
hypfs: Fix error number left in struct pointer member
[ Upstream commit
b54c64f7adeb241423cd46598f458b5486b0375e ]
In hypfs_fill_super(), if hypfs_create_update_file() fails,
sbi->update_file is left holding an error number. This is passed to
hypfs_kill_super() which doesn't check for this.
Fix this by not setting sbi->update_value until after we've checked for
error.
Fixes:
24bbb1faf3f0 ("[PATCH] s390_hypfs filesystem")
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
cc: Heiko Carstens <heiko.carstens@de.ibm.com>
cc: linux-s390@vger.kernel.org
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Sasha Levin <sashal@kernel.org>