Julian Wiedmann [Thu, 30 Jul 2020 15:01:20 +0000 (17:01 +0200)]
s390/qeth: don't process empty bridge port events
[ Upstream commit
02472e28b9a45471c6d8729ff2c7422baa9be46a ]
Discard events that don't contain any entries. This shouldn't happen,
but subsequent code relies on being able to use entry 0. So better
be safe than accessing garbage.
Fixes:
b4d72c08b358 ("qeth: bridgeport support - basic control")
Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com>
Reviewed-by: Alexandra Winter <wintera@linux.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sandipan Das [Thu, 30 Jul 2020 05:08:46 +0000 (10:38 +0530)]
selftests/powerpc: Fix online CPU selection
[ Upstream commit
dfa03fff86027e58c8dba5c03ae68150d4e513ad ]
The size of the CPU affinity mask must be large enough for
systems with a very large number of CPUs. Otherwise, tests
which try to determine the first online CPU by calling
sched_getaffinity() will fail. This makes sure that the size
of the allocated affinity mask is dependent on the number of
CPUs as reported by get_nprocs_conf().
Fixes:
3752e453f6ba ("selftests/powerpc: Add tests of PMU EBBs")
Reported-by: Shirisha Ganta <shiganta@in.ibm.com>
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/a408c4b8e9a23bb39b539417a21eb0ff47bb5127.1596084858.git.sandipan@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Harish [Tue, 9 Jun 2020 08:14:23 +0000 (13:44 +0530)]
selftests/powerpc: Fix CPU affinity for child process
[ Upstream commit
854eb5022be04f81e318765f089f41a57c8e5d83 ]
On systems with large number of cpus, test fails trying to set
affinity by calling sched_setaffinity() with smaller size for affinity
mask. This patch fixes it by making sure that the size of allocated
affinity mask is dependent on the number of CPUs as reported by
get_nprocs().
Fixes:
00b7ec5c9cf3 ("selftests/powerpc: Import Anton's context_switch2 benchmark")
Reported-by: Shirisha Ganta <shiganta@in.ibm.com>
Signed-off-by: Sandipan Das <sandipan@linux.ibm.com>
Signed-off-by: Harish <harish@linux.ibm.com>
Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com>
Reviewed-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200609081423.529664-1-harish@linux.ibm.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tom Rix [Sun, 12 Jul 2020 19:23:51 +0000 (12:23 -0700)]
power: supply: check if calc_soc succeeded in pm860x_init_battery
[ Upstream commit
ccf193dee1f0fff55b556928591f7818bac1b3b1 ]
clang static analysis flags this error
88pm860x_battery.c:522:19: warning: Assigned value is
garbage or undefined [core.uninitialized.Assign]
info->start_soc = soc;
^ ~~~
soc is set by calling calc_soc.
But calc_soc can return without setting soc.
So check the return status and bail similarly to other
checks in pm860x_init_battery and initialize soc to
silence the warning.
Fixes:
a830d28b48bf ("power_supply: Enable battery-charger for 88pm860x")
Signed-off-by: Tom Rix <trix@redhat.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Thu, 23 Jul 2020 15:23:05 +0000 (18:23 +0300)]
Smack: prevent underflow in smk_set_cipso()
[ Upstream commit
42a2df3e829f3c5562090391b33714b2e2e5ad4a ]
We have an upper bound on "maplevel" but forgot to check for negative
values.
Fixes:
e114e473771c ("Smack: Simplified Mandatory Access Control Kernel")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Thu, 23 Jul 2020 15:22:19 +0000 (18:22 +0300)]
Smack: fix another vsscanf out of bounds
[ Upstream commit
a6bd4f6d9b07452b0b19842044a6c3ea384b0b88 ]
This is similar to commit
84e99e58e8d1 ("Smack: slab-out-of-bounds in
vsscanf") where we added a bounds check on "rule".
Reported-by: syzbot+a22c6092d003d6fe1122@syzkaller.appspotmail.com
Fixes:
f7112e6c9abf ("Smack: allow for significantly longer Smack labels v4")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Finn Thain [Wed, 22 Jul 2020 23:25:51 +0000 (09:25 +1000)]
scsi: mesh: Fix panic after host or bus reset
[ Upstream commit
edd7dd2292ab9c3628b65c4d04514c3068ad54f6 ]
Booting Linux with a Conner CP3200 drive attached to the MESH SCSI bus
results in EH measures and a panic:
[ 25.499838] mesh: configured for synchronous 5 MB/s
[ 25.787154] mesh: performing initial bus reset...
[ 29.867115] scsi host0: MESH
[ 29.929527] mesh: target 0 synchronous at 3.6 MB/s
[ 29.998763] scsi 0:0:0:0: Direct-Access CONNER CP3200-200mb-3.5 4040 PQ: 0 ANSI: 1 CCS
[ 31.989975] sd 0:0:0:0: [sda] 415872 512-byte logical blocks: (213 MB/203 MiB)
[ 32.070975] sd 0:0:0:0: [sda] Write Protect is off
[ 32.137197] sd 0:0:0:0: [sda] Mode Sense: 5b 00 00 08
[ 32.209661] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 32.332708] sda: [mac] sda1 sda2 sda3
[ 32.417733] sd 0:0:0:0: [sda] Attached SCSI disk
... snip ...
[ 76.687067] mesh_abort((ptrval))
[ 76.743606] mesh: state at (ptrval), regs at (ptrval), dma at (ptrval)
[ 76.810798] ct=6000 seq=86 bs=4017 fc= 0 exc= 0 err= 0 im= 7 int= 0 sp=85
[ 76.880720] dma stat=84e0 cmdptr=
1f73d000
[ 76.941387] phase=4 msgphase=0 conn_tgt=0 data_ptr=24576
[ 77.005567] dma_st=1 dma_ct=0 n_msgout=0
[ 77.065456] target 0: req=(ptrval) goes_out=0 saved_ptr=0
[ 77.130512] mesh_abort((ptrval))
[ 77.187670] mesh: state at (ptrval), regs at (ptrval), dma at (ptrval)
[ 77.255594] ct=6000 seq=86 bs=4017 fc= 0 exc= 0 err= 0 im= 7 int= 0 sp=85
[ 77.325778] dma stat=84e0 cmdptr=
1f73d000
[ 77.387239] phase=4 msgphase=0 conn_tgt=0 data_ptr=24576
[ 77.453665] dma_st=1 dma_ct=0 n_msgout=0
[ 77.515900] target 0: req=(ptrval) goes_out=0 saved_ptr=0
[ 77.582902] mesh_host_reset
[ 88.187083] Kernel panic - not syncing: mesh: double DMA start !
[ 88.254510] CPU: 0 PID: 358 Comm: scsi_eh_0 Not tainted 5.6.13-pmac #1
[ 88.323302] Call Trace:
[ 88.378854] [
e16ddc58] [
c0027080] panic+0x13c/0x308 (unreliable)
[ 88.446221] [
e16ddcb8] [
c02b2478] mesh_start.part.12+0x130/0x414
[ 88.513298] [
e16ddcf8] [
c02b2fc8] mesh_queue+0x54/0x70
[ 88.577097] [
e16ddd18] [
c02a1848] scsi_send_eh_cmnd+0x374/0x384
[ 88.643476] [
e16dddc8] [
c02a1938] scsi_eh_tur+0x5c/0xb8
[ 88.707878] [
e16dddf8] [
c02a1ab8] scsi_eh_test_devices+0x124/0x178
[ 88.775663] [
e16dde28] [
c02a2094] scsi_eh_ready_devs+0x588/0x8a8
[ 88.843124] [
e16dde98] [
c02a31d8] scsi_error_handler+0x344/0x520
[ 88.910697] [
e16ddf08] [
c00409c8] kthread+0xe4/0xe8
[ 88.975166] [
e16ddf38] [
c000f234] ret_from_kernel_thread+0x14/0x1c
[ 89.044112] Rebooting in 180 seconds..
In theory, a panic can happen after a bus or host reset with dma_started
flag set. Fix this by halting the DMA before reinitializing the host.
Don't assume that ms->current_req is set when halt_dma() is invoked as it
may not hold for bus or host reset.
BTW, this particular Conner drive can be made to work by inhibiting
disconnect/reselect with 'mesh.resel_targets=0'.
Link: https://lore.kernel.org/r/3952bc691e150a7128b29120999b6092071b039a.1595460351.git.fthain@telegraphics.com.au
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: Paul Mackerras <paulus@ozlabs.org>
Reported-and-tested-by: Stan Johnson <userm57@yahoo.com>
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marek Szyprowski [Thu, 16 Jul 2020 12:09:48 +0000 (14:09 +0200)]
usb: dwc2: Fix error path in gadget registration
[ Upstream commit
33a06f1300a79cfd461cea0268f05e969d4f34ec ]
When gadget registration fails, one should not call usb_del_gadget_udc().
Ensure this by setting gadget->udc to NULL. Also in case of a failure
there is no need to disable low-level hardware, so return immiedetly
instead of jumping to error_init label.
This fixes the following kernel NULL ptr dereference on gadget failure
(can be easily triggered with g_mass_storage without any module
parameters):
dwc2
12480000.hsotg: dwc2_check_params: Invalid parameter besl=1
dwc2
12480000.hsotg: dwc2_check_params: Invalid parameter g_np_tx_fifo_size=1024
dwc2
12480000.hsotg: EPs: 16, dedicated fifos, 7808 entries in SPRAM
Mass Storage Function, version: 2009/09/11
LUN: removable file: (no medium)
no file given for LUN0
g_mass_storage
12480000.hsotg: failed to start g_mass_storage: -22
8<--- cut here ---
Unable to handle kernel NULL pointer dereference at virtual address
00000104
pgd = (ptrval)
[
00000104] *pgd=
00000000
Internal error: Oops: 805 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.8.0-rc5 #3133
Hardware name: Samsung Exynos (Flattened Device Tree)
Workqueue: events deferred_probe_work_func
PC is at usb_del_gadget_udc+0x38/0xc4
LR is at __mutex_lock+0x31c/0xb18
...
Process kworker/0:1 (pid: 12, stack limit = 0x(ptrval))
Stack: (0xef121db0 to 0xef122000)
...
[<
c076bf3c>] (usb_del_gadget_udc) from [<
c0726bec>] (dwc2_hsotg_remove+0x10/0x20)
[<
c0726bec>] (dwc2_hsotg_remove) from [<
c0711208>] (dwc2_driver_probe+0x57c/0x69c)
[<
c0711208>] (dwc2_driver_probe) from [<
c06247c0>] (platform_drv_probe+0x6c/0xa4)
[<
c06247c0>] (platform_drv_probe) from [<
c0621df4>] (really_probe+0x200/0x48c)
[<
c0621df4>] (really_probe) from [<
c06221e8>] (driver_probe_device+0x78/0x1fc)
[<
c06221e8>] (driver_probe_device) from [<
c061fcd4>] (bus_for_each_drv+0x74/0xb8)
[<
c061fcd4>] (bus_for_each_drv) from [<
c0621b54>] (__device_attach+0xd4/0x16c)
[<
c0621b54>] (__device_attach) from [<
c0620c98>] (bus_probe_device+0x88/0x90)
[<
c0620c98>] (bus_probe_device) from [<
c06211b0>] (deferred_probe_work_func+0x3c/0xd0)
[<
c06211b0>] (deferred_probe_work_func) from [<
c0149280>] (process_one_work+0x234/0x7dc)
[<
c0149280>] (process_one_work) from [<
c014986c>] (worker_thread+0x44/0x51c)
[<
c014986c>] (worker_thread) from [<
c0150b1c>] (kthread+0x158/0x1a0)
[<
c0150b1c>] (kthread) from [<
c0100114>] (ret_from_fork+0x14/0x20)
Exception stack(0xef121fb0 to 0xef121ff8)
...
---[ end trace
9724c2fc7cc9c982 ]---
While fixing this also fix the double call to dwc2_lowlevel_hw_disable()
if dr_mode is set to USB_DR_MODE_PERIPHERAL. In such case low-level
hardware is already disabled before calling usb_add_gadget_udc(). That
function correctly preserves low-level hardware state, there is no need
for the second unconditional dwc2_lowlevel_hw_disable() call.
Fixes:
207324a321a8 ("usb: dwc2: Postponed gadget registration to the udc class driver")
Acked-by: Minas Harutyunyan <hminas@synopsys.com>
Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johan Hovold [Thu, 16 Jul 2020 08:50:55 +0000 (10:50 +0200)]
USB: serial: iuu_phoenix: fix led-activity helpers
[ Upstream commit
de37458f8c2bfc465500a1dd0d15dbe96d2a698c ]
The set-led command is eight bytes long and starts with a command byte
followed by six bytes of RGB data and ends with a byte encoding a
frequency (see iuu_led() and iuu_rgbf_fill_buffer()).
The led activity helpers had a few long-standing bugs which corrupted
the command packets by inserting a second command byte and thereby
offsetting the RGB data and dropping the frequency in non-xmas mode.
In xmas mode, a related off-by-one error left the frequency field
uninitialised.
Fixes:
60a8fc017103 ("USB: add iuu_phoenix driver")
Reported-by: George Spelvin <lkml@sdf.org>
Link: https://lore.kernel.org/r/20200716085056.31471-1-johan@kernel.org
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Marco Felsch [Thu, 11 Jun 2020 12:43:32 +0000 (14:43 +0200)]
drm/imx: tve: fix regulator_disable error path
[ Upstream commit
7bb58b987fee26da2a1665c01033022624986b7c ]
Add missing regulator_disable() as devm_action to avoid dedicated
unbind() callback and fix the missing error handling.
Fixes:
fcbc51e54d2a ("staging: drm/imx: Add support for Television Encoder (TVEv2)")
Signed-off-by: Marco Felsch <m.felsch@pengutronix.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xiongfeng Wang [Fri, 17 Jul 2020 07:59:25 +0000 (15:59 +0800)]
PCI/ASPM: Add missing newline in sysfs 'policy'
[ Upstream commit
3167e3d340c092fd47924bc4d23117a3074ef9a9 ]
When I cat ASPM parameter 'policy' by sysfs, it displays as follows. Add a
newline for easy reading. Other sysfs attributes already include a
newline.
[root@localhost ~]# cat /sys/module/pcie_aspm/parameters/policy
[default] performance powersave powersupersave [root@localhost ~]#
Fixes:
7d715a6c1ae5 ("PCI: add PCI Express ASPM support")
Link: https://lore.kernel.org/r/1594972765-10404-1-git-send-email-wangxiongfeng2@huawei.com
Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Thu, 16 Jul 2020 15:47:20 +0000 (16:47 +0100)]
staging: rtl8192u: fix a dubious looking mask before a shift
[ Upstream commit
c4283950a9a4d3bf4a3f362e406c80ab14f10714 ]
Currently the masking of ret with 0xff and followed by a right shift
of 8 bits always leaves a zero result. It appears the mask of 0xff
is incorrect and should be 0xff00, but I don't have the hardware to
test this. Fix this to mask the upper 8 bits before shifting.
[ Not tested ]
Addresses-Coverity: ("Operands don't affect result")
Fixes:
8fc8598e61f6 ("Staging: Added Realtek rtl8192u driver to staging")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: https://lore.kernel.org/r/20200716154720.1710252-1-colin.king@canonical.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Milton Miller [Wed, 15 Jul 2020 23:37:04 +0000 (09:37 +1000)]
powerpc/vdso: Fix vdso cpu truncation
[ Upstream commit
a9f675f950a07d5c1dbcbb97aabac56f5ed085e3 ]
The code in vdso_cpu_init that exposes the cpu and numa node to
userspace via SPRG_VDSO incorrctly masks the cpu to 12 bits. This means
that any kernel running on a box with more than 4096 threads (NR_CPUS
advertises a limit of of 8192 cpus) would expose userspace to two cpu
contexts running at the same time with the same cpu number.
Note: I'm not aware of any distro shipping a kernel with support for more
than 4096 threads today, nor of any system image that currently exceeds
4096 threads. Found via code browsing.
Fixes:
18ad51dd342a7eb09dbcd059d0b451b616d4dafc ("powerpc: Add VDSO version of getcpu")
Signed-off-by: Milton Miller <miltonm@us.ibm.com>
Signed-off-by: Anton Blanchard <anton@linux.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20200715233704.1352257-1-anton@ozlabs.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Wed, 8 Jul 2020 11:58:57 +0000 (14:58 +0300)]
mwifiex: Prevent memory corruption handling keys
[ Upstream commit
e18696786548244914f36ec3c46ac99c53df99c3 ]
The length of the key comes from the network and it's a 16 bit number. It
needs to be capped to prevent a buffer overflow.
Fixes:
5e6e3a92b9a4 ("wireless: mwifiex: initial commit for Marvell mwifiex driver")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Ganapathi Bhat <ganapathi.bhat@nxp.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200708115857.GA13729@mwanda
Signed-off-by: Sasha Levin <sashal@kernel.org>
John Garry [Thu, 9 Jul 2020 12:23:19 +0000 (20:23 +0800)]
scsi: scsi_debug: Add check for sdebug_max_queue during module init
[ Upstream commit
c87bf24cfb60bce27b4d2c7e56ebfd86fb9d16bb ]
sdebug_max_queue should not exceed SDEBUG_CANQUEUE, otherwise crashes like
this can be triggered by passing an out-of-range value:
Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - V1.16.01 03/15/2019
pstate:
20400009 (nzCv daif +PAN -UAO BTYPE=--)
pc : schedule_resp+0x2a4/0xa70 [scsi_debug]
lr : schedule_resp+0x52c/0xa70 [scsi_debug]
sp :
ffff800022ab36f0
x29:
ffff800022ab36f0 x28:
ffff0023a935a610
x27:
ffff800008e0a648 x26:
0000000000000003
x25:
ffff0023e84f3200 x24:
00000000003d0900
x23:
0000000000000000 x22:
0000000000000000
x21:
ffff0023be60a320 x20:
ffff0023be60b538
x19:
ffff800008e13000 x18:
0000000000000000
x17:
0000000000000000 x16:
0000000000000000
x15:
0000000000000000 x14:
0000000000000000
x13:
0000000000000000 x12:
0000000000000000
x11:
0000000000000000 x10:
0000000000000000
x9 :
0000000000000001 x8 :
0000000000000000
x7 :
0000000000000000 x6 :
00000000000000c1
x5 :
0000020000200000 x4 :
dead0000000000ff
x3 :
0000000000000200 x2 :
0000000000000200
x1 :
ffff800008e13d88 x0 :
0000000000000000
Call trace:
schedule_resp+0x2a4/0xa70 [scsi_debug]
scsi_debug_queuecommand+0x2c4/0x9e0 [scsi_debug]
scsi_queue_rq+0x698/0x840
__blk_mq_try_issue_directly+0x108/0x228
blk_mq_request_issue_directly+0x58/0x98
blk_mq_try_issue_list_directly+0x5c/0xf0
blk_mq_sched_insert_requests+0x18c/0x200
blk_mq_flush_plug_list+0x11c/0x190
blk_flush_plug_list+0xdc/0x110
blk_finish_plug+0x38/0x210
blkdev_direct_IO+0x450/0x4d8
generic_file_read_iter+0x84/0x180
blkdev_read_iter+0x3c/0x50
aio_read+0xc0/0x170
io_submit_one+0x5c8/0xc98
__arm64_sys_io_submit+0x1b0/0x258
el0_svc_common.constprop.3+0x68/0x170
do_el0_svc+0x24/0x90
el0_sync_handler+0x13c/0x1a8
el0_sync+0x158/0x180
Code:
528847e0 72a001e0 6b00003f 540018cd (
3941c340)
In addition, it should not be less than 1.
So add checks for these, and fail the module init for those cases.
[mkp: changed if condition to match error message]
Link: https://lore.kernel.org/r/1594297400-24756-2-git-send-email-john.garry@huawei.com
Fixes:
c483739430f1 ("scsi_debug: add multiple queue support")
Reviewed-by: Ming Lei <ming.lei@redhat.com>
Acked-by: Douglas Gilbert <dgilbert@interlog.com>
Signed-off-by: John Garry <john.garry@huawei.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Laurent Pinchart [Sat, 11 Jul 2020 22:53:17 +0000 (01:53 +0300)]
drm: panel: simple: Fix bpc for LG LB070WV8 panel
[ Upstream commit
a6ae2fe5c9f9fd355a48fb7d21c863e5b20d6c9c ]
The LG LB070WV8 panel incorrectly reports a 16 bits per component value,
while the panel uses 8 bits per component. Fix it.
Fixes:
dd0150026901 ("drm/panel: simple: Add support for LG LB070WV8 800x480 7" panel")
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200711225317.28476-1-laurent.pinchart+renesas@ideasonboard.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Kai-Heng Feng [Thu, 2 Jul 2020 05:45:00 +0000 (13:45 +0800)]
leds: core: Flush scheduled work for system suspend
[ Upstream commit
302a085c20194bfa7df52e0fe684ee0c41da02e6 ]
Sometimes LED won't be turned off by LED_CORE_SUSPENDRESUME flag upon
system suspend.
led_set_brightness_nopm() uses schedule_work() to set LED brightness.
However, there's no guarantee that the scheduled work gets executed
because no one flushes the work.
So flush the scheduled work to make sure LED gets turned off.
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Fixes:
81fe8e5b73e3 ("leds: core: Add led_set_brightness_nosleep{nopm} functions")
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bjorn Helgaas [Thu, 25 Jun 2020 23:14:55 +0000 (18:14 -0500)]
PCI: Fix pci_cfg_wait queue locking problem
[ Upstream commit
2a7e32d0547f41c5ce244f84cf5d6ca7fccee7eb ]
The pci_cfg_wait queue is used to prevent user-space config accesses to
devices while they are recovering from reset.
Previously we used these operations on pci_cfg_wait:
__add_wait_queue(&pci_cfg_wait, ...)
__remove_wait_queue(&pci_cfg_wait, ...)
wake_up_all(&pci_cfg_wait)
The wake_up acquires the wait queue lock, but the add and remove do not.
Originally these were all protected by the pci_lock, but
cdcb33f98244
("PCI: Avoid possible deadlock on pci_lock and p->pi_lock"), moved
wake_up_all() outside pci_lock, so it could race with add/remove
operations, which caused occasional kernel panics, e.g., during vfio-pci
hotplug/unplug testing:
Unable to handle kernel read from unreadable memory at virtual address
ffff802dac469000
Resolve this by using wait_event() instead of __add_wait_queue() and
__remove_wait_queue(). The wait queue lock is held by both wait_event()
and wake_up_all(), so it provides mutual exclusion.
Fixes:
cdcb33f98244 ("PCI: Avoid possible deadlock on pci_lock and p->pi_lock")
Link: https://lore.kernel.org/linux-pci/79827f2f-9b43-4411-1376-b9063b67aee3@huawei.com/T/#u
Based-on: https://lore.kernel.org/linux-pci/
20191210031527.40136-1-zhengxiang9@huawei.com/
Based-on-patch-by: Xiang Zheng <zhengxiang9@huawei.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Xiang Zheng <zhengxiang9@huawei.com>
Cc: Heyi Guo <guoheyi@huawei.com>
Cc: Biaoxiang Ye <yebiaoxiang@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Darrick J. Wong [Mon, 29 Jun 2020 21:47:18 +0000 (14:47 -0700)]
xfs: fix reflink quota reservation accounting error
[ Upstream commit
83895227aba1ade33e81f586aa7b6b1e143096a5 ]
Quota reservations are supposed to account for the blocks that might be
allocated due to a bmap btree split. Reflink doesn't do this, so fix
this to make the quota accounting more accurate before we start
rearranging things.
Fixes:
862bb360ef56 ("xfs: reflink extents from one file to another")
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chuhong Yuan [Thu, 28 May 2020 06:41:47 +0000 (08:41 +0200)]
media: exynos4-is: Add missed check for pinctrl_lookup_state()
[ Upstream commit
18ffec750578f7447c288647d7282c7d12b1d969 ]
fimc_md_get_pinctrl() misses a check for pinctrl_lookup_state().
Add the missed check to fix it.
Fixes:
4163851f7b99 ("[media] s5p-fimc: Use pinctrl API for camera ports configuration]")
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dan Carpenter [Fri, 8 May 2020 14:40:22 +0000 (16:40 +0200)]
media: firewire: Using uninitialized values in node_probe()
[ Upstream commit
2505a210fc126599013aec2be741df20aaacc490 ]
If fw_csr_string() returns -ENOENT, then "name" is uninitialized. So
then the "strlen(model_names[i]) <= name_len" is true because strlen()
is unsigned and -ENOENT is type promoted to a very high positive value.
Then the "strncmp(name, model_names[i], name_len)" uses uninitialized
data because "name" is uninitialized.
Fixes:
92374e886c75 ("[media] firedtv: drop obsolete backend abstraction")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Fri, 26 Jun 2020 04:05:53 +0000 (06:05 +0200)]
scsi: eesox: Fix different dev_id between request_irq() and free_irq()
[ Upstream commit
86f2da1112ccf744ad9068b1d5d9843faf8ddee6 ]
The dev_id used in request_irq() and free_irq() should match. Use 'info' in
both cases.
Link: https://lore.kernel.org/r/20200626040553.944352-1-christophe.jaillet@wanadoo.fr
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Fri, 26 Jun 2020 03:59:48 +0000 (05:59 +0200)]
scsi: powertec: Fix different dev_id between request_irq() and free_irq()
[ Upstream commit
d179f7c763241c1dc5077fca88ddc3c47d21b763 ]
The dev_id used in request_irq() and free_irq() should match. Use 'info' in
both cases.
Link: https://lore.kernel.org/r/20200626035948.944148-1-christophe.jaillet@wanadoo.fr
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Colin Ian King [Wed, 24 Jun 2020 12:07:10 +0000 (13:07 +0100)]
drm/radeon: fix array out-of-bounds read and write issues
[ Upstream commit
7ee78aff9de13d5dccba133f4a0de5367194b243 ]
There is an off-by-one bounds check on the index into arrays
table->mc_reg_address and table->mc_reg_table_entry[k].mc_data[j] that
can lead to reads and writes outside of arrays. Fix the bound checking
off-by-one error.
Addresses-Coverity: ("Out-of-bounds read/write")
Fixes:
cc8dbbb4f62a ("drm/radeon: add dpm support for CI dGPUs (v2)")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Wang Hai [Tue, 2 Jun 2020 12:07:33 +0000 (20:07 +0800)]
cxl: Fix kobject memleak
[ Upstream commit
85c5cbeba8f4fb28e6b9bfb3e467718385f78f76 ]
Currently the error return path from kobject_init_and_add() is not
followed by a call to kobject_put() - which means we are leaking
the kobject.
Fix it by adding a call to kobject_put() in the error path of
kobject_init_and_add().
Fixes:
b087e6190ddc ("cxl: Export optional AFU configuration record in sysfs")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Wang Hai <wanghai38@huawei.com>
Acked-by: Andrew Donnellan <ajd@linux.ibm.com>
Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
Link: https://lore.kernel.org/r/20200602120733.5943-1-wanghai38@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Emil Velikov [Tue, 5 May 2020 16:03:29 +0000 (17:03 +0100)]
drm/mipi: use dcs write for mipi_dsi_dcs_set_tear_scanline
[ Upstream commit
7a05c3b6d24b8460b3cec436cf1d33fac43c8450 ]
The helper uses the MIPI_DCS_SET_TEAR_SCANLINE, although it's currently
using the generic write. This does not look right.
Perhaps some platforms don't distinguish between the two writers?
Cc: Robert Chiras <robert.chiras@nxp.com>
Cc: Vinay Simha BN <simhavcs@gmail.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Thierry Reding <treding@nvidia.com>
Fixes:
e83950816367 ("drm/dsi: Implement set tear scanline")
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20200505160329.2976059-3-emil.l.velikov@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Thu, 25 Jun 2020 20:47:30 +0000 (22:47 +0200)]
scsi: cumana_2: Fix different dev_id between request_irq() and free_irq()
[ Upstream commit
040ab9c4fd0070cd5fa71ba3a7b95b8470db9b4d ]
The dev_id used in request_irq() and free_irq() should match. Use 'info'
in both cases.
Link: https://lore.kernel.org/r/20200625204730.943520-1-christophe.jaillet@wanadoo.fr
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Chuhong Yuan [Wed, 3 Jun 2020 16:41:22 +0000 (18:41 +0200)]
media: omap3isp: Add missed v4l2_ctrl_handler_free() for preview_init_entities()
[ Upstream commit
dc7690a73017e1236202022e26a6aa133f239c8c ]
preview_init_entities() does not call v4l2_ctrl_handler_free() when
it fails.
Add the missed function to fix it.
Fixes:
de1135d44f4f ("[media] omap3isp: CCDC, preview engine and resizer")
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Arnd Bergmann [Tue, 5 May 2020 14:19:17 +0000 (16:19 +0200)]
leds: lm355x: avoid enum conversion warning
[ Upstream commit
985b1f596f9ed56f42b8c2280005f943e1434c06 ]
clang points out that doing arithmetic between diffent enums is usually
a mistake:
drivers/leds/leds-lm355x.c:167:28: warning: bitwise operation between different enumeration types ('enum lm355x_tx2' and 'enum lm355x_ntc') [-Wenum-enum-conversion]
reg_val = pdata->pin_tx2 | pdata->ntc_pin;
~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~
drivers/leds/leds-lm355x.c:178:28: warning: bitwise operation between different enumeration types ('enum lm355x_tx2' and 'enum lm355x_ntc') [-Wenum-enum-conversion]
reg_val = pdata->pin_tx2 | pdata->ntc_pin | pdata->pass_mode;
~~~~~~~~~~~~~~ ^ ~~~~~~~~~~~~~~
In this driver, it is intentional, so add a cast to hide the false-positive
warning. It appears to be the only instance of this warning at the moment.
Fixes:
b98d13c72592 ("leds: Add new LED driver for lm355x chips")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tomasz Duszynski [Mon, 1 Jun 2020 16:15:52 +0000 (18:15 +0200)]
iio: improve IIO_CONCENTRATION channel type description
[ Upstream commit
df16c33a4028159d1ba8a7061c9fa950b58d1a61 ]
IIO_CONCENTRATION together with INFO_RAW specifier is used for reporting
raw concentrations of pollutants. Raw value should be meaningless
before being properly scaled. Because of that description shouldn't
mention raw value unit whatsoever.
Fix this by rephrasing existing description so it follows conventions
used throughout IIO ABI docs.
Fixes:
8ff6b3bc94930 ("iio: chemical: Add IIO_CONCENTRATION channel type")
Signed-off-by: Tomasz Duszynski <tomasz.duszynski@octakon.com>
Acked-by: Matt Ranostay <matt.ranostay@konsulko.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christophe JAILLET [Wed, 29 Apr 2020 08:45:05 +0000 (10:45 +0200)]
video: pxafb: Fix the function used to balance a 'dma_alloc_coherent()' call
[ Upstream commit
499a2c41b954518c372873202d5e7714e22010c4 ]
'dma_alloc_coherent()' must be balanced by a call to 'dma_free_coherent()'
not 'dma_free_wc()'.
The correct dma_free_ function is already used in the error handling path
of the probe function.
Fixes:
77e196752bdd ("[ARM] pxafb: allow video memory size to be configurable")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: Sumit Semwal <sumit.semwal@linaro.org>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Jani Nikula <jani.nikula@intel.com>
cc: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: Eric Miao <eric.miao@marvell.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429084505.108897-1-christophe.jaillet@wanadoo.fr
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dejin Zheng [Thu, 23 Apr 2020 16:42:51 +0000 (00:42 +0800)]
console: newport_con: fix an issue about leak related system resources
[ Upstream commit
fd4b8243877250c05bb24af7fea5567110c9720b ]
A call of the function do_take_over_console() can fail here.
The corresponding system resources were not released then.
Thus add a call of iounmap() and release_mem_region()
together with the check of a failure predicate. and also
add release_mem_region() on device removal.
Fixes:
e86bb8acc0fdc ("[PATCH] VT binding: Make newport_con support binding")
Suggested-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Andrew Morton <akpm@osdl.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200423164251.3349-1-zhengdejin5@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Dejin Zheng [Wed, 22 Apr 2020 16:07:19 +0000 (00:07 +0800)]
video: fbdev: sm712fb: fix an issue about iounmap for a wrong address
[ Upstream commit
98bd4f72988646c35569e1e838c0ab80d06c77f6 ]
the sfb->fb->screen_base is not save the value get by iounmap() when
the chip id is 0x720. so iounmap() for address sfb->fb->screen_base
is not right.
Fixes:
1461d6672864854 ("staging: sm7xxfb: merge sm712fb with fbdev")
Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: Sudip Mukherjee <sudipm.mukherjee@gmail.com>
Cc: Teddy Wang <teddy.wang@siliconmotion.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Dejin Zheng <zhengdejin5@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200422160719.27763-1-zhengdejin5@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Qiushi Wu [Fri, 22 May 2020 08:34:51 +0000 (09:34 +0100)]
agp/intel: Fix a memory leak on module initialisation failure
[ Upstream commit
b975abbd382fe442713a4c233549abb90e57c22b ]
In intel_gtt_setup_scratch_page(), pointer "page" is not released if
pci_dma_mapping_error() return an error, leading to a memory leak on
module initialisation failure. Simply fix this issue by freeing "page"
before return.
Fixes:
0e87d2b06cb46 ("intel-gtt: initialize our own scratch page")
Signed-off-by: Qiushi Wu <wu000273@umn.edu>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200522083451.7448-1-chris@chris-wilson.co.uk
Signed-off-by: Sasha Levin <sashal@kernel.org>
Erik Kaneda [Mon, 20 Jul 2020 17:31:20 +0000 (10:31 -0700)]
ACPICA: Do not increment operation_region reference counts for field units
[ Upstream commit
6a54ebae6d047c988a31f5ac5a64ab5cf83797a2 ]
ACPICA commit
e17b28cfcc31918d0db9547b6b274b09c413eb70
Object reference counts are used as a part of ACPICA's garbage
collection mechanism. This mechanism keeps track of references to
heap-allocated structures such as the ACPI operand objects.
Recent server firmware has revealed that this reference count can
overflow on large servers that declare many field units under the
same operation_region. This occurs because each field unit declaration
will add a reference count to the source operation_region.
This change solves the reference count overflow for operation_regions
objects by preventing fieldunits from incrementing their
operation_region's reference count. Each operation_region's reference
count will not be changed by named objects declared under the Field
operator. During namespace deletion, the operation_region namespace
node will be deleted and each fieldunit will be deleted without
touching the deleted operation_region object.
Link: https://github.com/acpica/acpica/commit/e17b28cf
Signed-off-by: Erik Kaneda <erik.kaneda@intel.com>
Signed-off-by: Bob Moore <robert.moore@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Coly Li [Sat, 25 Jul 2020 12:00:26 +0000 (20:00 +0800)]
bcache: fix super block seq numbers comparision in register_cache_set()
[ Upstream commit
117f636ea695270fe492d0c0c9dfadc7a662af47 ]
In register_cache_set(), c is pointer to struct cache_set, and ca is
pointer to struct cache, if ca->sb.seq > c->sb.seq, it means this
registering cache has up to date version and other members, the in-
memory version and other members should be updated to the newer value.
But current implementation makes a cache set only has a single cache
device, so the above assumption works well except for a special case.
The execption is when a cache device new created and both ca->sb.seq and
c->sb.seq are 0, because the super block is never flushed out yet. In
the location for the following if() check,
2156 if (ca->sb.seq > c->sb.seq) {
2157 c->sb.version = ca->sb.version;
2158 memcpy(c->sb.set_uuid, ca->sb.set_uuid, 16);
2159 c->sb.flags = ca->sb.flags;
2160 c->sb.seq = ca->sb.seq;
2161 pr_debug("set version = %llu\n", c->sb.version);
2162 }
c->sb.version is not initialized yet and valued 0. When ca->sb.seq is 0,
the if() check will fail (because both values are 0), and the cache set
version, set_uuid, flags and seq won't be updated.
The above problem is hiden for current code, because the bucket size is
compatible among different super block version. And the next time when
running cache set again, ca->sb.seq will be larger than 0 and cache set
super block version will be updated properly.
But if the large bucket feature is enabled, sb->bucket_size is the low
16bits of the bucket size. For a power of 2 value, when the actual
bucket size exceeds 16bit width, sb->bucket_size will always be 0. Then
read_super_common() will fail because the if() check to
is_power_of_2(sb->bucket_size) is false. This is how the long time
hidden bug is triggered.
This patch modifies the if() check to the following way,
2156 if (ca->sb.seq > c->sb.seq || c->sb.seq == 0) {
Then cache set's version, set_uuid, flags and seq will always be updated
corectly including for a new created cache device.
Signed-off-by: Coly Li <colyli@suse.de>
Reviewed-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Jens Axboe <axboe@kernel.dk>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Jim Cromie [Sun, 19 Jul 2020 23:10:47 +0000 (17:10 -0600)]
dyndbg: fix a BUG_ON in ddebug_describe_flags
[ Upstream commit
f678ce8cc3cb2ad29df75d8824c74f36398ba871 ]
ddebug_describe_flags() currently fills a caller provided string buffer,
after testing its size (also passed) in a BUG_ON. Fix this by
replacing them with a known-big-enough string buffer wrapped in a
struct, and passing that instead.
Also simplify ddebug_describe_flags() flags parameter from a struct to
a member in that struct, and hoist the member deref up to the caller.
This makes the function reusable (soon) where flags are unpacked.
Acked-by: <jbaron@akamai.com>
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
Link: https://lore.kernel.org/r/20200719231058.1586423-8-jim.cromie@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Sasi Kumar [Wed, 22 Jul 2020 17:07:42 +0000 (13:07 -0400)]
bdc: Fix bug causing crash after multiple disconnects
[ Upstream commit
a95bdfd22076497288868c028619bc5995f5cc7f ]
Multiple connects/disconnects can cause a crash on the second
disconnect. The driver had a problem where it would try to send
endpoint commands after it was disconnected which is not allowed
by the hardware. The fix is to only allow the endpoint commands
when the endpoint is connected. This will also fix issues that
showed up when using configfs to create gadgets.
Signed-off-by: Sasi Kumar <sasi.kumar@broadcom.com>
Signed-off-by: Al Cooper <alcooperx@gmail.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Evgeny Novikov [Tue, 21 Jul 2020 20:15:58 +0000 (23:15 +0300)]
usb: gadget: net2280: fix memory leak on probe error handling paths
[ Upstream commit
2468c877da428ebfd701142c4cdfefcfb7d4c00e ]
Driver does not release memory for device on error handling paths in
net2280_probe() when gadget_release() is not registered yet.
The patch fixes the bug like in other similar drivers.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
Signed-off-by: Felipe Balbi <balbi@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Bolarinwa Olayemi Saheed [Mon, 13 Jul 2020 17:55:27 +0000 (19:55 +0200)]
iwlegacy: Check the return value of pcie_capability_read_*()
[ Upstream commit
9018fd7f2a73e9b290f48a56b421558fa31e8b75 ]
On failure pcie_capability_read_dword() sets it's last parameter, val
to 0. However, with Patch 14/14, it is possible that val is set to ~0 on
failure. This would introduce a bug because (x & x) == (~0 & x).
This bug can be avoided without changing the function's behaviour if the
return value of pcie_capability_read_dword is checked to confirm success.
Check the return value of pcie_capability_read_dword() to ensure success.
Suggested-by: Bjorn Helgaas <bjorn@helgaas.com>
Signed-off-by: Bolarinwa Olayemi Saheed <refactormyself@gmail.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200713175529.29715-3-refactormyself@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Prasanna Kerekoppa [Thu, 4 Jun 2020 07:18:35 +0000 (02:18 -0500)]
brcmfmac: To fix Bss Info flag definition Bug
[ Upstream commit
fa3266541b13f390eb35bdbc38ff4a03368be004 ]
Bss info flag definition need to be fixed from 0x2 to 0x4
This flag is for rssi info received on channel.
All Firmware branches defined as 0x4 and this is bug in brcmfmac.
Signed-off-by: Prasanna Kerekoppa <prasanna.kerekoppa@cypress.com>
Signed-off-by: Chi-hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: Wright Feng <wright.feng@cypress.com>
Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Link: https://lore.kernel.org/r/20200604071835.3842-6-wright.feng@cypress.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Paul E. McKenney [Thu, 16 Apr 2020 23:46:10 +0000 (16:46 -0700)]
mm/mmap.c: Add cond_resched() for exit_mmap() CPU stalls
[ Upstream commit
0a3b3c253a1eb2c7fe7f34086d46660c909abeb3 ]
A large process running on a heavily loaded system can encounter the
following RCU CPU stall warning:
rcu: INFO: rcu_sched self-detected stall on CPU
rcu: 3-....: (20998 ticks this GP) idle=4ea/1/0x4000000000000002 softirq=556558/556558 fqs=5190
(t=21013 jiffies g=1005461 q=132576)
NMI backtrace for cpu 3
CPU: 3 PID: 501900 Comm: aio-free-ring-w Kdump: loaded Not tainted 5.2.9-108_fbk12_rc3_3858_gb83b75af7909 #1
Hardware name: Wiwynn HoneyBadger/PantherPlus, BIOS HBM6.71 02/03/2016
Call Trace:
<IRQ>
dump_stack+0x46/0x60
nmi_cpu_backtrace.cold.3+0x13/0x50
? lapic_can_unplug_cpu.cold.27+0x34/0x34
nmi_trigger_cpumask_backtrace+0xba/0xca
rcu_dump_cpu_stacks+0x99/0xc7
rcu_sched_clock_irq.cold.87+0x1aa/0x397
? tick_sched_do_timer+0x60/0x60
update_process_times+0x28/0x60
tick_sched_timer+0x37/0x70
__hrtimer_run_queues+0xfe/0x270
hrtimer_interrupt+0xf4/0x210
smp_apic_timer_interrupt+0x5e/0x120
apic_timer_interrupt+0xf/0x20
</IRQ>
RIP: 0010:kmem_cache_free+0x223/0x300
Code: 88 00 00 00 0f 85 ca 00 00 00 41 8b 55 18 31 f6 f7 da 41 f6 45 0a 02 40 0f 94 c6 83 c6 05 9c 41 5e fa e8 a0 a7 01 00 41 56 9d <49> 8b 47 08 a8 03 0f 85 87 00 00 00 65 48 ff 08 e9 3d fe ff ff 65
RSP: 0018:
ffffc9000e8e3da8 EFLAGS:
00000206 ORIG_RAX:
ffffffffffffff13
RAX:
0000000000020000 RBX:
ffff88861b9de960 RCX:
0000000000000030
RDX:
fffffffffffe41e8 RSI:
000060777fe3a100 RDI:
000000000001be18
RBP:
ffffea00186e7780 R08:
ffffffffffffffff R09:
ffffffffffffffff
R10:
ffff88861b9dea28 R11:
ffff88887ffde000 R12:
ffffffff81230a1f
R13:
ffff888854684dc0 R14:
0000000000000206 R15:
ffff8888547dbc00
? remove_vma+0x4f/0x60
remove_vma+0x4f/0x60
exit_mmap+0xd6/0x160
mmput+0x4a/0x110
do_exit+0x278/0xae0
? syscall_trace_enter+0x1d3/0x2b0
? handle_mm_fault+0xaa/0x1c0
do_group_exit+0x3a/0xa0
__x64_sys_exit_group+0x14/0x20
do_syscall_64+0x42/0x100
entry_SYSCALL_64_after_hwframe+0x44/0xa9
And on a PREEMPT=n kernel, the "while (vma)" loop in exit_mmap() can run
for a very long time given a large process. This commit therefore adds
a cond_resched() to this loop, providing RCU any needed quiescent states.
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: <linux-mm@kvack.org>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Reviewed-by: Joel Fernandes (Google) <joel@joelfernandes.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Michael Tretter [Thu, 17 Aug 2017 10:43:07 +0000 (12:43 +0200)]
drm/debugfs: fix plain echo to connector "force" attribute
[ Upstream commit
c704b17071c4dc571dca3af4e4151dac51de081a ]
Using plain echo to set the "force" connector attribute fails with
-EINVAL, because echo appends a newline to the output.
Replace strcmp with sysfs_streq to also accept strings that end with a
newline.
v2: use sysfs_streq instead of stripping trailing whitespace
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20170817104307.17124-1-m.tretter@pengutronix.de
Signed-off-by: Sasha Levin <sashal@kernel.org>
Aditya Pakki [Sun, 14 Jun 2020 01:41:56 +0000 (20:41 -0500)]
drm/nouveau: fix multiple instances of reference count leaks
[ Upstream commit
659fb5f154c3434c90a34586f3b7aa1c39cf6062 ]
On calling pm_runtime_get_sync() the reference count of the device
is incremented. In case of failure, decrement the
ref count before returning the error.
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Zhao Heming [Thu, 9 Jul 2020 03:29:29 +0000 (11:29 +0800)]
md-cluster: fix wild pointer of unlock_all_bitmaps()
[ Upstream commit
60f80d6f2d07a6d8aee485a1d1252327eeee0c81 ]
reproduction steps:
```
node1 # mdadm -C /dev/md0 -b clustered -e 1.2 -n 2 -l mirror /dev/sda
/dev/sdb
node2 # mdadm -A /dev/md0 /dev/sda /dev/sdb
node1 # mdadm -G /dev/md0 -b none
mdadm: failed to remove clustered bitmap.
node1 # mdadm -S --scan
^C <==== mdadm hung & kernel crash
```
kernel stack:
```
[ 335.230657] general protection fault: 0000 [#1] SMP NOPTI
[...]
[ 335.230848] Call Trace:
[ 335.230873] ? unlock_all_bitmaps+0x5/0x70 [md_cluster]
[ 335.230886] unlock_all_bitmaps+0x3d/0x70 [md_cluster]
[ 335.230899] leave+0x10f/0x190 [md_cluster]
[ 335.230932] ? md_super_wait+0x93/0xa0 [md_mod]
[ 335.230947] ? leave+0x5/0x190 [md_cluster]
[ 335.230973] md_cluster_stop+0x1a/0x30 [md_mod]
[ 335.230999] md_bitmap_free+0x142/0x150 [md_mod]
[ 335.231013] ? _cond_resched+0x15/0x40
[ 335.231025] ? mutex_lock+0xe/0x30
[ 335.231056] __md_stop+0x1c/0xa0 [md_mod]
[ 335.231083] do_md_stop+0x160/0x580 [md_mod]
[ 335.231119] ? 0xffffffffc05fb078
[ 335.231148] md_ioctl+0xa04/0x1930 [md_mod]
[ 335.231165] ? filename_lookup+0xf2/0x190
[ 335.231179] blkdev_ioctl+0x93c/0xa10
[ 335.231205] ? _cond_resched+0x15/0x40
[ 335.231214] ? __check_object_size+0xd4/0x1a0
[ 335.231224] block_ioctl+0x39/0x40
[ 335.231243] do_vfs_ioctl+0xa0/0x680
[ 335.231253] ksys_ioctl+0x70/0x80
[ 335.231261] __x64_sys_ioctl+0x16/0x20
[ 335.231271] do_syscall_64+0x65/0x1f0
[ 335.231278] entry_SYSCALL_64_after_hwframe+0x44/0xa9
```
Signed-off-by: Zhao Heming <heming.zhao@suse.com>
Signed-off-by: Song Liu <songliubraving@fb.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Evgeny Novikov [Tue, 30 Jun 2020 19:54:51 +0000 (22:54 +0300)]
video: fbdev: neofb: fix memory leak in neo_scan_monitor()
[ Upstream commit
edcb3895a751c762a18d25c8d9846ce9759ed7e1 ]
neofb_probe() calls neo_scan_monitor() that can successfully allocate a
memory for info->monspecs.modedb and proceed to case 0x03. There it does
not free the memory and returns -1. neofb_probe() goes to label
err_scan_monitor, thus, it does not free this memory through calling
fb_destroy_modedb() as well. We can not go to label err_init_hw since
neo_scan_monitor() can fail during memory allocation. So, the patch frees
the memory directly for case 0x03.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Evgeny Novikov <novikov@ispras.ru>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630195451.18675-1-novikov@ispras.ru
Signed-off-by: Sasha Levin <sashal@kernel.org>
Aditya Pakki [Sun, 14 Jun 2020 02:21:22 +0000 (21:21 -0500)]
drm/radeon: Fix reference count leaks caused by pm_runtime_get_sync
[ Upstream commit
9fb10671011143d15b6b40d6d5fa9c52c57e9d63 ]
On calling pm_runtime_get_sync() the reference count of the device
is incremented. In case of failure, decrement the
reference count before returning the error.
Acked-by: Evan Quan <evan.quan@amd.com>
Signed-off-by: Aditya Pakki <pakki001@umn.edu>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Paul E. McKenney [Fri, 8 May 2020 21:15:37 +0000 (14:15 -0700)]
fs/btrfs: Add cond_resched() for try_release_extent_mapping() stalls
[ Upstream commit
9f47eb5461aaeb6cb8696f9d11503ae90e4d5cb0 ]
Very large I/Os can cause the following RCU CPU stall warning:
RIP: 0010:rb_prev+0x8/0x50
Code: 49 89 c0 49 89 d1 48 89 c2 48 89 f8 e9 e5 fd ff ff 4c 89 48 10 c3 4c =
89 06 c3 4c 89 40 10 c3 0f 1f 00 48 8b 0f 48 39 cf 74 38 <48> 8b 47 10 48 85 c0 74 22 48 8b 50 08 48 85 d2 74 0c 48 89 d0 48
RSP: 0018:
ffffc9002212bab0 EFLAGS:
00000287 ORIG_RAX:
ffffffffffffff13
RAX:
ffff888821f93630 RBX:
ffff888821f93630 RCX:
ffff888821f937e0
RDX:
0000000000000000 RSI:
0000000000102000 RDI:
ffff888821f93630
RBP:
0000000000103000 R08:
000000000006c000 R09:
0000000000000238
R10:
0000000000102fff R11:
ffffc9002212bac8 R12:
0000000000000001
R13:
ffffffffffffffff R14:
0000000000102000 R15:
ffff888821f937e0
__lookup_extent_mapping+0xa0/0x110
try_release_extent_mapping+0xdc/0x220
btrfs_releasepage+0x45/0x70
shrink_page_list+0xa39/0xb30
shrink_inactive_list+0x18f/0x3b0
shrink_lruvec+0x38e/0x6b0
shrink_node+0x14d/0x690
do_try_to_free_pages+0xc6/0x3e0
try_to_free_mem_cgroup_pages+0xe6/0x1e0
reclaim_high.constprop.73+0x87/0xc0
mem_cgroup_handle_over_high+0x66/0x150
exit_to_usermode_loop+0x82/0xd0
do_syscall_64+0xd4/0x100
entry_SYSCALL_64_after_hwframe+0x44/0xa9
On a PREEMPT=n kernel, the try_release_extent_mapping() function's
"while" loop might run for a very long time on a large I/O. This commit
therefore adds a cond_resched() to this loop, providing RCU any needed
quiescent states.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lihong Kou [Tue, 23 Jun 2020 12:28:41 +0000 (20:28 +0800)]
Bluetooth: add a mutex lock to avoid UAF in do_enale_set
[ Upstream commit
f9c70bdc279b191da8d60777c627702c06e4a37d ]
In the case we set or free the global value listen_chan in
different threads, we can encounter the UAF problems because
the method is not protected by any lock, add one to avoid
this bug.
BUG: KASAN: use-after-free in l2cap_chan_close+0x48/0x990
net/bluetooth/l2cap_core.c:730
Read of size 8 at addr
ffff888096950000 by task kworker/1:102/2868
CPU: 1 PID: 2868 Comm: kworker/1:102 Not tainted 5.5.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine,
BIOS Google 01/01/2011
Workqueue: events do_enable_set
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1fb/0x318 lib/dump_stack.c:118
print_address_description+0x74/0x5c0 mm/kasan/report.c:374
__kasan_report+0x149/0x1c0 mm/kasan/report.c:506
kasan_report+0x26/0x50 mm/kasan/common.c:641
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:135
l2cap_chan_close+0x48/0x990 net/bluetooth/l2cap_core.c:730
do_enable_set+0x660/0x900 net/bluetooth/6lowpan.c:1074
process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264
worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410
kthread+0x332/0x350 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Allocated by task 2870:
save_stack mm/kasan/common.c:72 [inline]
set_track mm/kasan/common.c:80 [inline]
__kasan_kmalloc+0x118/0x1c0 mm/kasan/common.c:515
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:529
kmem_cache_alloc_trace+0x221/0x2f0 mm/slab.c:3551
kmalloc include/linux/slab.h:555 [inline]
kzalloc include/linux/slab.h:669 [inline]
l2cap_chan_create+0x50/0x320 net/bluetooth/l2cap_core.c:446
chan_create net/bluetooth/6lowpan.c:640 [inline]
bt_6lowpan_listen net/bluetooth/6lowpan.c:959 [inline]
do_enable_set+0x6a4/0x900 net/bluetooth/6lowpan.c:1078
process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264
worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410
kthread+0x332/0x350 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Freed by task 2870:
save_stack mm/kasan/common.c:72 [inline]
set_track mm/kasan/common.c:80 [inline]
kasan_set_free_info mm/kasan/common.c:337 [inline]
__kasan_slab_free+0x12e/0x1e0 mm/kasan/common.c:476
kasan_slab_free+0xe/0x10 mm/kasan/common.c:485
__cache_free mm/slab.c:3426 [inline]
kfree+0x10d/0x220 mm/slab.c:3757
l2cap_chan_destroy net/bluetooth/l2cap_core.c:484 [inline]
kref_put include/linux/kref.h:65 [inline]
l2cap_chan_put+0x170/0x190 net/bluetooth/l2cap_core.c:498
do_enable_set+0x66c/0x900 net/bluetooth/6lowpan.c:1075
process_one_work+0x7f5/0x10f0 kernel/workqueue.c:2264
worker_thread+0xbbc/0x1630 kernel/workqueue.c:2410
kthread+0x332/0x350 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
The buggy address belongs to the object at
ffff888096950000
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 0 bytes inside of
2048-byte region [
ffff888096950000,
ffff888096950800)
The buggy address belongs to the page:
page:
ffffea00025a5400 refcount:1 mapcount:0 mapping:
ffff8880aa400e00 index:0x0
flags: 0xfffe0000000200(slab)
raw:
00fffe0000000200 ffffea00027d1548 ffffea0002397808 ffff8880aa400e00
raw:
0000000000000000 ffff888096950000 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88809694ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff88809694ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
ffff888096950000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff888096950080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888096950100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Reported-by: syzbot+96414aa0033c363d8458@syzkaller.appspotmail.com
Signed-off-by: Lihong Kou <koulihong@huawei.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Tomi Valkeinen [Wed, 29 Apr 2020 10:42:32 +0000 (13:42 +0300)]
drm/tilcdc: fix leak & null ref in panel_connector_get_modes
[ Upstream commit
3f9c1c872cc97875ddc8d63bc9fe6ee13652b933 ]
If videomode_from_timings() returns true, the mode allocated with
drm_mode_create will be leaked.
Also, the return value of drm_mode_create() is never checked, and thus
could cause NULL deref.
Fix these two issues.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200429104234.18910-1-tomi.valkeinen@ti.com
Reviewed-by: Jyri Sarha <jsarha@ti.com>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yu Kuai [Tue, 21 Jul 2020 13:45:51 +0000 (21:45 +0800)]
ARM: socfpga: PM: add missing put_device() call in socfpga_setup_ocram_self_refresh()
[ Upstream commit
3ad7b4e8f89d6bcc9887ca701cf2745a6aedb1a0 ]
if of_find_device_by_node() succeed, socfpga_setup_ocram_self_refresh
doesn't have a corresponding put_device(). Thus add a jump target to
fix the exception handling for this function implementation.
Fixes:
44fd8c7d4005 ("ARM: socfpga: support suspend to ram")
Signed-off-by: Yu Kuai <yukuai3@huawei.com>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
yu kuai [Thu, 4 Jun 2020 12:33:01 +0000 (20:33 +0800)]
ARM: at91: pm: add missing put_device() call in at91_pm_sram_init()
[ Upstream commit
f87a4f022c44e5b87e842a9f3e644fba87e8385f ]
if of_find_device_by_node() succeed, at91_pm_sram_init() doesn't have
a corresponding put_device(). Thus add a jump target to fix the exception
handling for this function implementation.
Fixes:
d2e467905596 ("ARM: at91: pm: use the mmio-sram pool to access SRAM")
Signed-off-by: yu kuai <yukuai3@huawei.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Link: https://lore.kernel.org/r/20200604123301.3905837-1-yukuai3@huawei.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lu Wei [Fri, 10 Jul 2020 09:30:18 +0000 (17:30 +0800)]
platform/x86: intel-vbtn: Fix return value check in check_acpi_dev()
[ Upstream commit
64dd4a5a7d214a07e3d9f40227ec30ac8ba8796e ]
In the function check_acpi_dev(), if it fails to create
platform device, the return value is ERR_PTR() or NULL.
Thus it must use IS_ERR_OR_NULL() to check return value.
Fixes:
332e081225fc ("intel-vbtn: new driver for Intel Virtual Button")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Lu Wei <luwei32@huawei.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Lu Wei [Fri, 10 Jul 2020 09:30:17 +0000 (17:30 +0800)]
platform/x86: intel-hid: Fix return value check in check_acpi_dev()
[ Upstream commit
71fbe886ce6dd0be17f20aded9c63fe58edd2806 ]
In the function check_acpi_dev(), if it fails to create
platform device, the return value is ERR_PTR() or NULL.
Thus it must use IS_ERR_OR_NULL() to check return value.
Fixes:
ecc83e52b28c ("intel-hid: new hid event driver for hotkeys")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: Lu Wei <luwei32@huawei.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Finn Thain [Sat, 30 May 2020 23:12:13 +0000 (09:12 +1000)]
m68k: mac: Fix IOP status/control register writes
[ Upstream commit
931fc82a6aaf4e2e4a5490addaa6a090d78c24a7 ]
When writing values to the IOP status/control register make sure those
values do not have any extraneous bits that will clear interrupt flags.
To place the SCC IOP into bypass mode would be desirable but this is not
achieved by writing IOP_DMAINACTIVE | IOP_RUN | IOP_AUTOINC | IOP_BYPASS
to the control register. Drop this ineffective register write.
Remove the flawed and unused iop_bypass() function. Make use of the
unused iop_stop() function.
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Tested-by: Stan Johnson <userm57@yahoo.com>
Cc: Joshua Thompson <funaho@jurai.org>
Link: https://lore.kernel.org/r/09bcb7359a1719a18b551ee515da3c4c3cf709e6.1590880333.git.fthain@telegraphics.com.au
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Finn Thain [Sat, 30 May 2020 23:12:13 +0000 (09:12 +1000)]
m68k: mac: Don't send IOP message until channel is idle
[ Upstream commit
aeb445bf2194d83e12e85bf5c65baaf1f093bd8f ]
In the following sequence of calls, iop_do_send() gets called when the
"send" channel is not in the IOP_MSG_IDLE state:
iop_ism_irq()
iop_handle_send()
(msg->handler)()
iop_send_message()
iop_do_send()
Avoid this by testing the channel state before calling iop_do_send().
When sending, and iop_send_queue is empty, call iop_do_send() because
the channel is idle. If iop_send_queue is not empty, iop_do_send() will
get called later by iop_handle_send().
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Tested-by: Stan Johnson <userm57@yahoo.com>
Cc: Joshua Thompson <funaho@jurai.org>
Link: https://lore.kernel.org/r/6d667c39e53865661fa5a48f16829d18ed8abe54.1590880333.git.fthain@telegraphics.com.au
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Alim Akhtar [Sun, 5 Jul 2020 07:09:17 +0000 (12:39 +0530)]
arm64: dts: exynos: Fix silent hang after boot on Espresso
[ Upstream commit
b072714bfc0e42c984b8fd6e069f3ca17de8137a ]
Once regulators are disabled after kernel boot, on Espresso board silent
hang observed because of LDO7 being disabled. LDO7 actually provide
power to CPU cores and non-cpu blocks circuitries. Keep this regulator
always-on to fix this hang.
Fixes:
9589f7721e16 ("arm64: dts: Add S2MPS15 PMIC node on exynos7-espresso")
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Stephan Gerhold [Fri, 5 Jun 2020 18:59:14 +0000 (20:59 +0200)]
arm64: dts: qcom: msm8916: Replace invalid bias-pull-none property
[ Upstream commit
1b6a1a162defe649c5599d661b58ac64bb6f31b6 ]
msm8916-pins.dtsi specifies "bias-pull-none" for most of the audio
pin configurations. This was likely copied from the qcom kernel fork
where the same property was used for these audio pins.
However, "bias-pull-none" actually does not exist at all - not in
mainline and not in downstream. I can only guess that the original
intention was to configure "no pull", i.e. bias-disable.
Change it to that instead.
Fixes:
143bb9ad85b7 ("arm64: dts: qcom: add audio pinctrls")
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20200605185916.318494-2-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Qiushi Wu [Thu, 28 May 2020 20:22:37 +0000 (15:22 -0500)]
EDAC: Fix reference count leaks
[ Upstream commit
17ed808ad243192fb923e4e653c1338d3ba06207 ]
When kobject_init_and_add() returns an error, it should be handled
because kobject_init_and_add() takes a reference even when it fails. If
this function returns an error, kobject_put() must be called to properly
clean up the memory associated with the object.
Therefore, replace calling kfree() and call kobject_put() and add a
missing kobject_put() in the edac_device_register_sysfs_main_kobj()
error path.
[ bp: Massage and merge into a single patch. ]
Fixes:
b2ed215a3338 ("Kobject: change drivers/edac to use kobject_init_and_add")
Signed-off-by: Qiushi Wu <wu000273@umn.edu>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20200528202238.18078-1-wu000273@umn.edu
Link: https://lkml.kernel.org/r/20200528203526.20908-1-wu000273@umn.edu
Signed-off-by: Sasha Levin <sashal@kernel.org>
Yang Yingliang [Thu, 13 Aug 2020 20:27:57 +0000 (20:27 +0000)]
cgroup: add missing skcd->no_refcnt check in cgroup_sk_clone()
Add skcd->no_refcnt check which is missed when backporting
ad0f75e5f57c ("cgroup: fix cgroup_sk_alloc() for sk_clone_lock()").
This patch is needed in stable-4.9, stable-4.14 and stable-4.19.
Signed-off-by: Yang Yingliang <yangyingliang@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Uwe Kleine-König [Fri, 14 Aug 2020 07:47:11 +0000 (09:47 +0200)]
gpio: fix oops resulting from calling of_get_named_gpio(NULL, ...)
This happens for the spi-imx driver when running a dt-enabled kernel on
a non-dt machine on Linux 4.0. Among the still supported stable versions
only 4.4 and 4.9 are affected. (However the spi-imx driver doesn't call
of_get_named_gpio() since v4.8-rc1 (commit
b36581df7e78 ("spi: imx:
Using existing properties for chipselects")) any more, but the problem
might still affect other users of of_get_named_gpio().)
In 4.14-rc1 this problem is gone with
commit
7eb6ce2f2723 ("gpio: Convert to using %pOF instead of
full_name"). This commit however doesn't seem sensible to backport as it
depends on
ce4fecf1fe15 ("vsprintf: Add %p extension "%pOF" for device
tree") which doesn't trivially apply to v4.4.
[ 1.649453] Unable to handle kernel NULL pointer dereference at virtual address
0000000c
[ 1.659270] pgd =
c0004000
[ 1.662036] [
0000000c] *pgd=
00000000
[ 1.665919] Internal error: Oops - BUG: 5 [#1] PREEMPT ARM
[ 1.671438] Modules linked in:
[ 1.674552] CPU: 0 PID: 1 Comm: swapper Not tainted 4.0.0 #1
[ 1.680235] Hardware name: Eckelmann ECU01
[ 1.684361] task:
c7840000 ti:
c7842000 task.ti:
c7842000
[ 1.689821] PC is at of_get_named_gpiod_flags+0xac/0xe0
[ 1.695104] LR is at of_find_property+0x38/0x7c
[ 1.699674] pc : [<
c025db2c>] lr : [<
c03c5f54>] psr:
a0000013
[ 1.699674] sp :
c7843cc8 ip :
c7843c38 fp :
c7843d3c
[ 1.711183] r10:
c7884dc0 r9 :
c7a8de10 r8 :
00000000
[ 1.716434] r7 :
00000000 r6 :
00000000 r5 :
c065ef50 r4 :
fffffffe
[ 1.722986] r3 :
00000000 r2 :
00000000 r1 :
c065ef50 r0 :
fffffffe
[ 1.729541] Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
[ 1.736879] Control:
0005317f Table:
80004000 DAC:
00000017
[ 1.742652] Process swapper (pid: 1, stack limit = 0xc7842190)
[ 1.748510] Stack: (0xc7843cc8 to 0xc7844000)
[ 1.752906] 3cc0:
c7843cd4 c003ccec 00000000 00000000 00000000 00000000
[ 1.761125] 3ce0:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1.769345] 3d00:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 fffffdfb
[ 1.777566] 3d20:
00000000 c78b4e10 c7a8dc00 000001ff c7843d4c c7843d40 c025db70 c025da90
[ 1.785788] 3d40:
c7843dcc c7843d50 c02f8938 c025db70 c7843d74 c7843d60 c79bc3c0 c79bc320
[ 1.794007] 3d60:
c78bb140 c065476c c7a8de10 00000000 c78b4e10 c78b4e00 00000004 00000001
[ 1.802227] 3d80:
c06d25d4 00000000 c7843dbc c7843d98 c0115a68 c0112538 00000001 c78b4e10
[ 1.810448] 3da0:
c78b4e18 ffffffed c78b4e10 fffffdfb c070bc80 00000000 c06d25d4 00000000
[ 1.818669] 3dc0:
c7843dec c7843dd0 c02a0670 c02f8828 c78b4e10 c073fcb0 00000000 c070bc80
[ 1.826890] 3de0:
c7843e14 c7843df0 c029f064 c02a0630 00000000 c78b4e10 c070bc80 c78b4e44
[ 1.835110] 3e00:
00000000 c06c8cac c7843e34 c7843e18 c029f204 c029ef70 c029f170 00000000
[ 1.843332] 3e20:
c070bc80 c029f170 c7843e5c c7843e38 c029d6f4 c029f180 c785c1cc c7873c30
[ 1.851553] 3e40:
c0235728 c070bc80 c7ab9720 c0701e20 c7843e6c c7843e60 c029eb74 c029d6a4
[ 1.859774] 3e60:
c7843e94 c7843e70 c029e7f4 c029eb64 c065f390 c7843e80 c070bc80 c06f0718
[ 1.867998] 3e80:
c7ab8d60 c06b1528 c7843eac c7843e98 c029f810 c029e728 c06f0718 c06f0718
[ 1.876220] 3ea0:
c7843ebc c7843eb0 c02a04dc c029f7ac c7843ecc c7843ec0 c06c8cc4 c02a049c
[ 1.884443] 3ec0:
c7843f4c c7843ed0 c00089dc c06c8cbc c0109ec0 c0109d18 c780ac00 00000001
[ 1.892665] 3ee0:
c7843f00 c7843ef0 c06b1544 c0238a24 c7ffca48 c054c854 c7843f4c c7843f08
[ 1.900886] 3f00:
c002e7f4 c06b1538 c003d0e0 00000006 00000006 c06af1a4 00000000 c066ccb4
[ 1.909107] 3f20:
c7843f4c c06ea994 00000006 c071ff20 c06b1528 c06d25e0 c06d25d4 0000008f
[ 1.917327] 3f40:
c7843f94 c7843f50 c06b1e6c c0008964 00000006 00000006 c06b1528 dfe48a08
[ 1.925547] 3f60:
33f73660 3fd760c5 0b5d4bfd 00000000 c0527ef0 00000000 00000000 00000000
[ 1.933768] 3f80:
00000000 00000000 c7843fac c7843f98 c0527f00 c06b1d00 c7842000 00000000
[ 1.941988] 3fa0:
00000000 c7843fb0 c0009798 c0527f00 00000000 00000000 00000000 00000000
[ 1.950206] 3fc0:
00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1.958424] 3fe0:
00000000 00000000 00000000 00000000 00000013 00000000 b3cf731f fe6afeef
[ 1.966617] Backtrace:
[ 1.969150] [<
c025da80>] (of_get_named_gpiod_flags) from [<
c025db70>] (of_get_named_gpio_flags+0x10/0x24)
[ 1.978744] r7:
000001ff r6:
c7a8dc00 r5:
c78b4e10 r4:
00000000
[ 1.984548] [<
c025db60>] (of_get_named_gpio_flags) from [<
c02f8938>] (spi_imx_probe+0x120/0x67c)
[ 1.993390] [<
c02f8818>] (spi_imx_probe) from [<
c02a0670>] (platform_drv_probe+0x50/0xac)
[ 2.001589] r10:
00000000 r9:
c06d25d4 r8:
00000000 r7:
c070bc80 r6:
fffffdfb r5:
c78b4e10
[ 2.009549] r4:
ffffffed
[ 2.012144] [<
c02a0620>] (platform_drv_probe) from [<
c029f064>] (driver_probe_device+0x104/0x210)
[ 2.021040] r7:
c070bc80 r6:
00000000 r5:
c073fcb0 r4:
c78b4e10
[ 2.026822] [<
c029ef60>] (driver_probe_device) from [<
c029f204>] (__driver_attach+0x94/0x98)
[ 2.035282] r8:
c06c8cac r7:
00000000 r6:
c78b4e44 r5:
c070bc80 r4:
c78b4e10 r3:
00000000
[ 2.043191] [<
c029f170>] (__driver_attach) from [<
c029d6f4>] (bus_for_each_dev+0x60/0x90)
[ 2.051394] r6:
c029f170 r5:
c070bc80 r4:
00000000 r3:
c029f170
[ 2.057185] [<
c029d694>] (bus_for_each_dev) from [<
c029eb74>] (driver_attach+0x20/0x28)
[ 2.065212] r6:
c0701e20 r5:
c7ab9720 r4:
c070bc80
[ 2.069931] [<
c029eb54>] (driver_attach) from [<
c029e7f4>] (bus_add_driver+0xdc/0x1dc)
[ 2.077894] [<
c029e718>] (bus_add_driver) from [<
c029f810>] (driver_register+0x74/0xec)
[ 2.085919] r7:
c06b1528 r6:
c7ab8d60 r5:
c06f0718 r4:
c070bc80
[ 2.091705] [<
c029f79c>] (driver_register) from [<
c02a04dc>] (__platform_driver_register+0x50/0x64)
[ 2.100774] r5:
c06f0718 r4:
c06f0718
[ 2.104437] [<
c02a048c>] (__platform_driver_register) from [<
c06c8cc4>] (spi_imx_driver_init+0x18/0x20)
[ 2.113884] [<
c06c8cac>] (spi_imx_driver_init) from [<
c00089dc>] (do_one_initcall+0x88/0x1b0)
[ 2.122459] [<
c0008954>] (do_one_initcall) from [<
c06b1e6c>] (kernel_init_freeable+0x17c/0x248)
[ 2.131182] r10:
0000008f r9:
c06d25d4 r8:
c06d25e0 r7:
c06b1528 r6:
c071ff20 r5:
00000006
[ 2.139141] r4:
c06ea994
[ 2.141751] [<
c06b1cf0>] (kernel_init_freeable) from [<
c0527f00>] (kernel_init+0x10/0xec)
[ 2.149955] r10:
00000000 r9:
00000000 r8:
00000000 r7:
00000000 r6:
00000000 r5:
c0527ef0
[ 2.157909] r4:
00000000
[ 2.160508] [<
c0527ef0>] (kernel_init) from [<
c0009798>] (ret_from_fork+0x14/0x3c)
[ 2.168099] r4:
00000000 r3:
c7842000
[ 2.171755] Code:
eb0b2dc2 e51b0020 e24bd01c e89da8f0 (
e597300c)
Cc: stable@vger.kernel.org # v4.4.x, v4.9.x
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Nick Desaulniers [Thu, 30 Jul 2020 22:45:54 +0000 (15:45 -0700)]
tracepoint: Mark __tracepoint_string's __used
commit
f3751ad0116fb6881f2c3c957d66a9327f69cefb upstream.
__tracepoint_string's have their string data stored in .rodata, and an
address to that data stored in the "__tracepoint_str" section. Functions
that refer to those strings refer to the symbol of the address. Compiler
optimization can replace those address references with references
directly to the string data. If the address doesn't appear to have other
uses, then it appears dead to the compiler and is removed. This can
break the /tracing/printk_formats sysfs node which iterates the
addresses stored in the "__tracepoint_str" section.
Like other strings stored in custom sections in this header, mark these
__used to inform the compiler that there are other non-obvious users of
the address, so they should still be emitted.
Link: https://lkml.kernel.org/r/20200730224555.2142154-2-ndesaulniers@google.com
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Cc: stable@vger.kernel.org
Fixes:
102c9323c35a8 ("tracing: Add __tracepoint_string() to export string pointers")
Reported-by: Tim Murray <timmurray@google.com>
Reported-by: Simon MacMullen <simonmacm@google.com>
Suggested-by: Greg Hackmann <ghackmann@google.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Eric Biggers [Wed, 8 Jul 2020 20:15:20 +0000 (13:15 -0700)]
Smack: fix use-after-free in smk_write_relabel_self()
commit
beb4ee6770a89646659e6a2178538d2b13e2654e upstream.
smk_write_relabel_self() frees memory from the task's credentials with
no locking, which can easily cause a use-after-free because multiple
tasks can share the same credentials structure.
Fix this by using prepare_creds() and commit_creds() to correctly modify
the task's credentials.
Reproducer for "BUG: KASAN: use-after-free in smk_write_relabel_self":
#include <fcntl.h>
#include <pthread.h>
#include <unistd.h>
static void *thrproc(void *arg)
{
int fd = open("/sys/fs/smackfs/relabel-self", O_WRONLY);
for (;;) write(fd, "foo", 3);
}
int main()
{
pthread_t t;
pthread_create(&t, NULL, thrproc, NULL);
thrproc(NULL);
}
Reported-by: syzbot+e6416dabb497a650da40@syzkaller.appspotmail.com
Fixes:
38416e53936e ("Smack: limited capability for changing process label")
Cc: <stable@vger.kernel.org> # v4.4+
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>
Rustam Kovhaev [Tue, 28 Jul 2020 06:42:17 +0000 (23:42 -0700)]
usb: hso: check for return value in hso_serial_common_create()
[ Upstream commit
e911e99a0770f760377c263bc7bac1b1593c6147 ]
in case of an error tty_register_device_attr() returns ERR_PTR(),
add IS_ERR() check
Reported-and-tested-by: syzbot+67b2bd0e34f952d0321e@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=67b2bd0e34f952d0321e
Signed-off-by: Rustam Kovhaev <rkovhaev@gmail.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Hangbin Liu [Wed, 5 Aug 2020 02:41:31 +0000 (10:41 +0800)]
Revert "vxlan: fix tos value before xmit"
[ Upstream commit
a0dced17ad9dc08b1b25e0065b54c97a318e6e8b ]
This reverts commit
71130f29979c7c7956b040673e6b9d5643003176.
In commit
71130f29979c ("vxlan: fix tos value before xmit") we want to
make sure the tos value are filtered by RT_TOS() based on RFC1349.
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS | MBZ |
+-----+-----+-----+-----+-----+-----+-----+-----+
But RFC1349 has been obsoleted by RFC2474. The new DSCP field defined like
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| DS FIELD, DSCP | ECN FIELD |
+-----+-----+-----+-----+-----+-----+-----+-----+
So with
IPTOS_TOS_MASK 0x1E
RT_TOS(tos) ((tos)&IPTOS_TOS_MASK)
the first 3 bits DSCP info will get lost.
To take all the DSCP info in xmit, we should revert the patch and just push
all tos bits to ip_tunnel_ecn_encap(), which will handling ECN field later.
Fixes:
71130f29979c ("vxlan: fix tos value before xmit")
Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Acked-by: Guillaume Nault <gnault@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Tue, 28 Jul 2020 12:10:31 +0000 (14:10 +0200)]
net: lan78xx: replace bogus endpoint lookup
[ Upstream commit
ea060b352654a8de1e070140d25fe1b7e4d50310 ]
Drop the bogus endpoint-lookup helper which could end up accepting
interfaces based on endpoints belonging to unrelated altsettings.
Note that the returned bulk pipes and interrupt endpoint descriptor
were never actually used. Instead the bulk-endpoint numbers are
hardcoded to 1 and 2 (matching the specification), while the interrupt-
endpoint descriptor was assumed to be the third descriptor created by
USB core.
Try to bring some order to this by dropping the bogus lookup helper and
adding the missing endpoint sanity checks while keeping the interrupt-
descriptor assumption for now.
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>
Ido Schimmel [Wed, 29 Jul 2020 08:34:36 +0000 (11:34 +0300)]
vxlan: Ensure FDB dump is performed under RCU
[ Upstream commit
b5141915b5aec3b29a63db869229e3741ebce258 ]
The commit cited below removed the RCU read-side critical section from
rtnl_fdb_dump() which means that the ndo_fdb_dump() callback is invoked
without RCU protection.
This results in the following warning [1] in the VXLAN driver, which
relied on the callback being invoked from an RCU read-side critical
section.
Fix this by calling rcu_read_lock() in the VXLAN driver, as already done
in the bridge driver.
[1]
WARNING: suspicious RCU usage
5.8.0-rc4-custom-01521-g481007553ce6 #29 Not tainted
-----------------------------
drivers/net/vxlan.c:1379 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by bridge/166:
#0:
ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xea/0x1090
stack backtrace:
CPU: 1 PID: 166 Comm: bridge Not tainted 5.8.0-rc4-custom-01521-g481007553ce6 #29
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
Call Trace:
dump_stack+0x100/0x184
lockdep_rcu_suspicious+0x153/0x15d
vxlan_fdb_dump+0x51e/0x6d0
rtnl_fdb_dump+0x4dc/0xad0
netlink_dump+0x540/0x1090
__netlink_dump_start+0x695/0x950
rtnetlink_rcv_msg+0x802/0xbd0
netlink_rcv_skb+0x17a/0x480
rtnetlink_rcv+0x22/0x30
netlink_unicast+0x5ae/0x890
netlink_sendmsg+0x98a/0xf40
__sys_sendto+0x279/0x3b0
__x64_sys_sendto+0xe6/0x1a0
do_syscall_64+0x54/0xa0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fe14fa2ade0
Code: Bad RIP value.
RSP: 002b:
00007fff75bb5b88 EFLAGS:
00000246 ORIG_RAX:
000000000000002c
RAX:
ffffffffffffffda RBX:
00005614b1ba0020 RCX:
00007fe14fa2ade0
RDX:
000000000000011c RSI:
00007fff75bb5b90 RDI:
0000000000000003
RBP:
00007fff75bb5b90 R08:
0000000000000000 R09:
0000000000000000
R10:
0000000000000000 R11:
0000000000000246 R12:
00005614b1b89160
R13:
0000000000000000 R14:
0000000000000000 R15:
0000000000000000
Fixes:
5e6d24358799 ("bridge: netlink dump interface at par with brctl")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cong Wang [Sat, 25 Jul 2020 22:40:53 +0000 (15:40 -0700)]
ipv6: fix memory leaks on IPV6_ADDRFORM path
[ Upstream commit
8c0de6e96c9794cb523a516c465991a70245da1c ]
IPV6_ADDRFORM causes resource leaks when converting an IPv6 socket
to IPv4, particularly struct ipv6_ac_socklist. Similar to
struct ipv6_mc_socklist, we should just close it on this path.
This bug can be easily reproduced with the following C program:
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <arpa/inet.h>
int main()
{
int s, value;
struct sockaddr_in6 addr;
struct ipv6_mreq m6;
s = socket(AF_INET6, SOCK_DGRAM, 0);
addr.sin6_family = AF_INET6;
addr.sin6_port = htons(5000);
inet_pton(AF_INET6, "::ffff:192.168.122.194", &addr.sin6_addr);
connect(s, (struct sockaddr *)&addr, sizeof(addr));
inet_pton(AF_INET6, "fe80::AAAA", &m6.ipv6mr_multiaddr);
m6.ipv6mr_interface = 5;
setsockopt(s, SOL_IPV6, IPV6_JOIN_ANYCAST, &m6, sizeof(m6));
value = AF_INET;
setsockopt(s, SOL_IPV6, IPV6_ADDRFORM, &value, sizeof(value));
close(s);
return 0;
}
Reported-by: ch3332xr@gmail.com
Fixes:
1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Ido Schimmel [Wed, 29 Jul 2020 08:37:13 +0000 (11:37 +0300)]
ipv4: Silence suspicious RCU usage warning
[ Upstream commit
83f3522860f702748143e022f1a546547314c715 ]
fib_trie_unmerge() is called with RTNL held, but not from an RCU
read-side critical section. This leads to the following warning [1] when
the FIB alias list in a leaf is traversed with
hlist_for_each_entry_rcu().
Since the function is always called with RTNL held and since
modification of the list is protected by RTNL, simply use
hlist_for_each_entry() and silence the warning.
[1]
WARNING: suspicious RCU usage
5.8.0-rc4-custom-01520-gc1f937f3f83b #30 Not tainted
-----------------------------
net/ipv4/fib_trie.c:1867 RCU-list traversed in non-reader section!!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
1 lock held by ip/164:
#0:
ffffffff85a27850 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x49a/0xbd0
stack backtrace:
CPU: 0 PID: 164 Comm: ip Not tainted 5.8.0-rc4-custom-01520-gc1f937f3f83b #30
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-2.fc32 04/01/2014
Call Trace:
dump_stack+0x100/0x184
lockdep_rcu_suspicious+0x153/0x15d
fib_trie_unmerge+0x608/0xdb0
fib_unmerge+0x44/0x360
fib4_rule_configure+0xc8/0xad0
fib_nl_newrule+0x37a/0x1dd0
rtnetlink_rcv_msg+0x4f7/0xbd0
netlink_rcv_skb+0x17a/0x480
rtnetlink_rcv+0x22/0x30
netlink_unicast+0x5ae/0x890
netlink_sendmsg+0x98a/0xf40
____sys_sendmsg+0x879/0xa00
___sys_sendmsg+0x122/0x190
__sys_sendmsg+0x103/0x1d0
__x64_sys_sendmsg+0x7d/0xb0
do_syscall_64+0x54/0xa0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7fc80a234e97
Code: Bad RIP value.
RSP: 002b:
00007ffef8b66798 EFLAGS:
00000246 ORIG_RAX:
000000000000002e
RAX:
ffffffffffffffda RBX:
0000000000000000 RCX:
00007fc80a234e97
RDX:
0000000000000000 RSI:
00007ffef8b66800 RDI:
0000000000000003
RBP:
000000005f141b1c R08:
0000000000000001 R09:
0000000000000000
R10:
00007fc80a2a8ac0 R11:
0000000000000246 R12:
0000000000000001
R13:
0000000000000000 R14:
00007ffef8b67008 R15:
0000556fccb10020
Fixes:
0ddcf43d5d4a ("ipv4: FIB Local/MAIN table collapse")
Signed-off-by: Ido Schimmel <idosch@mellanox.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jann Horn [Mon, 27 Jul 2020 12:04:24 +0000 (14:04 +0200)]
binder: Prevent context manager from incrementing ref 0
commit
4b836a1426cb0f1ef2a6e211d7e553221594f8fc upstream.
Binder is designed such that a binder_proc never has references to
itself. If this rule is violated, memory corruption can occur when a
process sends a transaction to itself; see e.g.
<https://syzkaller.appspot.com/bug?extid=
09e05aba06723a94d43d>.
There is a remaining edgecase through which such a transaction-to-self
can still occur from the context of a task with BINDER_SET_CONTEXT_MGR
access:
- task A opens /dev/binder twice, creating binder_proc instances P1
and P2
- P1 becomes context manager
- P2 calls ACQUIRE on the magic handle 0, allocating index 0 in its
handle table
- P1 dies (by closing the /dev/binder fd and waiting a bit)
- P2 becomes context manager
- P2 calls ACQUIRE on the magic handle 0, allocating index 1 in its
handle table
[this triggers a warning: "binder: 1974:1974 tried to acquire
reference to desc 0, got 1 instead"]
- task B opens /dev/binder once, creating binder_proc instance P3
- P3 calls P2 (via magic handle 0) with (void*)1 as argument (two-way
transaction)
- P2 receives the handle and uses it to call P3 (two-way transaction)
- P3 calls P2 (via magic handle 0) (two-way transaction)
- P2 calls P2 (via handle 1) (two-way transaction)
And then, if P2 does *NOT* accept the incoming transaction work, but
instead closes the binder fd, we get a crash.
Solve it by preventing the context manager from using ACQUIRE on ref 0.
There shouldn't be any legitimate reason for the context manager to do
that.
Additionally, print a warning if someone manages to find another way to
trigger a transaction-to-self bug in the future.
Cc: stable@vger.kernel.org
Fixes:
457b9a6f09f0 ("Staging: android: add binder driver")
Acked-by: Todd Kjos <tkjos@google.com>
Signed-off-by: Jann Horn <jannh@google.com>
Reviewed-by: Martijn Coenen <maco@android.com>
Link: https://lore.kernel.org/r/20200727120424.1627555-1-jannh@google.com
[manual backport: remove fine-grained locking and error reporting that
don't exist in <=4.9]
Signed-off-by: Jann Horn <jannh@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Frank van der Linden [Tue, 23 Jun 2020 22:39:18 +0000 (22:39 +0000)]
xattr: break delegations in {set,remove}xattr
commit
08b5d5014a27e717826999ad20e394a8811aae92 upstream.
set/removexattr on an exported filesystem should break NFS delegations.
This is true in general, but also for the upcoming support for
RFC 8726 (NFSv4 extended attribute support). Make sure that they do.
Additionally, they need to grow a _locked variant, since callers might
call this with i_rwsem held (like the NFS server code).
Cc: stable@vger.kernel.org # v4.9+
Cc: linux-fsdevel@vger.kernel.org
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Frank van der Linden <fllinden@amazon.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Philippe Duplessis-Guindon [Thu, 30 Jul 2020 15:02:36 +0000 (11:02 -0400)]
tools lib traceevent: Fix memory leak in process_dynamic_array_len
[ Upstream commit
e24c6447ccb7b1a01f9bf0aec94939e6450c0b4d ]
I compiled with AddressSanitizer and I had these memory leaks while I
was using the tep_parse_format function:
Direct leak of 28 byte(s) in 4 object(s) allocated from:
#0 0x7fb07db49ffe in __interceptor_realloc (/lib/x86_64-linux-gnu/libasan.so.5+0x10dffe)
#1 0x7fb07a724228 in extend_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:985
#2 0x7fb07a724c21 in __read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1140
#3 0x7fb07a724f78 in read_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1206
#4 0x7fb07a725191 in __read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1291
#5 0x7fb07a7251df in read_expect_type /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1299
#6 0x7fb07a72e6c8 in process_dynamic_array_len /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:2849
#7 0x7fb07a7304b8 in process_function /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3161
#8 0x7fb07a730900 in process_arg_token /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3207
#9 0x7fb07a727c0b in process_arg /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:1786
#10 0x7fb07a731080 in event_read_print_args /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3285
#11 0x7fb07a731722 in event_read_print /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:3369
#12 0x7fb07a740054 in __tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6335
#13 0x7fb07a74047a in __parse_event /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6389
#14 0x7fb07a740536 in tep_parse_format /home/pduplessis/repo/linux/tools/lib/traceevent/event-parse.c:6431
#15 0x7fb07a785acf in parse_event ../../../src/fs-src/fs.c:251
#16 0x7fb07a785ccd in parse_systems ../../../src/fs-src/fs.c:284
#17 0x7fb07a786fb3 in read_metadata ../../../src/fs-src/fs.c:593
#18 0x7fb07a78760e in ftrace_fs_source_init ../../../src/fs-src/fs.c:727
#19 0x7fb07d90c19c in add_component_with_init_method_data ../../../../src/lib/graph/graph.c:1048
#20 0x7fb07d90c87b in add_source_component_with_initialize_method_data ../../../../src/lib/graph/graph.c:1127
#21 0x7fb07d90c92a in bt_graph_add_source_component ../../../../src/lib/graph/graph.c:1152
#22 0x55db11aa632e in cmd_run_ctx_create_components_from_config_components ../../../src/cli/babeltrace2.c:2252
#23 0x55db11aa6fda in cmd_run_ctx_create_components ../../../src/cli/babeltrace2.c:2347
#24 0x55db11aa780c in cmd_run ../../../src/cli/babeltrace2.c:2461
#25 0x55db11aa8a7d in main ../../../src/cli/babeltrace2.c:2673
#26 0x7fb07d5460b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
The token variable in the process_dynamic_array_len function is
allocated in the read_expect_type function, but is not freed before
calling the read_token function.
Free the token variable before calling read_token in order to plug the
leak.
Signed-off-by: Philippe Duplessis-Guindon <pduplessis@efficios.com>
Reviewed-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Link: https://lore.kernel.org/linux-trace-devel/20200730150236.5392-1-pduplessis@efficios.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Xin Xiong [Wed, 29 Jul 2020 13:06:59 +0000 (21:06 +0800)]
atm: fix atm_dev refcnt leaks in atmtcp_remove_persistent
[ Upstream commit
51875dad43b44241b46a569493f1e4bfa0386d86 ]
atmtcp_remove_persistent() invokes atm_dev_lookup(), which returns a
reference of atm_dev with increased refcount or NULL if fails.
The refcount leaks issues occur in two error handling paths. If
dev_data->persist is zero or PRIV(dev)->vcc isn't NULL, the function
returns 0 without decreasing the refcount kept by a local variable,
resulting in refcount leaks.
Fix the issue by adding atm_dev_put() before returning 0 both when
dev_data->persist is zero or PRIV(dev)->vcc isn't NULL.
Signed-off-by: Xin Xiong <xiongx18@fudan.edu.cn>
Signed-off-by: Xiyu Yang <xiyuyang19@fudan.edu.cn>
Signed-off-by: Xin Tan <tanxin.ctf@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Francesco Ruggeri [Thu, 2 Jul 2020 22:39:06 +0000 (15:39 -0700)]
igb: reinit_locked() should be called with rtnl_lock
[ Upstream commit
024a8168b749db7a4aa40a5fbdfa04bf7e77c1c0 ]
We observed two panics involving races with igb_reset_task.
The first panic is caused by this race condition:
kworker reboot -f
igb_reset_task
igb_reinit_locked
igb_down
napi_synchronize
__igb_shutdown
igb_clear_interrupt_scheme
igb_free_q_vectors
igb_free_q_vector
adapter->q_vector[v_idx] = NULL;
napi_disable
Panics trying to access
adapter->q_vector[v_idx].napi_state
The second panic (a divide error) is caused by this race:
kworker reboot -f tx packet
igb_reset_task
__igb_shutdown
rtnl_lock()
...
igb_clear_interrupt_scheme
igb_free_q_vectors
adapter->num_tx_queues = 0
...
rtnl_unlock()
rtnl_lock()
igb_reinit_locked
igb_down
igb_up
netif_tx_start_all_queues
dev_hard_start_xmit
igb_xmit_frame
igb_tx_queue_mapping
Panics on
r_idx % adapter->num_tx_queues
This commit applies to igb_reset_task the same changes that
were applied to ixgbe in commit
2f90b8657ec9 ("ixgbe: this patch
adds support for DCB to the kernel and ixgbe driver"),
commit
8f4c5c9fb87a ("ixgbe: reinit_locked() should be called with
rtnl_lock") and commit
88adce4ea8f9 ("ixgbe: fix possible race in
reset subtask").
Signed-off-by: Francesco Ruggeri <fruggeri@arista.com>
Tested-by: Aaron Brown <aaron.f.brown@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Julian Squires [Mon, 6 Jul 2020 21:13:53 +0000 (17:13 -0400)]
cfg80211: check vendor command doit pointer before use
[ Upstream commit
4052d3d2e8f47a15053320bbcbe365d15610437d ]
In the case where a vendor command does not implement doit, and has no
flags set, doit would not be validated and a NULL pointer dereference
would occur, for example when invoking the vendor command via iw.
I encountered this while developing new vendor commands. Perhaps in
practice it is advisable to always implement doit along with dumpit,
but it seems reasonable to me to always check doit anyway, not just
when NEED_WDEV.
Signed-off-by: Julian Squires <julian@cipht.net>
Link: https://lore.kernel.org/r/20200706211353.2366470-1-julian@cipht.net
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Ben Skeggs [Fri, 24 Jul 2020 07:01:39 +0000 (17:01 +1000)]
drm/nouveau/fbcon: fix module unload when fbcon init has failed for some reason
[ Upstream commit
498595abf5bd51f0ae074cec565d888778ea558f ]
Stale pointer was tripping up the unload path.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Christoph Hellwig [Fri, 10 Jul 2020 08:57:22 +0000 (10:57 +0200)]
net/9p: validate fds in p9_fd_open
[ Upstream commit
a39c46067c845a8a2d7144836e9468b7f072343e ]
p9_fd_open just fgets file descriptors passed in from userspace, but
doesn't verify that they are valid for read or writing. This gets
cought down in the VFS when actually attempting a read or write, but
a new warning added in linux-next upsets syzcaller.
Fix this by just verifying the fds early on.
Link: http://lkml.kernel.org/r/20200710085722.435850-1-hch@lst.de
Reported-by: syzbot+e6f77e16ff68b2434a2c@syzkaller.appspotmail.com
Signed-off-by: Christoph Hellwig <hch@lst.de>
[Dominique: amend goto as per Doug Nazar's review]
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Johan Hovold [Mon, 1 Jun 2020 13:39:45 +0000 (15:39 +0200)]
leds: 88pm860x: fix use-after-free on unbind
commit
eca21c2d8655387823d695b26e6fe78cf3975c05 upstream.
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.
Fixes:
375446df95ee ("leds: 88pm860x: Use devm_led_classdev_register")
Cc: stable <stable@vger.kernel.org> # 4.6
Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Mon, 1 Jun 2020 13:39:47 +0000 (15:39 +0200)]
leds: lm3533: fix use-after-free on unbind
commit
d584221e683bbd173738603b83a315f27d27d043 upstream.
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.
Fixes:
50154e29e5cc ("leds: lm3533: Use devm_led_classdev_register")
Cc: stable <stable@vger.kernel.org> # 4.6
Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Mon, 1 Jun 2020 13:39:46 +0000 (15:39 +0200)]
leds: da903x: fix use-after-free on unbind
commit
6f4aa35744f69ed9b0bf5a736c9ca9b44bc1dcea upstream.
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.
Fixes:
eed16255d66b ("leds: da903x: Use devm_led_classdev_register")
Cc: stable <stable@vger.kernel.org> # 4.6
Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Johan Hovold [Mon, 1 Jun 2020 13:39:49 +0000 (15:39 +0200)]
leds: wm831x-status: fix use-after-free on unbind
commit
47a459ecc800a17109d0c496a4e21e478806ee40 upstream.
Several MFD child drivers register their class devices directly under
the parent device. This means you cannot blindly do devres conversions
so that deregistration ends up being tied to the parent device,
something which leads to use-after-free on driver unbind when the class
device is released while still being registered.
Fixes:
8d3b6a4001ce ("leds: wm831x-status: Use devm_led_classdev_register")
Cc: stable <stable@vger.kernel.org> # 4.6
Cc: Amitoj Kaur Chawla <amitoj1606@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Greg Kroah-Hartman [Thu, 16 Jul 2020 11:53:46 +0000 (13:53 +0200)]
mtd: properly check all write ioctls for permissions
commit
f7e6b19bc76471ba03725fe58e0c218a3d6266c3 upstream.
When doing a "write" ioctl call, properly check that we have permissions
to do so before copying anything from userspace or anything else so we
can "fail fast". This includes also covering the MEMWRITE ioctl which
previously missed checking for this.
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[rw: Fixed locking issue]
Signed-off-by: Richard Weinberger <richard@nod.at>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Yunhai Zhang [Tue, 28 Jul 2020 01:58:03 +0000 (09:58 +0800)]
vgacon: Fix for missing check in scrollback handling
commit
ebfdfeeae8c01fcb2b3b74ffaf03876e20835d2d upstream.
vgacon_scrollback_update() always leaves enbough room in the scrollback
buffer for the next call, but if the console size changed that room
might not actually be enough, and so we need to re-check.
The check should be in the loop since vgacon_scrollback_cur->tail is
updated in the loop and count may be more than 1 when triggered by CSI M,
as Jiri's PoC:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <fcntl.h>
int main(int argc, char** argv)
{
int fd = open("/dev/tty1", O_RDWR);
unsigned short size[3] = {25, 200, 0};
ioctl(fd, 0x5609, size); // VT_RESIZE
write(fd, "\e[1;1H", 6);
for (int i = 0; i < 30; i++)
write(fd, "\e[10M", 5);
}
It leads to various crashes as vgacon_scrollback_update writes out of
the buffer:
BUG: unable to handle page fault for address:
ffffc900001752a0
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
RIP: 0010:mutex_unlock+0x13/0x30
...
Call Trace:
n_tty_write+0x1a0/0x4d0
tty_write+0x1a0/0x2e0
Or to KASAN reports:
BUG: KASAN: slab-out-of-bounds in vgacon_scroll+0x57a/0x8ed
This fixes CVE-2020-14331.
Reported-by: 张云海 <zhangyunhai@nsfocus.com>
Reported-by: Yang Yingliang <yangyingliang@huawei.com>
Reported-by: Kyungtae Kim <kt0755@gmail.com>
Fixes:
15bdab959c9b ([PATCH] vgacon: Add support for soft scrollback)
Cc: stable@vger.kernel.org
Cc: linux-fbdev@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Solar Designer <solar@openwall.com>
Cc: "Srivatsa S. Bhat" <srivatsa@csail.mit.edu>
Cc: Anthony Liguori <aliguori@amazon.com>
Cc: Yang Yingliang <yangyingliang@huawei.com>
Cc: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Cc: Jiri Slaby <jirislaby@kernel.org>
Signed-off-by: Yunhai Zhang <zhangyunhai@nsfocus.com>
Link: https://lore.kernel.org/r/9fb43895-ca91-9b07-ebfd-808cf854ca95@nsfocus.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Adam Ford [Tue, 30 Jun 2020 18:26:36 +0000 (13:26 -0500)]
omapfb: dss: Fix max fclk divider for omap36xx
commit
254503a2b186caa668a188dbbd7ab0d25149c0a5 upstream.
The drm/omap driver was fixed to correct an issue where using a
divider of 32 breaks the DSS despite the TRM stating 32 is a valid
number. Through experimentation, it appears that 31 works, and
it is consistent with the value used by the drm/omap driver.
This patch fixes the divider for fbdev driver instead of the drm.
Fixes:
f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
Cc: <stable@vger.kernel.org> #4.5+
Signed-off-by: Adam Ford <aford173@gmail.com>
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Dave Airlie <airlied@gmail.com>
Cc: Rob Clark <robdclark@gmail.com>
[b.zolnierkie: mark patch as applicable to stable 4.5+ (was 4.9+)]
Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200630182636.439015-1-aford173@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peilin Ye [Fri, 10 Jul 2020 21:45:26 +0000 (17:45 -0400)]
Bluetooth: Prevent out-of-bounds read in hci_inquiry_result_with_rssi_evt()
commit
629b49c848ee71244203934347bd7730b0ddee8d upstream.
Check `num_rsp` before using it as for-loop counter. Add `unlock` label.
Cc: stable@vger.kernel.org
Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peilin Ye [Fri, 10 Jul 2020 21:39:18 +0000 (17:39 -0400)]
Bluetooth: Prevent out-of-bounds read in hci_inquiry_result_evt()
commit
75bbd2ea50ba1c5d9da878a17e92eac02fe0fd3a upstream.
Check `num_rsp` before using it as for-loop counter.
Cc: stable@vger.kernel.org
Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Peilin Ye [Fri, 10 Jul 2020 16:09:15 +0000 (12:09 -0400)]
Bluetooth: Fix slab-out-of-bounds read in hci_extended_inquiry_result_evt()
commit
51c19bf3d5cfaa66571e4b88ba2a6f6295311101 upstream.
Check upon `num_rsp` is insufficient. A malformed event packet with a
large `num_rsp` number makes hci_extended_inquiry_result_evt() go out
of bounds. Fix it.
This patch fixes the following syzbot bug:
https://syzkaller.appspot.com/bug?id=
4bf11aa05c4ca51ce0df86e500fce486552dc8d2
Reported-by: syzbot+d8489a79b781849b9c46@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Takashi Iwai [Tue, 4 Aug 2020 18:58:15 +0000 (20:58 +0200)]
ALSA: seq: oss: Serialize ioctls
commit
80982c7e834e5d4e325b6ce33757012ecafdf0bb upstream.
Some ioctls via OSS sequencer API may race and lead to UAF when the
port create and delete are performed concurrently, as spotted by a
couple of syzkaller cases. This patch is an attempt to address it by
serializing the ioctls with the existing register_mutex.
Basically OSS sequencer API is an obsoleted interface and was designed
without much consideration of the concurrency. There are very few
applications with it, and the concurrent performance isn't asked,
hence this "big hammer" approach should be good enough.
Reported-by: syzbot+1a54a94bd32716796edd@syzkaller.appspotmail.com
Reported-by: syzbot+9d2abfef257f3e2d4713@syzkaller.appspotmail.com
Suggested-by: Hillf Danton <hdanton@sina.com>
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20200804185815.2453-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Roi Dayan [Fri, 7 Aug 2020 02:05:42 +0000 (19:05 -0700)]
net/mlx5e: Don't support phys switch id if not in switchdev mode
Support for phys switch id ndo added for representors and if
we do not have representors there is no need to support it.
Since each port return different switch id supporting this
block support for creating bond over PFs and attaching to bridge
in legacy mode.
This bug doesn't exist upstream as the code got refactored and the
netdev api is totally different.
Fixes:
cb67b832921c ("net/mlx5e: Introduce SRIOV VF representors")
Signed-off-by: Roi Dayan <roid@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Erik Ekman [Fri, 17 Jul 2020 18:51:18 +0000 (20:51 +0200)]
USB: serial: qcserial: add EM7305 QDL product ID
commit
d2a4309c1ab6df424b2239fe2920d6f26f808d17 upstream.
When running qmi-firmware-update on the Sierra Wireless EM7305 in a Toshiba
laptop, it changed product ID to 0x9062 when entering QDL mode:
usb 2-4: new high-speed USB device number 78 using xhci_hcd
usb 2-4: New USB device found, idVendor=1199, idProduct=9062, bcdDevice= 0.00
usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 2-4: Product: EM7305
usb 2-4: Manufacturer: Sierra Wireless, Incorporated
The upgrade could complete after running
# echo 1199 9062 > /sys/bus/usb-serial/drivers/qcserial/new_id
qcserial 2-4:1.0: Qualcomm USB modem converter detected
usb 2-4: Qualcomm USB modem converter now attached to ttyUSB0
Signed-off-by: Erik Ekman <erik@kryo.se>
Link: https://lore.kernel.org/r/20200717185118.3640219-1-erik@kryo.se
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Jiang Ying [Thu, 6 Aug 2020 12:01:04 +0000 (20:01 +0800)]
ext4: fix direct I/O read error
This patch is used to fix ext4 direct I/O read error when
the read size is not aligned with block size.
Then, I will use a test to explain the error.
(1) Make a file that is not aligned with block size:
$dd if=/dev/zero of=./test.jar bs=1000 count=3
(2) I wrote a source file named "direct_io_read_file.c" as following:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/file.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <string.h>
#define BUF_SIZE 1024
int main()
{
int fd;
int ret;
unsigned char *buf;
ret = posix_memalign((void **)&buf, 512, BUF_SIZE);
if (ret) {
perror("posix_memalign failed");
exit(1);
}
fd = open("./test.jar", O_RDONLY | O_DIRECT, 0755);
if (fd < 0){
perror("open ./test.jar failed");
exit(1);
}
do {
ret = read(fd, buf, BUF_SIZE);
printf("ret=%d\n",ret);
if (ret < 0) {
perror("write test.jar failed");
}
} while (ret > 0);
free(buf);
close(fd);
}
(3) Compile the source file:
$gcc direct_io_read_file.c -D_GNU_SOURCE
(4) Run the test program:
$./a.out
The result is as following:
ret=1024
ret=1024
ret=952
ret=-1
write test.jar failed: Invalid argument.
I have tested this program on XFS filesystem, XFS does not have
this problem, because XFS use iomap_dio_rw() to do direct I/O
read. And the comparing between read offset and file size is done
in iomap_dio_rw(), the code is as following:
if (pos < size) {
retval = filemap_write_and_wait_range(mapping, pos,
pos + iov_length(iov, nr_segs) - 1);
if (!retval) {
retval = mapping->a_ops->direct_IO(READ, iocb,
iov, pos, nr_segs);
}
...
}
...only when "pos < size", direct I/O can be done, or 0 will be return.
I have tested the fix patch on Ext4, it is up to the mustard of
EINVAL in man2(read) as following:
#include <unistd.h>
ssize_t read(int fd, void *buf, size_t count);
EINVAL
fd is attached to an object which is unsuitable for reading;
or the file was opened with the O_DIRECT flag, and either the
address specified in buf, the value specified in count, or the
current file offset is not suitably aligned.
So I think this patch can be applied to fix ext4 direct I/O error.
However Ext4 introduces direct I/O read using iomap infrastructure
on kernel 5.5, the patch is commit <
b1b4705d54ab>
("ext4: introduce direct I/O read using iomap infrastructure"),
then Ext4 will be the same as XFS, they all use iomap_dio_rw() to do direct
I/O read. So this problem does not exist on kernel 5.5 for Ext4.
>From above description, we can see this problem exists on all the kernel
versions between kernel 3.14 and kernel 5.4. It will cause the Applications
to fail to read. For example, when the search service downloads a new full
index file, the search engine is loading the previous index file and is
processing the search request, it can not use buffer io that may squeeze
the previous index file in use from pagecache, so the serch service must
use direct I/O read.
Please apply this patch on these kernel versions, or please use the method
on kernel 5.5 to fix this problem.
Fixes:
9fe55eea7e4b ("Fix race when checking i_size on direct i/o read")
Reviewed-by: Jan Kara <jack@suse.cz>
Reviewed-by: Wang Long <wanglong19@meituan.com>
Signed-off-by: Jiang Ying <jiangying8582@126.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Torvalds [Fri, 31 Jul 2020 05:51:14 +0000 (07:51 +0200)]
random32: move the pseudo-random 32-bit definitions to prandom.h
commit
c0842fbc1b18c7a044e6ff3e8fa78bfa822c7d1a upstream.
The addition of percpu.h to the list of includes in random.h revealed
some circular dependencies on arm64 and possibly other platforms. This
include was added solely for the pseudo-random definitions, which have
nothing to do with the rest of the definitions in this file but are
still there for legacy reasons.
This patch moves the pseudo-random parts to linux/prandom.h and the
percpu.h include with it, which is now guarded by _LINUX_PRANDOM_H and
protected against recursive inclusion.
A further cleanup step would be to remove this from <linux/random.h>
entirely, and make people who use the prandom infrastructure include
just the new header file. That's a bit of a churn patch, but grepping
for "prandom_" and "next_pseudo_random32" "struct rnd_state" should
catch most users.
But it turns out that that nice cleanup step is fairly painful, because
a _lot_ of code currently seems to depend on the implicit include of
<linux/random.h>, which can currently come in a lot of ways, including
such fairly core headfers as <linux/net.h>.
So the "nice cleanup" part may or may never happen.
Fixes:
1c9df907da83 ("random: fix circular include dependency on arm64 after addition of percpu.h")
Tested-by: Guenter Roeck <linux@roeck-us.net>
Acked-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linus Torvalds [Thu, 30 Jul 2020 02:11:00 +0000 (19:11 -0700)]
random32: remove net_rand_state from the latent entropy gcc plugin
commit
83bdc7275e6206f560d247be856bceba3e1ed8f2 upstream.
It turns out that the plugin right now ends up being really unhappy
about the change from 'static' to 'extern' storage that happened in
commit
f227e3ec3b5c ("random32: update the net random state on interrupt
and activity").
This is probably a trivial fix for the latent_entropy plugin, but for
now, just remove net_rand_state from the list of things the plugin
worries about.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Emese Revfy <re.emese@gmail.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Willy Tarreau [Thu, 30 Jul 2020 05:59:24 +0000 (07:59 +0200)]
random: fix circular include dependency on arm64 after addition of percpu.h
commit
1c9df907da83812e4f33b59d3d142c864d9da57f upstream.
Daniel Díaz and Kees Cook independently reported that commit
f227e3ec3b5c ("random32: update the net random state on interrupt and
activity") broke arm64 due to a circular dependency on include files
since the addition of percpu.h in random.h.
The correct fix would definitely be to move all the prandom32 stuff out
of random.h but for backporting, a smaller solution is preferred.
This one replaces linux/percpu.h with asm/percpu.h, and this fixes the
problem on x86_64, arm64, arm, and mips. Note that moving percpu.h
around didn't change anything and that removing it entirely broke
differently. When backporting, such options might still be considered
if this patch fails to help.
[ It turns out that an alternate fix seems to be to just remove the
troublesome <asm/pointer_auth.h> remove from the arm64 <asm/smp.h>
that causes the circular dependency.
But we might as well do the whole belt-and-suspenders thing, and
minimize inclusion in <linux/random.h> too. Either will fix the
problem, and both are good changes. - Linus ]
Reported-by: Daniel Díaz <daniel.diaz@linaro.org>
Reported-by: Kees Cook <keescook@chromium.org>
Tested-by: Marc Zyngier <maz@kernel.org>
Fixes:
f227e3ec3b5c
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Grygorii Strashko [Thu, 30 Jul 2020 19:05:01 +0000 (22:05 +0300)]
ARM: percpu.h: fix build error
commit
aa54ea903abb02303bf55855fb51e3fcee135d70 upstream.
Fix build error for the case:
defined(CONFIG_SMP) && !defined(CONFIG_CPU_V6)
config: keystone_defconfig
CC arch/arm/kernel/signal.o
In file included from ../include/linux/random.h:14,
from ../arch/arm/kernel/signal.c:8:
../arch/arm/include/asm/percpu.h: In function ‘__my_cpu_offset’:
../arch/arm/include/asm/percpu.h:29:34: error: ‘current_stack_pointer’ undeclared (first use in this function); did you mean ‘user_stack_pointer’?
: "Q" (*(const unsigned long *)current_stack_pointer));
^~~~~~~~~~~~~~~~~~~~~
user_stack_pointer
Fixes:
f227e3ec3b5c ("random32: update the net random state on interrupt and activity")
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Willy Tarreau [Fri, 10 Jul 2020 13:23:19 +0000 (15:23 +0200)]
random32: update the net random state on interrupt and activity
commit
f227e3ec3b5cad859ad15666874405e8c1bbc1d4 upstream.
This modifies the first 32 bits out of the 128 bits of a random CPU's
net_rand_state on interrupt or CPU activity to complicate remote
observations that could lead to guessing the network RNG's internal
state.
Note that depending on some network devices' interrupt rate moderation
or binding, this re-seeding might happen on every packet or even almost
never.
In addition, with NOHZ some CPUs might not even get timer interrupts,
leaving their local state rarely updated, while they are running
networked processes making use of the random state. For this reason, we
also perform this update in update_process_times() in order to at least
update the state when there is user or system activity, since it's the
only case we care about.
Reported-by: Amit Klein <aksecurity@gmail.com>
Suggested-by: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Eric Dumazet <edumazet@google.com>
Cc: "Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Thomas Gleixner [Wed, 29 Jul 2020 08:53:28 +0000 (10:53 +0200)]
x86/i8259: Use printk_deferred() to prevent deadlock
commit
bdd65589593edd79b6a12ce86b3b7a7c6dae5208 upstream.
0day reported a possible circular locking dependency:
Chain exists of:
&irq_desc_lock_class --> console_owner --> &port_lock_key
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&port_lock_key);
lock(console_owner);
lock(&port_lock_key);
lock(&irq_desc_lock_class);
The reason for this is a printk() in the i8259 interrupt chip driver
which is invoked with the irq descriptor lock held, which reverses the
lock operations vs. printk() from arbitrary contexts.
Switch the printk() to printk_deferred() to avoid that.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/87365abt2v.fsf@nanos.tec.linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Wanpeng Li [Fri, 31 Jul 2020 03:12:19 +0000 (11:12 +0800)]
KVM: LAPIC: Prevent setting the tscdeadline timer if the lapic is hw disabled
commit
d2286ba7d574ba3103a421a2f9ec17cb5b0d87a1 upstream.
Prevent setting the tscdeadline timer if the lapic is hw disabled.
Fixes:
bce87cce88 (KVM: x86: consolidate different ways to test for in-kernel LAPIC)
Cc: <stable@vger.kernel.org>
Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
Message-Id: <
1596165141-28874-1-git-send-email-wanpengli@tencent.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Andrea Righi [Fri, 24 Jul 2020 08:59:10 +0000 (10:59 +0200)]
xen-netfront: fix potential deadlock in xennet_remove()
[ Upstream commit
c2c633106453611be07821f53dff9e93a9d1c3f0 ]
There's a potential race in xennet_remove(); this is what the driver is
doing upon unregistering a network device:
1. state = read bus state
2. if state is not "Closed":
3. request to set state to "Closing"
4. wait for state to be set to "Closing"
5. request to set state to "Closed"
6. wait for state to be set to "Closed"
If the state changes to "Closed" immediately after step 1 we are stuck
forever in step 4, because the state will never go back from "Closed" to
"Closing".
Make sure to check also for state == "Closed" in step 4 to prevent the
deadlock.
Also add a 5 sec timeout any time we wait for the bus state to change,
to avoid getting stuck forever in wait_event().
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Raviteja Narayanam [Fri, 3 Jul 2020 13:55:49 +0000 (19:25 +0530)]
Revert "i2c: cadence: Fix the hold bit setting"
[ Upstream commit
0db9254d6b896b587759e2c844c277fb1a6da5b9 ]
This reverts commit
d358def706880defa4c9e87381c5bf086a97d5f9.
There are two issues with "i2c: cadence: Fix the hold bit setting" commit.
1. In case of combined message request from user space, when the HOLD
bit is cleared in cdns_i2c_mrecv function, a STOP condition is sent
on the bus even before the last message is started. This is because when
the HOLD bit is cleared, the FIFOS are empty and there is no pending
transfer. The STOP condition should occur only after the last message
is completed.
2. The code added by the commit is redundant. Driver is handling the
setting/clearing of HOLD bit in right way before the commit.
The setting of HOLD bit based on 'bus_hold_flag' is taken care in
cdns_i2c_master_xfer function even before cdns_i2c_msend/cdns_i2c_recv
functions.
The clearing of HOLD bit is taken care at the end of cdns_i2c_msend and
cdns_i2c_recv functions based on bus_hold_flag and byte count.
Since clearing of HOLD bit is done after the slave address is written to
the register (writing to address register triggers the message transfer),
it is ensured that STOP condition occurs at the right time after
completion of the pending transfer (last message).
Signed-off-by: Raviteja Narayanam <raviteja.narayanam@xilinx.com>
Acked-by: Michal Simek <michal.simek@xilinx.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>