Re: Regression: OOPs on boot due to "wlcore: Add support for optional wakeirq"

[Tony Lindgren]

* John Stultz  [181025 17:04]:
> Hey Tony,
>   In testing linus/master on my hikey board, I'm hitting the following
> OOPS on bootup:
> 
> [1.870279] Unable to handle kernel read from unreadable memory at
...
> [1.870485]  wl1271_probe+0x210/0x350
> [1.870491]  sdio_bus_probe+0x100/0x128
...
> I've bisected it down to 3c83dd577c7f ("wlcore: Add support for
> optional wakeirq").
> 
> It seems since we don't have a wakeirq value in the dts, the wakeirq
> value in wl1271_probe() is zero, which then causes trouble in
> irqd_get_trigger_type(irq_get_irq_data(wakeirq)).
> 
> Should we check wakeirq before we set the second elements of res[]?

Oh sorry about that, yeah I'll take a look and post a patch ASAP.
Hmm for me value 0 there causes no errors looks like.

Regards,

Tony

Re: Regression: OOPs on boot due to "wlcore: Add support for optional wakeirq"

[John Stultz]

On Thu, Oct 25, 2018 at 10:04 AM, John Stultz  wrote:
> Hey Tony,
>   In testing linus/master on my hikey board, I'm hitting the following
> OOPS on bootup:
>
> [1.870279] Unable to handle kernel read from unreadable memory at
> virtual address 0010
> [1.870283] Mem abort info:
> [1.870287]   ESR = 0x9605
> [1.870292]   Exception class = DABT (current EL), IL = 32 bits
> [1.870296]   SET = 0, FnV = 0
> [1.870299]   EA = 0, S1PTW = 0
> [1.870302] Data abort info:
> [1.870306]   ISV = 0, ISS = 0x0005
> [1.870309]   CM = 0, WnR = 0
> [1.870312] [0010] user address but active_mm is swapper
> [1.870318] Internal error: Oops: 9605 [#1] PREEMPT SMP
> [1.870327] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted
> 4.19.0-05129-gb3d1e8e #48
> [1.870331] Hardware name: HiKey Development Board (DT)
> [1.870350] Workqueue: events_freezable mmc_rescan
> [1.870358] pstate: 6045 (nZCv daif +PAN -UAO)
> [1.870366] pc : wl1271_probe+0x210/0x350
> [1.870371] lr : wl1271_probe+0x210/0x350
> [1.870374] sp : ff80080739b0
> [1.870377] x29: ff80080739b0 x28: 
> [1.870384] x27:  x26: 
> [1.870391] x25: 0036 x24: ffc074ecb598
> [1.870398] x23: ffc07ffdce78 x22: ffc0744ed808
> [1.870404] x21: ffc074ecbb98 x20: ff8008ff9000
> [1.870411] x19: ffc0744ed800 x18: ff8008ff9a48
> [1.870418] x17:  x16: 
> [1.870425] x15: ffc074ecb503 x14: 
> [1.870431] x13: ffc074ecb502 x12: 0030
> [1.870438] x11: 0101010101010101 x10: 0040
> [1.870444] x9 : ffc075400248 x8 : ffc075400270
> [1.870451] x7 :  x6 : 
> [1.870457] x5 :  x4 : 
> [1.870463] x3 :  x2 : 
> [1.870469] x1 : 0028 x0 : 
> [1.870477] Process kworker/0:0 (pid: 5, stack limit = 0x(ptrval))
> [1.870480] Call trace:
> [1.870485]  wl1271_probe+0x210/0x350
> [1.870491]  sdio_bus_probe+0x100/0x128
> [1.870500]  really_probe+0x1a8/0x2b8
> [1.870506]  driver_probe_device+0x58/0x100
> [1.870511]  __device_attach_driver+0x94/0xd8
> [1.870517]  bus_for_each_drv+0x70/0xc8
> [1.870522]  __device_attach+0xe0/0x140
> [1.870527]  device_initial_probe+0x10/0x18
> [1.870532]  bus_probe_device+0x94/0xa0
> [1.870537]  device_add+0x374/0x5b8
> [1.870542]  sdio_add_func+0x60/0x88
> [1.870546]  mmc_attach_sdio+0x1b0/0x358
> [1.870551]  mmc_rescan+0x2cc/0x390
> [1.870558]  process_one_work+0x12c/0x320
> [1.870563]  worker_thread+0x48/0x458
> [1.870569]  kthread+0xf8/0x128
> [1.870575]  ret_from_fork+0x10/0x18
> [1.870583] Code: 92400c21 b2760021 a90687a2 97e95bf9 (f9400803)
> [1.870587] ---[ end trace 1e15f81d3c139ca9 ]---
>
>
> I've bisected it down to 3c83dd577c7f ("wlcore: Add support for
> optional wakeirq").
>
> It seems since we don't have a wakeirq value in the dts, the wakeirq
> value in wl1271_probe() is zero, which then causes trouble in
> irqd_get_trigger_type(irq_get_irq_data(wakeirq)).
>
> Should we check wakeirq before we set the second elements of res[]?

Here's my first swing at doing the above. It seems to work ok. Let me
know if it looks reasonable and I'll submit it as a proper patch.

https://git.linaro.org/people/john.stultz/android-dev.git/commit/?h=dev/hikey-mainline-WIP&id=383fb6e3abb71b8a721f196120a2e3a9da3315ac


thanks
-john

Regression: OOPs on boot due to "wlcore: Add support for optional wakeirq"

[John Stultz]

Hey Tony,
  In testing linus/master on my hikey board, I'm hitting the following
OOPS on bootup:

[1.870279] Unable to handle kernel read from unreadable memory at
virtual address 0010
[1.870283] Mem abort info:
[1.870287]   ESR = 0x9605
[1.870292]   Exception class = DABT (current EL), IL = 32 bits
[1.870296]   SET = 0, FnV = 0
[1.870299]   EA = 0, S1PTW = 0
[1.870302] Data abort info:
[1.870306]   ISV = 0, ISS = 0x0005
[1.870309]   CM = 0, WnR = 0
[1.870312] [0010] user address but active_mm is swapper
[1.870318] Internal error: Oops: 9605 [#1] PREEMPT SMP
[1.870327] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted
4.19.0-05129-gb3d1e8e #48
[1.870331] Hardware name: HiKey Development Board (DT)
[1.870350] Workqueue: events_freezable mmc_rescan
[1.870358] pstate: 6045 (nZCv daif +PAN -UAO)
[1.870366] pc : wl1271_probe+0x210/0x350
[1.870371] lr : wl1271_probe+0x210/0x350
[1.870374] sp : ff80080739b0
[1.870377] x29: ff80080739b0 x28: 
[1.870384] x27:  x26: 
[1.870391] x25: 0036 x24: ffc074ecb598
[1.870398] x23: ffc07ffdce78 x22: ffc0744ed808
[1.870404] x21: ffc074ecbb98 x20: ff8008ff9000
[1.870411] x19: ffc0744ed800 x18: ff8008ff9a48
[1.870418] x17:  x16: 
[1.870425] x15: ffc074ecb503 x14: 
[1.870431] x13: ffc074ecb502 x12: 0030
[1.870438] x11: 0101010101010101 x10: 0040
[1.870444] x9 : ffc075400248 x8 : ffc075400270
[1.870451] x7 :  x6 : 
[1.870457] x5 :  x4 : 
[1.870463] x3 :  x2 : 
[1.870469] x1 : 0028 x0 : 
[1.870477] Process kworker/0:0 (pid: 5, stack limit = 0x(ptrval))
[1.870480] Call trace:
[1.870485]  wl1271_probe+0x210/0x350
[1.870491]  sdio_bus_probe+0x100/0x128
[1.870500]  really_probe+0x1a8/0x2b8
[1.870506]  driver_probe_device+0x58/0x100
[1.870511]  __device_attach_driver+0x94/0xd8
[1.870517]  bus_for_each_drv+0x70/0xc8
[1.870522]  __device_attach+0xe0/0x140
[1.870527]  device_initial_probe+0x10/0x18
[1.870532]  bus_probe_device+0x94/0xa0
[1.870537]  device_add+0x374/0x5b8
[1.870542]  sdio_add_func+0x60/0x88
[1.870546]  mmc_attach_sdio+0x1b0/0x358
[1.870551]  mmc_rescan+0x2cc/0x390
[1.870558]  process_one_work+0x12c/0x320
[1.870563]  worker_thread+0x48/0x458
[1.870569]  kthread+0xf8/0x128
[1.870575]  ret_from_fork+0x10/0x18
[1.870583] Code: 92400c21 b2760021 a90687a2 97e95bf9 (f9400803)
[1.870587] ---[ end trace 1e15f81d3c139ca9 ]---


I've bisected it down to 3c83dd577c7f ("wlcore: Add support for
optional wakeirq").

It seems since we don't have a wakeirq value in the dts, the wakeirq
value in wl1271_probe() is zero, which then causes trouble in
irqd_get_trigger_type(irq_get_irq_data(wakeirq)).

Should we check wakeirq before we set the second elements of res[]?

thanks
-john

[PATCH AUTOSEL 4.4 34/65] drm/nouveau/fbcon: fix oops without fbdev emulation

[Sasha Levin]

From: Pavel Roskin 

[ Upstream commit 4813766325374af6ed0b66879ba6a0bbb05c83b6 ]

This is similar to an earlier commit 52dfcc5ccfbb ("drm/nouveau: fix for
disabled fbdev emulation"), but protects all occurrences of helper.fbdev
in the source.

I see oops in nouveau_fbcon_accel_save_disable() called from
nouveau_fbcon_set_suspend_work() on Linux 3.13 when
CONFIG_DRM_FBDEV_EMULATION option is disabled.

Signed-off-by: Pavel Roskin 
Reviewed-by: Daniel Vetter 
Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/nouveau/nouveau_fbcon.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c 
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index e40a1b07a014..343476d15726 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -235,7 +235,7 @@ void
 nouveau_fbcon_accel_save_disable(struct drm_device *dev)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
-   if (drm->fbcon) {
+   if (drm->fbcon && drm->fbcon->helper.fbdev) {
drm->fbcon->saved_flags = drm->fbcon->helper.fbdev->flags;
drm->fbcon->helper.fbdev->flags |= FBINFO_HWACCEL_DISABLED;
}
@@ -245,7 +245,7 @@ void
 nouveau_fbcon_accel_restore(struct drm_device *dev)
 {
struct nouveau_drm *drm = nouveau_drm(dev);
-   if (drm->fbcon) {
+   if (drm->fbcon && drm->fbcon->helper.fbdev) {
drm->fbcon->helper.fbdev->flags = drm->fbcon->saved_flags;
}
 }
@@ -257,7 +257,8 @@ nouveau_fbcon_accel_fini(struct drm_device *dev)
struct nouveau_fbdev *fbcon = drm->fbcon;
if (fbcon && drm->channel) {
console_lock();
-   fbcon->helper.fbdev->flags |= FBINFO_HWACCEL_DISABLED;
+   if (fbcon->helper.fbdev)
+   fbcon->helper.fbdev->flags |= FBINFO_HWACCEL_DISABLED;
console_unlock();
nouveau_channel_idle(drm->channel);
nvif_object_fini(&fbcon->twod);
-- 
2.17.1

[PATCH AUTOSEL 3.18 09/98] usb: gadget: gadgetfs: fix an oops in ep_write()

[Sasha Levin]

From: Dan Carpenter 

[ Upstream commit 42d6cfa0caec4b68a7f17147fbf13a36e94a8bf2 ]

We try to free an ERR_PTR on this error path.

Fixes: b44be2462dbe ('usb: gadget: gadgetfs: Free memory allocated by 
memdup_user()')
Signed-off-by: Dan Carpenter 
Signed-off-by: Felipe Balbi 
Signed-off-by: Sasha Levin 
---
 drivers/usb/gadget/legacy/inode.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/gadget/legacy/inode.c 
b/drivers/usb/gadget/legacy/inode.c
index e2d57e3d67c7..7974956e8ded 100644
--- a/drivers/usb/gadget/legacy/inode.c
+++ b/drivers/usb/gadget/legacy/inode.c
@@ -442,6 +442,7 @@ ep_write (struct file *fd, const char __user *buf, size_t 
len, loff_t *ptr)
kbuf = memdup_user(buf, len);
if (IS_ERR(kbuf)) {
value = PTR_ERR(kbuf);
+   kbuf = NULL;
goto free1;
}
 
-- 
2.17.1

[PATCH 4.4 44/48] usb: gadget: serial: fix oops when data rxd after close

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Stephen Warren 

commit daa35bd95634a2a2d72d1049c93576a02711cb1a upstream.

When the gadget serial device has no associated TTY, do not pass any
received data into the TTY layer for processing; simply drop it instead.
This prevents the TTY layer from calling back into the gadget serial
driver, which will then crash in e.g. gs_write_room() due to lack of
gadget serial device to TTY association (i.e. a NULL pointer dereference).

Signed-off-by: Stephen Warren 
Signed-off-by: Felipe Balbi 
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/gadget/function/u_serial.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -518,7 +518,7 @@ static void gs_rx_push(unsigned long _po
}
 
/* push data to (open) tty */
-   if (req->actual) {
+   if (req->actual && tty) {
char*packet = req->buf;
unsignedsize = req->actual;
unsignedn;

[PATCH 4.9 29/35] usb: gadget: serial: fix oops when data rxd after close

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Stephen Warren 

commit daa35bd95634a2a2d72d1049c93576a02711cb1a upstream.

When the gadget serial device has no associated TTY, do not pass any
received data into the TTY layer for processing; simply drop it instead.
This prevents the TTY layer from calling back into the gadget serial
driver, which will then crash in e.g. gs_write_room() due to lack of
gadget serial device to TTY association (i.e. a NULL pointer dereference).

Signed-off-by: Stephen Warren 
Signed-off-by: Felipe Balbi 
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/gadget/function/u_serial.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/gadget/function/u_serial.c
+++ b/drivers/usb/gadget/function/u_serial.c
@@ -537,7 +537,7 @@ static void gs_rx_push(unsigned long _po
}
 
/* push data to (open) tty */
-   if (req->actual) {
+   if (req->actual && tty) {
char*packet = req->buf;
unsignedsize = req->actual;
unsignedn;

Re: [PATCH stable v4.4+] usb: gadget: serial: fix oops when data rx'd after close

[Greg Kroah-Hartman]

On Thu, Oct 18, 2018 at 04:28:20PM +0200, Krzysztof Kozlowski wrote:
> From: Stephen Warren 
> 
> commit daa35bd95634a2a2d72d1049c93576a02711cb1a upstream
> 
> When the gadget serial device has no associated TTY, do not pass any
> received data into the TTY layer for processing; simply drop it instead.
> This prevents the TTY layer from calling back into the gadget serial
> driver, which will then crash in e.g. gs_write_room() due to lack of
> gadget serial device to TTY association (i.e. a NULL pointer dereference).
> 
> Signed-off-by: Stephen Warren 
> Signed-off-by: Felipe Balbi 
> Signed-off-by: Krzysztof Kozlowski 

Now queued up, thanks.

greg k-h

[PATCH stable v4.4+] usb: gadget: serial: fix oops when data rx'd after close

[Krzysztof Kozlowski]

From: Stephen Warren 

commit daa35bd95634a2a2d72d1049c93576a02711cb1a upstream

When the gadget serial device has no associated TTY, do not pass any
received data into the TTY layer for processing; simply drop it instead.
This prevents the TTY layer from calling back into the gadget serial
driver, which will then crash in e.g. gs_write_room() due to lack of
gadget serial device to TTY association (i.e. a NULL pointer dereference).

Signed-off-by: Stephen Warren 
Signed-off-by: Felipe Balbi 
Signed-off-by: Krzysztof Kozlowski 

---

This is necessary for v4.4+ to fix:

[  134.015750] Unable to handle kernel NULL pointer dereference at virtual 
address 00a8
[  134.023988] pgd = 80004000
[  134.026749] [00a8] *pgd=
[  134.030417] Internal error: Oops: 17 [#1] ARM
[  134.034826] Modules linked in: ctr ccm usb_f_acm u_serial ath9k_htc 
ath9k_common ath9k_hw ath mac80211 cfg80211 libcomposite configfs
[  134.047166] CPU: 0 PID: 51 Comm: kworker/u2:1 Not tainted 4.9.133 #60
[  134.053664] Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
[  134.060195] Workqueue: events_unbound flush_to_ldisc
[  134.065244] task: 86a42140 task.stack: 86a9a000
[  134.069872] PC is at gs_flush_chars+0x18/0x30 [u_serial]
[  134.075261] LR is at n_tty_receive_buf_common+0x648/0xa54
[  134.080726] pc : [<7f169d4c>]lr : [<803cce74>]psr: 200f0093
[  134.080726] sp : 86a9be08  ip : 86a9be20  fp : 86a9be1c
[  134.092310] r10: 86bff600  r9 : 862240cc  r8 : 
[  134.097589] r7 : 862240cc  r6 :   r5 :   r4 : 200f0013
[  134.104177] r3 : 7f169d34  r2 : 000a  r1 : 003c  r0 : 
[  134.110763] Flags: nzCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment 
none
[  134.118081] Control: 10c5387d  Table: 85fb8059  DAC: 0051
[  134.123882] Process kworker/u2:1 (pid: 51, stack limit = 0x86a9a208)
[  134.130293] Stack: (0x86a9be08 to 0x86a9c000)
[  134.134717] be00:   89f0b000  86a9be8c 86a9be20 
803cce74 7f169d40
[  134.143000] be20: 86bff658 00020001 86bff73c 86a9be38 5556 89f0b000 
86a9be6c 8061f090
[  134.151282] be40: 89f0b018 89f0d000 89f0b000  86224090 003c 
 003c
[  134.159567] be60: 86a9be94 003c 803cd280 86be5e00 8604ea40 86be5e14 
 86802014
[  134.167852] be80: 86a9bea4 86a9be90 803cd29c 803cc838 0001 80101438 
86a9bebc 86a9bea8
[  134.176135] bea0: 803d00c4 803cd28c 86224000 86be5e04 86a9bee4 86a9bec0 
803d05fc 803d00a8
[  134.184419] bec0: 86be5e04 86acf980  86808700 86802000  
86a9bf1c 86a9bee8
[  134.192703] bee0: 8012ef38 803d054c 0088 8090cac0 86a9a000 86acf980 
86802000 86acf998
[  134.200988] bf00: 0088 8090cac0 86a9a000 86802014 86a9bf5c 86a9bf20 
8012f260 8012ee20
[  134.209270] bf20: 86ad1dc0 8070ee70 8092c91c 86802000   
86ad1dc0 86a9a000
[  134.217554] bf40: 86acf980 8012f1f4   86a9bfac 86a9bf60 
80134a78 8012f200
[  134.225838] bf60:   86ad1dc0 86acf980  86a9bf74 
86a9bf74 
[  134.234122] bf80: 86a9bf80 86a9bf80 8013b048 86ad1dc0 80134980  
 
[  134.242406] bfa0:  86a9bfb0 80107990 8013498c   
 
[  134.250688] bfc0:       
 
[  134.258970] bfe0:     0013  
 
[  134.267228] Backtrace:
[  134.269785] [<7f169d34>] (gs_flush_chars [u_serial]) from [<803cce74>] 
(n_tty_receive_buf_common+0x648/0xa54)
[  134.279800]  r5: r4:89f0b000
[  134.283449] [<803cc82c>] (n_tty_receive_buf_common) from [<803cd29c>] 
(n_tty_receive_buf2+0x1c/0x24)
[  134.292695]  r10:86802014 r9: r8:86be5e14 r7:8604ea40 r6:86be5e00 
r5:803cd280
[  134.300610]  r4:003c
[  134.303216] [<803cd280>] (n_tty_receive_buf2) from [<803d00c4>] 
(tty_ldisc_receive_buf+0x28/0x64)
[  134.312201] [<803d009c>] (tty_ldisc_receive_buf) from [<803d05fc>] 
(flush_to_ldisc+0xbc/0xd4)
[  134.320822]  r5:86be5e04 r4:86224000
[  134.324476] [<803d0540>] (flush_to_ldisc) from [<8012ef38>] 
(process_one_work+0x124/0x3e0)
[  134.332851]  r9: r8:86802000 r7:86808700 r6: r5:86acf980 
r4:86be5e04
[  134.340706] [<8012ee14>] (process_one_work) from [<8012f260>] 
(worker_thread+0x6c/0x5a8)
[  134.348905]  r10:86802014 r9:86a9a000 r8:8090cac0 r7:0088 r6:86acf998 
r5:86802000
[  134.356828]  r4:86acf980
[  134.359431] [<8012f1f4>] (worker_thread) from [<80134a78>] 
(kthread+0xf8/0x110)
[  134.366847]  r10: r9: r8:8012f1f4 r7:86acf980 r6:86a9a000 
r5:86ad1dc0
[  134.374765]  r4:
[  134.377375] [<80134980>] (kthread) from [<80107990>] 
(ret_from_fork+0x14/0x24)
[  134.384708]  r8: r7: r6: r5:80134980 r4:86ad1dc0
[  134.391483] Code: e24cb004 e5900168 e10f4000 f10c0080 (e59030a8)
[  134.3976

[PATCH 4.18 046/135] sfp: fix oops with ethtool -m

[Greg Kroah-Hartman]

4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Russell King 

[ Upstream commit 126d6848ef13958e1cb959e96c21d19bc498ade9 ]

If a network interface is created prior to the SFP socket being
available, ethtool can request module information.  This unfortunately
leads to an oops:

Unable to handle kernel NULL pointer dereference at virtual address 0008
pgd = (ptrval)
[0008] *pgd=7c400831, *pte=, *ppte=
Internal error: Oops: 17 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1480 Comm: ethtool Not tainted 4.19.0-rc3 #138
Hardware name: Broadcom Northstar Plus SoC
PC is at sfp_get_module_info+0x8/0x10
LR is at dev_ethtool+0x218c/0x2afc

Fix this by not filling in the network device's SFP bus pointer until
SFP is fully bound, thereby avoiding the core calling into the SFP bus
code.

Fixes: ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and 
sfp cages")
Reported-by: Florian Fainelli 
Tested-by: Florian Fainelli 
Signed-off-by: Russell King 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/phy/sfp-bus.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -349,6 +349,7 @@ static int sfp_register_bus(struct sfp_b
}
if (bus->started)
bus->socket_ops->start(bus->sfp);
+   bus->netdev->sfp_bus = bus;
bus->registered = true;
return 0;
 }
@@ -357,6 +358,7 @@ static void sfp_unregister_bus(struct sf
 {
const struct sfp_upstream_ops *ops = bus->upstream_ops;
 
+   bus->netdev->sfp_bus = NULL;
if (bus->registered) {
if (bus->started)
bus->socket_ops->stop(bus->sfp);
@@ -438,7 +440,6 @@ static void sfp_upstream_clear(struct sf
 {
bus->upstream_ops = NULL;
bus->upstream = NULL;
-   bus->netdev->sfp_bus = NULL;
bus->netdev = NULL;
 }
 
@@ -467,7 +468,6 @@ struct sfp_bus *sfp_register_upstream(st
bus->upstream_ops = ops;
bus->upstream = upstream;
bus->netdev = ndev;
-   ndev->sfp_bus = bus;
 
if (bus->sfp) {
ret = sfp_register_bus(bus);

[PATCH 3.16 042/366] media: rc: oops in ir_timer_keyup after device unplug

[Ben Hutchings]

3.16.60-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Sean Young 

commit 8d4068810d9926250dd2435719a080b889eb44c3 upstream.

If there is IR in the raw kfifo when ir_raw_event_unregister() is called,
then kthread_stop() causes ir_raw_event_thread to be scheduled, decode
some scancodes and re-arm timer_keyup. The timer_keyup then fires when
the rc device is long gone.

Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab 
[bwh: Backported to 3.16:
 - There's no timer_repeat to move
 - Adjust context]
Signed-off-by: Ben Hutchings 
---
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1427,13 +1427,13 @@ void rc_unregister_device(struct rc_dev
if (!dev)
return;
 
-   del_timer_sync(&dev->timer_keyup);
-
clear_bit(dev->devno, ir_core_dev_number);
 
if (dev->driver_type == RC_DRIVER_IR_RAW)
ir_raw_event_unregister(dev);
 
+   del_timer_sync(&dev->timer_keyup);
+
/* Freeing the table should also call the stop callback */
ir_free_table(&dev->rc_map);
IR_dprintk(1, "Freed keycode table\n");

[PATCH 3.16 165/366] x86/mm: Prevent kernel Oops in PTDUMP code with HIGHPTE=y

[Ben Hutchings]

3.16.60-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Joerg Roedel 

commit d6ef1f194b7569af8b8397876dc9ab07649d63cb upstream.

The walk_pte_level() function just uses __va to get the virtual address of
the PTE page, but that breaks when the PTE page is not in the direct
mapping with HIGHPTE=y.

The result is an unhandled kernel paging request at some random address
when accessing the current_kernel or current_user file.

Use the correct API to access PTE pages.

Fixes: fe770bf0310d ('x86: clean up the page table dumper and add 32-bit 
support')
Signed-off-by: Joerg Roedel 
Signed-off-by: Thomas Gleixner 
Cc: jgr...@suse.com
Cc: jbeul...@suse.com
Cc: h...@zytor.com
Cc: aryabi...@virtuozzo.com
Cc: kirill.shute...@linux.intel.com
Link: https://lkml.kernel.org/r/1523971636-4137-1-git-send-email-j...@8bytes.org
[bwh: Backported to 3.16:
 - Keep using pte_pgprot() to get protection flags
 - Adjust context]
Signed-off-by: Ben Hutchings 
---
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -263,15 +264,16 @@ static void walk_pte_level(struct seq_fi
unsigned long P)
 {
int i;
-   pte_t *start;
+   pte_t *pte;
 
-   start = (pte_t *) pmd_page_vaddr(addr);
for (i = 0; i < PTRS_PER_PTE; i++) {
-   pgprot_t prot = pte_pgprot(*start);
+   pgprot_t prot;
 
st->current_address = normalize_addr(P + i * PTE_LEVEL_MULT);
+   pte = pte_offset_map(&addr, st->current_address);
+   prot = pte_pgprot(*pte);
note_page(m, st, prot, 4);
-   start++;
+   pte_unmap(pte);
}
 }
 

[PATCH 3.16 104/366] media: v4l2-compat-ioctl32: don't oops on overlay

[Ben Hutchings]

3.16.60-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Mauro Carvalho Chehab 

commit 85ea29f19eab56ec16ec6b92bc67305998706afa upstream.

At put_v4l2_window32(), it tries to access kp->clips. However,
kp points to an userspace pointer. So, it should be obtained
via get_user(), otherwise it can OOPS:

 vivid-000: ==  END STATUS  ==
 BUG: unable to handle kernel paging request at fffb18e0
 IP: [] __put_v4l2_format32+0x169/0x220 [videodev]
 PGD 3f5776067 PUD 3f576f067 PMD 3f5769067 PTE 80042548f067
 Oops: 0001 [#1] SMP
 Modules linked in: vivid videobuf2_vmalloc videobuf2_memops v4l2_dv_timings 
videobuf2_core v4l2_common videodev media xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc 
ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill binfmt_misc 
snd_hda_codec_hdmi i915 snd_hda_intel snd_hda_controller snd_hda_codec 
intel_rapl x86_pkg_temp_thermal snd_hwdep intel_powerclamp snd_pcm coretemp 
snd_seq_midi kvm_intel kvm snd_seq_midi_event snd_rawmidi i2c_algo_bit 
drm_kms_helper snd_seq drm crct10dif_pclmul e1000e snd_seq_device crc32_pclmul 
snd_timer ghash_clmulni_intel snd mei_me mei ptp pps_core soundcore lpc_ich 
video crc32c_intel [last unloaded: media]
 CPU: 2 PID: 28332 Comm: v4l2-compliance Not tainted 3.18.102+ #107
 Hardware name:  /NUC5i7RYB, BIOS 
RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
 task: 8804293f8000 ti: 8803f564 task.ti: 8803f564
 RIP: 0010:[]  [] 
__put_v4l2_format32+0x169/0x220 [videodev]
 RSP: 0018:8803f5643e28  EFLAGS: 00010246
 RAX:  RBX:  RCX: fffb1ab4
 RDX: fffb1a68 RSI: fffb18d8 RDI: fffb1aa8
 RBP: 8803f5643e48 R08: 0001 R09: 8803f54b0378
 R10:  R11: 0168 R12: fffb18c0
 R13: fffb1a94 R14: fffb18c8 R15: 
 FS:  () GS:880456d0(0063) knlGS:f7100980
 CS:  0010 DS: 002b ES: 002b CR0: 80050033
 CR2: fffb18e0 CR3: 0003f552b000 CR4: 003407e0
 Stack:
  fffb1a94 c0cc5640 0056 8804274f3600
  8803f5643ed0 c0547e16 0003 8803f5643eb0
  81301460 88009db44b01 880441942520 8800c0d05640
 Call Trace:
  [] v4l2_compat_ioctl32+0x12d6/0x1b1d [videodev]
  [] ? file_has_perm+0x70/0xc0
  [] compat_SyS_ioctl+0xec/0x1200
  [] sysenter_dispatch+0x7/0x21
 Code: 00 00 48 8b 80 48 c0 ff ff 48 83 e8 38 49 39 c6 0f 87 2b ff ff ff 49 8d 
45 1c e8 a3 ce e3 c0 85 c0 0f 85 1a ff ff ff 41 8d 40 ff <4d> 8b 64 24 20 41 89 
d5 48 8d 44 40 03 4d 8d 34 c4 eb 15 0f 1f
 RIP  [] __put_v4l2_format32+0x169/0x220 [videodev]
 RSP 
 CR2: fffb18e0

Tested with vivid driver on Kernel v3.18.102.

Same bug happens upstream too:

 BUG: KASAN: user-memory-access in __put_v4l2_format32+0x98/0x4d0 [videodev]
 Read of size 8 at addr ffe48400 by task v4l2-compliance/8713

 CPU: 0 PID: 8713 Comm: v4l2-compliance Not tainted 4.16.0-rc4+ #108
 Hardware name:  /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
 Call Trace:
  dump_stack+0x5c/0x7c
  kasan_report+0x164/0x380
  ? __put_v4l2_format32+0x98/0x4d0 [videodev]
  __put_v4l2_format32+0x98/0x4d0 [videodev]
  v4l2_compat_ioctl32+0x1aec/0x27a0 [videodev]
  ? __fsnotify_inode_delete+0x20/0x20
  ? __put_v4l2_format32+0x4d0/0x4d0 [videodev]
  compat_SyS_ioctl+0x646/0x14d0
  ? do_ioctl+0x30/0x30
  do_fast_syscall_32+0x191/0x3f4
  entry_SYSENTER_compat+0x6b/0x7a
 ==
 Disabling lock debugging due to kernel taint
 BUG: unable to handle kernel paging request at ffe48400
 IP: __put_v4l2_format32+0x98/0x4d0 [videodev]
 PGD 3a22fb067 P4D 3a22fb067 PUD 39b6f0067 PMD 39b6f1067 PTE 8003256af067
 Oops: 0001 [#1] SMP KASAN
 Modules linked in: vivid videobuf2_vmalloc videobuf2_dma_contig 
videobuf2_memops v4l2_tpg v4l2_dv_timings videobuf2_v4l2 videobuf2_common 
v4l2_common videodev xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c tun bridge stp llc 
ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill 
ecdh_generic binfmt_misc snd_hda_codec_hdmi intel_rapl x86_pkg_temp_thermal 
intel_powerclamp i915 coretemp snd_hda_intel snd_hda_codec kvm_intel snd_hwdep 
snd_hda_core kvm snd_pcm irqbypass crct10dif_pclmul crc32_pclmul snd_seq_midi 
ghash_clmulni_intel snd_seq_midi_event i2c_algo_bit intel_cstate snd_rawmidi 
intel_uncore snd_seq drm_kms_helper e1000e snd_seq_device snd_timer 
intel_rapl_perf
  drm ptp snd mei_me mei lpc_ich pps_core soundcore video crc32c_intel
 CPU: 0 PID: 8713 Comm: v4l2-complianc

[PATCH 3.16 258/366] bdi: Fix oops in wb_workfn()

[Ben Hutchings]

3.16.60-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara 

commit b8b784958eccbf8f51ebeee65282ca3fd59ea391 upstream.

Syzbot has reported that it can hit a NULL pointer dereference in
wb_workfn() due to wb->bdi->dev being NULL. This indicates that
wb_workfn() was called for an already unregistered bdi which should not
happen as wb_shutdown() called from bdi_unregister() should make sure
all pending writeback works are completed before bdi is unregistered.
Except that wb_workfn() itself can requeue the work with:

mod_delayed_work(bdi_wq, &wb->dwork, 0);

and if this happens while wb_shutdown() is waiting in:

flush_delayed_work(&wb->dwork);

the dwork can get executed after wb_shutdown() has finished and
bdi_unregister() has cleared wb->bdi->dev.

Make wb_workfn() use wakeup_wb() for requeueing the work which takes all
the necessary precautions against racing with bdi unregistration.

CC: Tetsuo Handa 
CC: Tejun Heo 
Fixes: 839a8e8660b6777e7fe4e80af1a048aebe2b5977
Reported-by: syzbot 
Reviewed-by: Dave Chinner 
Signed-off-by: Jan Kara 
Signed-off-by: Jens Axboe 
[bwh: Backported to 3.16:
 - Use bdi_wakeup_thread() instead of wb_wakeup()
 - Adjust context]
Signed-off-by: Ben Hutchings 
---
 fs/fs-writeback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -1071,7 +1071,7 @@ void bdi_writeback_workfn(struct work_st
}
 
if (!list_empty(&bdi->work_list))
-   mod_delayed_work(bdi_wq, &wb->dwork, 0);
+   bdi_wakeup_thread(bdi);
else if (wb_has_dirty_io(wb) && dirty_writeback_interval)
bdi_wakeup_thread_delayed(bdi);
 

[PATCH 4.18 108/168] drm/nouveau: fix oops in client init failure path

[Greg Kroah-Hartman]

4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Ben Skeggs 

[ Upstream commit a43b16dda2d7485f5c5aed075c1dc9785e339515 ]

The NV_ERROR macro requires drm->client to be initialised, which it may not
be at this stage of the init process.

Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c |   14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -230,7 +230,7 @@ nouveau_cli_init(struct nouveau_drm *drm
mutex_unlock(&drm->master.lock);
}
if (ret) {
-   NV_ERROR(drm, "Client allocation failed: %d\n", ret);
+   NV_PRINTK(err, cli, "Client allocation failed: %d\n", ret);
goto done;
}
 
@@ -240,37 +240,37 @@ nouveau_cli_init(struct nouveau_drm *drm
   }, sizeof(struct nv_device_v0),
   &cli->device);
if (ret) {
-   NV_ERROR(drm, "Device allocation failed: %d\n", ret);
+   NV_PRINTK(err, cli, "Device allocation failed: %d\n", ret);
goto done;
}
 
ret = nvif_mclass(&cli->device.object, mmus);
if (ret < 0) {
-   NV_ERROR(drm, "No supported MMU class\n");
+   NV_PRINTK(err, cli, "No supported MMU class\n");
goto done;
}
 
ret = nvif_mmu_init(&cli->device.object, mmus[ret].oclass, &cli->mmu);
if (ret) {
-   NV_ERROR(drm, "MMU allocation failed: %d\n", ret);
+   NV_PRINTK(err, cli, "MMU allocation failed: %d\n", ret);
goto done;
}
 
ret = nvif_mclass(&cli->mmu.object, vmms);
if (ret < 0) {
-   NV_ERROR(drm, "No supported VMM class\n");
+   NV_PRINTK(err, cli, "No supported VMM class\n");
goto done;
}
 
ret = nouveau_vmm_init(cli, vmms[ret].oclass, &cli->vmm);
if (ret) {
-   NV_ERROR(drm, "VMM allocation failed: %d\n", ret);
+   NV_PRINTK(err, cli, "VMM allocation failed: %d\n", ret);
goto done;
}
 
ret = nvif_mclass(&cli->mmu.object, mems);
if (ret < 0) {
-   NV_ERROR(drm, "No supported MEM class\n");
+   NV_PRINTK(err, cli, "No supported MEM class\n");
goto done;
}
 

[PATCH AUTOSEL 4.18 33/58] sfp: fix oops with ethtool -m

[Sasha Levin]

From: Russell King 

[ Upstream commit 126d6848ef13958e1cb959e96c21d19bc498ade9 ]

If a network interface is created prior to the SFP socket being
available, ethtool can request module information.  This unfortunately
leads to an oops:

Unable to handle kernel NULL pointer dereference at virtual address 0008
pgd = (ptrval)
[0008] *pgd=7c400831, *pte=, *ppte=
Internal error: Oops: 17 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1480 Comm: ethtool Not tainted 4.19.0-rc3 #138
Hardware name: Broadcom Northstar Plus SoC
PC is at sfp_get_module_info+0x8/0x10
LR is at dev_ethtool+0x218c/0x2afc

Fix this by not filling in the network device's SFP bus pointer until
SFP is fully bound, thereby avoiding the core calling into the SFP bus
code.

Fixes: ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and 
sfp cages")
Reported-by: Florian Fainelli 
Tested-by: Florian Fainelli 
Signed-off-by: Russell King 
Signed-off-by: David S. Miller 
Signed-off-by: Sasha Levin 
---
 drivers/net/phy/sfp-bus.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index 740655261e5b..83060fb349f4 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -349,6 +349,7 @@ static int sfp_register_bus(struct sfp_bus *bus)
}
if (bus->started)
bus->socket_ops->start(bus->sfp);
+   bus->netdev->sfp_bus = bus;
bus->registered = true;
return 0;
 }
@@ -357,6 +358,7 @@ static void sfp_unregister_bus(struct sfp_bus *bus)
 {
const struct sfp_upstream_ops *ops = bus->upstream_ops;
 
+   bus->netdev->sfp_bus = NULL;
if (bus->registered) {
if (bus->started)
bus->socket_ops->stop(bus->sfp);
@@ -438,7 +440,6 @@ static void sfp_upstream_clear(struct sfp_bus *bus)
 {
bus->upstream_ops = NULL;
bus->upstream = NULL;
-   bus->netdev->sfp_bus = NULL;
bus->netdev = NULL;
 }
 
@@ -467,7 +468,6 @@ struct sfp_bus *sfp_register_upstream(struct fwnode_handle 
*fwnode,
bus->upstream_ops = ops;
bus->upstream = upstream;
bus->netdev = ndev;
-   ndev->sfp_bus = bus;
 
if (bus->sfp) {
ret = sfp_register_bus(bus);
-- 
2.17.1

Re: [PATCH] ACPI/sbshc: Fix rare oops when removing modules.

[Rafael J. Wysocki]

On Monday, October 1, 2018 4:53:13 AM CEST Ronald Tschalär wrote:
> There was a small race when removing the sbshc module where
> smbus_alarm() had queued acpi_smbus_callback() for deferred execution
> but it hadn't been run yet, so that when it did run hc had been freed
> and the module unloaded, resulting in an invalid paging request.
> 
> A similar race existed when removing the sbs module with regards to
> acpi_sbs_callback() (which is called from acpi_smbus_callback()).
> 
> We therefore need to ensure no callbacks are pending or executing before
> the cleanups are done and the modules are removed.
> 
> Signed-off-by: Ronald Tschalär 
> ---
>  drivers/acpi/osl.c   | 1 +
>  drivers/acpi/sbshc.c | 2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
> index 8df9abfa947b..9d139727f164 100644
> --- a/drivers/acpi/osl.c
> +++ b/drivers/acpi/osl.c
> @@ -1129,6 +1129,7 @@ void acpi_os_wait_events_complete(void)
>   flush_workqueue(kacpid_wq);
>   flush_workqueue(kacpi_notify_wq);
>  }
> +EXPORT_SYMBOL(acpi_os_wait_events_complete);
>  
>  struct acpi_hp_work {
>   struct work_struct work;
> diff --git a/drivers/acpi/sbshc.c b/drivers/acpi/sbshc.c
> index 7a3431018e0a..5008ead4609a 100644
> --- a/drivers/acpi/sbshc.c
> +++ b/drivers/acpi/sbshc.c
> @@ -196,6 +196,7 @@ int acpi_smbus_unregister_callback(struct acpi_smb_hc *hc)
>   hc->callback = NULL;
>   hc->context = NULL;
>   mutex_unlock(&hc->lock);
> + acpi_os_wait_events_complete();
>   return 0;
>  }
>  
> @@ -292,6 +293,7 @@ static int acpi_smbus_hc_remove(struct acpi_device 
> *device)
>  
>   hc = acpi_driver_data(device);
>   acpi_ec_remove_query_handler(hc->ec, hc->query_bit);
> + acpi_os_wait_events_complete();
>   kfree(hc);
>   device->driver_data = NULL;
>   return 0;
> 

Applied, thanks!

[PATCH] ACPI/sbshc: Fix rare oops when removing modules.

[Ronald Tschalär]

There was a small race when removing the sbshc module where
smbus_alarm() had queued acpi_smbus_callback() for deferred execution
but it hadn't been run yet, so that when it did run hc had been freed
and the module unloaded, resulting in an invalid paging request.

A similar race existed when removing the sbs module with regards to
acpi_sbs_callback() (which is called from acpi_smbus_callback()).

We therefore need to ensure no callbacks are pending or executing before
the cleanups are done and the modules are removed.

Signed-off-by: Ronald Tschalär 
---
 drivers/acpi/osl.c   | 1 +
 drivers/acpi/sbshc.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 8df9abfa947b..9d139727f164 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -1129,6 +1129,7 @@ void acpi_os_wait_events_complete(void)
flush_workqueue(kacpid_wq);
flush_workqueue(kacpi_notify_wq);
 }
+EXPORT_SYMBOL(acpi_os_wait_events_complete);
 
 struct acpi_hp_work {
struct work_struct work;
diff --git a/drivers/acpi/sbshc.c b/drivers/acpi/sbshc.c
index 7a3431018e0a..5008ead4609a 100644
--- a/drivers/acpi/sbshc.c
+++ b/drivers/acpi/sbshc.c
@@ -196,6 +196,7 @@ int acpi_smbus_unregister_callback(struct acpi_smb_hc *hc)
hc->callback = NULL;
hc->context = NULL;
mutex_unlock(&hc->lock);
+   acpi_os_wait_events_complete();
return 0;
 }
 
@@ -292,6 +293,7 @@ static int acpi_smbus_hc_remove(struct acpi_device *device)
 
hc = acpi_driver_data(device);
acpi_ec_remove_query_handler(hc->ec, hc->query_bit);
+   acpi_os_wait_events_complete();
kfree(hc);
device->driver_data = NULL;
return 0;
-- 
2.17.1

[PATCH AUTOSEL 4.18 30/65] drm/nouveau: fix oops in client init failure path

[Sasha Levin]

From: Ben Skeggs 

[ Upstream commit a43b16dda2d7485f5c5aed075c1dc9785e339515 ]

The NV_ERROR macro requires drm->client to be initialised, which it may not
be at this stage of the init process.

Signed-off-by: Ben Skeggs 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/nouveau/nouveau_drm.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
b/drivers/gpu/drm/nouveau/nouveau_drm.c
index c2ebe5da34d0..89225adaa60a 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drm.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drm.c
@@ -230,7 +230,7 @@ nouveau_cli_init(struct nouveau_drm *drm, const char *sname,
mutex_unlock(&drm->master.lock);
}
if (ret) {
-   NV_ERROR(drm, "Client allocation failed: %d\n", ret);
+   NV_PRINTK(err, cli, "Client allocation failed: %d\n", ret);
goto done;
}
 
@@ -240,37 +240,37 @@ nouveau_cli_init(struct nouveau_drm *drm, const char 
*sname,
   }, sizeof(struct nv_device_v0),
   &cli->device);
if (ret) {
-   NV_ERROR(drm, "Device allocation failed: %d\n", ret);
+   NV_PRINTK(err, cli, "Device allocation failed: %d\n", ret);
goto done;
}
 
ret = nvif_mclass(&cli->device.object, mmus);
if (ret < 0) {
-   NV_ERROR(drm, "No supported MMU class\n");
+   NV_PRINTK(err, cli, "No supported MMU class\n");
goto done;
}
 
ret = nvif_mmu_init(&cli->device.object, mmus[ret].oclass, &cli->mmu);
if (ret) {
-   NV_ERROR(drm, "MMU allocation failed: %d\n", ret);
+   NV_PRINTK(err, cli, "MMU allocation failed: %d\n", ret);
goto done;
}
 
ret = nvif_mclass(&cli->mmu.object, vmms);
if (ret < 0) {
-   NV_ERROR(drm, "No supported VMM class\n");
+   NV_PRINTK(err, cli, "No supported VMM class\n");
goto done;
}
 
ret = nouveau_vmm_init(cli, vmms[ret].oclass, &cli->vmm);
if (ret) {
-   NV_ERROR(drm, "VMM allocation failed: %d\n", ret);
+   NV_PRINTK(err, cli, "VMM allocation failed: %d\n", ret);
goto done;
}
 
ret = nvif_mclass(&cli->mmu.object, mems);
if (ret < 0) {
-   NV_ERROR(drm, "No supported MEM class\n");
+   NV_PRINTK(err, cli, "No supported MEM class\n");
goto done;
}
 
-- 
2.17.1

[PATCH 4.18 142/235] NFSv4: Fix a tracepoint Oops in initiate_file_draining()

[Greg Kroah-Hartman]

4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Trond Myklebust 

commit 2a534a7473bf4e7f1c12805113f80c795fc8e89a upstream.

Now that the value of 'ino' can be NULL or an ERR_PTR(), we need to
change the test in the tracepoint.

Fixes: ce5624f7e6675 ("NFSv4: Return NFS4ERR_DELAY when a layout fails...")
Signed-off-by: Trond Myklebust 
Cc: sta...@vger.kernel.org # v4.17+
Signed-off-by: Anna Schumaker 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/nfs/nfs4trace.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/nfs/nfs4trace.h
+++ b/fs/nfs/nfs4trace.h
@@ -1194,7 +1194,7 @@ DECLARE_EVENT_CLASS(nfs4_inode_stateid_c
TP_fast_assign(
__entry->error = error;
__entry->fhandle = nfs_fhandle_hash(fhandle);
-   if (inode != NULL) {
+   if (!IS_ERR_OR_NULL(inode)) {
__entry->fileid = NFS_FILEID(inode);
__entry->dev = inode->i_sb->s_dev;
} else {

[PATCH 4.18 036/235] media: tw686x: Fix oops on buffer alloc failure

[Greg Kroah-Hartman]

4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Krzysztof Ha?asa 

[ Upstream commit 5a1a2f63d840dc2631505b607e11ff65ac1b7d3c ]

The error path currently calls tw686x_video_free() which requires
vc->dev to be initialized, causing a NULL dereference on uninitizalized
channels.

Fix this by setting the vc->dev fields for all the channels first.

Fixes: f8afaa8dbc0d ("[media] tw686x: Introduce an interface to support 
multiple DMA modes")

Signed-off-by: Krzysztof Ha?asa 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/media/pci/tw686x/tw686x-video.c |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

--- a/drivers/media/pci/tw686x/tw686x-video.c
+++ b/drivers/media/pci/tw686x/tw686x-video.c
@@ -1190,6 +1190,14 @@ int tw686x_video_init(struct tw686x_dev
return err;
}
 
+   /* Initialize vc->dev and vc->ch for the error path */
+   for (ch = 0; ch < max_channels(dev); ch++) {
+   struct tw686x_video_channel *vc = &dev->video_channels[ch];
+
+   vc->dev = dev;
+   vc->ch = ch;
+   }
+
for (ch = 0; ch < max_channels(dev); ch++) {
struct tw686x_video_channel *vc = &dev->video_channels[ch];
struct video_device *vdev;
@@ -1198,9 +1206,6 @@ int tw686x_video_init(struct tw686x_dev
spin_lock_init(&vc->qlock);
INIT_LIST_HEAD(&vc->vidq_queued);
 
-   vc->dev = dev;
-   vc->ch = ch;
-
/* default settings */
err = tw686x_set_standard(vc, V4L2_STD_NTSC);
if (err)

[PATCH 4.14 025/173] media: tw686x: Fix oops on buffer alloc failure

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Krzysztof Ha?asa 

[ Upstream commit 5a1a2f63d840dc2631505b607e11ff65ac1b7d3c ]

The error path currently calls tw686x_video_free() which requires
vc->dev to be initialized, causing a NULL dereference on uninitizalized
channels.

Fix this by setting the vc->dev fields for all the channels first.

Fixes: f8afaa8dbc0d ("[media] tw686x: Introduce an interface to support 
multiple DMA modes")

Signed-off-by: Krzysztof Ha?asa 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/media/pci/tw686x/tw686x-video.c |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

--- a/drivers/media/pci/tw686x/tw686x-video.c
+++ b/drivers/media/pci/tw686x/tw686x-video.c
@@ -1190,6 +1190,14 @@ int tw686x_video_init(struct tw686x_dev
return err;
}
 
+   /* Initialize vc->dev and vc->ch for the error path */
+   for (ch = 0; ch < max_channels(dev); ch++) {
+   struct tw686x_video_channel *vc = &dev->video_channels[ch];
+
+   vc->dev = dev;
+   vc->ch = ch;
+   }
+
for (ch = 0; ch < max_channels(dev); ch++) {
struct tw686x_video_channel *vc = &dev->video_channels[ch];
struct video_device *vdev;
@@ -1198,9 +1206,6 @@ int tw686x_video_init(struct tw686x_dev
spin_lock_init(&vc->qlock);
INIT_LIST_HEAD(&vc->vidq_queued);
 
-   vc->dev = dev;
-   vc->ch = ch;
-
/* default settings */
err = tw686x_set_standard(vc, V4L2_STD_NTSC);
if (err)

[PATCH 4.9 013/111] media: tw686x: Fix oops on buffer alloc failure

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Krzysztof Ha?asa 

[ Upstream commit 5a1a2f63d840dc2631505b607e11ff65ac1b7d3c ]

The error path currently calls tw686x_video_free() which requires
vc->dev to be initialized, causing a NULL dereference on uninitizalized
channels.

Fix this by setting the vc->dev fields for all the channels first.

Fixes: f8afaa8dbc0d ("[media] tw686x: Introduce an interface to support 
multiple DMA modes")

Signed-off-by: Krzysztof Ha?asa 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/media/pci/tw686x/tw686x-video.c |   11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

--- a/drivers/media/pci/tw686x/tw686x-video.c
+++ b/drivers/media/pci/tw686x/tw686x-video.c
@@ -1190,6 +1190,14 @@ int tw686x_video_init(struct tw686x_dev
return err;
}
 
+   /* Initialize vc->dev and vc->ch for the error path */
+   for (ch = 0; ch < max_channels(dev); ch++) {
+   struct tw686x_video_channel *vc = &dev->video_channels[ch];
+
+   vc->dev = dev;
+   vc->ch = ch;
+   }
+
for (ch = 0; ch < max_channels(dev); ch++) {
struct tw686x_video_channel *vc = &dev->video_channels[ch];
struct video_device *vdev;
@@ -1198,9 +1206,6 @@ int tw686x_video_init(struct tw686x_dev
spin_lock_init(&vc->qlock);
INIT_LIST_HEAD(&vc->vidq_queued);
 
-   vc->dev = dev;
-   vc->ch = ch;
-
/* default settings */
err = tw686x_set_standard(vc, V4L2_STD_NTSC);
if (err)

[PATCH 4.18 141/158] media: em28xx: Fix DualHD disconnect oops

[Greg Kroah-Hartman]

4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Brad Love 

[ Upstream commit 20cdcaf903298d54b834daedf65a2ddef70cae0a ]

During the duplication of em28xx state for the second tuner pair
a pointer to alt_max_pkt_size_isoc is copied. During tear down
the second tuner is destroyed first and kfrees alt_max_pkt_size_isoc,
then the first tuner is destroyed and kfrees it again. The property
should only be kfree'd if the tuner is PRIMARY_TS.

[  354.888560] [ cut here ]
[  354.888562] kernel BUG at mm/slub.c:296!
[  354.888574] invalid opcode:  [#1] SMP NOPTI
[  354.69] CPU: 1 PID: 19 Comm: kworker/1:0 Not tainted 4.18.0-rc1+ #20
[  354.889140] Hardware name: MSI MS-7A39/B350M GAMING PRO (MS-7A39), BIOS 2.G0 
04/27/2018
[  354.889408] Workqueue: usb_hub_wq hub_event
[  354.889679] RIP: 0010:__slab_free+0x217/0x370
[  354.889942] Code: bb c0 e8 07 41 38 c7 72 39 48 83 c4 70 5b 41 5a 41 5c 41 
5d 41 5e 41 5f 5d 49 8d 62 f8 c3 f3 90 49 8b 04 24 a8 01 75 f6 eb 82 <0f> 0b 44 
89 45 80 48 89 4d 88 e8 aa fa ff ff 85 c0 74 cc e9 b7 fe
[  354.890598] RSP: 0018:b84c41a4fad0 EFLAGS: 00010246
[  354.890934] RAX: 948646e85150 RBX: 948646e85150 RCX: 948646e85150
[  354.891280] RDX: 820001d9 RSI: fa8fd01ba140 RDI: 94865e807c00
[  354.891649] RBP: b84c41a4fb70 R08: 0001 R09: c059ce21
[  354.892025] R10: 948646e85150 R11: 0001 R12: fa8fd01ba140
[  354.892403] R13: 948646e85150 R14: 94865e807c00 R15: 94864c92e0a0
[  354.892780] FS:  () GS:94865ec4() 
knlGS:
[  354.893150] CS:  0010 DS:  ES:  CR0: 80050033
[  354.893530] CR2: 7f4e476da950 CR3: 00040112c000 CR4: 003406e0
[  354.893917] Call Trace:
[  354.894315]  ? __dev_printk+0x3c/0x80
[  354.894695]  ? _dev_info+0x64/0x80
[  354.895082]  ? em28xx_free_device+0x41/0x50 [em28xx]
[  354.895464]  kfree+0x17a/0x190
[  354.895852]  ? kfree+0x17a/0x190
[  354.896310]  em28xx_free_device+0x41/0x50 [em28xx]
[  354.896698]  em28xx_usb_disconnect+0xfa/0x110 [em28xx]
[  354.897083]  usb_unbind_interface+0x7a/0x270
[  354.897475]  device_release_driver_internal+0x17c/0x250
[  354.897864]  device_release_driver+0x12/0x20
[  354.898252]  bus_remove_device+0xec/0x160
[  354.898639]  device_del+0x13d/0x320
[  354.899018]  ? usb_remove_ep_devs+0x1f/0x30
[  354.899392]  usb_disable_device+0x9e/0x270
[  354.899772]  usb_disconnect+0x92/0x2a0
[  354.900149]  hub_event+0x98e/0x1650
[  354.900519]  ? sched_clock_cpu+0x11/0xa0
[  354.900890]  process_one_work+0x167/0x3f0
[  354.901251]  worker_thread+0x4d/0x460
[  354.901610]  kthread+0x105/0x140
[  354.901964]  ? rescuer_thread+0x360/0x360
[  354.902318]  ? kthread_associate_blkcg+0xa0/0xa0
[  354.902672]  ret_from_fork+0x22/0x40
[  354.903024] Modules linked in: rc_hauppauge em28xx_rc rc_core si2157 
lgdt3306a i2c_mux em28xx_dvb dvb_core videobuf2_vmalloc videobuf2_memops 
videobuf2_common snd_hda_codec_hdmi nls_iso8859_1 edac_mce_amd kvm 
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc snd_hda_intel 
snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi aesni_intel 
snd_seq_midi_event aes_x86_64 snd_rawmidi crypto_simd em28xx cryptd glue_helper 
asix tveeprom usbnet snd_seq v4l2_common mii videodev snd_seq_device media 
input_leds snd_timer joydev ccp k10temp wmi_bmof snd soundcore mac_hid 
sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables vfio_pci 
vfio_virqfd irqbypass vfio_iommu_type1 vfio nouveau mxm_wmi video i2c_algo_bit 
ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops i2c_piix4 drm 
ahci libahci
[  354.905129]  wmi gpio_amdpt gpio_generic hid_generic usbhid hid
[  354.908140] ---[ end trace c230d02716298c34 ]---
[  354.908145] RIP: 0010:__slab_free+0x217/0x370
[  354.908147] Code: bb c0 e8 07 41 38 c7 72 39 48 83 c4 70 5b 41 5a 41 5c 41 
5d 41 5e 41 5f 5d 49 8d 62 f8 c3 f3 90 49 8b 04 24 a8 01 75 f6 eb 82 <0f> 0b 44 
89 45 80 48 89 4d 88 e8 aa fa ff ff 85 c0 74 cc e9 b7 fe
[  354.908183] RSP: 0018:b84c41a4fad0 EFLAGS: 00010246
[  354.908186] RAX: 948646e85150 RBX: 948646e85150 RCX: 948646e85150
[  354.908189] RDX: 820001d9 RSI: fa8fd01ba140 RDI: 94865e807c00
[  354.908191] RBP: b84c41a4fb70 R08: 0001 R09: c059ce21
[  354.908193] R10: 948646e85150 R11: 0001 R12: fa8fd01ba140
[  354.908195] R13: 948646e85150 R14: 94865e807c00 R15: 94864c92e0a0
[  354.908198] FS:  () GS:94865ec4() 
knlGS:
[  354.908201] CS:  0010 DS:  ES:  CR0: 80050033
[  354.908203] CR2: 7f4e476da950 CR3: 00016b20a000 CR4: 003406e0

Signed-off-by: Brad Love 
Signed-off-by: Michael Ira Krufky 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/media/usb/em28xx/em2

Re: 答复: Re: 答复: Re: [PATCH] tty: max3100: Fix oops while 'cat/proc/tty/driver/ttyMAX'

[Jiri Slaby]

On 09/15/2018, 04:14 AM, chen.l...@zte.com.cn wrote:
> yes, creation and destroy of the workqueue is not locked, I think
> maybe there is some
> 
> remainder work to do in destroy-wq, so I cannot sure if there is
> any usage about lock destroy-wq.
> 
> 
> What you worried of the races is about this  ?  
> 
>    --> when max3100_shutdown,  destroy_workqueue is doing, s->workqueue
> is not NULL, at this moment, get_mctrl is executed, destroying wq is
> queued again.
> 
> bu this cannot happen, becasue s->force_end_work = 1
> before destroy_workqueue  , so max3100_dowork do nothing.

Oh, so this relies on flush_workqueue or destroy_workqueue to be a
barrier (so that the assignment to end_work is not reordered), correct?

> static void max3100_shutdown(struct uart_port *port)
> 
> {
> 
> ...
> 
> s->force_end_work = 1;
> 
> 
> if (s->poll_time > 0)
> 
> del_timer_sync(&s->timer);
> 
> 
> if (s->workqueue) {
> 
> flush_workqueue(s->workqueue);
> 
> destroy_workqueue(s->workqueue);
> 
> s->workqueue = NULL;
> 
> }
> 
> 
> 
> static void max3100_dowork(struct max3100_port *s)
> 
> {
> 
> if (!s->force_end_work && !freezing(current) && !s->suspending)
> 
> queue_work(s->workqueue, &s->work);
> 
> }

Also, on the first open:
s->force_end_work = 0;
s->parity = 0;
s->rts = 0;

sprintf(b, "max3100-%d", s->minor);
s->workqueue = create_freezable_workqueue(b);
if (!s->workqueue) {
dev_warn(&s->spi->dev, "cannot create workqueue\n");
return -EBUSY;
}

Here, s->force_end_work is 0, s->workqueue is non-NULL, but s->work is
garbage until:

INIT_WORK(&s->work, max3100_work);


INIT_WORK should be in max3100_probe as far as I can see (or at least
before create_freezable_workqueue), right? But those variable
assignments also rely on some implicit barrier which is not there.

thanks,
-- 
js
suse labs

Re: 答复: Re: [PATCH] tty: max3100: Fix oops while 'cat/proc/tty/driver/ttyMAX'

[Jiri Slaby]

On 09/13/2018, 08:32 AM, chen.l...@zte.com.cn wrote:
>        
> 
> but 'get_mctrl' is already protected by  the upper layer by spin lock,
> so, will the races happen?
> 
> 
> for example: in /drivers/tty/serial/serial_core.c 
> 
>               spin_lock_irq(&uport->lock);
> 
>               result |= uport->ops->get_mctrl(uport);
> 
>               spin_unlock_irq(&uport->lock);

Right, but creation and destroy of the workqueue is not locked as far as
I can see. Am I missing something?

thanks,.
-- 
js
suse labs

Re: [PATCH] tty: max3100: Fix oops while 'cat /proc/tty/driver/ttyMAX'

[Jiri Slaby]

On 09/13/2018, 04:38 AM, chen.l...@zte.com.cn wrote:
> Before wq 's->workqueue' be initialized in function 'max3100_startup',
> 
> 'cat /proc/tty/driver/ttyMAX' will cause oops.
> 
> 
> Oops: Kernel access of bad area, sig: 11 [#1]
> 
> ...
> 
> NIP [c0049070] __queue_work+0x24/0x268
> 
> LR [c0049308] queue_work_on+0x54/0x70
> 
> Call Trace:
> 
> [db44dba0] [c0049308] queue_work_on+0x54/0x70
> 
> [db44dbb0] [c036befc] max3100_get_mctrl+0x18/0x40
> 
> [db44dbc0] [c03614a4] uart_proc_show+0xfc/0x448
> 
> [db44dc40] [c0111aa8] seq_read+0x198/0x514
> 
> [db44dc90] [c01436e4] proc_reg_read+0x58/0x94
> 
> [db44dca0] [c00ee804] do_iter_read+0x190/0x1e0
> 
> [db44dcc0] [c00f0040] vfs_readv+0x58/0x7c
> 
> [db44dd40] [c011a2f4] default_file_splice_read+0x160/0x27c
> 
> [db44de30] [c0119f74] splice_direct_to_actor+0xec/0x23c
> 
> [db44de80] [c011a158] do_splice_direct+0x94/0xd0
> 
> [db44dec0] [c008] do_sendfile+0x1e0/0x380
> 
> [db44df10] [c00f0424] sys_sendfile64+0xc0/0xd4
> 
> [db44df40] [c000e260] ret_from_syscall+0x0/0x3c
> 
> 
> Signed-off-by: Chen Lin 
> 
> ---
> 
>  drivers/tty/serial/max3100.c | 3 ++-
> 
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> 
> diff --git a/drivers/tty/serial/max3100.c b/drivers/tty/serial/max3100.c
> 
> index 371569a..0429c2d 100644
> 
> --- a/drivers/tty/serial/max3100.c
> 
> +++ b/drivers/tty/serial/max3100.c
> 
> @@ -391,7 +391,8 @@ static unsigned int max3100_get_mctrl(struct
> uart_port *port)
> 
>         dev_dbg(&s->spi->dev, "%s\n", __func__);
> 
> 
>         /* may not be truly up-to-date */
> 
> -       max3100_dowork(s);
> 
> +       if (s->workqueue)
> 
> +               max3100_dowork(s);

This does not look right in the sense of races (shutdown can kill the
workqueue right after the if. Or even before the if, as s->workqueue =
NULL is only after destroy_workqueue in max3100_shutdown).

If get_mctrl needs the queue, it shall not be created and destroyed ad hoc.

>         /* always assert DCD and DSR since these lines are not wired */
> 
>         return (s->cts ? TIOCM_CTS : 0) | TIOCM_DSR | TIOCM_CAR;
> 
>  }

thanks,
-- 
js
suse labs

[PATCH AUTOSEL 4.18 24/88] media: tw686x: Fix oops on buffer alloc failure

[Sasha Levin]

From: Krzysztof Ha?asa 

[ Upstream commit 5a1a2f63d840dc2631505b607e11ff65ac1b7d3c ]

The error path currently calls tw686x_video_free() which requires
vc->dev to be initialized, causing a NULL dereference on uninitizalized
channels.

Fix this by setting the vc->dev fields for all the channels first.

Fixes: f8afaa8dbc0d ("[media] tw686x: Introduce an interface to support 
multiple DMA modes")

Signed-off-by: Krzysztof Ha?asa 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
---
 drivers/media/pci/tw686x/tw686x-video.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/media/pci/tw686x/tw686x-video.c 
b/drivers/media/pci/tw686x/tw686x-video.c
index 0ea8dd44026c..3a06c000f97b 100644
--- a/drivers/media/pci/tw686x/tw686x-video.c
+++ b/drivers/media/pci/tw686x/tw686x-video.c
@@ -1190,6 +1190,14 @@ int tw686x_video_init(struct tw686x_dev *dev)
return err;
}
 
+   /* Initialize vc->dev and vc->ch for the error path */
+   for (ch = 0; ch < max_channels(dev); ch++) {
+   struct tw686x_video_channel *vc = &dev->video_channels[ch];
+
+   vc->dev = dev;
+   vc->ch = ch;
+   }
+
for (ch = 0; ch < max_channels(dev); ch++) {
struct tw686x_video_channel *vc = &dev->video_channels[ch];
struct video_device *vdev;
@@ -1198,9 +1206,6 @@ int tw686x_video_init(struct tw686x_dev *dev)
spin_lock_init(&vc->qlock);
INIT_LIST_HEAD(&vc->vidq_queued);
 
-   vc->dev = dev;
-   vc->ch = ch;
-
/* default settings */
err = tw686x_set_standard(vc, V4L2_STD_NTSC);
if (err)
-- 
2.17.1

[PATCH AUTOSEL 4.9 10/43] media: tw686x: Fix oops on buffer alloc failure

[Sasha Levin]

From: Krzysztof Ha?asa 

[ Upstream commit 5a1a2f63d840dc2631505b607e11ff65ac1b7d3c ]

The error path currently calls tw686x_video_free() which requires
vc->dev to be initialized, causing a NULL dereference on uninitizalized
channels.

Fix this by setting the vc->dev fields for all the channels first.

Fixes: f8afaa8dbc0d ("[media] tw686x: Introduce an interface to support 
multiple DMA modes")

Signed-off-by: Krzysztof Ha?asa 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
---
 drivers/media/pci/tw686x/tw686x-video.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/media/pci/tw686x/tw686x-video.c 
b/drivers/media/pci/tw686x/tw686x-video.c
index 0ea8dd44026c..3a06c000f97b 100644
--- a/drivers/media/pci/tw686x/tw686x-video.c
+++ b/drivers/media/pci/tw686x/tw686x-video.c
@@ -1190,6 +1190,14 @@ int tw686x_video_init(struct tw686x_dev *dev)
return err;
}
 
+   /* Initialize vc->dev and vc->ch for the error path */
+   for (ch = 0; ch < max_channels(dev); ch++) {
+   struct tw686x_video_channel *vc = &dev->video_channels[ch];
+
+   vc->dev = dev;
+   vc->ch = ch;
+   }
+
for (ch = 0; ch < max_channels(dev); ch++) {
struct tw686x_video_channel *vc = &dev->video_channels[ch];
struct video_device *vdev;
@@ -1198,9 +1206,6 @@ int tw686x_video_init(struct tw686x_dev *dev)
spin_lock_init(&vc->qlock);
INIT_LIST_HEAD(&vc->vidq_queued);
 
-   vc->dev = dev;
-   vc->ch = ch;
-
/* default settings */
err = tw686x_set_standard(vc, V4L2_STD_NTSC);
if (err)
-- 
2.17.1

[PATCH AUTOSEL 4.14 16/67] media: tw686x: Fix oops on buffer alloc failure

[Sasha Levin]

From: Krzysztof Ha?asa 

[ Upstream commit 5a1a2f63d840dc2631505b607e11ff65ac1b7d3c ]

The error path currently calls tw686x_video_free() which requires
vc->dev to be initialized, causing a NULL dereference on uninitizalized
channels.

Fix this by setting the vc->dev fields for all the channels first.

Fixes: f8afaa8dbc0d ("[media] tw686x: Introduce an interface to support 
multiple DMA modes")

Signed-off-by: Krzysztof Ha?asa 
Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
---
 drivers/media/pci/tw686x/tw686x-video.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/drivers/media/pci/tw686x/tw686x-video.c 
b/drivers/media/pci/tw686x/tw686x-video.c
index 0ea8dd44026c..3a06c000f97b 100644
--- a/drivers/media/pci/tw686x/tw686x-video.c
+++ b/drivers/media/pci/tw686x/tw686x-video.c
@@ -1190,6 +1190,14 @@ int tw686x_video_init(struct tw686x_dev *dev)
return err;
}
 
+   /* Initialize vc->dev and vc->ch for the error path */
+   for (ch = 0; ch < max_channels(dev); ch++) {
+   struct tw686x_video_channel *vc = &dev->video_channels[ch];
+
+   vc->dev = dev;
+   vc->ch = ch;
+   }
+
for (ch = 0; ch < max_channels(dev); ch++) {
struct tw686x_video_channel *vc = &dev->video_channels[ch];
struct video_device *vdev;
@@ -1198,9 +1206,6 @@ int tw686x_video_init(struct tw686x_dev *dev)
spin_lock_init(&vc->qlock);
INIT_LIST_HEAD(&vc->vidq_queued);
 
-   vc->dev = dev;
-   vc->ch = ch;
-
/* default settings */
err = tw686x_set_standard(vc, V4L2_STD_NTSC);
if (err)
-- 
2.17.1

[PATCH 4.18 063/123] fuse: Fix oops at process_init_reply()

[Greg Kroah-Hartman]

4.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Miklos Szeredi 

commit e8f3bd773d22f488724dffb886a1618da85c2966 upstream.

syzbot is hitting NULL pointer dereference at process_init_reply().
This is because deactivate_locked_super() is called before response for
initial request is processed.

Fix this by aborting and waiting for all requests (including FUSE_INIT)
before resetting fc->sb.

Original patch by Tetsuo Handa .

Reported-by: syzbot 
Fixes: e27c9d3877a0 ("fuse: fuse: add time_gran to INIT_OUT")
Cc:  # v3.19
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/fuse/inode.c |   25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -397,11 +397,6 @@ static void fuse_put_super(struct super_
 {
struct fuse_conn *fc = get_fuse_conn_super(sb);
 
-   fuse_send_destroy(fc);
-
-   fuse_abort_conn(fc, false);
-   fuse_wait_aborted(fc);
-
mutex_lock(&fuse_mutex);
list_del(&fc->entry);
fuse_ctl_remove_conn(fc);
@@ -1218,16 +1213,25 @@ static struct dentry *fuse_mount(struct
return mount_nodev(fs_type, flags, raw_data, fuse_fill_super);
 }
 
-static void fuse_kill_sb_anon(struct super_block *sb)
+static void fuse_sb_destroy(struct super_block *sb)
 {
struct fuse_conn *fc = get_fuse_conn_super(sb);
 
if (fc) {
+   fuse_send_destroy(fc);
+
+   fuse_abort_conn(fc, false);
+   fuse_wait_aborted(fc);
+
down_write(&fc->killsb);
fc->sb = NULL;
up_write(&fc->killsb);
}
+}
 
+static void fuse_kill_sb_anon(struct super_block *sb)
+{
+   fuse_sb_destroy(sb);
kill_anon_super(sb);
 }
 
@@ -1250,14 +1254,7 @@ static struct dentry *fuse_mount_blk(str
 
 static void fuse_kill_sb_blk(struct super_block *sb)
 {
-   struct fuse_conn *fc = get_fuse_conn_super(sb);
-
-   if (fc) {
-   down_write(&fc->killsb);
-   fc->sb = NULL;
-   up_write(&fc->killsb);
-   }
-
+   fuse_sb_destroy(sb);
kill_block_super(sb);
 }
 

[PATCH 4.14 123/165] fuse: Fix oops at process_init_reply()

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Miklos Szeredi 

commit e8f3bd773d22f488724dffb886a1618da85c2966 upstream.

syzbot is hitting NULL pointer dereference at process_init_reply().
This is because deactivate_locked_super() is called before response for
initial request is processed.

Fix this by aborting and waiting for all requests (including FUSE_INIT)
before resetting fc->sb.

Original patch by Tetsuo Handa .

Reported-by: syzbot 
Fixes: e27c9d3877a0 ("fuse: fuse: add time_gran to INIT_OUT")
Cc:  # v3.19
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/fuse/inode.c |   25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -397,11 +397,6 @@ static void fuse_put_super(struct super_
 {
struct fuse_conn *fc = get_fuse_conn_super(sb);
 
-   fuse_send_destroy(fc);
-
-   fuse_abort_conn(fc);
-   fuse_wait_aborted(fc);
-
mutex_lock(&fuse_mutex);
list_del(&fc->entry);
fuse_ctl_remove_conn(fc);
@@ -1198,16 +1193,25 @@ static struct dentry *fuse_mount(struct
return mount_nodev(fs_type, flags, raw_data, fuse_fill_super);
 }
 
-static void fuse_kill_sb_anon(struct super_block *sb)
+static void fuse_sb_destroy(struct super_block *sb)
 {
struct fuse_conn *fc = get_fuse_conn_super(sb);
 
if (fc) {
+   fuse_send_destroy(fc);
+
+   fuse_abort_conn(fc);
+   fuse_wait_aborted(fc);
+
down_write(&fc->killsb);
fc->sb = NULL;
up_write(&fc->killsb);
}
+}
 
+static void fuse_kill_sb_anon(struct super_block *sb)
+{
+   fuse_sb_destroy(sb);
kill_anon_super(sb);
 }
 
@@ -1230,14 +1234,7 @@ static struct dentry *fuse_mount_blk(str
 
 static void fuse_kill_sb_blk(struct super_block *sb)
 {
-   struct fuse_conn *fc = get_fuse_conn_super(sb);
-
-   if (fc) {
-   down_write(&fc->killsb);
-   fc->sb = NULL;
-   up_write(&fc->killsb);
-   }
-
+   fuse_sb_destroy(sb);
kill_block_super(sb);
 }
 

[PATCH 4.9 078/107] fuse: Fix oops at process_init_reply()

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Miklos Szeredi 

commit e8f3bd773d22f488724dffb886a1618da85c2966 upstream.

syzbot is hitting NULL pointer dereference at process_init_reply().
This is because deactivate_locked_super() is called before response for
initial request is processed.

Fix this by aborting and waiting for all requests (including FUSE_INIT)
before resetting fc->sb.

Original patch by Tetsuo Handa .

Reported-by: syzbot 
Fixes: e27c9d3877a0 ("fuse: fuse: add time_gran to INIT_OUT")
Cc:  # v3.19
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/fuse/inode.c |   25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -402,11 +402,6 @@ static void fuse_put_super(struct super_
 {
struct fuse_conn *fc = get_fuse_conn_super(sb);
 
-   fuse_send_destroy(fc);
-
-   fuse_abort_conn(fc);
-   fuse_wait_aborted(fc);
-
mutex_lock(&fuse_mutex);
list_del(&fc->entry);
fuse_ctl_remove_conn(fc);
@@ -1206,16 +1201,25 @@ static struct dentry *fuse_mount(struct
return mount_nodev(fs_type, flags, raw_data, fuse_fill_super);
 }
 
-static void fuse_kill_sb_anon(struct super_block *sb)
+static void fuse_sb_destroy(struct super_block *sb)
 {
struct fuse_conn *fc = get_fuse_conn_super(sb);
 
if (fc) {
+   fuse_send_destroy(fc);
+
+   fuse_abort_conn(fc);
+   fuse_wait_aborted(fc);
+
down_write(&fc->killsb);
fc->sb = NULL;
up_write(&fc->killsb);
}
+}
 
+static void fuse_kill_sb_anon(struct super_block *sb)
+{
+   fuse_sb_destroy(sb);
kill_anon_super(sb);
 }
 
@@ -1238,14 +1242,7 @@ static struct dentry *fuse_mount_blk(str
 
 static void fuse_kill_sb_blk(struct super_block *sb)
 {
-   struct fuse_conn *fc = get_fuse_conn_super(sb);
-
-   if (fc) {
-   down_write(&fc->killsb);
-   fc->sb = NULL;
-   up_write(&fc->killsb);
-   }
-
+   fuse_sb_destroy(sb);
kill_block_super(sb);
 }
 

[PATCH 4.4 61/80] fuse: Fix oops at process_init_reply()

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Miklos Szeredi 

commit e8f3bd773d22f488724dffb886a1618da85c2966 upstream.

syzbot is hitting NULL pointer dereference at process_init_reply().
This is because deactivate_locked_super() is called before response for
initial request is processed.

Fix this by aborting and waiting for all requests (including FUSE_INIT)
before resetting fc->sb.

Original patch by Tetsuo Handa .

Reported-by: syzbot 
Fixes: e27c9d3877a0 ("fuse: fuse: add time_gran to INIT_OUT")
Cc:  # v3.19
Signed-off-by: Miklos Szeredi 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/fuse/inode.c |   25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

--- a/fs/fuse/inode.c
+++ b/fs/fuse/inode.c
@@ -379,11 +379,6 @@ static void fuse_put_super(struct super_
 {
struct fuse_conn *fc = get_fuse_conn_super(sb);
 
-   fuse_send_destroy(fc);
-
-   fuse_abort_conn(fc);
-   fuse_wait_aborted(fc);
-
mutex_lock(&fuse_mutex);
list_del(&fc->entry);
fuse_ctl_remove_conn(fc);
@@ -1174,16 +1169,25 @@ static struct dentry *fuse_mount(struct
return mount_nodev(fs_type, flags, raw_data, fuse_fill_super);
 }
 
-static void fuse_kill_sb_anon(struct super_block *sb)
+static void fuse_sb_destroy(struct super_block *sb)
 {
struct fuse_conn *fc = get_fuse_conn_super(sb);
 
if (fc) {
+   fuse_send_destroy(fc);
+
+   fuse_abort_conn(fc);
+   fuse_wait_aborted(fc);
+
down_write(&fc->killsb);
fc->sb = NULL;
up_write(&fc->killsb);
}
+}
 
+static void fuse_kill_sb_anon(struct super_block *sb)
+{
+   fuse_sb_destroy(sb);
kill_anon_super(sb);
 }
 
@@ -1206,14 +1210,7 @@ static struct dentry *fuse_mount_blk(str
 
 static void fuse_kill_sb_blk(struct super_block *sb)
 {
-   struct fuse_conn *fc = get_fuse_conn_super(sb);
-
-   if (fc) {
-   down_write(&fc->killsb);
-   fc->sb = NULL;
-   up_write(&fc->killsb);
-   }
-
+   fuse_sb_destroy(sb);
kill_block_super(sb);
 }
 

[PATCH AUTOSEL 4.9 47/62] media: em28xx: Fix DualHD disconnect oops

[Sasha Levin]

From: Brad Love 

[ Upstream commit 20cdcaf903298d54b834daedf65a2ddef70cae0a ]

During the duplication of em28xx state for the second tuner pair
a pointer to alt_max_pkt_size_isoc is copied. During tear down
the second tuner is destroyed first and kfrees alt_max_pkt_size_isoc,
then the first tuner is destroyed and kfrees it again. The property
should only be kfree'd if the tuner is PRIMARY_TS.

[  354.888560] [ cut here ]
[  354.888562] kernel BUG at mm/slub.c:296!
[  354.888574] invalid opcode:  [#1] SMP NOPTI
[  354.69] CPU: 1 PID: 19 Comm: kworker/1:0 Not tainted 4.18.0-rc1+ #20
[  354.889140] Hardware name: MSI MS-7A39/B350M GAMING PRO (MS-7A39), BIOS 2.G0 
04/27/2018
[  354.889408] Workqueue: usb_hub_wq hub_event
[  354.889679] RIP: 0010:__slab_free+0x217/0x370
[  354.889942] Code: bb c0 e8 07 41 38 c7 72 39 48 83 c4 70 5b 41 5a 41 5c 41 
5d 41 5e 41 5f 5d 49 8d 62 f8 c3 f3 90 49 8b 04 24 a8 01 75 f6 eb 82 <0f> 0b 44 
89 45 80 48 89 4d 88 e8 aa fa ff ff 85 c0 74 cc e9 b7 fe
[  354.890598] RSP: 0018:b84c41a4fad0 EFLAGS: 00010246
[  354.890934] RAX: 948646e85150 RBX: 948646e85150 RCX: 948646e85150
[  354.891280] RDX: 820001d9 RSI: fa8fd01ba140 RDI: 94865e807c00
[  354.891649] RBP: b84c41a4fb70 R08: 0001 R09: c059ce21
[  354.892025] R10: 948646e85150 R11: 0001 R12: fa8fd01ba140
[  354.892403] R13: 948646e85150 R14: 94865e807c00 R15: 94864c92e0a0
[  354.892780] FS:  () GS:94865ec4() 
knlGS:
[  354.893150] CS:  0010 DS:  ES:  CR0: 80050033
[  354.893530] CR2: 7f4e476da950 CR3: 00040112c000 CR4: 003406e0
[  354.893917] Call Trace:
[  354.894315]  ? __dev_printk+0x3c/0x80
[  354.894695]  ? _dev_info+0x64/0x80
[  354.895082]  ? em28xx_free_device+0x41/0x50 [em28xx]
[  354.895464]  kfree+0x17a/0x190
[  354.895852]  ? kfree+0x17a/0x190
[  354.896310]  em28xx_free_device+0x41/0x50 [em28xx]
[  354.896698]  em28xx_usb_disconnect+0xfa/0x110 [em28xx]
[  354.897083]  usb_unbind_interface+0x7a/0x270
[  354.897475]  device_release_driver_internal+0x17c/0x250
[  354.897864]  device_release_driver+0x12/0x20
[  354.898252]  bus_remove_device+0xec/0x160
[  354.898639]  device_del+0x13d/0x320
[  354.899018]  ? usb_remove_ep_devs+0x1f/0x30
[  354.899392]  usb_disable_device+0x9e/0x270
[  354.899772]  usb_disconnect+0x92/0x2a0
[  354.900149]  hub_event+0x98e/0x1650
[  354.900519]  ? sched_clock_cpu+0x11/0xa0
[  354.900890]  process_one_work+0x167/0x3f0
[  354.901251]  worker_thread+0x4d/0x460
[  354.901610]  kthread+0x105/0x140
[  354.901964]  ? rescuer_thread+0x360/0x360
[  354.902318]  ? kthread_associate_blkcg+0xa0/0xa0
[  354.902672]  ret_from_fork+0x22/0x40
[  354.903024] Modules linked in: rc_hauppauge em28xx_rc rc_core si2157 
lgdt3306a i2c_mux em28xx_dvb dvb_core videobuf2_vmalloc videobuf2_memops 
videobuf2_common snd_hda_codec_hdmi nls_iso8859_1 edac_mce_amd kvm 
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc snd_hda_intel 
snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi aesni_intel 
snd_seq_midi_event aes_x86_64 snd_rawmidi crypto_simd em28xx cryptd glue_helper 
asix tveeprom usbnet snd_seq v4l2_common mii videodev snd_seq_device media 
input_leds snd_timer joydev ccp k10temp wmi_bmof snd soundcore mac_hid 
sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables vfio_pci 
vfio_virqfd irqbypass vfio_iommu_type1 vfio nouveau mxm_wmi video i2c_algo_bit 
ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops i2c_piix4 drm 
ahci libahci
[  354.905129]  wmi gpio_amdpt gpio_generic hid_generic usbhid hid
[  354.908140] ---[ end trace c230d02716298c34 ]---
[  354.908145] RIP: 0010:__slab_free+0x217/0x370
[  354.908147] Code: bb c0 e8 07 41 38 c7 72 39 48 83 c4 70 5b 41 5a 41 5c 41 
5d 41 5e 41 5f 5d 49 8d 62 f8 c3 f3 90 49 8b 04 24 a8 01 75 f6 eb 82 <0f> 0b 44 
89 45 80 48 89 4d 88 e8 aa fa ff ff 85 c0 74 cc e9 b7 fe
[  354.908183] RSP: 0018:b84c41a4fad0 EFLAGS: 00010246
[  354.908186] RAX: 948646e85150 RBX: 948646e85150 RCX: 948646e85150
[  354.908189] RDX: 820001d9 RSI: fa8fd01ba140 RDI: 94865e807c00
[  354.908191] RBP: b84c41a4fb70 R08: 0001 R09: c059ce21
[  354.908193] R10: 948646e85150 R11: 0001 R12: fa8fd01ba140
[  354.908195] R13: 948646e85150 R14: 94865e807c00 R15: 94864c92e0a0
[  354.908198] FS:  () GS:94865ec4() 
knlGS:
[  354.908201] CS:  0010 DS:  ES:  CR0: 80050033
[  354.908203] CR2: 7f4e476da950 CR3: 00016b20a000 CR4: 003406e0

Signed-off-by: Brad Love 
Signed-off-by: Michael Ira Krufky 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
---
 drivers/media/usb/em28xx/em28xx-cards.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers

[PATCH AUTOSEL 4.4 33/47] media: em28xx: Fix DualHD disconnect oops

[Sasha Levin]

From: Brad Love 

[ Upstream commit 20cdcaf903298d54b834daedf65a2ddef70cae0a ]

During the duplication of em28xx state for the second tuner pair
a pointer to alt_max_pkt_size_isoc is copied. During tear down
the second tuner is destroyed first and kfrees alt_max_pkt_size_isoc,
then the first tuner is destroyed and kfrees it again. The property
should only be kfree'd if the tuner is PRIMARY_TS.

[  354.888560] [ cut here ]
[  354.888562] kernel BUG at mm/slub.c:296!
[  354.888574] invalid opcode:  [#1] SMP NOPTI
[  354.69] CPU: 1 PID: 19 Comm: kworker/1:0 Not tainted 4.18.0-rc1+ #20
[  354.889140] Hardware name: MSI MS-7A39/B350M GAMING PRO (MS-7A39), BIOS 2.G0 
04/27/2018
[  354.889408] Workqueue: usb_hub_wq hub_event
[  354.889679] RIP: 0010:__slab_free+0x217/0x370
[  354.889942] Code: bb c0 e8 07 41 38 c7 72 39 48 83 c4 70 5b 41 5a 41 5c 41 
5d 41 5e 41 5f 5d 49 8d 62 f8 c3 f3 90 49 8b 04 24 a8 01 75 f6 eb 82 <0f> 0b 44 
89 45 80 48 89 4d 88 e8 aa fa ff ff 85 c0 74 cc e9 b7 fe
[  354.890598] RSP: 0018:b84c41a4fad0 EFLAGS: 00010246
[  354.890934] RAX: 948646e85150 RBX: 948646e85150 RCX: 948646e85150
[  354.891280] RDX: 820001d9 RSI: fa8fd01ba140 RDI: 94865e807c00
[  354.891649] RBP: b84c41a4fb70 R08: 0001 R09: c059ce21
[  354.892025] R10: 948646e85150 R11: 0001 R12: fa8fd01ba140
[  354.892403] R13: 948646e85150 R14: 94865e807c00 R15: 94864c92e0a0
[  354.892780] FS:  () GS:94865ec4() 
knlGS:
[  354.893150] CS:  0010 DS:  ES:  CR0: 80050033
[  354.893530] CR2: 7f4e476da950 CR3: 00040112c000 CR4: 003406e0
[  354.893917] Call Trace:
[  354.894315]  ? __dev_printk+0x3c/0x80
[  354.894695]  ? _dev_info+0x64/0x80
[  354.895082]  ? em28xx_free_device+0x41/0x50 [em28xx]
[  354.895464]  kfree+0x17a/0x190
[  354.895852]  ? kfree+0x17a/0x190
[  354.896310]  em28xx_free_device+0x41/0x50 [em28xx]
[  354.896698]  em28xx_usb_disconnect+0xfa/0x110 [em28xx]
[  354.897083]  usb_unbind_interface+0x7a/0x270
[  354.897475]  device_release_driver_internal+0x17c/0x250
[  354.897864]  device_release_driver+0x12/0x20
[  354.898252]  bus_remove_device+0xec/0x160
[  354.898639]  device_del+0x13d/0x320
[  354.899018]  ? usb_remove_ep_devs+0x1f/0x30
[  354.899392]  usb_disable_device+0x9e/0x270
[  354.899772]  usb_disconnect+0x92/0x2a0
[  354.900149]  hub_event+0x98e/0x1650
[  354.900519]  ? sched_clock_cpu+0x11/0xa0
[  354.900890]  process_one_work+0x167/0x3f0
[  354.901251]  worker_thread+0x4d/0x460
[  354.901610]  kthread+0x105/0x140
[  354.901964]  ? rescuer_thread+0x360/0x360
[  354.902318]  ? kthread_associate_blkcg+0xa0/0xa0
[  354.902672]  ret_from_fork+0x22/0x40
[  354.903024] Modules linked in: rc_hauppauge em28xx_rc rc_core si2157 
lgdt3306a i2c_mux em28xx_dvb dvb_core videobuf2_vmalloc videobuf2_memops 
videobuf2_common snd_hda_codec_hdmi nls_iso8859_1 edac_mce_amd kvm 
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc snd_hda_intel 
snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi aesni_intel 
snd_seq_midi_event aes_x86_64 snd_rawmidi crypto_simd em28xx cryptd glue_helper 
asix tveeprom usbnet snd_seq v4l2_common mii videodev snd_seq_device media 
input_leds snd_timer joydev ccp k10temp wmi_bmof snd soundcore mac_hid 
sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables vfio_pci 
vfio_virqfd irqbypass vfio_iommu_type1 vfio nouveau mxm_wmi video i2c_algo_bit 
ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops i2c_piix4 drm 
ahci libahci
[  354.905129]  wmi gpio_amdpt gpio_generic hid_generic usbhid hid
[  354.908140] ---[ end trace c230d02716298c34 ]---
[  354.908145] RIP: 0010:__slab_free+0x217/0x370
[  354.908147] Code: bb c0 e8 07 41 38 c7 72 39 48 83 c4 70 5b 41 5a 41 5c 41 
5d 41 5e 41 5f 5d 49 8d 62 f8 c3 f3 90 49 8b 04 24 a8 01 75 f6 eb 82 <0f> 0b 44 
89 45 80 48 89 4d 88 e8 aa fa ff ff 85 c0 74 cc e9 b7 fe
[  354.908183] RSP: 0018:b84c41a4fad0 EFLAGS: 00010246
[  354.908186] RAX: 948646e85150 RBX: 948646e85150 RCX: 948646e85150
[  354.908189] RDX: 820001d9 RSI: fa8fd01ba140 RDI: 94865e807c00
[  354.908191] RBP: b84c41a4fb70 R08: 0001 R09: c059ce21
[  354.908193] R10: 948646e85150 R11: 0001 R12: fa8fd01ba140
[  354.908195] R13: 948646e85150 R14: 94865e807c00 R15: 94864c92e0a0
[  354.908198] FS:  () GS:94865ec4() 
knlGS:
[  354.908201] CS:  0010 DS:  ES:  CR0: 80050033
[  354.908203] CR2: 7f4e476da950 CR3: 00016b20a000 CR4: 003406e0

Signed-off-by: Brad Love 
Signed-off-by: Michael Ira Krufky 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
---
 drivers/media/usb/em28xx/em28xx-cards.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers

[PATCH AUTOSEL 4.14 73/89] media: em28xx: Fix DualHD disconnect oops

[Sasha Levin]

From: Brad Love 

[ Upstream commit 20cdcaf903298d54b834daedf65a2ddef70cae0a ]

During the duplication of em28xx state for the second tuner pair
a pointer to alt_max_pkt_size_isoc is copied. During tear down
the second tuner is destroyed first and kfrees alt_max_pkt_size_isoc,
then the first tuner is destroyed and kfrees it again. The property
should only be kfree'd if the tuner is PRIMARY_TS.

[  354.888560] [ cut here ]
[  354.888562] kernel BUG at mm/slub.c:296!
[  354.888574] invalid opcode:  [#1] SMP NOPTI
[  354.69] CPU: 1 PID: 19 Comm: kworker/1:0 Not tainted 4.18.0-rc1+ #20
[  354.889140] Hardware name: MSI MS-7A39/B350M GAMING PRO (MS-7A39), BIOS 2.G0 
04/27/2018
[  354.889408] Workqueue: usb_hub_wq hub_event
[  354.889679] RIP: 0010:__slab_free+0x217/0x370
[  354.889942] Code: bb c0 e8 07 41 38 c7 72 39 48 83 c4 70 5b 41 5a 41 5c 41 
5d 41 5e 41 5f 5d 49 8d 62 f8 c3 f3 90 49 8b 04 24 a8 01 75 f6 eb 82 <0f> 0b 44 
89 45 80 48 89 4d 88 e8 aa fa ff ff 85 c0 74 cc e9 b7 fe
[  354.890598] RSP: 0018:b84c41a4fad0 EFLAGS: 00010246
[  354.890934] RAX: 948646e85150 RBX: 948646e85150 RCX: 948646e85150
[  354.891280] RDX: 820001d9 RSI: fa8fd01ba140 RDI: 94865e807c00
[  354.891649] RBP: b84c41a4fb70 R08: 0001 R09: c059ce21
[  354.892025] R10: 948646e85150 R11: 0001 R12: fa8fd01ba140
[  354.892403] R13: 948646e85150 R14: 94865e807c00 R15: 94864c92e0a0
[  354.892780] FS:  () GS:94865ec4() 
knlGS:
[  354.893150] CS:  0010 DS:  ES:  CR0: 80050033
[  354.893530] CR2: 7f4e476da950 CR3: 00040112c000 CR4: 003406e0
[  354.893917] Call Trace:
[  354.894315]  ? __dev_printk+0x3c/0x80
[  354.894695]  ? _dev_info+0x64/0x80
[  354.895082]  ? em28xx_free_device+0x41/0x50 [em28xx]
[  354.895464]  kfree+0x17a/0x190
[  354.895852]  ? kfree+0x17a/0x190
[  354.896310]  em28xx_free_device+0x41/0x50 [em28xx]
[  354.896698]  em28xx_usb_disconnect+0xfa/0x110 [em28xx]
[  354.897083]  usb_unbind_interface+0x7a/0x270
[  354.897475]  device_release_driver_internal+0x17c/0x250
[  354.897864]  device_release_driver+0x12/0x20
[  354.898252]  bus_remove_device+0xec/0x160
[  354.898639]  device_del+0x13d/0x320
[  354.899018]  ? usb_remove_ep_devs+0x1f/0x30
[  354.899392]  usb_disable_device+0x9e/0x270
[  354.899772]  usb_disconnect+0x92/0x2a0
[  354.900149]  hub_event+0x98e/0x1650
[  354.900519]  ? sched_clock_cpu+0x11/0xa0
[  354.900890]  process_one_work+0x167/0x3f0
[  354.901251]  worker_thread+0x4d/0x460
[  354.901610]  kthread+0x105/0x140
[  354.901964]  ? rescuer_thread+0x360/0x360
[  354.902318]  ? kthread_associate_blkcg+0xa0/0xa0
[  354.902672]  ret_from_fork+0x22/0x40
[  354.903024] Modules linked in: rc_hauppauge em28xx_rc rc_core si2157 
lgdt3306a i2c_mux em28xx_dvb dvb_core videobuf2_vmalloc videobuf2_memops 
videobuf2_common snd_hda_codec_hdmi nls_iso8859_1 edac_mce_amd kvm 
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc snd_hda_intel 
snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi aesni_intel 
snd_seq_midi_event aes_x86_64 snd_rawmidi crypto_simd em28xx cryptd glue_helper 
asix tveeprom usbnet snd_seq v4l2_common mii videodev snd_seq_device media 
input_leds snd_timer joydev ccp k10temp wmi_bmof snd soundcore mac_hid 
sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables vfio_pci 
vfio_virqfd irqbypass vfio_iommu_type1 vfio nouveau mxm_wmi video i2c_algo_bit 
ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops i2c_piix4 drm 
ahci libahci
[  354.905129]  wmi gpio_amdpt gpio_generic hid_generic usbhid hid
[  354.908140] ---[ end trace c230d02716298c34 ]---
[  354.908145] RIP: 0010:__slab_free+0x217/0x370
[  354.908147] Code: bb c0 e8 07 41 38 c7 72 39 48 83 c4 70 5b 41 5a 41 5c 41 
5d 41 5e 41 5f 5d 49 8d 62 f8 c3 f3 90 49 8b 04 24 a8 01 75 f6 eb 82 <0f> 0b 44 
89 45 80 48 89 4d 88 e8 aa fa ff ff 85 c0 74 cc e9 b7 fe
[  354.908183] RSP: 0018:b84c41a4fad0 EFLAGS: 00010246
[  354.908186] RAX: 948646e85150 RBX: 948646e85150 RCX: 948646e85150
[  354.908189] RDX: 820001d9 RSI: fa8fd01ba140 RDI: 94865e807c00
[  354.908191] RBP: b84c41a4fb70 R08: 0001 R09: c059ce21
[  354.908193] R10: 948646e85150 R11: 0001 R12: fa8fd01ba140
[  354.908195] R13: 948646e85150 R14: 94865e807c00 R15: 94864c92e0a0
[  354.908198] FS:  () GS:94865ec4() 
knlGS:
[  354.908201] CS:  0010 DS:  ES:  CR0: 80050033
[  354.908203] CR2: 7f4e476da950 CR3: 00016b20a000 CR4: 003406e0

Signed-off-by: Brad Love 
Signed-off-by: Michael Ira Krufky 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
---
 drivers/media/usb/em28xx/em28xx-cards.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers

[PATCH AUTOSEL 4.18 106/131] media: em28xx: Fix DualHD disconnect oops

[Sasha Levin]

From: Brad Love 

[ Upstream commit 20cdcaf903298d54b834daedf65a2ddef70cae0a ]

During the duplication of em28xx state for the second tuner pair
a pointer to alt_max_pkt_size_isoc is copied. During tear down
the second tuner is destroyed first and kfrees alt_max_pkt_size_isoc,
then the first tuner is destroyed and kfrees it again. The property
should only be kfree'd if the tuner is PRIMARY_TS.

[  354.888560] [ cut here ]
[  354.888562] kernel BUG at mm/slub.c:296!
[  354.888574] invalid opcode:  [#1] SMP NOPTI
[  354.69] CPU: 1 PID: 19 Comm: kworker/1:0 Not tainted 4.18.0-rc1+ #20
[  354.889140] Hardware name: MSI MS-7A39/B350M GAMING PRO (MS-7A39), BIOS 2.G0 
04/27/2018
[  354.889408] Workqueue: usb_hub_wq hub_event
[  354.889679] RIP: 0010:__slab_free+0x217/0x370
[  354.889942] Code: bb c0 e8 07 41 38 c7 72 39 48 83 c4 70 5b 41 5a 41 5c 41 
5d 41 5e 41 5f 5d 49 8d 62 f8 c3 f3 90 49 8b 04 24 a8 01 75 f6 eb 82 <0f> 0b 44 
89 45 80 48 89 4d 88 e8 aa fa ff ff 85 c0 74 cc e9 b7 fe
[  354.890598] RSP: 0018:b84c41a4fad0 EFLAGS: 00010246
[  354.890934] RAX: 948646e85150 RBX: 948646e85150 RCX: 948646e85150
[  354.891280] RDX: 820001d9 RSI: fa8fd01ba140 RDI: 94865e807c00
[  354.891649] RBP: b84c41a4fb70 R08: 0001 R09: c059ce21
[  354.892025] R10: 948646e85150 R11: 0001 R12: fa8fd01ba140
[  354.892403] R13: 948646e85150 R14: 94865e807c00 R15: 94864c92e0a0
[  354.892780] FS:  () GS:94865ec4() 
knlGS:
[  354.893150] CS:  0010 DS:  ES:  CR0: 80050033
[  354.893530] CR2: 7f4e476da950 CR3: 00040112c000 CR4: 003406e0
[  354.893917] Call Trace:
[  354.894315]  ? __dev_printk+0x3c/0x80
[  354.894695]  ? _dev_info+0x64/0x80
[  354.895082]  ? em28xx_free_device+0x41/0x50 [em28xx]
[  354.895464]  kfree+0x17a/0x190
[  354.895852]  ? kfree+0x17a/0x190
[  354.896310]  em28xx_free_device+0x41/0x50 [em28xx]
[  354.896698]  em28xx_usb_disconnect+0xfa/0x110 [em28xx]
[  354.897083]  usb_unbind_interface+0x7a/0x270
[  354.897475]  device_release_driver_internal+0x17c/0x250
[  354.897864]  device_release_driver+0x12/0x20
[  354.898252]  bus_remove_device+0xec/0x160
[  354.898639]  device_del+0x13d/0x320
[  354.899018]  ? usb_remove_ep_devs+0x1f/0x30
[  354.899392]  usb_disable_device+0x9e/0x270
[  354.899772]  usb_disconnect+0x92/0x2a0
[  354.900149]  hub_event+0x98e/0x1650
[  354.900519]  ? sched_clock_cpu+0x11/0xa0
[  354.900890]  process_one_work+0x167/0x3f0
[  354.901251]  worker_thread+0x4d/0x460
[  354.901610]  kthread+0x105/0x140
[  354.901964]  ? rescuer_thread+0x360/0x360
[  354.902318]  ? kthread_associate_blkcg+0xa0/0xa0
[  354.902672]  ret_from_fork+0x22/0x40
[  354.903024] Modules linked in: rc_hauppauge em28xx_rc rc_core si2157 
lgdt3306a i2c_mux em28xx_dvb dvb_core videobuf2_vmalloc videobuf2_memops 
videobuf2_common snd_hda_codec_hdmi nls_iso8859_1 edac_mce_amd kvm 
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc snd_hda_intel 
snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi aesni_intel 
snd_seq_midi_event aes_x86_64 snd_rawmidi crypto_simd em28xx cryptd glue_helper 
asix tveeprom usbnet snd_seq v4l2_common mii videodev snd_seq_device media 
input_leds snd_timer joydev ccp k10temp wmi_bmof snd soundcore mac_hid 
sch_fq_codel parport_pc ppdev lp parport ip_tables x_tables vfio_pci 
vfio_virqfd irqbypass vfio_iommu_type1 vfio nouveau mxm_wmi video i2c_algo_bit 
ttm drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops i2c_piix4 drm 
ahci libahci
[  354.905129]  wmi gpio_amdpt gpio_generic hid_generic usbhid hid
[  354.908140] ---[ end trace c230d02716298c34 ]---
[  354.908145] RIP: 0010:__slab_free+0x217/0x370
[  354.908147] Code: bb c0 e8 07 41 38 c7 72 39 48 83 c4 70 5b 41 5a 41 5c 41 
5d 41 5e 41 5f 5d 49 8d 62 f8 c3 f3 90 49 8b 04 24 a8 01 75 f6 eb 82 <0f> 0b 44 
89 45 80 48 89 4d 88 e8 aa fa ff ff 85 c0 74 cc e9 b7 fe
[  354.908183] RSP: 0018:b84c41a4fad0 EFLAGS: 00010246
[  354.908186] RAX: 948646e85150 RBX: 948646e85150 RCX: 948646e85150
[  354.908189] RDX: 820001d9 RSI: fa8fd01ba140 RDI: 94865e807c00
[  354.908191] RBP: b84c41a4fb70 R08: 0001 R09: c059ce21
[  354.908193] R10: 948646e85150 R11: 0001 R12: fa8fd01ba140
[  354.908195] R13: 948646e85150 R14: 94865e807c00 R15: 94864c92e0a0
[  354.908198] FS:  () GS:94865ec4() 
knlGS:
[  354.908201] CS:  0010 DS:  ES:  CR0: 80050033
[  354.908203] CR2: 7f4e476da950 CR3: 00016b20a000 CR4: 003406e0

Signed-off-by: Brad Love 
Signed-off-by: Michael Ira Krufky 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sasha Levin 
---
 drivers/media/usb/em28xx/em28xx-cards.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers

RE: AW: PROBLEM: Kernel Oops in UDP stack

[David Laight]

From: Marcel Hellwig
> Sent: 01 August 2018 11:36
> >> [] (udp_recvmsg+0x284/0x33c) from [] 
> >> (inet_recvmsg+0x38/0x4c):
> net/ipv4/udp.c:1234
> >
> >  sin->sin_addr.s_addr = ip_hdr(skb)->saddr;
> >
> >Unaligned access trap (virtual address c14fe63a), so either sin or 
> >ip_hdr(skb) are not on a 32bit
> alignment
> >
> >Can you produce the disassembly of the trapping instruction ?
> 
> https://gist.github.com/hellow554/6b11c6c0827d5db80a7e66f71f5636ff#file-net_uipv4_udp-lst-L1892-L1895
> 
>   sin->sin_addr.s_addr = ip_hdr(skb)->saddr;
> c0228ad8: e5943080ldr r3, [r4, #128]  ; 0x80
> c0228adc: e593300cldr r3, [r3, #12]
> c0228ae0: e5823004str r3, [r2, #4]

There are actually 2 faults, difficult to quickly sort out the merged 
tracebacks.
You are also running a rather old kernel: Linux version 3.4.113.

It may well be that whichever ethernet driver generated the misaligned frame
has since been fixed.

David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, 
UK
Registration No: 1397386 (Wales)

[PATCH 4.17 075/101] bdi: Fix another oops in wb_workfn()

[Greg Kroah-Hartman]

4.17-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara 

commit 3ee7e8697d5860b173132606d80a9cd35e7113ee upstream.

syzbot is reporting NULL pointer dereference at wb_workfn() [1] due to
wb->bdi->dev being NULL. And Dmitry confirmed that wb->state was
WB_shutting_down after wb->bdi->dev became NULL. This indicates that
unregister_bdi() failed to call wb_shutdown() on one of wb objects.

The problem is in cgwb_bdi_unregister() which does cgwb_kill() and thus
drops bdi's reference to wb structures before going through the list of
wbs again and calling wb_shutdown() on each of them. This way the loop
iterating through all wbs can easily miss a wb if that wb has already
passed through cgwb_remove_from_bdi_list() called from wb_shutdown()
from cgwb_release_workfn() and as a result fully shutdown bdi although
wb_workfn() for this wb structure is still running. In fact there are
also other ways cgwb_bdi_unregister() can race with
cgwb_release_workfn() leading e.g. to use-after-free issues:

CPU1CPU2
cgwb_bdi_unregister()
  cgwb_kill(*slot);

cgwb_release()
  queue_work(cgwb_release_wq, &wb->release_work);
cgwb_release_workfn()
  wb = list_first_entry(&bdi->wb_list, ...)
  spin_unlock_irq(&cgwb_lock);
  wb_shutdown(wb);
  ...
  kfree_rcu(wb, rcu);
  wb_shutdown(wb); -> oops use-after-free

We solve these issues by synchronizing writeback structure shutdown from
cgwb_bdi_unregister() with cgwb_release_workfn() using a new mutex. That
way we also no longer need synchronization using WB_shutting_down as the
mutex provides it for CONFIG_CGROUP_WRITEBACK case and without
CONFIG_CGROUP_WRITEBACK wb_shutdown() can be called only once from
bdi_unregister().

Reported-by: syzbot 
Acked-by: Tejun Heo 
Signed-off-by: Jan Kara 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/backing-dev-defs.h |2 +-
 mm/backing-dev.c |   20 +++-
 2 files changed, 8 insertions(+), 14 deletions(-)

--- a/include/linux/backing-dev-defs.h
+++ b/include/linux/backing-dev-defs.h
@@ -22,7 +22,6 @@ struct dentry;
  */
 enum wb_state {
WB_registered,  /* bdi_register() was done */
-   WB_shutting_down,   /* wb_shutdown() in progress */
WB_writeback_running,   /* Writeback is in progress */
WB_has_dirty_io,/* Dirty inodes on ->b_{dirty|io|more_io} */
WB_start_all,   /* nr_pages == 0 (all) work pending */
@@ -189,6 +188,7 @@ struct backing_dev_info {
 #ifdef CONFIG_CGROUP_WRITEBACK
struct radix_tree_root cgwb_tree; /* radix tree of active cgroup wbs */
struct rb_root cgwb_congested_tree; /* their congested states */
+   struct mutex cgwb_release_mutex;  /* protect shutdown of wb structs */
 #else
struct bdi_writeback_congested *wb_congested;
 #endif
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -359,15 +359,8 @@ static void wb_shutdown(struct bdi_write
spin_lock_bh(&wb->work_lock);
if (!test_and_clear_bit(WB_registered, &wb->state)) {
spin_unlock_bh(&wb->work_lock);
-   /*
-* Wait for wb shutdown to finish if someone else is just
-* running wb_shutdown(). Otherwise we could proceed to wb /
-* bdi destruction before wb_shutdown() is finished.
-*/
-   wait_on_bit(&wb->state, WB_shutting_down, TASK_UNINTERRUPTIBLE);
return;
}
-   set_bit(WB_shutting_down, &wb->state);
spin_unlock_bh(&wb->work_lock);
 
cgwb_remove_from_bdi_list(wb);
@@ -379,12 +372,6 @@ static void wb_shutdown(struct bdi_write
mod_delayed_work(bdi_wq, &wb->dwork, 0);
flush_delayed_work(&wb->dwork);
WARN_ON(!list_empty(&wb->work_list));
-   /*
-* Make sure bit gets cleared after shutdown is finished. Matches with
-* the barrier provided by test_and_clear_bit() above.
-*/
-   smp_wmb();
-   clear_and_wake_up_bit(WB_shutting_down, &wb->state);
 }
 
 static void wb_exit(struct bdi_writeback *wb)
@@ -508,10 +495,12 @@ static void cgwb_release_workfn(struct w
struct bdi_writeback *wb = container_of(work, struct bdi_writeback,
release_work);
 
+   mutex_lock(&wb->bdi->cgwb_release_mutex);
wb_shutdown(wb);
 
css_put(wb->memcg_css);
css_put(wb->blkcg_css);
+   mutex_unlock(&wb->bdi->cgwb_release_mutex);
 
fprop_local_destroy_percpu(&wb->memcg_completions);
percpu_ref_exit(&wb->refcnt);
@@ -697,6 +686,7 @@ static int

[PATCH 4.17 063/101] rtlwifi: Fix kernel Oops "Fw download fail!!"

[Greg Kroah-Hartman]

4.17-stable review patch.  If anyone has any objections, please let me know.

--

From: Ping-Ke Shih 

commit 12dfa2f68ab659636e092db13b5d17cf9aac82af upstream.

When connecting to AP, mac80211 asks driver to enter and leave PS quickly,
but driver deinit doesn't wait for delayed work complete when entering PS,
then driver reinit procedure and delay work are running simultaneously.
This will cause unpredictable kernel oops or crash like

rtl8723be: error H2C cmd because of Fw download fail!!!
WARNING: CPU: 3 PID: 159 at drivers/net/wireless/realtek/rtlwifi/
 rtl8723be/fw.c:227 rtl8723be_fill_h2c_cmd+0x182/0x510 [rtl8723be]
CPU: 3 PID: 159 Comm: kworker/3:2 Tainted: G   O 4.16.13-2-ARCH #1
Hardware name: ASUSTeK COMPUTER INC. X556UF/X556UF, BIOS X556UF.406
   10/21/2016
Workqueue: rtl8723be_pci rtl_c2hcmd_wq_callback [rtlwifi]
RIP: 0010:rtl8723be_fill_h2c_cmd+0x182/0x510 [rtl8723be]
RSP: 0018:a6ab01e1bd70 EFLAGS: 00010282
RAX:  RBX: a26069071520 RCX: 0001
RDX: 8001 RSI: 8be70e9c RDI: 
RBP:  R08: 0048 R09: 0348
R10:  R11: 0001 R12: 
R13: a26069071520 R14:  R15: a2607d205f70
FS:  () GS:a26081d8() knlGS:000
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0443b39d3000 CR3: 00037700a005 CR4: 003606e0
Call Trace:
 ? halbtc_send_bt_mp_operation.constprop.17+0xd5/0xe0 [btcoexist]
 ? ex_btc8723b1ant_bt_info_notify+0x3b8/0x820 [btcoexist]
 ? rtl_c2hcmd_launcher+0xab/0x110 [rtlwifi]
 ? process_one_work+0x1d1/0x3b0
 ? worker_thread+0x2b/0x3d0
 ? process_one_work+0x3b0/0x3b0
 ? kthread+0x112/0x130
 ? kthread_create_on_node+0x60/0x60
 ? ret_from_fork+0x35/0x40
Code: 00 76 b4 e9 e2 fe ff ff 4c 89 ee 4c 89 e7 e8 56 22 86 ca e9 5e ...

This patch ensures all delayed works done before entering PS to satisfy
our expectation, so use cancel_delayed_work_sync() instead. An exception
is delayed work ips_nic_off_wq because running task may be itself, so add
a parameter ips_wq to deinit function to handle this case.

This issue is reported and fixed in below threads:
https://github.com/lwfinger/rtlwifi_new/issues/367
https://github.com/lwfinger/rtlwifi_new/issues/366

Tested-by: Evgeny Kapun  # 8723DE
Tested-by: Shivam Kakkar  # 8723BE on 4.18-rc1
Signed-off-by: Ping-Ke Shih 
Fixes: cceb0a597320 ("rtlwifi: Add work queue for c2h cmd.")
Cc: Stable  # 4.11+
Reviewed-by: Larry Finger 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/realtek/rtlwifi/base.c |   17 ++---
 drivers/net/wireless/realtek/rtlwifi/base.h |2 +-
 drivers/net/wireless/realtek/rtlwifi/core.c |2 +-
 drivers/net/wireless/realtek/rtlwifi/pci.c  |2 +-
 drivers/net/wireless/realtek/rtlwifi/ps.c   |4 ++--
 drivers/net/wireless/realtek/rtlwifi/usb.c  |2 +-
 6 files changed, 16 insertions(+), 13 deletions(-)

--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -485,18 +485,21 @@ static void _rtl_init_deferred_work(stru
 
 }
 
-void rtl_deinit_deferred_work(struct ieee80211_hw *hw)
+void rtl_deinit_deferred_work(struct ieee80211_hw *hw, bool ips_wq)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
 
del_timer_sync(&rtlpriv->works.watchdog_timer);
 
-   cancel_delayed_work(&rtlpriv->works.watchdog_wq);
-   cancel_delayed_work(&rtlpriv->works.ips_nic_off_wq);
-   cancel_delayed_work(&rtlpriv->works.ps_work);
-   cancel_delayed_work(&rtlpriv->works.ps_rfon_wq);
-   cancel_delayed_work(&rtlpriv->works.fwevt_wq);
-   cancel_delayed_work(&rtlpriv->works.c2hcmd_wq);
+   cancel_delayed_work_sync(&rtlpriv->works.watchdog_wq);
+   if (ips_wq)
+   cancel_delayed_work(&rtlpriv->works.ips_nic_off_wq);
+   else
+   cancel_delayed_work_sync(&rtlpriv->works.ips_nic_off_wq);
+   cancel_delayed_work_sync(&rtlpriv->works.ps_work);
+   cancel_delayed_work_sync(&rtlpriv->works.ps_rfon_wq);
+   cancel_delayed_work_sync(&rtlpriv->works.fwevt_wq);
+   cancel_delayed_work_sync(&rtlpriv->works.c2hcmd_wq);
 }
 EXPORT_SYMBOL_GPL(rtl_deinit_deferred_work);
 
--- a/drivers/net/wireless/realtek/rtlwifi/base.h
+++ b/drivers/net/wireless/realtek/rtlwifi/base.h
@@ -121,7 +121,7 @@ void rtl_init_rfkill(struct ieee80211_hw
 void rtl_deinit_rfkill(struct ieee80211_hw *hw);
 
 void rtl_watch_dog_timer_callback(struct timer_list *t);
-void rtl_deinit_deferred_work(struct ieee80211_hw *hw);
+void rtl_deinit_deferred_work(struct ieee80211_hw *hw, bool ips_wq);
 
 bool rtl_action_proc(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx);
 int rtlwifi_rate_mapping(struct ieee80211_hw *hw, bool isht,
---

[PATCH 4.14 54/92] media: rc: oops in ir_timer_keyup after device unplug

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Sean Young 

commit 8d4068810d9926250dd2435719a080b889eb44c3 upstream.

If there is IR in the raw kfifo when ir_raw_event_unregister() is called,
then kthread_stop() causes ir_raw_event_thread to be scheduled, decode
some scancodes and re-arm timer_keyup. The timer_keyup then fires when
the rc device is long gone.

Cc: sta...@vger.kernel.org
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Sudip Mukherjee 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/media/rc/rc-main.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1824,11 +1824,11 @@ void rc_unregister_device(struct rc_dev
if (!dev)
return;
 
-   del_timer_sync(&dev->timer_keyup);
-
if (dev->driver_type == RC_DRIVER_IR_RAW)
ir_raw_event_unregister(dev);
 
+   del_timer_sync(&dev->timer_keyup);
+
rc_free_rx_device(dev);
 
device_del(&dev->dev);

[PATCH 4.14 67/92] bdi: Fix another oops in wb_workfn()

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara 

commit 3ee7e8697d5860b173132606d80a9cd35e7113ee upstream.

syzbot is reporting NULL pointer dereference at wb_workfn() [1] due to
wb->bdi->dev being NULL. And Dmitry confirmed that wb->state was
WB_shutting_down after wb->bdi->dev became NULL. This indicates that
unregister_bdi() failed to call wb_shutdown() on one of wb objects.

The problem is in cgwb_bdi_unregister() which does cgwb_kill() and thus
drops bdi's reference to wb structures before going through the list of
wbs again and calling wb_shutdown() on each of them. This way the loop
iterating through all wbs can easily miss a wb if that wb has already
passed through cgwb_remove_from_bdi_list() called from wb_shutdown()
from cgwb_release_workfn() and as a result fully shutdown bdi although
wb_workfn() for this wb structure is still running. In fact there are
also other ways cgwb_bdi_unregister() can race with
cgwb_release_workfn() leading e.g. to use-after-free issues:

CPU1CPU2
cgwb_bdi_unregister()
  cgwb_kill(*slot);

cgwb_release()
  queue_work(cgwb_release_wq, &wb->release_work);
cgwb_release_workfn()
  wb = list_first_entry(&bdi->wb_list, ...)
  spin_unlock_irq(&cgwb_lock);
  wb_shutdown(wb);
  ...
  kfree_rcu(wb, rcu);
  wb_shutdown(wb); -> oops use-after-free

We solve these issues by synchronizing writeback structure shutdown from
cgwb_bdi_unregister() with cgwb_release_workfn() using a new mutex. That
way we also no longer need synchronization using WB_shutting_down as the
mutex provides it for CONFIG_CGROUP_WRITEBACK case and without
CONFIG_CGROUP_WRITEBACK wb_shutdown() can be called only once from
bdi_unregister().

Reported-by: syzbot 
Acked-by: Tejun Heo 
Signed-off-by: Jan Kara 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 include/linux/backing-dev-defs.h |2 +-
 mm/backing-dev.c |   20 +++-
 2 files changed, 8 insertions(+), 14 deletions(-)

--- a/include/linux/backing-dev-defs.h
+++ b/include/linux/backing-dev-defs.h
@@ -22,7 +22,6 @@ struct dentry;
  */
 enum wb_state {
WB_registered,  /* bdi_register() was done */
-   WB_shutting_down,   /* wb_shutdown() in progress */
WB_writeback_running,   /* Writeback is in progress */
WB_has_dirty_io,/* Dirty inodes on ->b_{dirty|io|more_io} */
 };
@@ -165,6 +164,7 @@ struct backing_dev_info {
 #ifdef CONFIG_CGROUP_WRITEBACK
struct radix_tree_root cgwb_tree; /* radix tree of active cgroup wbs */
struct rb_root cgwb_congested_tree; /* their congested states */
+   struct mutex cgwb_release_mutex;  /* protect shutdown of wb structs */
 #else
struct bdi_writeback_congested *wb_congested;
 #endif
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -356,15 +356,8 @@ static void wb_shutdown(struct bdi_write
spin_lock_bh(&wb->work_lock);
if (!test_and_clear_bit(WB_registered, &wb->state)) {
spin_unlock_bh(&wb->work_lock);
-   /*
-* Wait for wb shutdown to finish if someone else is just
-* running wb_shutdown(). Otherwise we could proceed to wb /
-* bdi destruction before wb_shutdown() is finished.
-*/
-   wait_on_bit(&wb->state, WB_shutting_down, TASK_UNINTERRUPTIBLE);
return;
}
-   set_bit(WB_shutting_down, &wb->state);
spin_unlock_bh(&wb->work_lock);
 
cgwb_remove_from_bdi_list(wb);
@@ -376,12 +369,6 @@ static void wb_shutdown(struct bdi_write
mod_delayed_work(bdi_wq, &wb->dwork, 0);
flush_delayed_work(&wb->dwork);
WARN_ON(!list_empty(&wb->work_list));
-   /*
-* Make sure bit gets cleared after shutdown is finished. Matches with
-* the barrier provided by test_and_clear_bit() above.
-*/
-   smp_wmb();
-   clear_and_wake_up_bit(WB_shutting_down, &wb->state);
 }
 
 static void wb_exit(struct bdi_writeback *wb)
@@ -505,10 +492,12 @@ static void cgwb_release_workfn(struct w
struct bdi_writeback *wb = container_of(work, struct bdi_writeback,
release_work);
 
+   mutex_lock(&wb->bdi->cgwb_release_mutex);
wb_shutdown(wb);
 
css_put(wb->memcg_css);
css_put(wb->blkcg_css);
+   mutex_unlock(&wb->bdi->cgwb_release_mutex);
 
fprop_local_destroy_percpu(&wb->memcg_completions);
percpu_ref_exit(&wb->refcnt);
@@ -694,6 +683,7 @@ static int cgwb_bdi_init(struct backing_
 
INIT_RADIX_TREE(&b

[PATCH 4.14 50/92] rtlwifi: Fix kernel Oops "Fw download fail!!"

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Ping-Ke Shih 

commit 12dfa2f68ab659636e092db13b5d17cf9aac82af upstream.

When connecting to AP, mac80211 asks driver to enter and leave PS quickly,
but driver deinit doesn't wait for delayed work complete when entering PS,
then driver reinit procedure and delay work are running simultaneously.
This will cause unpredictable kernel oops or crash like

rtl8723be: error H2C cmd because of Fw download fail!!!
WARNING: CPU: 3 PID: 159 at drivers/net/wireless/realtek/rtlwifi/
 rtl8723be/fw.c:227 rtl8723be_fill_h2c_cmd+0x182/0x510 [rtl8723be]
CPU: 3 PID: 159 Comm: kworker/3:2 Tainted: G   O 4.16.13-2-ARCH #1
Hardware name: ASUSTeK COMPUTER INC. X556UF/X556UF, BIOS X556UF.406
   10/21/2016
Workqueue: rtl8723be_pci rtl_c2hcmd_wq_callback [rtlwifi]
RIP: 0010:rtl8723be_fill_h2c_cmd+0x182/0x510 [rtl8723be]
RSP: 0018:a6ab01e1bd70 EFLAGS: 00010282
RAX:  RBX: a26069071520 RCX: 0001
RDX: 8001 RSI: 8be70e9c RDI: 
RBP:  R08: 0048 R09: 0348
R10:  R11: 0001 R12: 
R13: a26069071520 R14:  R15: a2607d205f70
FS:  () GS:a26081d8() knlGS:000
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 0443b39d3000 CR3: 00037700a005 CR4: 003606e0
Call Trace:
 ? halbtc_send_bt_mp_operation.constprop.17+0xd5/0xe0 [btcoexist]
 ? ex_btc8723b1ant_bt_info_notify+0x3b8/0x820 [btcoexist]
 ? rtl_c2hcmd_launcher+0xab/0x110 [rtlwifi]
 ? process_one_work+0x1d1/0x3b0
 ? worker_thread+0x2b/0x3d0
 ? process_one_work+0x3b0/0x3b0
 ? kthread+0x112/0x130
 ? kthread_create_on_node+0x60/0x60
 ? ret_from_fork+0x35/0x40
Code: 00 76 b4 e9 e2 fe ff ff 4c 89 ee 4c 89 e7 e8 56 22 86 ca e9 5e ...

This patch ensures all delayed works done before entering PS to satisfy
our expectation, so use cancel_delayed_work_sync() instead. An exception
is delayed work ips_nic_off_wq because running task may be itself, so add
a parameter ips_wq to deinit function to handle this case.

This issue is reported and fixed in below threads:
https://github.com/lwfinger/rtlwifi_new/issues/367
https://github.com/lwfinger/rtlwifi_new/issues/366

Tested-by: Evgeny Kapun  # 8723DE
Tested-by: Shivam Kakkar  # 8723BE on 4.18-rc1
Signed-off-by: Ping-Ke Shih 
Fixes: cceb0a597320 ("rtlwifi: Add work queue for c2h cmd.")
Cc: Stable  # 4.11+
Reviewed-by: Larry Finger 
Signed-off-by: Kalle Valo 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/net/wireless/realtek/rtlwifi/base.c |   17 ++---
 drivers/net/wireless/realtek/rtlwifi/base.h |2 +-
 drivers/net/wireless/realtek/rtlwifi/core.c |2 +-
 drivers/net/wireless/realtek/rtlwifi/pci.c  |2 +-
 drivers/net/wireless/realtek/rtlwifi/ps.c   |4 ++--
 drivers/net/wireless/realtek/rtlwifi/usb.c  |2 +-
 6 files changed, 16 insertions(+), 13 deletions(-)

--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -483,18 +483,21 @@ static void _rtl_init_deferred_work(stru
 
 }
 
-void rtl_deinit_deferred_work(struct ieee80211_hw *hw)
+void rtl_deinit_deferred_work(struct ieee80211_hw *hw, bool ips_wq)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
 
del_timer_sync(&rtlpriv->works.watchdog_timer);
 
-   cancel_delayed_work(&rtlpriv->works.watchdog_wq);
-   cancel_delayed_work(&rtlpriv->works.ips_nic_off_wq);
-   cancel_delayed_work(&rtlpriv->works.ps_work);
-   cancel_delayed_work(&rtlpriv->works.ps_rfon_wq);
-   cancel_delayed_work(&rtlpriv->works.fwevt_wq);
-   cancel_delayed_work(&rtlpriv->works.c2hcmd_wq);
+   cancel_delayed_work_sync(&rtlpriv->works.watchdog_wq);
+   if (ips_wq)
+   cancel_delayed_work(&rtlpriv->works.ips_nic_off_wq);
+   else
+   cancel_delayed_work_sync(&rtlpriv->works.ips_nic_off_wq);
+   cancel_delayed_work_sync(&rtlpriv->works.ps_work);
+   cancel_delayed_work_sync(&rtlpriv->works.ps_rfon_wq);
+   cancel_delayed_work_sync(&rtlpriv->works.fwevt_wq);
+   cancel_delayed_work_sync(&rtlpriv->works.c2hcmd_wq);
 }
 EXPORT_SYMBOL_GPL(rtl_deinit_deferred_work);
 
--- a/drivers/net/wireless/realtek/rtlwifi/base.h
+++ b/drivers/net/wireless/realtek/rtlwifi/base.h
@@ -121,7 +121,7 @@ void rtl_init_rfkill(struct ieee80211_hw
 void rtl_deinit_rfkill(struct ieee80211_hw *hw);
 
 void rtl_watch_dog_timer_callback(unsigned long data);
-void rtl_deinit_deferred_work(struct ieee80211_hw *hw);
+void rtl_deinit_deferred_work(struct ieee80211_hw *hw, bool ips_wq);
 
 bool rtl_action_proc(struct ieee80211_hw *hw, struct sk_buff *skb, u8 is_tx);
 int rtlwifi_rate_mapping(struct ieee80211_hw *hw, bool isht,
---

[PATCH 3.18 10/29] PM / hibernate: Fix oops at snapshot_write()

[Greg Kroah-Hartman]

3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Tetsuo Handa 

commit fc14eebfc20854a38fd9f1d93a42b1783dad4d17 upstream.

syzbot is reporting NULL pointer dereference at snapshot_write() [1].
This is because data->handle is zero-cleared by ioctl(SNAPSHOT_FREE).
Fix this by checking data_of(data->handle) != NULL before using it.

[1] 
https://syzkaller.appspot.com/bug?id=828a3c71bd344a6de8b6a31233d51a72099f27fd

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/power/user.c |5 +
 1 file changed, 5 insertions(+)

--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -184,6 +184,11 @@ static ssize_t snapshot_write(struct fil
res = PAGE_SIZE - pg_offp;
}
 
+   if (!data_of(data->handle)) {
+   res = -EINVAL;
+   goto unlock;
+   }
+
res = simple_write_to_buffer(data_of(data->handle), res, &pg_offp,
buf, count);
if (res > 0)

[PATCH 4.4 41/43] PM / hibernate: Fix oops at snapshot_write()

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Tetsuo Handa 

commit fc14eebfc20854a38fd9f1d93a42b1783dad4d17 upstream.

syzbot is reporting NULL pointer dereference at snapshot_write() [1].
This is because data->handle is zero-cleared by ioctl(SNAPSHOT_FREE).
Fix this by checking data_of(data->handle) != NULL before using it.

[1] 
https://syzkaller.appspot.com/bug?id=828a3c71bd344a6de8b6a31233d51a72099f27fd

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/power/user.c |5 +
 1 file changed, 5 insertions(+)

--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -184,6 +184,11 @@ static ssize_t snapshot_write(struct fil
res = PAGE_SIZE - pg_offp;
}
 
+   if (!data_of(data->handle)) {
+   res = -EINVAL;
+   goto unlock;
+   }
+
res = simple_write_to_buffer(data_of(data->handle), res, &pg_offp,
buf, count);
if (res > 0)

[PATCH 4.9 30/32] PM / hibernate: Fix oops at snapshot_write()

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Tetsuo Handa 

commit fc14eebfc20854a38fd9f1d93a42b1783dad4d17 upstream.

syzbot is reporting NULL pointer dereference at snapshot_write() [1].
This is because data->handle is zero-cleared by ioctl(SNAPSHOT_FREE).
Fix this by checking data_of(data->handle) != NULL before using it.

[1] 
https://syzkaller.appspot.com/bug?id=828a3c71bd344a6de8b6a31233d51a72099f27fd

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/power/user.c |5 +
 1 file changed, 5 insertions(+)

--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -186,6 +186,11 @@ static ssize_t snapshot_write(struct fil
res = PAGE_SIZE - pg_offp;
}
 
+   if (!data_of(data->handle)) {
+   res = -EINVAL;
+   goto unlock;
+   }
+
res = simple_write_to_buffer(data_of(data->handle), res, &pg_offp,
buf, count);
if (res > 0)

[PATCH 4.14 51/54] PM / hibernate: Fix oops at snapshot_write()

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Tetsuo Handa 

commit fc14eebfc20854a38fd9f1d93a42b1783dad4d17 upstream.

syzbot is reporting NULL pointer dereference at snapshot_write() [1].
This is because data->handle is zero-cleared by ioctl(SNAPSHOT_FREE).
Fix this by checking data_of(data->handle) != NULL before using it.

[1] 
https://syzkaller.appspot.com/bug?id=828a3c71bd344a6de8b6a31233d51a72099f27fd

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/power/user.c |5 +
 1 file changed, 5 insertions(+)

--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -186,6 +186,11 @@ static ssize_t snapshot_write(struct fil
res = PAGE_SIZE - pg_offp;
}
 
+   if (!data_of(data->handle)) {
+   res = -EINVAL;
+   goto unlock;
+   }
+
res = simple_write_to_buffer(data_of(data->handle), res, &pg_offp,
buf, count);
if (res > 0)

[PATCH 4.17 59/67] PM / hibernate: Fix oops at snapshot_write()

[Greg Kroah-Hartman]

4.17-stable review patch.  If anyone has any objections, please let me know.

--

From: Tetsuo Handa 

commit fc14eebfc20854a38fd9f1d93a42b1783dad4d17 upstream.

syzbot is reporting NULL pointer dereference at snapshot_write() [1].
This is because data->handle is zero-cleared by ioctl(SNAPSHOT_FREE).
Fix this by checking data_of(data->handle) != NULL before using it.

[1] 
https://syzkaller.appspot.com/bug?id=828a3c71bd344a6de8b6a31233d51a72099f27fd

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman 

---
 kernel/power/user.c |5 +
 1 file changed, 5 insertions(+)

--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -186,6 +186,11 @@ static ssize_t snapshot_write(struct fil
res = PAGE_SIZE - pg_offp;
}
 
+   if (!data_of(data->handle)) {
+   res = -EINVAL;
+   goto unlock;
+   }
+
res = simple_write_to_buffer(data_of(data->handle), res, &pg_offp,
buf, count);
if (res > 0)

[PATCH 4.14 08/61] xhci: Fix kernel oops in trace_xhci_free_virt_device

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Zhengjun Xing 

commit d850c1658328e757635a46763783c6fd56390dcb upstream.

commit 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device")
set dev->udev pointer to NULL in xhci_free_dev(), it will cause kernel
panic in trace_xhci_free_virt_device. This patch reimplement the trace
function trace_xhci_free_virt_device, remove dev->udev dereference and
added more useful parameters to show in the trace function,it also makes
sure dev->udev is not NULL before calling trace_xhci_free_virt_device.
This issue happened when xhci-hcd trace is enabled and USB devices hot
plug test. Original use-after-free patch went to stable so this needs so
be applied there as well.

[ 1092.022457] usb 2-4: USB disconnect, device number 6
[ 1092.092772] BUG: unable to handle kernel NULL pointer dereference at 

[ 1092.101694] PGD 0 P4D 0
[ 1092.104601] Oops:  [#1] SMP
[ 1092.207734] Workqueue: usb_hub_wq hub_event
[ 1092.212507] RIP: 0010:trace_event_raw_event_xhci_log_virt_dev+0x6c/0xf0
[ 1092.220050] RSP: 0018:8c252e883d28 EFLAGS: 00010086
[ 1092.226024] RAX: 8c24af86fa84 RBX: 0003 RCX: 8c25255c2a01
[ 1092.234130] RDX:  RSI: aef55009 RDI: 8c252e883d28
[ 1092.242242] RBP: 8c252550e2c0 R08: 8c24af86fa84 R09: 0a70
[ 1092.250364] R10: 0a70 R11:  R12: 8c251f21a000
[ 1092.258468] R13: 000c R14: 8c251f21a000 R15: 8c251f432f60
[ 1092.266572] FS:  () GS:8c252e88() 
knlGS:
[ 1092.275757] CS:  0010 DS:  ES:  CR0: 80050033
[ 1092.282281] CR2:  CR3: 000154209001 CR4: 003606e0
[ 1092.290384] Call Trace:
[ 1092.293156]  
[ 1092.295439]  xhci_free_virt_device.part.34+0x182/0x1a0
[ 1092.301288]  handle_cmd_completion+0x7ac/0xfa0
[ 1092.306336]  ? trace_event_raw_event_xhci_log_trb+0x6e/0xa0
[ 1092.312661]  xhci_irq+0x3e8/0x1f60
[ 1092.316524]  __handle_irq_event_percpu+0x75/0x180
[ 1092.321876]  handle_irq_event_percpu+0x20/0x50
[ 1092.326922]  handle_irq_event+0x36/0x60
[ 1092.331273]  handle_edge_irq+0x6d/0x180
[ 1092.335644]  handle_irq+0x16/0x20
[ 1092.339417]  do_IRQ+0x41/0xc0
[ 1092.342782]  common_interrupt+0xf/0xf
[ 1092.346955]  

Fixes: 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device")
Cc: 
Signed-off-by: Zhengjun Xing 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/host/xhci-mem.c   |4 ++--
 drivers/usb/host/xhci-trace.h |   36 +++-
 2 files changed, 33 insertions(+), 7 deletions(-)

--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -891,12 +891,12 @@ void xhci_free_virt_device(struct xhci_h
 
dev = xhci->devs[slot_id];
 
-   trace_xhci_free_virt_device(dev);
-
xhci->dcbaa->dev_context_ptrs[slot_id] = 0;
if (!dev)
return;
 
+   trace_xhci_free_virt_device(dev);
+
if (dev->tt_info)
old_active_eps = dev->tt_info->active_eps;
 
--- a/drivers/usb/host/xhci-trace.h
+++ b/drivers/usb/host/xhci-trace.h
@@ -158,6 +158,37 @@ DEFINE_EVENT(xhci_log_trb, xhci_queue_tr
TP_ARGS(ring, trb)
 );
 
+DECLARE_EVENT_CLASS(xhci_log_free_virt_dev,
+   TP_PROTO(struct xhci_virt_device *vdev),
+   TP_ARGS(vdev),
+   TP_STRUCT__entry(
+   __field(void *, vdev)
+   __field(unsigned long long, out_ctx)
+   __field(unsigned long long, in_ctx)
+   __field(u8, fake_port)
+   __field(u8, real_port)
+   __field(u16, current_mel)
+
+   ),
+   TP_fast_assign(
+   __entry->vdev = vdev;
+   __entry->in_ctx = (unsigned long long) vdev->in_ctx->dma;
+   __entry->out_ctx = (unsigned long long) vdev->out_ctx->dma;
+   __entry->fake_port = (u8) vdev->fake_port;
+   __entry->real_port = (u8) vdev->real_port;
+   __entry->current_mel = (u16) vdev->current_mel;
+   ),
+   TP_printk("vdev %p ctx %llx | %llx fake_port %d real_port %d 
current_mel %d",
+   __entry->vdev, __entry->in_ctx, __entry->out_ctx,
+   __entry->fake_port, __entry->real_port, __entry->current_mel
+   )
+);
+
+DEFINE_EVENT(xhci_log_free_virt_dev, xhci_free_virt_device,
+   TP_PROTO(struct xhci_virt_device *vdev),
+   TP_ARGS(vdev)
+);
+
 DECLARE_EVENT_CLASS(xhci_log_virt_dev,
TP_PROTO(struct xhci_virt_device *vdev),
TP_ARGS(vdev),
@@ -194,11 +225,6 @@ DEFINE_EVENT(xhci_log_virt_dev, xhci_all
TP_PROTO(struct xhci_virt_device *vdev),
TP_ARGS(vdev)
 );
-
-DEFINE_EVENT(xhci_log_virt_dev, xhci_free_virt_device,
-   TP_PR

[PATCH 4.17 09/46] xhci: Fix kernel oops in trace_xhci_free_virt_device

[Greg Kroah-Hartman]

4.17-stable review patch.  If anyone has any objections, please let me know.

--

From: Zhengjun Xing 

commit d850c1658328e757635a46763783c6fd56390dcb upstream.

commit 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device")
set dev->udev pointer to NULL in xhci_free_dev(), it will cause kernel
panic in trace_xhci_free_virt_device. This patch reimplement the trace
function trace_xhci_free_virt_device, remove dev->udev dereference and
added more useful parameters to show in the trace function,it also makes
sure dev->udev is not NULL before calling trace_xhci_free_virt_device.
This issue happened when xhci-hcd trace is enabled and USB devices hot
plug test. Original use-after-free patch went to stable so this needs so
be applied there as well.

[ 1092.022457] usb 2-4: USB disconnect, device number 6
[ 1092.092772] BUG: unable to handle kernel NULL pointer dereference at 

[ 1092.101694] PGD 0 P4D 0
[ 1092.104601] Oops:  [#1] SMP
[ 1092.207734] Workqueue: usb_hub_wq hub_event
[ 1092.212507] RIP: 0010:trace_event_raw_event_xhci_log_virt_dev+0x6c/0xf0
[ 1092.220050] RSP: 0018:8c252e883d28 EFLAGS: 00010086
[ 1092.226024] RAX: 8c24af86fa84 RBX: 0003 RCX: 8c25255c2a01
[ 1092.234130] RDX:  RSI: aef55009 RDI: 8c252e883d28
[ 1092.242242] RBP: 8c252550e2c0 R08: 8c24af86fa84 R09: 0a70
[ 1092.250364] R10: 0a70 R11:  R12: 8c251f21a000
[ 1092.258468] R13: 000c R14: 8c251f21a000 R15: 8c251f432f60
[ 1092.266572] FS:  () GS:8c252e88() 
knlGS:
[ 1092.275757] CS:  0010 DS:  ES:  CR0: 80050033
[ 1092.282281] CR2:  CR3: 000154209001 CR4: 003606e0
[ 1092.290384] Call Trace:
[ 1092.293156]  
[ 1092.295439]  xhci_free_virt_device.part.34+0x182/0x1a0
[ 1092.301288]  handle_cmd_completion+0x7ac/0xfa0
[ 1092.306336]  ? trace_event_raw_event_xhci_log_trb+0x6e/0xa0
[ 1092.312661]  xhci_irq+0x3e8/0x1f60
[ 1092.316524]  __handle_irq_event_percpu+0x75/0x180
[ 1092.321876]  handle_irq_event_percpu+0x20/0x50
[ 1092.326922]  handle_irq_event+0x36/0x60
[ 1092.331273]  handle_edge_irq+0x6d/0x180
[ 1092.335644]  handle_irq+0x16/0x20
[ 1092.339417]  do_IRQ+0x41/0xc0
[ 1092.342782]  common_interrupt+0xf/0xf
[ 1092.346955]  

Fixes: 44a182b9d177 ("xhci: Fix use-after-free in xhci_free_virt_device")
Cc: 
Signed-off-by: Zhengjun Xing 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/host/xhci-mem.c   |4 ++--
 drivers/usb/host/xhci-trace.h |   36 +++-
 2 files changed, 33 insertions(+), 7 deletions(-)

--- a/drivers/usb/host/xhci-mem.c
+++ b/drivers/usb/host/xhci-mem.c
@@ -878,12 +878,12 @@ void xhci_free_virt_device(struct xhci_h
 
dev = xhci->devs[slot_id];
 
-   trace_xhci_free_virt_device(dev);
-
xhci->dcbaa->dev_context_ptrs[slot_id] = 0;
if (!dev)
return;
 
+   trace_xhci_free_virt_device(dev);
+
if (dev->tt_info)
old_active_eps = dev->tt_info->active_eps;
 
--- a/drivers/usb/host/xhci-trace.h
+++ b/drivers/usb/host/xhci-trace.h
@@ -171,6 +171,37 @@ DEFINE_EVENT(xhci_log_trb, xhci_dbc_gadg
TP_ARGS(ring, trb)
 );
 
+DECLARE_EVENT_CLASS(xhci_log_free_virt_dev,
+   TP_PROTO(struct xhci_virt_device *vdev),
+   TP_ARGS(vdev),
+   TP_STRUCT__entry(
+   __field(void *, vdev)
+   __field(unsigned long long, out_ctx)
+   __field(unsigned long long, in_ctx)
+   __field(u8, fake_port)
+   __field(u8, real_port)
+   __field(u16, current_mel)
+
+   ),
+   TP_fast_assign(
+   __entry->vdev = vdev;
+   __entry->in_ctx = (unsigned long long) vdev->in_ctx->dma;
+   __entry->out_ctx = (unsigned long long) vdev->out_ctx->dma;
+   __entry->fake_port = (u8) vdev->fake_port;
+   __entry->real_port = (u8) vdev->real_port;
+   __entry->current_mel = (u16) vdev->current_mel;
+   ),
+   TP_printk("vdev %p ctx %llx | %llx fake_port %d real_port %d 
current_mel %d",
+   __entry->vdev, __entry->in_ctx, __entry->out_ctx,
+   __entry->fake_port, __entry->real_port, __entry->current_mel
+   )
+);
+
+DEFINE_EVENT(xhci_log_free_virt_dev, xhci_free_virt_device,
+   TP_PROTO(struct xhci_virt_device *vdev),
+   TP_ARGS(vdev)
+);
+
 DECLARE_EVENT_CLASS(xhci_log_virt_dev,
TP_PROTO(struct xhci_virt_device *vdev),
TP_ARGS(vdev),
@@ -207,11 +238,6 @@ DEFINE_EVENT(xhci_log_virt_dev, xhci_all
TP_PROTO(struct xhci_virt_device *vdev),
TP_ARGS(vdev)
 );
-
-DEFINE_EVENT(xhci_log_virt_dev, xhci_free_virt_device,
-   TP_PR

[nfsd] page allocation failure -> kernel oops, even local fs hangs.

[Ian Kumlien]

Hi,

I just had this happen a little while ago, got different weird
deadlocks but this one actually generated a oops..

This is basic operation, a machine with 16 gb memory mainly doing NFS traffic.

I'm currently playing with RDMA for this, which is why mlx4 is included.

When the crash occurs, the local filesystem is just as inaccessible as
trying to use it remotely - i couldn't find any change that looked
related to it in v4.18-rc3 so here goes:

(the same report is attached as well)
[1609167.131537] nfsd: page allocation failure: order:8,
mode:0x14000c0(GFP_KERNEL), nodemask=(null)
[1609167.131548] nfsd cpuset=/ mems_allowed=0
[1609167.131554] CPU: 5 PID: 1310 Comm: nfsd Not tainted 4.17.1 #196
[1609167.131557] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./X370 Taichi, BIOS P4.70 04/17/2018
[1609167.131561] Call Trace:
[1609167.131567]  dump_stack+0x46/0x5b
[1609167.131571]  warn_alloc+0xf8/0x180
[1609167.131575]  ? __alloc_pages_direct_compact+0x8b/0x110
[1609167.131578]  __alloc_pages_slowpath+0xb86/0xbc0
[1609167.131583]  ? set_next_entity+0x47b/0x680
[1609167.131586]  __alloc_pages_nodemask+0x1f9/0x230
[1609167.131589]  dma_direct_alloc+0xbd/0x120
[1609167.131593]  alloc_coherent+0x60/0x160
[1609167.131599]  mlx4_buf_direct_alloc.isra.9+0xc1/0x170 [mlx4_core]
[1609167.131604]  mlx4_buf_alloc+0x158/0x1d0 [mlx4_core]
[1609167.131608]  ? _raw_spin_lock_irqsave+0x1d/0x50
[1609167.131612]  create_qp_common.isra.48+0x4bc/0x10d0 [mlx4_ib]
[1609167.131616]  ? _raw_spin_unlock_irqrestore+0xf/0x30
[1609167.131620]  ? mlx4_free_cmd_mailbox.part.20+0x17/0x20 [mlx4_core]
[1609167.131624]  mlx4_ib_create_qp+0x128/0x880 [mlx4_ib]
[1609167.131627]  ? mlx4_ib_create_cq+0x25f/0x420 [mlx4_ib]
[1609167.131633]  ib_create_qp+0x9c/0x310 [ib_core]
[1609167.131636]  rdma_create_qp+0x39/0xb0 [rdma_cm]
[1609167.131641]  svc_rdma_accept+0x325/0x4d0 [rpcrdma]
[1609167.131644]  ? _raw_spin_unlock_irqrestore+0xf/0x30
[1609167.131648]  ? try_to_del_timer_sync+0x47/0x70
[1609167.131651]  ? svc_rdma_detach+0x10/0x10 [rpcrdma]
[1609167.131655]  svc_recv+0x2cc/0x7d0
[1609167.131659]  ? nfsd_destroy+0x80/0x80
[1609167.131661]  nfsd+0xd5/0x150
[1609167.131665]  kthread+0x109/0x120
[1609167.131668]  ? kthread_create_worker_on_cpu+0x70/0x70
[1609167.131671]  ret_from_fork+0x22/0x40
[1609167.131674] Mem-Info:
[1609167.131678] active_anon:16522 inactive_anon:21289 isolated_anon:0
  active_file:736374 inactive_file:2641993 isolated_file:23
  unevictable:0 dirty:2 writeback:123602 unstable:0
  slab_reclaimable:103077 slab_unreclaimable:76545
  mapped:10454 shmem:318 pagetables:2054 bounce:0
  free:42337 free_pcp:12 free_cma:0
[1609167.136395] Node 0 active_anon:66088kB inactive_anon:85156kB
active_file:2945496kB inactive_file:10567972kB unevictable:0kB
isolated(anon):0kB isolated
(file):92kB mapped:41816kB dirty:8kB writeback:494408kB shmem:1272kB
shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 98304kB
writeback_tmp:0kB unstable:0kB al
l_unreclaimable? no
[1609167.138299] Node 0 DMA free:15900kB min:64kB low:80kB high:96kB
active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB
unevictable:0kB wri
tepending:0kB present:15984kB managed:15900kB mlocked:0kB
kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB
free_cma:0kB
[1609167.140313] lowmem_reserve[]: 0 3449 15946 15946
[1609167.141305] Node 0 DMA32 free:75596kB min:14604kB low:18252kB
high:21900kB active_anon:7208kB inactive_anon:10828kB
active_file:651676kB inactive_file:
2600688kB unevictable:0kB writepending:151540kB present:3597884kB
managed:3597884kB mlocked:0kB kernel_stack:288kB pagetables:20kB
bounce:0kB free_pcp:0kB l
ocal_pcp:0kB free_cma:0kB
[1609167.143453] lowmem_reserve[]: 0 0 12497 12497
[1609167.144600] Node 0 Normal free:77852kB min:52912kB low:66140kB
high:79368kB active_anon:58880kB inactive_anon:74328kB
active_file:2293820kB inactive_fi
le:7967284kB unevictable:0kB writepending:342876kB present:13094400kB
managed:12802572kB mlocked:0kB kernel_stack:5760kB pagetables:8196kB
bounce:0kB free_p
cp:48kB local_pcp:48kB free_cma:0kB
[1609167.146913] lowmem_reserve[]: 0 0 0 0
[1609167.148033] Node 0 DMA: 1*4kB (U) 1*8kB (U) 1*16kB (U) 0*32kB
2*64kB (U) 1*128kB (U) 1*256kB (U) 0*512kB 1*1024kB (U) 1*2048kB (M)
3*4096kB (M) = 15900
kB
[1609167.149199] Node 0 DMA32: 564*4kB (UME) 640*8kB (UME) 465*16kB
(UME) 358*32kB (UME) 275*64kB (UME) 119*128kB (UME) 45*256kB (UM)
10*512kB (M) 0*1024kB
0*2048kB 0*4096kB = 75744kB
[1609167.150389] Node 0 Normal: 1517*4kB (UMEH) 1231*8kB (UMEH)
840*16kB (UMEH) 545*32kB (UM) 304*64kB (UM) 62*128kB (UM) 14*256kB (M)
1*512kB (M) 0*1024kB
0*2048kB 0*4096kB = 78284kB
[1609167.151592] Node 0 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=1048576kB
[1609167.152783] Node 0 hugepages_total=0 hugepages_free=0
hugepages_surp=0 hugepages_size=2048kB
[1609167.153980] 3379126 total pagecache pages
[1609167.1

RE: iscsi_trx oops in 4.18.0-rc2 and potential patch for percpu_ida.c

[Calciano, Jess]

Hello Sebastian,

> In Linus' tree:
> 4bb6e96ab808 ("lib/percpu_ida.c: don't do alloc from per-CPU list if there is 
> none")

We've tested with 4.18.0-rc3 and we're no longer seeing the kernel oops. Thank 
you!

-- Jess

Re: iscsi_trx oops in 4.18.0-rc2 and potential patch for percpu_ida.c

[bige...@linutronix.de]

On 2018-06-28 19:53:21 [+], Calciano, Jess wrote:
> So although the problem has already been reported, we're wondering if there 
> are any updates on the status of the fix, or if it will be available in an 
> upcoming mainline build.
In Linus' tree:
4bb6e96ab808 ("lib/percpu_ida.c: don't do alloc from per-CPU list if there is 
none")

> Thanks,
> Jess

Sebastian

iscsi_trx oops in 4.18.0-rc2 and potential patch for percpu_ida.c

[Calciano, Jess]

Hello,

In 4.18.0-rc1 and rc2, we're seeing a kernel oops on the SCSI target host when 
an initiator issues an "iscsiadm -m discovery" command.
Stack trace is below.

It seems to be the same bug discussed on the target-devel list in this thread: 
https://www.spinics.net/lists/target-devel/msg16815.html
...and resolved with the patch posted there: [PATCH] lib/percpu_ida.c: don't do 
alloc from per-CPU list if there is none
We tried the patch, and it works to fix the problem in our testing as well.

So although the problem has already been reported, we're wondering if there are 
any updates on the status of the fix, or if it will be available in an upcoming 
mainline build.


Thanks,
Jess



[  278.870830] BUG: unable to handle kernel paging request at c128bfa06b34
[  278.878629] PGD 85e46d067 P4D 85e46d067 PUD 0
[  278.883600] Oops:  [#1] SMP PTI
[  278.887500] CPU: 0 PID: 3331 Comm: iscsi_trx Not tainted 4.18.0-rc2 #1
[  278.894799] Hardware name: Intel Corporation S2600WT2R/S2600WT2R, BIOS 
SE5C610.86B.01.01.0016.033120161139 03/31/2016
[  278.906669] RIP: 0010:percpu_ida_alloc+0x67/0x90
[  278.911831] Code: 8c 48 89 44 24 18 48 89 44 24 20 65 48 03 1d e8 6e c6 73 
48 89 df e8 58 b8 3e 00 8b 4b 04 48 89 c6 48 89 df 8d 51 ff 89 53 04 <8b> 6c 93 
08 e8 70 b6 3e 00 48 8b 74 24 28 65 48 33 34 25 28 00 00
[  278.932933] RSP: 0018:a12cc8e87db0 EFLAGS: 00010046
[  278.938775] RAX: 0286 RBX: c124bfa06b30 RCX: 
[  278.946753] RDX:  RSI: 0286 RDI: c124bfa06b30
[  278.954730] RBP: 90a819b92000 R08:  R09: 0030
[  278.962707] R10: 90a016f080c8 R11: 000c R12: a12cc8e87e58
[  278.970683] R13: 90a01baa8000 R14: 90a819b92000 R15: 90a8197a62d8
[  278.979145] FS:  () GS:90a01f20() 
knlGS:
[  278.988606] CS:  0010 DS:  ES:  CR0: 80050033
[  278.995440] CR2: c128bfa06b34 CR3: 00064220a001 CR4: 003606f0
[  279.003831] DR0:  DR1:  DR2: 
[  279.012233] DR3:  DR6: fffe0ff0 DR7: 0400
[  279.020609] Call Trace:
[  279.023746]  ? remove_wait_queue+0x60/0x60
[  279.028741]  iscsit_allocate_cmd+0x28/0x110 [iscsi_target_mod]
[  279.035670]  iscsit_get_rx_pdu+0x4bb/0x880 [iscsi_target_mod]
[  279.042506]  ? pick_next_task_fair+0x291/0x620
[  279.047888]  ? __switch_to+0xa8/0x480
[  279.052405]  iscsi_target_rx_thread+0xb5/0xf0 [iscsi_target_mod]
[  279.059552]  kthread+0xf5/0x130
[  279.063499]  ? iscsi_target_tx_thread+0x1f0/0x1f0 [iscsi_target_mod]
[  279.071042]  ? kthread_bind+0x10/0x10
[  279.075576]  ret_from_fork+0x35/0x40
[  279.080007] Modules linked in: target_core_user uio tcm_fc libfc 
scsi_transport_fc tcm_loop target_core_pscsi target_core_iblock 
target_core_file rpcrdma ib_isert iscsi_target_mod sunrpc target_core_mod 
rdma_ucm ib_uverbs ib_ipoib dm_mirror ib_iser dm_region_hash ib_umad dm_log 
rdma_cm libiscsi ib_cm dm_mod iw_cm scsi_transport_iscsi intel_rapl sb_edac 
x86_pkg_temp_thermal intel_powerclamp coretemp kvm hfi1 irqbypass joydev 
crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc rdmavt iTCO_wdt mei_me 
aesni_intel mei iTCO_vendor_support sg lpc_ich ib_core i2c_i801 crypto_simd 
cryptd glue_helper ipmi_si mxm_wmi ipmi_devintf ipmi_msghandler pcspkr ioatdma 
acpi_pad wmi acpi_power_meter ip_tables ext4 mbcache jbd2 sd_mod mgag200 
drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm igb
[  279.162388]  ahci libahci libata crc32c_intel dca i2c_algo_bit i2c_core
[  279.170337] CR2: c128bfa06b34
[  279.174655] ---[ end trace 3b147417c7ae0be8 ]---

[next-20180601][nvme][ppc] Kernel Oops is triggered when creating lvm snapshots on nvme disks

[Abdul Haleem]

Greeting's

Kernel Oops is seen on 4.17.0-rc7-next-20180601 kernel on a bare-metal
machine when running lvm snapshot tests on nvme disks.

Machine Type: Power 8 bare-metal
kernel : 4.17.0-rc7-next-20180601
test:  
$ pvcreate -y /dev/nvme0n1
$ vgcreate avocado_vg /dev/nvme0n1
$ lvcreate --size 1.4T --name avocado_lv avocado_vg -y
$ mkfs.ext2 /dev/avocado_vg/avocado_lv
$ lvcreate --size 1G --snapshot --name avocado_sn /dev/avocado_vg/avocado_lv -y
$ lvconvert --merge /dev/avocado_vg/avocado_sn

the last command results in Oops:

Unable to handle kernel paging request for data at address 0x00d0
Faulting instruction address: 0xc02dced4
Oops: Kernel access of bad area, sig: 11 [#1]
LE SMP NR_CPUS=2048 NUMA PowerNV
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in: dm_snapshot dm_bufio nvme bnx2x iptable_mangle
ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4
nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4
xt_tcpudp tun bridge stp llc iptable_filter dm_mirror dm_region_hash
dm_log dm_service_time vmx_crypto powernv_rng rng_core dm_multipath
kvm_hv binfmt_misc kvm nfsd ip_tables x_tables autofs4 xfs lpfc
crc_t10dif crct10dif_generic mdio nvme_fc libcrc32c nvme_fabrics
nvme_core crct10dif_common [last unloaded: nvme]
CPU: 70 PID: 157763 Comm: lvconvert Not tainted 
4.17.0-rc7-next-20180601-autotest-autotest #1
NIP:  c02dced4 LR: c0244d14 CTR: c0244cf0
REGS: c01f81d6b5a0 TRAP: 0300   Not tainted  
(4.17.0-rc7-next-20180601-autotest-autotest)
MSR:  90010280b033   CR: 22442444 
 XER: 2000
CFAR: c0008934 DAR: 00d0 DSISR: 4000 SOFTE: 0
GPR00: c0244d14 c01f81d6b820 c109c400 c03c9d080180
GPR04: 0001 c01fad51 c01fad51 0001
GPR08:  f000 f008 
GPR12: c0244cf0 c01c4f80 7fffa0e31090 7fffd9d9b470
GPR16:  005c 7fffa0e3a5b0 7fffa0e62040
GPR20: 010014ad7d50 010014ad7d20 7fffa0e64210 0001
GPR24:  c081bae0 c01ed2461b00 df859d08
GPR28: c03c9d080180 c0244d14 0001 
NIP [c02dced4] kmem_cache_free+0x1a4/0x2b0
LR [c0244d14] mempool_free_slab+0x24/0x40
Call Trace:
[c01f81d6b820] [c02dcfbc] kmem_cache_free+0x28c/0x2b0 (unreliable)
[c01f81d6b8b0] [c0244d14] mempool_free_slab+0x24/0x40
[c01f81d6b8d0] [c0244e10] mempool_exit+0x50/0x90
[c01f81d6b900] [c081d730] dm_io_client_destroy+0x20/0x50
[c01f81d6b930] [c081f1dc] dm_kcopyd_client_destroy+0x9c/0x140
[c01f81d6b9a0] [df851da4] 
dm_exception_table_exit.isra.14+0x204/0xaa0 [dm_snapshot]
[c01f81d6ba40] [c08162d0] dm_table_destroy+0xa0/0x190
[c01f81d6bad0] [c081bc24] dev_suspend+0x144/0x330
[c01f81d6bb10] [c081c870] ctl_ioctl+0x350/0x4e0
[c01f81d6bd00] [c081ca18] dm_ctl_ioctl+0x18/0x30
[c01f81d6bd20] [c0329b38] do_vfs_ioctl+0xc8/0x8b0
[c01f81d6bdc0] [c032a37c] ksys_ioctl+0x5c/0xe0
[c01f81d6be10] [c032a420] sys_ioctl+0x20/0x80
[c01f81d6be30] [c000b9e0] system_call+0x58/0x6c
Instruction dump:
39295e50 7bca8502 794a3664 e929 7d495214 7d495378 e94a0008 794807e1
40c2010c ebe90018 7fbcf840 419e00f8  7fbc4800 419efe9c e8bc0058
---[ end trace d60580773711c361 ]---
essage from syslogd@localhost at Jun  4 08:34:20 ...
 kernel:Dumping ftrace buffer:

[cache_from_obj: Wrong slab cache. ksm_rmap_item but object is from kmalloc-128
[WARNING: CPU: 0 PID: 157807 at mm/slab.h:381 kmem_cache_free+0x1d0/0x2b0
[Modules linked in: dm_snapshot dm_bufio nvme bnx2x iptable_mangle
ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4
nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4
xt_tcpudp tun bridge stp llc iptable_filter dm_mirror dm_region_hash
dm_log dm_service_time vmx_crypto powernv_rng rng_core dm_multipath
kvm_hv binfmt_misc kvm nfsd ip_tables x_tables autofs4 xfs lpfc
crc_t10dif crct10dif_generic mdio nvme_fc libcrc32c nvme_fabrics
nvme_core crct10dif_common [last unloaded: nvme]
[CPU: 0 PID: 157807 Comm: vgremove Tainted: G  D   
4.17.0-rc7-next-20180601-autotest-autotest #1
[NIP:  c02dcf00 LR: c02dcefc CTR: 
[REGS: c01ee130f500 TRAP: 0700   Tainted: G  D
(4.17.0-rc7-next-20180601-autotest-autotest)
[MSR:  90010282b033   CR: 
22442422  XER: 2000
[CFAR: c01668f4 SOFTE: 0
[GPR00: c02dcefc c01ee130f780 c109c400 004e
[GPR04: c01ff5c0cdd0 c01ff5c23a70 0001 
[GPR08:  c01ff5c13880 001ff4e9 900102803003
[GPR12: 2200 c126 7fff7f2e1090 7fffecda3550
[GPR16:  000

Re: [PATCH] m68k: fix "bad page state" oops on ColdFire boot

[Greg Ungerer]

Hi Geert,

On 18/06/18 16:58, Geert Uytterhoeven wrote:

Hi Greg,

On Mon, Jun 18, 2018 at 8:06 AM Greg Ungerer  wrote:

Booting a ColdFire m68k core with MMU enabled causes a "bad page state"
oops since commit 1d40a5ea01d5 ("mm: mark pages in use for page tables"):

  BUG: Bad page state in process sh  pfn:01ce2
  page:004fefc8 count:0 mapcount:-1024 mapping: index:0x0
  flags: 0x0()
  raw:    fbff  0100 0200 
  raw: 039c4000
  page dumped because: nonzero mapcount
  Modules linked in:
  CPU: 0 PID: 22 Comm: sh Not tainted 4.17.0-07461-g1d40a5ea01d5 #13

Fix by calling pgtable_page_dtor() in our __pte_free_tlb() code path,
so that the PG_table flag is cleared before we free the pte page.

Signed-off-by: Greg Ungerer 
CC: Matthew Wilcox 
---
  arch/m68k/include/asm/mcf_pgalloc.h | 1 +
  1 file changed, 1 insertion(+)

Matthew: I came across this thread at https://lkml.org/lkml/2018/6/17/163
  about a similar problem with openrisc. Based on that I came up
  with this fix for m68k/ColdFire. Fixes the issue for me.

diff --git a/arch/m68k/include/asm/mcf_pgalloc.h 
b/arch/m68k/include/asm/mcf_pgalloc.h
index 8b707c249026..8c441eb57b80 100644
--- a/arch/m68k/include/asm/mcf_pgalloc.h
+++ b/arch/m68k/include/asm/mcf_pgalloc.h
@@ -44,6 +44,7 @@ extern inline pmd_t *pmd_alloc_kernel(pgd_t *pgd, unsigned 
long address)
  static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t page,
   unsigned long address)
  {
+   pgtable_page_dtor(page);
 __free_page(page);
  }


Do you need a call to pgtable_page_dtor() in pte_free(), too?
On x86 (and motorola_pgalloc.h and sun3_pgalloc.h FWIW), both functions
call pgtable_page_dtor().


I am thinking yes, looking at those other examples.

Regards
Greg

[PATCH 4.16 191/279] drm/vc4: Fix oops dereferencing DPIs connector since panel_bridge.

[Greg Kroah-Hartman]

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Eric Anholt 

[ Upstream commit 164c2416dd40770aba5814f93da835e8a9f7196d ]

In the cleanup, I didn't notice that we needed to dereference the
connector for the bus_format.  Fix the regression by looking up the
first (and only) connector attached to us, and assume that its
bus_format is what we want.  Some day it would be good to have that
part of display_info attached to the bridge, instead.

v2: Fix stray whitespace change

Signed-off-by: Eric Anholt 
Fixes: 7b1298e05310 ("drm/vc4: Switch DPI to using the panel-bridge helper.")
Link: 
https://patchwork.freedesktop.org/patch/msgid/20180309233256.1667-1-e...@anholt.net
Reviewed-by: Sean Paul 
Reviewed-by: Boris Brezillon 
Signed-off-by: Sean Paul 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/vc4/vc4_dpi.c |   25 ++---
 1 file changed, 22 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/vc4/vc4_dpi.c
+++ b/drivers/gpu/drm/vc4/vc4_dpi.c
@@ -96,7 +96,6 @@ struct vc4_dpi {
struct platform_device *pdev;
 
struct drm_encoder *encoder;
-   struct drm_connector *connector;
 
void __iomem *regs;
 
@@ -164,14 +163,31 @@ static void vc4_dpi_encoder_disable(stru
 
 static void vc4_dpi_encoder_enable(struct drm_encoder *encoder)
 {
+   struct drm_device *dev = encoder->dev;
struct drm_display_mode *mode = &encoder->crtc->mode;
struct vc4_dpi_encoder *vc4_encoder = to_vc4_dpi_encoder(encoder);
struct vc4_dpi *dpi = vc4_encoder->dpi;
+   struct drm_connector_list_iter conn_iter;
+   struct drm_connector *connector = NULL, *connector_scan;
u32 dpi_c = DPI_ENABLE | DPI_OUTPUT_ENABLE_MODE;
int ret;
 
-   if (dpi->connector->display_info.num_bus_formats) {
-   u32 bus_format = dpi->connector->display_info.bus_formats[0];
+   /* Look up the connector attached to DPI so we can get the
+* bus_format.  Ideally the bridge would tell us the
+* bus_format we want, but it doesn't yet, so assume that it's
+* uniform throughout the bridge chain.
+*/
+   drm_connector_list_iter_begin(dev, &conn_iter);
+   drm_for_each_connector_iter(connector_scan, &conn_iter) {
+   if (connector_scan->encoder == encoder) {
+   connector = connector_scan;
+   break;
+   }
+   }
+   drm_connector_list_iter_end(&conn_iter);
+
+   if (connector && connector->display_info.num_bus_formats) {
+   u32 bus_format = connector->display_info.bus_formats[0];
 
switch (bus_format) {
case MEDIA_BUS_FMT_RGB888_1X24:
@@ -199,6 +215,9 @@ static void vc4_dpi_encoder_enable(struc
DRM_ERROR("Unknown media bus format %d\n", bus_format);
break;
}
+   } else {
+   /* Default to 24bit if no connector found. */
+   dpi_c |= VC4_SET_FIELD(DPI_FORMAT_24BIT_888_RGB, DPI_FORMAT);
}
 
if (mode->flags & DRM_MODE_FLAG_NHSYNC)

[PATCH 4.16 181/279] drm/exynos: mixer: avoid Oops in vp_video_buffer()

[Greg Kroah-Hartman]

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Tobias Jakobi 

[ Upstream commit 0ccc1c8f0282e237a0bd6dca7cdac4ed5e318ee7 ]

If an interlaced video mode is selected, a IOMMU pagefault is
triggered by vp_video_buffer().

Fix the most apparent bugs:
- pitch value for chroma plane
- divide by two of height and vpos of source and destination

Signed-off-by: Tobias Jakobi 
[ a.hajda: Halved also destination height and vpos, updated commit message ]
Signed-off-by: Andrzej Hajda 
Signed-off-by: Inki Dae 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/exynos/exynos_mixer.c |   12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -485,7 +485,7 @@ static void vp_video_buffer(struct mixer
chroma_addr[1] = chroma_addr[0] + 0x40;
} else {
luma_addr[1] = luma_addr[0] + fb->pitches[0];
-   chroma_addr[1] = chroma_addr[0] + fb->pitches[0];
+   chroma_addr[1] = chroma_addr[0] + fb->pitches[1];
}
} else {
luma_addr[1] = 0;
@@ -508,21 +508,23 @@ static void vp_video_buffer(struct mixer
vp_reg_write(ctx, VP_IMG_SIZE_Y, VP_IMG_HSIZE(fb->pitches[0]) |
VP_IMG_VSIZE(fb->height));
/* chroma plane for NV12/NV21 is half the height of the luma plane */
-   vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[0]) |
+   vp_reg_write(ctx, VP_IMG_SIZE_C, VP_IMG_HSIZE(fb->pitches[1]) |
VP_IMG_VSIZE(fb->height / 2));
 
vp_reg_write(ctx, VP_SRC_WIDTH, state->src.w);
-   vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h);
vp_reg_write(ctx, VP_SRC_H_POSITION,
VP_SRC_H_POSITION_VAL(state->src.x));
-   vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y);
-
vp_reg_write(ctx, VP_DST_WIDTH, state->crtc.w);
vp_reg_write(ctx, VP_DST_H_POSITION, state->crtc.x);
+
if (test_bit(MXR_BIT_INTERLACE, &ctx->flags)) {
+   vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h / 2);
+   vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y / 2);
vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h / 2);
vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y / 2);
} else {
+   vp_reg_write(ctx, VP_SRC_HEIGHT, state->src.h);
+   vp_reg_write(ctx, VP_SRC_V_POSITION, state->src.y);
vp_reg_write(ctx, VP_DST_HEIGHT, state->crtc.h);
vp_reg_write(ctx, VP_DST_V_POSITION, state->crtc.y);
}

Re: [PATCH] m68k: fix "bad page state" oops on ColdFire boot

[Geert Uytterhoeven]

Hi Greg,

On Mon, Jun 18, 2018 at 8:06 AM Greg Ungerer  wrote:
> Booting a ColdFire m68k core with MMU enabled causes a "bad page state"
> oops since commit 1d40a5ea01d5 ("mm: mark pages in use for page tables"):
>
>  BUG: Bad page state in process sh  pfn:01ce2
>  page:004fefc8 count:0 mapcount:-1024 mapping: index:0x0
>  flags: 0x0()
>  raw:    fbff  0100 0200 
>  raw: 039c4000
>  page dumped because: nonzero mapcount
>  Modules linked in:
>  CPU: 0 PID: 22 Comm: sh Not tainted 4.17.0-07461-g1d40a5ea01d5 #13
>
> Fix by calling pgtable_page_dtor() in our __pte_free_tlb() code path,
> so that the PG_table flag is cleared before we free the pte page.
>
> Signed-off-by: Greg Ungerer 
> CC: Matthew Wilcox 
> ---
>  arch/m68k/include/asm/mcf_pgalloc.h | 1 +
>  1 file changed, 1 insertion(+)
>
> Matthew: I came across this thread at https://lkml.org/lkml/2018/6/17/163
>  about a similar problem with openrisc. Based on that I came up
>  with this fix for m68k/ColdFire. Fixes the issue for me.
>
> diff --git a/arch/m68k/include/asm/mcf_pgalloc.h 
> b/arch/m68k/include/asm/mcf_pgalloc.h
> index 8b707c249026..8c441eb57b80 100644
> --- a/arch/m68k/include/asm/mcf_pgalloc.h
> +++ b/arch/m68k/include/asm/mcf_pgalloc.h
> @@ -44,6 +44,7 @@ extern inline pmd_t *pmd_alloc_kernel(pgd_t *pgd, unsigned 
> long address)
>  static inline void __pte_free_tlb(struct mmu_gather *tlb, pgtable_t page,
>   unsigned long address)
>  {
> +   pgtable_page_dtor(page);
> __free_page(page);
>  }

Do you need a call to pgtable_page_dtor() in pte_free(), too?
On x86 (and motorola_pgalloc.h and sun3_pgalloc.h FWIW), both functions
call pgtable_page_dtor().

Gr{oetje,eeting}s,

Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: Recall: PROBLEM: JFFS2 Empty summary info causes OOPS

[David Woodhouse]

> On Fri, Jun 15, 2018 at 9:13 PM, Veluthakkal, Sreeram
>  wrote:
>> Veluthakkal, Sreeram would like to recall the message, "PROBLEM: JFFS2
>> Empty summary info causes OOPS".
>
> -ENOMSEXCHANGE

Nom sex change? Oh, I see. No, it never works in Exchange either AFAICT.
Only ever serves to draw attention to the "recalled" mail and make more
people read it. Perhaps that was the intent? :)


-- 
dwmw2

Re: Recall: PROBLEM: JFFS2 Empty summary info causes OOPS

[Richard Weinberger]

On Fri, Jun 15, 2018 at 9:13 PM, Veluthakkal, Sreeram
 wrote:
> Veluthakkal, Sreeram would like to recall the message, "PROBLEM: JFFS2 Empty 
> summary info causes OOPS".

-ENOMSEXCHANGE

-- 
Thanks,
//richard

Recall: PROBLEM: JFFS2 Empty summary info causes OOPS

[Veluthakkal, Sreeram]

Veluthakkal, Sreeram would like to recall the message, "PROBLEM: JFFS2 Empty 
summary info causes OOPS".

PROBLEM: JFFS2 Empty summary info causes OOPS

[Veluthakkal, Sreeram]

Hi,

[1.] Summary: JFFS2 Empty summary node info causes OOPS
[2.] Description: Under stress situations on the filesystem, OOPs are observed. 
The OOPs points to empty summary node info bug. Confirmed that the filesystem 
is not full, not corrupted and is accessible.
[3.] Keywords (i.e., modules, networking, kernel): filesystem
[4.] Kernel information
[4.1.] Kernel version (from /proc/version): 4.1.12
Driver version:  jffs2: version 2.2. (NAND) (SUMMARY)  © 2001-2006 Red Hat, Inc.
[6.] Output of Oops.. 

Kernel BUG at c0268c78 [verbose debug info unavailable]
Internal error: Oops - BUG: 0 [#1] SMP ARM
Modules linked in: npcm750_rng dell_usbmuxdrv(O) g_edm_mass_storage3 vcd_dev(O) 

   usb_storage sd_mod scsi_mod 
rng_core oprofile md4 g_edm_mass_storage2 des_generi

   c dell_regmem_adds(O) dell_pmdrv(O) dell_oom_notify(O) 
dell_msgbox(O) g_edm_mass   

_storage1 dell_fpdrv(O) dell_early_board(O) dell_ipmbdrv(O) dell_i2cdrv(O) 
dell_   
cplddrv(O) 
g_edm_mass_storage cifs bonding g_edm_kbdmouse usb_f_ecm g_ether_usb

    arc4 aess_vkcsdrv(O) aess_smadrv(O) 
usb_f_rndis u_ether aess_pwmdrv(O) aess_pcim

   ailboxdrv(O) aess_mtddrv_spi_nor(O) aess_memdrv(O) libcomposite 
aess_fansensordr
   v(O) 
aess_dynairqdrv(O) aess_gpiodrv(O) aess_video(O) aess_biospostdrv(O) aess_k 

  csdrv(O) aess_eventhandlerdrv(O) 
aess_adcsensordrv(O)
CPU: 1 PID: 998 Comm: cfgmgrd Tainted: G   O    4.1.12
Hardware name: NPCMX50 Chip family
task: d7ccd340 ti: d7c8a000 task.ti: d7c8a000
PC is at jffs2_sum_write_sumnode+0x508/0x518
LR is at jffs2_sum_write_sumnode+0x508/0x518
pc : []    lr : []    psr: 600b0013
sp : d7c8ba90  ip :   fp : d7c8bb80
r10: 00c4  r9 : d84510a8  r8 : 00200200
r7 : 0fa4  r6 : d84510a8  r5 : d9aac000  r4 : d98ca5c0
r3 :   r2 : dcba772c  r1 : dcba52dc  r0 : 0044
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 18c5387d  Table: 17ea404a  DAC: 0015
Process cfgmgrd (pid: 998, stack limit = 0xd7c8a190)
Stack: (0xd7c8ba90 to 0xd7c8c000)
ba80:  d7c8ba88 c08a6080 c09159c0
baa0: 000a 0091ccfe d9aac11c d7c8bac0 bf074c4c bf072de0 c08a2ae8 de32a000
bac0: 0c200319 b100 00e41eb0  bf074c4c   0002
bae0: 001eb000 bf074c4c  d9aac000 0fcc d84510a8 0fa4 00200200
bb00: 00100100 00c4 d7c8bb80 c0259678 bf074c58 d7c8bb47 0001 
bb20: d7c8bc38 d95f5958 d9aac11c 00c4 d9aac000 0fa4 d7c8bb80 db4aa480
bb40: d845100c c0259c98 d95f5958 d9aac000 0fa4 d9aac000 d85b3d80 d9be43f8
bb60: db4aa480 c0604dc8  c0124818 d95f5998 0019d7bf d9ad9400 c060b44c
bb80: 00c4 c060b44c d95f5998 d95f5958 d9aac000 00028000 d8626700 d85b3d80
bba0: d95f5980 d9be43f8 d845100c c0605688 0019d7bf  d9be43f8 d845100c
bbc0: db4aa480 00029000  c00532a8  d9aac000 0003b000 c060b464
bbe0: 200b0013 c060b464 0003b000 c025fee4   d7c8bc20 
bc00: d7c8bc1c 0001 d9aac0fc  c094fe90 00100100 00200200 d9aac000
bc20: d9aac000 0019d7bf  c02614ec 000c e41eb0b1 d9aac000 d9aac000
bc40: d9aac11c 0019d7bf d9aac04c d9be43f8 d845100c d95f5958 d9aac164 c025ed54
bc60:  c0029350 000c 0001 0048 c025960c  0001
bc80: d8496040 0001  d9aac000 d9aac11c 0014 d9aac04c d7c8a000
bca0: 0013  d7c8bd24 c0259acc d8496040 001c 800b0013 c060b464
bcc0: d8496040 c002a158 d9aac000 800b0013 dab67208  dab67208 dab67208
bce0: c7b77954 d9aac2fc c0793f84 d9aac000 d9aac41c c0266228 0006 c060b5c0
bd00:  c7b77940 c5f06c00 0007 c7b77954 d7c8bd7c d9aac0c0 d7c8bd74
bd20: cc59aba8 0fb8 d9575c98 d7c8bd74 cc59aba8  c0266aac cc59ab68
bd40: d9aac000 d9575c98 d96c4280 c0266b00 001e  c02ca360 
bd60: cc59aba8 c02c2f74 d7c8bd78 d7c8bd7c d9575c98 c0793f84 c5f06c00 001e
bd80:       d9aac000 cc59aba8
bda0: d85f07c0 d9aac000

v4.18-rc0: ohci-platform on n900 oops-es on reboot

[Pavel Machek]

Hi!

When I enable

CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_OMAP3=y
CONFIG_USB_OHCI_HCD_PLATFORM=y

on n900 (I need it on droid4 and want common config), I get oops when
attempting to reboot the system. I believe problem is there in v4.17,
too.

I'll try to build it as a module and debug, but if you have better
idea, let me know...

Best regards,

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH] bdi: Fix another oops in wb_workfn()

[Tejun Heo]

Hello,

On Mon, Jun 11, 2018 at 11:12:48AM +0200, Jan Kara wrote:
> However this is wrong and so is the patch. The problem is in
> cgwb_bdi_unregister() which does cgwb_kill() and thus drops bdi's
> reference to wb structures before going through the list of wbs again and
> calling wb_shutdown() on each of them. The writeback structures we are
> accessing at this point can be already freed in principle like:
> 
> CPU1  CPU2
>   cgwb_bdi_unregister()
> cgwb_kill(*slot);
> 
> cgwb_release()
>   queue_work(cgwb_release_wq, &wb->release_work);
> cgwb_release_workfn()
> wb = list_first_entry(&bdi->wb_list, ...)
> spin_unlock_irq(&cgwb_lock);
>   wb_shutdown(wb);
>   ... 
>   kfree_rcu(wb, rcu);
> wb_shutdown(wb); -> oops use-after-free
> 
> I'm not 100% sure how to fix this. wb structures can be at various phases of
> shutdown (or there may be other external references still existing) when we
> enter cgwb_bdi_unregister() so I think adding a way for cgwb_bdi_unregister()
> to wait for standard wb shutdown path to finish is the most robust way.
> What do you think about attached patch Tejun? So far only compile tested...
> 
> Possible problem with it is that now cgwb_bdi_unregister() will wait for
> all wb references to be dropped so it adds some implicit dependencies to
> bdi shutdown path. 

Would something like the following work or am I missing the point
entirely?

Thanks.

diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index 347cc83..359cacd 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -715,14 +715,19 @@ static void cgwb_bdi_unregister(struct backing_dev_info 
*bdi)
WARN_ON(test_bit(WB_registered, &bdi->wb.state));
 
spin_lock_irq(&cgwb_lock);
-   radix_tree_for_each_slot(slot, &bdi->cgwb_tree, &iter, 0)
-   cgwb_kill(*slot);
+   radix_tree_for_each_slot(slot, &bdi->cgwb_tree, &iter, 0) {
+   struct bdi_writeback *wb = *slot;
+
+   wb_get(wb);
+   cgwb_kill(wb);
+   }
 
while (!list_empty(&bdi->wb_list)) {
wb = list_first_entry(&bdi->wb_list, struct bdi_writeback,
  bdi_node);
spin_unlock_irq(&cgwb_lock);
wb_shutdown(wb);
+   wb_put(wb);
spin_lock_irq(&cgwb_lock);
}
spin_unlock_irq(&cgwb_lock);


-- 
tejun

Re: [PATCH] bdi: Fix another oops in wb_workfn()

[Jan Kara]

On Sat 09-06-18 23:00:05, Tetsuo Handa wrote:
> From 014c4149f2e24cd26b278b32d5dfda056eecf093 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa 
> Date: Sat, 9 Jun 2018 22:47:52 +0900
> Subject: [PATCH] bdi: Fix another oops in wb_workfn()
> 
> syzbot is reporting NULL pointer dereference at wb_workfn() [1] due to
> wb->bdi->dev being NULL. And Dmitry confirmed that wb->state was
> WB_shutting_down after wb->bdi->dev became NULL. This indicates that
> unregister_bdi() failed to call wb_shutdown() on one of wb objects.
> 
> Since cgwb_bdi_unregister() from bdi_unregister() cannot call wb_shutdown()
> on wb objects which have already passed list_del_rcu() in wb_shutdown(),
> cgwb_bdi_unregister() from bdi_unregister() can return and set wb->bdi->dev
> to NULL before such wb objects enter final round of wb_workfn() via
> mod_delayed_work()/flush_delayed_work().

Thanks a lot for debugging the issue and also thanks a lot to Dmitry for
taking time to reproduce the race by hand with the debug patch! I really
appreciate it!

> Since WB_registered is already cleared by wb_shutdown(), only wb_shutdown()
> can schedule for final round of wb_workfn(). Since concurrent calls to
> wb_shutdown() on the same wb object is safe because of WB_shutting_down
> state, I think that wb_shutdown() can safely keep a wb object in the
> bdi->wb_list until that wb object leaves final round of wb_workfn().
> Thus, make wb_shutdown() call list_del_rcu() after flush_delayed_work().

However this is wrong and so is the patch. The problem is in
cgwb_bdi_unregister() which does cgwb_kill() and thus drops bdi's
reference to wb structures before going through the list of wbs again and
calling wb_shutdown() on each of them. The writeback structures we are
accessing at this point can be already freed in principle like:

CPU1CPU2
cgwb_bdi_unregister()
  cgwb_kill(*slot);

cgwb_release()
  queue_work(cgwb_release_wq, &wb->release_work);
cgwb_release_workfn()
  wb = list_first_entry(&bdi->wb_list, ...)
  spin_unlock_irq(&cgwb_lock);
  wb_shutdown(wb);
  ...   
  kfree_rcu(wb, rcu);
  wb_shutdown(wb); -> oops use-after-free

I'm not 100% sure how to fix this. wb structures can be at various phases of
shutdown (or there may be other external references still existing) when we
enter cgwb_bdi_unregister() so I think adding a way for cgwb_bdi_unregister()
to wait for standard wb shutdown path to finish is the most robust way.
What do you think about attached patch Tejun? So far only compile tested...

Possible problem with it is that now cgwb_bdi_unregister() will wait for
all wb references to be dropped so it adds some implicit dependencies to
bdi shutdown path. 

Honza
-- 
Jan Kara 
SUSE Labs, CR
>From f5038c6e7a3d1a4a91879187b92ede8c868988ac Mon Sep 17 00:00:00 2001
From: Jan Kara 
Date: Mon, 11 Jun 2018 10:56:04 +0200
Subject: [PATCH] bdi: Fix another oops in wb_workfn()

syzbot is reporting NULL pointer dereference at wb_workfn() [1] due to
wb->bdi->dev being NULL. And Dmitry confirmed that wb->state was
WB_shutting_down after wb->bdi->dev became NULL. This indicates that
unregister_bdi() failed to call wb_shutdown() on one of wb objects.

The problem is in cgwb_bdi_unregister() which does cgwb_kill() and thus
drops bdi's reference to wb structures before going through the list of
wbs again and calling wb_shutdown() on each of them. This way the loop
iterating through all wbs can easily miss a wb if that wb has already
passed through cgwb_remove_from_bdi_list() called from wb_shutdown()
from cgwb_release_workfn() and as a result fully shutdown bdi although
wb_workfn() for this wb structure is still running. In fact there are
also other ways cgwb_bdi_unregister() can race with
cgwb_release_workfn() leading e.g. to use-after-free issues:

CPU1CPU2
cgwb_bdi_unregister()
  cgwb_kill(*slot);

cgwb_release()
  queue_work(cgwb_release_wq, &wb->release_work);
cgwb_release_workfn()
  wb = list_first_entry(&bdi->wb_list, ...)
  spin_unlock_irq(&cgwb_lock);
  wb_shutdown(wb);
  ...
  kfree_rcu(wb, rcu);
  wb_shutdown(wb); -> oops use-after-free

We solve all these issues by making cgwb_bdi_unregister() wait for
shutdown of all wb structures instead of going through them and trying
to actively shut them down.

[1] https://syzkaller.appspot.com/bug?id=e0818ccb7e46190b3f1038b0c794299208ed4206

Cc: Dmitry Vyukov 
Cc: Tejun Heo 
Reported-and-an

[PATCH 3.16 240/410] crypto: s5p-sss - Fix kernel Oops in AES-ECB mode

[Ben Hutchings]

3.16.57-rc1 review patch.  If anyone has any objections, please let me know.

--

From: Kamil Konieczny 

commit c927b080c67e3e97193c81fc1d27f4251bf4e036 upstream.

In AES-ECB mode crypt is done with key only, so any use of IV
can cause kernel Oops. Use IV only in AES-CBC and AES-CTR.

Signed-off-by: Kamil Konieczny 
Reported-by: Anand Moon 
Reviewed-by: Krzysztof Kozlowski 
Tested-by: Anand Moon 
Signed-off-by: Herbert Xu 
[bwh: Backported to 3.16: adjust context]
Signed-off-by: Ben Hutchings 
---
 drivers/crypto/s5p-sss.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

--- a/drivers/crypto/s5p-sss.c
+++ b/drivers/crypto/s5p-sss.c
@@ -426,15 +426,21 @@ static void s5p_aes_crypt_start(struct s
uint32_taes_control;
int err;
unsigned long   flags;
+   u8 *iv;
 
aes_control = SSS_AES_KEY_CHANGE_MODE;
if (mode & FLAGS_AES_DECRYPT)
aes_control |= SSS_AES_MODE_DECRYPT;
 
-   if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CBC)
+   if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CBC) {
aes_control |= SSS_AES_CHAIN_MODE_CBC;
-   else if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CTR)
+   iv = req->info;
+   } else if ((mode & FLAGS_AES_MODE_MASK) == FLAGS_AES_CTR) {
aes_control |= SSS_AES_CHAIN_MODE_CTR;
+   iv = req->info;
+   } else {
+   iv = NULL; /* AES_ECB */
+   }
 
if (dev->ctx->keylen == AES_KEYSIZE_192)
aes_control |= SSS_AES_KEY_SIZE_192;
@@ -465,7 +471,7 @@ static void s5p_aes_crypt_start(struct s
goto outdata_error;
 
SSS_AES_WRITE(dev, AES_CONTROL, aes_control);
-   s5p_set_aes(dev, dev->ctx->aes_key, req->info, dev->ctx->keylen);
+   s5p_set_aes(dev, dev->ctx->aes_key, iv, dev->ctx->keylen);
 
s5p_set_dma_indata(dev,  req->src);
s5p_set_dma_outdata(dev, req->dst);

Re: [PATCH] PM / hibernate: Fix oops at snapshot_write().

[Rafael J. Wysocki]

On Saturday, May 26, 2018 2:59:36 AM CEST Tetsuo Handa wrote:
> syzbot is reporting NULL pointer dereference at snapshot_write() [1].
> This is because data->handle is zero-cleared by ioctl(SNAPSHOT_FREE).
> Fix this by checking data_of(data->handle) != NULL before using it.
> 
> [1] 
> https://syzkaller.appspot.com/bug?id=828a3c71bd344a6de8b6a31233d51a72099f27fd
> 
> Signed-off-by: Tetsuo Handa 
> Reported-by: syzbot 
> Cc: Rafael J. Wysocki 
> Cc: Len Brown 
> Cc: Pavel Machek 
> ---
>  kernel/power/user.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/kernel/power/user.c b/kernel/power/user.c
> index 75c959d..abd2255 100644
> --- a/kernel/power/user.c
> +++ b/kernel/power/user.c
> @@ -186,6 +186,11 @@ static ssize_t snapshot_write(struct file *filp, const 
> char __user *buf,
>   res = PAGE_SIZE - pg_offp;
>   }
>  
> + if (!data_of(data->handle)) {
> + res = -EINVAL;
> + goto unlock;
> + }
> +
>   res = simple_write_to_buffer(data_of(data->handle), res, &pg_offp,
>   buf, count);
>   if (res > 0)
> 

Applied, thanks!

[PATCH 4.14 341/496] IB/rxe: Fix for oops in rxe_register_device on ppc64le arch

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Mikhail Malygin 

[ Upstream commit efc365e7290d040fbd43f60b0e97653489a739d4 ]

On ppc64le arch rxe_add command causes oops in kernel log:

[   92.495140] Oops: Kernel access of bad area, sig: 11 [#1]
[   92.499710] SMP NR_CPUS=2048 NUMA pSeries
[   92.499792] Modules linked in: ipt_MASQUERADE(E) nf_nat_masquerade_ipv4(E) 
nf_conntrack_netlink(E) nfnetlink(E) xfrm_user(E) iptable
_nat(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_nat_ipv4(E) xt_addrtype(E) 
iptable_filter(E) ip_tables(E) xt_conntrack(E) x_tables(E)
 nf_nat(E) nf_conntrack(E) br_netfilter(E) bridge(E) stp(E) llc(E) overlay(E) 
af_packet(E) rpcrdma(E) ib_isert(E) iscsi_target_mod(E) i
b_iser(E) libiscsi(E) ib_srpt(E) target_core_mod(E) ib_srp(E) ib_ipoib(E) 
rdma_ucm(E) ib_ucm(E) ib_uverbs(E) ib_umad(E) bochs_drm(E) tt
m(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) 
fb_sys_fops(E) drm(E) agpgart(E) virtio_rng(E) virtio_console(E) rtc_
generic(E) dm_ec(OEN) ttln_rdma(OEN) rdma_cm(E) configfs(E) iw_cm(E) ib_cm(E) 
rdma_rxe(E) ip6_udp_tunnel(E) udp_tunnel(E) ib_core(E) ql
a2xxx(E)
[   92.499832]  scsi_transport_fc(E) nvme_fc(E) nvme_fabrics(E) nvme_core(E) 
ipmi_watchdog(E) ipmi_ssif(E) ipmi_poweroff(E) ipmi_powernv(EX) ipmi_devintf(E) 
ipmi_msghandler(E) dummy(E) ext4(E) crc16(E) jbd2(E) mbcache(E) 
dm_service_time(E) scsi_transport_iscsi(E) sd_mod(E) sr_mod(E) cdrom(E) 
hid_generic(E) usbhid(E) virtio_blk(E) virtio_scsi(E) virtio_net(E) 
ibmvscsi(EX) scsi_transport_srp(E) xhci_pci(E) xhci_hcd(E) usbcore(E) 
usb_common(E) virtio_pci(E) virtio_ring(E) virtio(E) sunrpc(E) dm_mirror(E) 
dm_region_hash(E) dm_log(E) sg(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) 
scsi_dh_emc(E) scsi_dh_alua(E) scsi_mod(E) autofs4(E)
[   92.499834] Supported: No, Unsupported modules are loaded
[   92.499839] CPU: 3 PID: 5576 Comm: sh Tainted: G   OE   NX 
4.4.120-ttln.17-default #1
[   92.499841] task: c000afe8a490 ti: c000beba8000 task.ti: 
c000beba8000
[   92.499842] NIP: c008ba3c LR: c0027644 CTR: c008ba10
[   92.499844] REGS: c000bebab750 TRAP: 0300   Tainted: G   OE   NX 
 (4.4.120-ttln.17-default)
[   92.499850] MSR: 80009033   CR: 28424428  XER: 
2000
[   92.499871] CFAR: 2424 DAR: 0208 DSISR: 4000 
SOFTE: 1
   GPR00: c0027644 c000bebab9d0 c0f09700 

   GPR04: d43d7192 0002 001a 
fffe
   GPR08: 009c c008ba10 d43e5848 
d43d3828
   GPR12: c008ba10 c7a02400 10062e38 
010020388860
   GPR16:   0100203885f0 
100f6c98
   GPR20: c000b3f1fcc0 c000b3f1fc48 c000b3f1fbd0 
c000b3f1fb58
   GPR24: c000b3f1fae0 c000b3f1fa68 05dc 
c000b3f1f9f0
   GPR28: d43e5848 c000b3f1f900 c000b3f1f320 
c000b3f1f000
[   92.499881] NIP [c008ba3c] dma_get_required_mask_pSeriesLP+0x2c/0x1a0
[   92.499885] LR [c0027644] dma_get_required_mask+0x44/0xac
[   92.499886] Call Trace:
[   92.499891] [c000bebab9d0] [c000bebaba30] 0xc000bebaba30 
(unreliable)
[   92.499894] [c000bebaba10] [c0027644] 
dma_get_required_mask+0x44/0xac
[   92.499904] [c000bebaba30] [d43cb4b4] 
rxe_register_device+0xc4/0x430 [rdma_rxe]
[   92.499910] [c000bebabab0] [d43c06c8] rxe_add+0x448/0x4e0 
[rdma_rxe]
[   92.499915] [c000bebabb30] [d43d28dc] rxe_net_add+0x4c/0xf0 
[rdma_rxe]
[   92.499921] [c000bebabb60] [d43d305c] 
rxe_param_set_add+0x6c/0x1ac [rdma_rxe]
[   92.499924] [c000bebabbf0] [c00e78c0] param_attr_store+0xa0/0x180
[   92.499927] [c000bebabc70] [c00e6448] module_attr_store+0x48/0x70
[   92.499932] [c000bebabc90] [c0391f60] sysfs_kf_write+0x70/0xb0
[   92.499935] [c000bebabcb0] [c0390f1c] 
kernfs_fop_write+0x18c/0x1e0
[   92.499939] [c000bebabd00] [c02e22ac] __vfs_write+0x4c/0x1d0
[   92.499942] [c000bebabd90] [c02e2f94] vfs_write+0xc4/0x200
[   92.499945] [c000bebabde0] [c02e488c] SyS_write+0x6c/0x110
[   92.499948] [c000bebabe30] [c0009384] system_call+0x38/0xe4
[   92.499949] Instruction dump:
[   92.499954] 4e800020 3c4c00e8 3842dcf0 7c0802a6 f8010010 6000 7c0802a6 
fba1ffe8
[   92.499958] fbc1fff0 fbe1fff8 f8010010 f821ffc1  7c7e1b78 2fa9 
419e0078
[   92.499962] ---[ end trace bed077e15eb420cf ]---

It fails in dma_get_required_mask, that has ppc-specific implementation,
and fail if provided device argument is NULL

Signed-off-by: Mikhail Malygin 
Reviewed-by: Yonatan Cohen 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah

[PATCH 4.16 074/272] IB/rxe: Fix for oops in rxe_register_device on ppc64le arch

[Greg Kroah-Hartman]

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Mikhail Malygin 

[ Upstream commit efc365e7290d040fbd43f60b0e97653489a739d4 ]

On ppc64le arch rxe_add command causes oops in kernel log:

[   92.495140] Oops: Kernel access of bad area, sig: 11 [#1]
[   92.499710] SMP NR_CPUS=2048 NUMA pSeries
[   92.499792] Modules linked in: ipt_MASQUERADE(E) nf_nat_masquerade_ipv4(E) 
nf_conntrack_netlink(E) nfnetlink(E) xfrm_user(E) iptable
_nat(E) nf_conntrack_ipv4(E) nf_defrag_ipv4(E) nf_nat_ipv4(E) xt_addrtype(E) 
iptable_filter(E) ip_tables(E) xt_conntrack(E) x_tables(E)
 nf_nat(E) nf_conntrack(E) br_netfilter(E) bridge(E) stp(E) llc(E) overlay(E) 
af_packet(E) rpcrdma(E) ib_isert(E) iscsi_target_mod(E) i
b_iser(E) libiscsi(E) ib_srpt(E) target_core_mod(E) ib_srp(E) ib_ipoib(E) 
rdma_ucm(E) ib_ucm(E) ib_uverbs(E) ib_umad(E) bochs_drm(E) tt
m(E) drm_kms_helper(E) syscopyarea(E) sysfillrect(E) sysimgblt(E) 
fb_sys_fops(E) drm(E) agpgart(E) virtio_rng(E) virtio_console(E) rtc_
generic(E) dm_ec(OEN) ttln_rdma(OEN) rdma_cm(E) configfs(E) iw_cm(E) ib_cm(E) 
rdma_rxe(E) ip6_udp_tunnel(E) udp_tunnel(E) ib_core(E) ql
a2xxx(E)
[   92.499832]  scsi_transport_fc(E) nvme_fc(E) nvme_fabrics(E) nvme_core(E) 
ipmi_watchdog(E) ipmi_ssif(E) ipmi_poweroff(E) ipmi_powernv(EX) ipmi_devintf(E) 
ipmi_msghandler(E) dummy(E) ext4(E) crc16(E) jbd2(E) mbcache(E) 
dm_service_time(E) scsi_transport_iscsi(E) sd_mod(E) sr_mod(E) cdrom(E) 
hid_generic(E) usbhid(E) virtio_blk(E) virtio_scsi(E) virtio_net(E) 
ibmvscsi(EX) scsi_transport_srp(E) xhci_pci(E) xhci_hcd(E) usbcore(E) 
usb_common(E) virtio_pci(E) virtio_ring(E) virtio(E) sunrpc(E) dm_mirror(E) 
dm_region_hash(E) dm_log(E) sg(E) dm_multipath(E) dm_mod(E) scsi_dh_rdac(E) 
scsi_dh_emc(E) scsi_dh_alua(E) scsi_mod(E) autofs4(E)
[   92.499834] Supported: No, Unsupported modules are loaded
[   92.499839] CPU: 3 PID: 5576 Comm: sh Tainted: G   OE   NX 
4.4.120-ttln.17-default #1
[   92.499841] task: c000afe8a490 ti: c000beba8000 task.ti: 
c000beba8000
[   92.499842] NIP: c008ba3c LR: c0027644 CTR: c008ba10
[   92.499844] REGS: c000bebab750 TRAP: 0300   Tainted: G   OE   NX 
 (4.4.120-ttln.17-default)
[   92.499850] MSR: 80009033   CR: 28424428  XER: 
2000
[   92.499871] CFAR: 2424 DAR: 0208 DSISR: 4000 
SOFTE: 1
   GPR00: c0027644 c000bebab9d0 c0f09700 

   GPR04: d43d7192 0002 001a 
fffe
   GPR08: 009c c008ba10 d43e5848 
d43d3828
   GPR12: c008ba10 c7a02400 10062e38 
010020388860
   GPR16:   0100203885f0 
100f6c98
   GPR20: c000b3f1fcc0 c000b3f1fc48 c000b3f1fbd0 
c000b3f1fb58
   GPR24: c000b3f1fae0 c000b3f1fa68 05dc 
c000b3f1f9f0
   GPR28: d43e5848 c000b3f1f900 c000b3f1f320 
c000b3f1f000
[   92.499881] NIP [c008ba3c] dma_get_required_mask_pSeriesLP+0x2c/0x1a0
[   92.499885] LR [c0027644] dma_get_required_mask+0x44/0xac
[   92.499886] Call Trace:
[   92.499891] [c000bebab9d0] [c000bebaba30] 0xc000bebaba30 
(unreliable)
[   92.499894] [c000bebaba10] [c0027644] 
dma_get_required_mask+0x44/0xac
[   92.499904] [c000bebaba30] [d43cb4b4] 
rxe_register_device+0xc4/0x430 [rdma_rxe]
[   92.499910] [c000bebabab0] [d43c06c8] rxe_add+0x448/0x4e0 
[rdma_rxe]
[   92.499915] [c000bebabb30] [d43d28dc] rxe_net_add+0x4c/0xf0 
[rdma_rxe]
[   92.499921] [c000bebabb60] [d43d305c] 
rxe_param_set_add+0x6c/0x1ac [rdma_rxe]
[   92.499924] [c000bebabbf0] [c00e78c0] param_attr_store+0xa0/0x180
[   92.499927] [c000bebabc70] [c00e6448] module_attr_store+0x48/0x70
[   92.499932] [c000bebabc90] [c0391f60] sysfs_kf_write+0x70/0xb0
[   92.499935] [c000bebabcb0] [c0390f1c] 
kernfs_fop_write+0x18c/0x1e0
[   92.499939] [c000bebabd00] [c02e22ac] __vfs_write+0x4c/0x1d0
[   92.499942] [c000bebabd90] [c02e2f94] vfs_write+0xc4/0x200
[   92.499945] [c000bebabde0] [c02e488c] SyS_write+0x6c/0x110
[   92.499948] [c000bebabe30] [c0009384] system_call+0x38/0xe4
[   92.499949] Instruction dump:
[   92.499954] 4e800020 3c4c00e8 3842dcf0 7c0802a6 f8010010 6000 7c0802a6 
fba1ffe8
[   92.499958] fbc1fff0 fbe1fff8 f8010010 f821ffc1  7c7e1b78 2fa9 
419e0078
[   92.499962] ---[ end trace bed077e15eb420cf ]---

It fails in dma_get_required_mask, that has ppc-specific implementation,
and fail if provided device argument is NULL

Signed-off-by: Mikhail Malygin 
Reviewed-by: Yonatan Cohen 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah

[PATCH 4.14 078/496] IB/uverbs: Fix possible oops with duplicate ioctl attributes

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Matan Barak 

[ Upstream commit 4d39a959bc1f3d164b5a54147fdeb19f84b1ed58 ]

If the same attribute is listed twice by the user in the ioctl attribute
list then error unwind can cause the kernel to deref garbage.

This happens when an object with WRITE access is sent twice. The second
parse properly fails but corrupts the state required for the error unwind
it triggers.

Fixing this by making duplicates in the attribute list invalid. This is
not something we need to support.

The ioctl interface is currently recommended to be disabled in kConfig.

Signed-off-by: Matan Barak 
Signed-off-by: Leon Romanovsky 
Signed-off-by: Jason Gunthorpe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/infiniband/core/uverbs_ioctl.c |3 +++
 1 file changed, 3 insertions(+)

--- a/drivers/infiniband/core/uverbs_ioctl.c
+++ b/drivers/infiniband/core/uverbs_ioctl.c
@@ -59,6 +59,9 @@ static int uverbs_process_attr(struct ib
return 0;
}
 
+   if (test_bit(attr_id, attr_bundle_h->valid_bitmap))
+   return -EINVAL;
+
spec = &attr_spec_bucket->attrs[attr_id];
e = &elements[attr_id];
e->uattr = uattr_ptr;

Re: [PATCH] bdi: Fix another oops in wb_workfn()

[Tejun Heo]

On Sun, May 27, 2018 at 11:21:25AM +0900, Tetsuo Handa wrote:
> From 8a8222698163d1fe180258566e9a3ff43f54fcd9 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa 
> Date: Sun, 27 May 2018 11:08:20 +0900
> Subject: [PATCH] bdi: Fix another oops in wb_workfn()
> 
> syzbot is still hitting NULL pointer dereference at wb_workfn() [1].
> This might be because we overlooked that delayed_work_timer_fn() does not
> check WB_registered before calling __queue_work() while mod_delayed_work()
> does not wait for already started delayed_work_timer_fn() because it uses
> del_timer() rather than del_timer_sync().

It shouldn't be that as dwork timer is an irq safe timer.  Even if
that's the case, the right thing to do would be fixing workqueue
rather than reaching into workqueue internals from backing-dev code.

Thanks.

-- 
tejun

[PATCH] bdi: Fix another oops in wb_workfn()

[Tetsuo Handa]

>From 8a8222698163d1fe180258566e9a3ff43f54fcd9 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa 
Date: Sun, 27 May 2018 11:08:20 +0900
Subject: [PATCH] bdi: Fix another oops in wb_workfn()

syzbot is still hitting NULL pointer dereference at wb_workfn() [1].
This might be because we overlooked that delayed_work_timer_fn() does not
check WB_registered before calling __queue_work() while mod_delayed_work()
does not wait for already started delayed_work_timer_fn() because it uses
del_timer() rather than del_timer_sync().

Make wb_shutdown() be careful about wb_wakeup_delayed() path.

[1] 
https://syzkaller.appspot.com/bug?id=e0818ccb7e46190b3f1038b0c794299208ed4206

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Cc: Tejun Heo 
Cc: Dave Chinner 
Cc: Jan Kara 
Cc: Jens Axboe 
---
 mm/backing-dev.c | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/mm/backing-dev.c b/mm/backing-dev.c
index 7441bd9..31e1d7e 100644
--- a/mm/backing-dev.c
+++ b/mm/backing-dev.c
@@ -372,11 +372,24 @@ static void wb_shutdown(struct bdi_writeback *wb)
 
cgwb_remove_from_bdi_list(wb);
/*
+* mod_delayed_work() is not appropriate here, for
+* delayed_work_timer_fn() from wb_wakeup_delayed() does not check
+* WB_registered before calling __queue_work().
+*/
+   del_timer_sync(&wb->dwork.timer);
+   /*
+* Clear WORK_STRUCT_PENDING_BIT in order to make sure that next
+* queue_delayed_work() actually enqueues this work to the tail, for
+* wb_wakeup_delayed() already set WORK_STRUCT_PENDING_BIT before
+* scheduling delayed_work_timer_fn().
+*/
+   cancel_delayed_work_sync(&wb->dwork);
+   /*
 * Drain work list and shutdown the delayed_work.  !WB_registered
 * tells wb_workfn() that @wb is dying and its work_list needs to
 * be drained no matter what.
 */
-   mod_delayed_work(bdi_wq, &wb->dwork, 0);
+   queue_delayed_work(bdi_wq, &wb->dwork, 0);
flush_delayed_work(&wb->dwork);
WARN_ON(!list_empty(&wb->work_list));
/*
-- 
1.8.3.1

[PATCH] PM / hibernate: Fix oops at snapshot_write().

[Tetsuo Handa]

syzbot is reporting NULL pointer dereference at snapshot_write() [1].
This is because data->handle is zero-cleared by ioctl(SNAPSHOT_FREE).
Fix this by checking data_of(data->handle) != NULL before using it.

[1] 
https://syzkaller.appspot.com/bug?id=828a3c71bd344a6de8b6a31233d51a72099f27fd

Signed-off-by: Tetsuo Handa 
Reported-by: syzbot 
Cc: Rafael J. Wysocki 
Cc: Len Brown 
Cc: Pavel Machek 
---
 kernel/power/user.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/kernel/power/user.c b/kernel/power/user.c
index 75c959d..abd2255 100644
--- a/kernel/power/user.c
+++ b/kernel/power/user.c
@@ -186,6 +186,11 @@ static ssize_t snapshot_write(struct file *filp, const 
char __user *buf,
res = PAGE_SIZE - pg_offp;
}
 
+   if (!data_of(data->handle)) {
+   res = -EINVAL;
+   goto unlock;
+   }
+
res = simple_write_to_buffer(data_of(data->handle), res, &pg_offp,
buf, count);
if (res > 0)
-- 
1.8.3.1

Re: [PATCH v2 0/2] uio: Prevent kernel oops on UIO device remove with open fds

[Greg KH]

On Mon, May 14, 2018 at 01:32:21PM +1200, Hamish Martin wrote:
> If a UIO device is removed while a user space app has an open file 
> descriptor to that device's /dev/uio* file, a kernel oops can occur when
> the file descriptor is ultimately closed. The oops is triggered by
> dereferencing either the uio_listener struct's 'dev' pointer, or at the
> next level, when dereferencing a stale 'info' pointer on that dev.
> 
> To resolve this we now increment the reference count for the uio_device
> and prevent the destruction of the uio_device until all open file
> descriptors are closed.
> A further consequence of resolving the stale pointers to the uio_device
> is that it exposes an issue with the independent life cycles of the 
> uio_device and its related uio_info. The uio_info struct is allocated by
> the user of the uio subsystem and connected to a uio_device at 
> registration time (see __uio_register_device()). When the device
> corresponding to that uio_info is unregistered and the memory for the 
> uio_info is freed, the uio_device is left with a stale pointer which may
> still be used in the file system ops (uio_poll(), uio_read(), etc)
> To resolve this second issue, we now lock alteration or access of the
> 'info' member of the uio_device struct and alter the accessing code to 
> handle that pointer being null.
> 
> This patch series contains two patches. The first is a cosmetic change
> to the return paths from uio_write to facilitate easier review of the 
> second patch. The second patch contains the change to prevent destruction
> of the uio_device while file descriptors to it remain open and the
> additional locking to prevent the use of a stale 'info' pointer.
> 
> This patch series is heavily based on the work done by Brian Russell
> (formerly of Brocade) in May 2015. His last version of an attempt to fix
> this is seen here:
> https://patchwork.kernel.org/patch/6057431/
> My new addition is the locking around use of the info pointer. It is my
> proposed solution to Brian's last comment about what he had left
> unfinished: 
> "It needs a bit more work. uio_info needs to live as long as the 
>  corresponding uio_device. Since they seem to always be 1:1, 
>  uio_info could embedded within uio_device (but then all the users
>  of uio need changed) or uio_info could be a refcounted object."
> 
> For further info here is an example of the kernel oops this patch series
> is trying to resolve. Output is from a 4.17.0-rc1 kernel with a test app
> opening a uio device and doing select with the fd, then removing the UIO
> device while the select is still happening:
> 
> Unable to handle kernel paging request for data at address 0x6b6b6b6b6b6b6d63
> Faulting instruction address: 0xc0605c98
> Oops: Kernel access of bad area, sig: 11 [#1]
> BE PREEMPT SMP NR_CPUS=8 CoreNet Generic
> Modules linked in:
> CPU: 6 PID: 282 Comm: uio_tester Not tainted 4.17.0-rc1-at1+ #8
> NIP:  c0605c98 LR: c0211d8c CTR: c0605c60
> REGS: c000f02f3480 TRAP: 0300   Not tainted  (4.17.0-rc1-at1+)
> MSR:  8202b000   CR: 24284448  XER: 2000
> DEAR: 6b6b6b6b6b6b6d63 ESR:  SOFTE: 0 
> GPR00: c0211d8c c000f02f3700 c0dc7d00 c000ef365bc0 
> GPR04: c000f02f3800  c000ef4b9b58 0006 
> GPR08: c0605c60 6b6b6b6b6b6b6b6b  0016 
> GPR12: 42284448 c0003fffd440 0004 0003 
> GPR16: 0008  ef365bc0  
> GPR20: c000f02f3c00   c000ef365bc0 
> GPR24:     
> GPR28: c000f02f3800 c000ef365bc0 c000f02c2c68 c000efd01d20 
> NIP [c0605c98] .uio_poll+0x38/0xe0
> LR [c0211d8c] .do_select+0x39c/0x7a0
> Call Trace:
> [c000f02f3700] [c000f02f3790] 0xc000f02f3790 (unreliable)
> [c000f02f3790] [c0211d8c] .do_select+0x39c/0x7a0
> [c000f02f3b90] [c0212eac] .core_sys_select+0x22c/0x320
> [c000f02f3d70] [c0213098] .__se_sys_select+0xf8/0x170
> [c000f02f3e30] [c674] system_call+0x58/0x64
> Instruction dump:
> f8010010 fba1ffe8 fbc1fff0 fbe1fff8 f821ff71 7c7d1b78 7c9c2378 6000 
> 6000 ebdd00c0 ebfe e93f0038  2fa9 40de0030 3c60 
> ---[ end trace 8badf75b83f45856 ]---


Very nice work, thanks for doing this.  I've now queued it up.

greg k-h

[PATCH 4.4 41/56] bdi: Fix oops in wb_workfn()

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara 

commit b8b784958eccbf8f51ebeee65282ca3fd59ea391 upstream.

Syzbot has reported that it can hit a NULL pointer dereference in
wb_workfn() due to wb->bdi->dev being NULL. This indicates that
wb_workfn() was called for an already unregistered bdi which should not
happen as wb_shutdown() called from bdi_unregister() should make sure
all pending writeback works are completed before bdi is unregistered.
Except that wb_workfn() itself can requeue the work with:

mod_delayed_work(bdi_wq, &wb->dwork, 0);

and if this happens while wb_shutdown() is waiting in:

flush_delayed_work(&wb->dwork);

the dwork can get executed after wb_shutdown() has finished and
bdi_unregister() has cleared wb->bdi->dev.

Make wb_workfn() use wakeup_wb() for requeueing the work which takes all
the necessary precautions against racing with bdi unregistration.

CC: Tetsuo Handa 
CC: Tejun Heo 
Fixes: 839a8e8660b6777e7fe4e80af1a048aebe2b5977
Reported-by: syzbot 
Reviewed-by: Dave Chinner 
Signed-off-by: Jan Kara 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/fs-writeback.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -1906,7 +1906,7 @@ void wb_workfn(struct work_struct *work)
}
 
if (!list_empty(&wb->work_list))
-   mod_delayed_work(bdi_wq, &wb->dwork, 0);
+   wb_wakeup(wb);
else if (wb_has_dirty_io(wb) && dirty_writeback_interval)
wb_wakeup_delayed(wb);
 

[PATCH 4.9 13/36] bdi: Fix oops in wb_workfn()

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara 

commit b8b784958eccbf8f51ebeee65282ca3fd59ea391 upstream.

Syzbot has reported that it can hit a NULL pointer dereference in
wb_workfn() due to wb->bdi->dev being NULL. This indicates that
wb_workfn() was called for an already unregistered bdi which should not
happen as wb_shutdown() called from bdi_unregister() should make sure
all pending writeback works are completed before bdi is unregistered.
Except that wb_workfn() itself can requeue the work with:

mod_delayed_work(bdi_wq, &wb->dwork, 0);

and if this happens while wb_shutdown() is waiting in:

flush_delayed_work(&wb->dwork);

the dwork can get executed after wb_shutdown() has finished and
bdi_unregister() has cleared wb->bdi->dev.

Make wb_workfn() use wakeup_wb() for requeueing the work which takes all
the necessary precautions against racing with bdi unregistration.

CC: Tetsuo Handa 
CC: Tejun Heo 
Fixes: 839a8e8660b6777e7fe4e80af1a048aebe2b5977
Reported-by: syzbot 
Reviewed-by: Dave Chinner 
Signed-off-by: Jan Kara 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/fs-writeback.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -1942,7 +1942,7 @@ void wb_workfn(struct work_struct *work)
}
 
if (!list_empty(&wb->work_list))
-   mod_delayed_work(bdi_wq, &wb->dwork, 0);
+   wb_wakeup(wb);
else if (wb_has_dirty_io(wb) && dirty_writeback_interval)
wb_wakeup_delayed(wb);
 

[PATCH 4.14 17/62] bdi: Fix oops in wb_workfn()

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara 

commit b8b784958eccbf8f51ebeee65282ca3fd59ea391 upstream.

Syzbot has reported that it can hit a NULL pointer dereference in
wb_workfn() due to wb->bdi->dev being NULL. This indicates that
wb_workfn() was called for an already unregistered bdi which should not
happen as wb_shutdown() called from bdi_unregister() should make sure
all pending writeback works are completed before bdi is unregistered.
Except that wb_workfn() itself can requeue the work with:

mod_delayed_work(bdi_wq, &wb->dwork, 0);

and if this happens while wb_shutdown() is waiting in:

flush_delayed_work(&wb->dwork);

the dwork can get executed after wb_shutdown() has finished and
bdi_unregister() has cleared wb->bdi->dev.

Make wb_workfn() use wakeup_wb() for requeueing the work which takes all
the necessary precautions against racing with bdi unregistration.

CC: Tetsuo Handa 
CC: Tejun Heo 
Fixes: 839a8e8660b6777e7fe4e80af1a048aebe2b5977
Reported-by: syzbot 
Reviewed-by: Dave Chinner 
Signed-off-by: Jan Kara 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/fs-writeback.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -1940,7 +1940,7 @@ void wb_workfn(struct work_struct *work)
}
 
if (!list_empty(&wb->work_list))
-   mod_delayed_work(bdi_wq, &wb->dwork, 0);
+   wb_wakeup(wb);
else if (wb_has_dirty_io(wb) && dirty_writeback_interval)
wb_wakeup_delayed(wb);
 

[PATCH 4.16 22/72] bdi: Fix oops in wb_workfn()

[Greg Kroah-Hartman]

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Jan Kara 

commit b8b784958eccbf8f51ebeee65282ca3fd59ea391 upstream.

Syzbot has reported that it can hit a NULL pointer dereference in
wb_workfn() due to wb->bdi->dev being NULL. This indicates that
wb_workfn() was called for an already unregistered bdi which should not
happen as wb_shutdown() called from bdi_unregister() should make sure
all pending writeback works are completed before bdi is unregistered.
Except that wb_workfn() itself can requeue the work with:

mod_delayed_work(bdi_wq, &wb->dwork, 0);

and if this happens while wb_shutdown() is waiting in:

flush_delayed_work(&wb->dwork);

the dwork can get executed after wb_shutdown() has finished and
bdi_unregister() has cleared wb->bdi->dev.

Make wb_workfn() use wakeup_wb() for requeueing the work which takes all
the necessary precautions against racing with bdi unregistration.

CC: Tetsuo Handa 
CC: Tejun Heo 
Fixes: 839a8e8660b6777e7fe4e80af1a048aebe2b5977
Reported-by: syzbot 
Reviewed-by: Dave Chinner 
Signed-off-by: Jan Kara 
Signed-off-by: Jens Axboe 
Signed-off-by: Greg Kroah-Hartman 

---
 fs/fs-writeback.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@ -1961,7 +1961,7 @@ void wb_workfn(struct work_struct *work)
}
 
if (!list_empty(&wb->work_list))
-   mod_delayed_work(bdi_wq, &wb->dwork, 0);
+   wb_wakeup(wb);
else if (wb_has_dirty_io(wb) && dirty_writeback_interval)
wb_wakeup_delayed(wb);
 

[PATCH v2 0/2] uio: Prevent kernel oops on UIO device remove with open fds

[Hamish Martin]

If a UIO device is removed while a user space app has an open file 
descriptor to that device's /dev/uio* file, a kernel oops can occur when
the file descriptor is ultimately closed. The oops is triggered by
dereferencing either the uio_listener struct's 'dev' pointer, or at the
next level, when dereferencing a stale 'info' pointer on that dev.

To resolve this we now increment the reference count for the uio_device
and prevent the destruction of the uio_device until all open file
descriptors are closed.
A further consequence of resolving the stale pointers to the uio_device
is that it exposes an issue with the independent life cycles of the 
uio_device and its related uio_info. The uio_info struct is allocated by
the user of the uio subsystem and connected to a uio_device at 
registration time (see __uio_register_device()). When the device
corresponding to that uio_info is unregistered and the memory for the 
uio_info is freed, the uio_device is left with a stale pointer which may
still be used in the file system ops (uio_poll(), uio_read(), etc)
To resolve this second issue, we now lock alteration or access of the
'info' member of the uio_device struct and alter the accessing code to 
handle that pointer being null.

This patch series contains two patches. The first is a cosmetic change
to the return paths from uio_write to facilitate easier review of the 
second patch. The second patch contains the change to prevent destruction
of the uio_device while file descriptors to it remain open and the
additional locking to prevent the use of a stale 'info' pointer.

This patch series is heavily based on the work done by Brian Russell
(formerly of Brocade) in May 2015. His last version of an attempt to fix
this is seen here:
https://patchwork.kernel.org/patch/6057431/
My new addition is the locking around use of the info pointer. It is my
proposed solution to Brian's last comment about what he had left
unfinished: 
"It needs a bit more work. uio_info needs to live as long as the 
 corresponding uio_device. Since they seem to always be 1:1, 
 uio_info could embedded within uio_device (but then all the users
 of uio need changed) or uio_info could be a refcounted object."

For further info here is an example of the kernel oops this patch series
is trying to resolve. Output is from a 4.17.0-rc1 kernel with a test app
opening a uio device and doing select with the fd, then removing the UIO
device while the select is still happening:

Unable to handle kernel paging request for data at address 0x6b6b6b6b6b6b6d63
Faulting instruction address: 0xc0605c98
Oops: Kernel access of bad area, sig: 11 [#1]
BE PREEMPT SMP NR_CPUS=8 CoreNet Generic
Modules linked in:
CPU: 6 PID: 282 Comm: uio_tester Not tainted 4.17.0-rc1-at1+ #8
NIP:  c0605c98 LR: c0211d8c CTR: c0605c60
REGS: c000f02f3480 TRAP: 0300   Not tainted  (4.17.0-rc1-at1+)
MSR:  8202b000   CR: 24284448  XER: 2000
DEAR: 6b6b6b6b6b6b6d63 ESR:  SOFTE: 0 
GPR00: c0211d8c c000f02f3700 c0dc7d00 c000ef365bc0 
GPR04: c000f02f3800  c000ef4b9b58 0006 
GPR08: c0605c60 6b6b6b6b6b6b6b6b  0016 
GPR12: 42284448 c0003fffd440 0004 0003 
GPR16: 0008  ef365bc0  
GPR20: c000f02f3c00   c000ef365bc0 
GPR24:     
GPR28: c000f02f3800 c000ef365bc0 c000f02c2c68 c000efd01d20 
NIP [c0605c98] .uio_poll+0x38/0xe0
LR [c0211d8c] .do_select+0x39c/0x7a0
Call Trace:
[c000f02f3700] [c000f02f3790] 0xc000f02f3790 (unreliable)
[c000f02f3790] [c0211d8c] .do_select+0x39c/0x7a0
[c000f02f3b90] [c0212eac] .core_sys_select+0x22c/0x320
[c000f02f3d70] [c0213098] .__se_sys_select+0xf8/0x170
[c000f02f3e30] [c674] system_call+0x58/0x64
Instruction dump:
f8010010 fba1ffe8 fbc1fff0 fbe1fff8 f821ff71 7c7d1b78 7c9c2378 6000 
6000 ebdd00c0 ebfe e93f0038  2fa9 40de0030 3c60 
---[ end trace 8badf75b83f45856 ]---

Hamish Martin (2):
  uio: Reduce return paths from uio_write()
  uio: Prevent device destruction while fds are open

 drivers/uio/uio.c  | 121 -
 include/linux/uio_driver.h |   4 +-
 2 files changed, 91 insertions(+), 34 deletions(-)

-- 
2.16.2

[PATCH 0/2] Prevent kernel oops on UIO device remove with open fds

[Hamish Martin]

If a UIO device is removed while a user space app has an open file 
descriptor to that device's /dev/uio* file, a kernel oops can occur when
the file descriptor is ultimately closed. The oops is triggered by
dereferencing either the uio_listener struct's 'dev' pointer, or at the
next level, when dereferencing a stale 'info' pointer on that dev.

To resolve this we now increment the reference count for the uio_device
and prevent the destruction of the uio_device until all open file
descriptors are closed.
A further consequence of resolving the stale pointers to the uio_device
is that it exposes an issue with the independent life cycles of the 
uio_device and its related uio_info. The uio_info struct is allocated by
the user of the uio subsystem and connected to a uio_device at 
registration time (see __uio_register_device()). When the device
corresponding to that uio_info is unregistered and the memory for the 
uio_info is freed, the uio_device is left with a stale pointer which may
still be used in the file system ops (uio_poll(), uio_read(), etc)
To resolve this second issue, we now lock alteration or access of the
'info' member of the uio_device struct and alter the accessing code to 
handle that pointer being null.

This patch series contains two patches. The first is a cosmetic change
to the return paths from uio_write to facilitate easier review of the 
second patch. The second patch contains the change to prevent destruction
of the uio_device while file descriptors to it remain open and the
additional locking to prevent the use of a stale 'info' pointer.

This patch series is heavily based on the work done by Brian Russell
(formerly of Brocade) in May 2015. His last version of an attempt to fix
this is seen here:
https://patchwork.kernel.org/patch/6057431/
My new addition is the locking around use of the info pointer. It is my
proposed solution to Brian's last comment about what he had left
unfinished: 
"It needs a bit more work. uio_info needs to live as long as the 
 corresponding uio_device. Since they seem to always be 1:1, 
 uio_info could embedded within uio_device (but then all the users
 of uio need changed) or uio_info could be a refcounted object."

For further info here is an example of the kernel oops this patch series
is trying to resolve. Output is from a 4.17.0-rc1 kernel with a test app
opening a uio device and doing select with the fd, then removing the UIO
device while the select is still happening:

Unable to handle kernel paging request for data at address 0x6b6b6b6b6b6b6d63
Faulting instruction address: 0xc0605c98
Oops: Kernel access of bad area, sig: 11 [#1]
BE PREEMPT SMP NR_CPUS=8 CoreNet Generic
Modules linked in:
CPU: 6 PID: 282 Comm: uio_tester Not tainted 4.17.0-rc1-at1+ #8
NIP:  c0605c98 LR: c0211d8c CTR: c0605c60
REGS: c000f02f3480 TRAP: 0300   Not tainted  (4.17.0-rc1-at1+)
MSR:  8202b000   CR: 24284448  XER: 2000
DEAR: 6b6b6b6b6b6b6d63 ESR:  SOFTE: 0 
GPR00: c0211d8c c000f02f3700 c0dc7d00 c000ef365bc0 
GPR04: c000f02f3800  c000ef4b9b58 0006 
GPR08: c0605c60 6b6b6b6b6b6b6b6b  0016 
GPR12: 42284448 c0003fffd440 0004 0003 
GPR16: 0008  ef365bc0  
GPR20: c000f02f3c00   c000ef365bc0 
GPR24:     
GPR28: c000f02f3800 c000ef365bc0 c000f02c2c68 c000efd01d20 
NIP [c0605c98] .uio_poll+0x38/0xe0
LR [c0211d8c] .do_select+0x39c/0x7a0
Call Trace:
[c000f02f3700] [c000f02f3790] 0xc000f02f3790 (unreliable)
[c000f02f3790] [c0211d8c] .do_select+0x39c/0x7a0
[c000f02f3b90] [c0212eac] .core_sys_select+0x22c/0x320
[c000f02f3d70] [c0213098] .__se_sys_select+0xf8/0x170
[c000f02f3e30] [c674] system_call+0x58/0x64
Instruction dump:
f8010010 fba1ffe8 fbc1fff0 fbe1fff8 f821ff71 7c7d1b78 7c9c2378 6000 
6000 ebdd00c0 ebfe e93f0038  2fa9 40de0030 3c60 
---[ end trace 8badf75b83f45856 ]---

Hamish Martin (2):
  uio: Reduce return paths from uio_write()
  uio: Prevent device destruction while fds are open

 drivers/uio/uio.c  | 121 -
 include/linux/uio_driver.h |   3 +-
 2 files changed, 90 insertions(+), 34 deletions(-)

-- 
2.16.2

Re: Oops on the system startup in the function part_in_flight()

[Jens Axboe]

On 5/4/18 6:35 PM, Ben Greear wrote:
> Hello,
> 
> I am trying to bisect a pktgen related performance regression that appears to
> be between the 4.13 and 4.14 kernels.  But, my system keeps crashing due to 
> part_in_flight
> oops so bisecting is not going well.
> 
> It looks like this oops was fixed, but the link to the patch in the email is 
> no longer
> valid.  Can someone let me know what patch fixes this crash so I can apply it 
> while
> bisecting?
> 
> https://www.spinics.net/lists/linux-block/msg17809.html

Should be this one:

http://git.kernel.dk/cgit/linux-block/commit/?h=for-linus&id=f5c156c4c29a3d87176dd6e5c099388e187ec29b

-- 
Jens Axboe

Re: Oops on the system startup in the function part_in_flight()

[Ben Greear]

Hello,

I am trying to bisect a pktgen related performance regression that appears to
be between the 4.13 and 4.14 kernels.  But, my system keeps crashing due to 
part_in_flight
oops so bisecting is not going well.

It looks like this oops was fixed, but the link to the patch in the email is no 
longer
valid.  Can someone let me know what patch fixes this crash so I can apply it 
while
bisecting?

https://www.spinics.net/lists/linux-block/msg17809.html

Thanks,
Ben

--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

Re: [PATCH] drm/vc4: Fix oops dereferencing DPI's connector since panel_bridge.

[Boris Brezillon]

On Fri,  9 Mar 2018 15:32:56 -0800
Eric Anholt  wrote:

> In the cleanup, I didn't notice that we needed to dereference the
> connector for the bus_format.  Fix the regression by looking up the
> first (and only) connector attached to us, and assume that its
> bus_format is what we want.  Some day it would be good to have that
> part of display_info attached to the bridge, instead.
> 
> Signed-off-by: Eric Anholt 
> Fixes: 7b1298e05310 ("drm/vc4: Switch DPI to using the panel-bridge helper.")
> Cc: Boris Brezillon 

Reviewed-by: Boris Brezillon 

> ---
>  drivers/gpu/drm/vc4/vc4_dpi.c | 27 +++
>  1 file changed, 23 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
> index 72c9dbd81d7f..88783e143cc2 100644
> --- a/drivers/gpu/drm/vc4/vc4_dpi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dpi.c
> @@ -96,7 +96,6 @@ struct vc4_dpi {
>   struct platform_device *pdev;
>  
>   struct drm_encoder *encoder;
> - struct drm_connector *connector;
>  
>   void __iomem *regs;
>  
> @@ -164,14 +163,31 @@ static void vc4_dpi_encoder_disable(struct drm_encoder 
> *encoder)
>  
>  static void vc4_dpi_encoder_enable(struct drm_encoder *encoder)
>  {
> + struct drm_device *dev = encoder->dev;
>   struct drm_display_mode *mode = &encoder->crtc->mode;
>   struct vc4_dpi_encoder *vc4_encoder = to_vc4_dpi_encoder(encoder);
>   struct vc4_dpi *dpi = vc4_encoder->dpi;
> + struct drm_connector_list_iter conn_iter;
> + struct drm_connector *connector = NULL, *connector_scan;
>   u32 dpi_c = DPI_ENABLE | DPI_OUTPUT_ENABLE_MODE;
>   int ret;
>  
> - if (dpi->connector->display_info.num_bus_formats) {
> - u32 bus_format = dpi->connector->display_info.bus_formats[0];
> + /* Look up the connector attached to DPI so we can get the
> +  * bus_format.  Ideally the bridge would tell us the
> +  * bus_format we want, but it doesn't yet, so assume that it's
> +  * uniform throughout the bridge chain.
> +  */
> + drm_connector_list_iter_begin(dev, &conn_iter);
> + drm_for_each_connector_iter(connector_scan, &conn_iter) {
> + if (connector_scan->encoder == encoder) {
> + connector = connector_scan;
> + break;
> + }
> + }
> + drm_connector_list_iter_end(&conn_iter);
> +
> + if (connector && connector->display_info.num_bus_formats) {
> + u32 bus_format = connector->display_info.bus_formats[0];
>  
>   switch (bus_format) {
>   case MEDIA_BUS_FMT_RGB888_1X24:
> @@ -199,6 +215,9 @@ static void vc4_dpi_encoder_enable(struct drm_encoder 
> *encoder)
>   DRM_ERROR("Unknown media bus format %d\n", bus_format);
>   break;
>   }
> + } else {
> + /* Default to 24bit if no connector found. */
> + dpi_c |= VC4_SET_FIELD(DPI_FORMAT_24BIT_888_RGB, DPI_FORMAT);
>   }
>  
>   if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> @@ -264,7 +283,7 @@ static int vc4_dpi_init_bridge(struct vc4_dpi *dpi)
>   return ret;
>   }
>  
> - if (panel)
> + if (panel) 
>   bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_DPI);
>  
>   return drm_bridge_attach(dpi->encoder, bridge, NULL);

Re: [PATCH] drm/vc4: Fix oops dereferencing DPI's connector since panel_bridge.

[Sean Paul]

On Fri, Mar 09, 2018 at 03:32:56PM -0800, Eric Anholt wrote:
> In the cleanup, I didn't notice that we needed to dereference the
> connector for the bus_format.  Fix the regression by looking up the
> first (and only) connector attached to us, and assume that its
> bus_format is what we want.  Some day it would be good to have that
> part of display_info attached to the bridge, instead.
> 
> Signed-off-by: Eric Anholt 
> Fixes: 7b1298e05310 ("drm/vc4: Switch DPI to using the panel-bridge helper.")
> Cc: Boris Brezillon 
> ---
>  drivers/gpu/drm/vc4/vc4_dpi.c | 27 +++
>  1 file changed, 23 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c b/drivers/gpu/drm/vc4/vc4_dpi.c
> index 72c9dbd81d7f..88783e143cc2 100644
> --- a/drivers/gpu/drm/vc4/vc4_dpi.c
> +++ b/drivers/gpu/drm/vc4/vc4_dpi.c
> @@ -96,7 +96,6 @@ struct vc4_dpi {
>   struct platform_device *pdev;
>  
>   struct drm_encoder *encoder;
> - struct drm_connector *connector;
>  
>   void __iomem *regs;
>  
> @@ -164,14 +163,31 @@ static void vc4_dpi_encoder_disable(struct drm_encoder 
> *encoder)
>  
>  static void vc4_dpi_encoder_enable(struct drm_encoder *encoder)
>  {
> + struct drm_device *dev = encoder->dev;
>   struct drm_display_mode *mode = &encoder->crtc->mode;
>   struct vc4_dpi_encoder *vc4_encoder = to_vc4_dpi_encoder(encoder);
>   struct vc4_dpi *dpi = vc4_encoder->dpi;
> + struct drm_connector_list_iter conn_iter;
> + struct drm_connector *connector = NULL, *connector_scan;
>   u32 dpi_c = DPI_ENABLE | DPI_OUTPUT_ENABLE_MODE;
>   int ret;
>  
> - if (dpi->connector->display_info.num_bus_formats) {
> - u32 bus_format = dpi->connector->display_info.bus_formats[0];
> + /* Look up the connector attached to DPI so we can get the
> +  * bus_format.  Ideally the bridge would tell us the
> +  * bus_format we want, but it doesn't yet, so assume that it's
> +  * uniform throughout the bridge chain.
> +  */
> + drm_connector_list_iter_begin(dev, &conn_iter);
> + drm_for_each_connector_iter(connector_scan, &conn_iter) {
> + if (connector_scan->encoder == encoder) {
> + connector = connector_scan;
> + break;
> + }
> + }
> + drm_connector_list_iter_end(&conn_iter);
> +
> + if (connector && connector->display_info.num_bus_formats) {
> + u32 bus_format = connector->display_info.bus_formats[0];
>  
>   switch (bus_format) {
>   case MEDIA_BUS_FMT_RGB888_1X24:
> @@ -199,6 +215,9 @@ static void vc4_dpi_encoder_enable(struct drm_encoder 
> *encoder)
>   DRM_ERROR("Unknown media bus format %d\n", bus_format);
>   break;
>   }
> + } else {
> + /* Default to 24bit if no connector found. */
> + dpi_c |= VC4_SET_FIELD(DPI_FORMAT_24BIT_888_RGB, DPI_FORMAT);
>   }
>  
>   if (mode->flags & DRM_MODE_FLAG_NHSYNC)
> @@ -264,7 +283,7 @@ static int vc4_dpi_init_bridge(struct vc4_dpi *dpi)
>   return ret;
>   }
>  
> - if (panel)
> + if (panel) 

whitespace creep, with that fixed:

Reviewed-by: Sean Paul 

>   bridge = drm_panel_bridge_add(panel, DRM_MODE_CONNECTOR_DPI);
>  
>   return drm_bridge_attach(dpi->encoder, bridge, NULL);
> -- 
> 2.16.2
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Sean Paul, Software Engineer, Google / Chromium OS

Re: [PATCH] drm/vc4: Fix oops dereferencing DPI's connector since panel_bridge.

[Eric Anholt]

Eric Anholt  writes:

> In the cleanup, I didn't notice that we needed to dereference the
> connector for the bus_format.  Fix the regression by looking up the
> first (and only) connector attached to us, and assume that its
> bus_format is what we want.  Some day it would be good to have that
> part of display_info attached to the bridge, instead.

Could anyone comment on this patch?


signature.asc
Description: PGP signature

[PATCH 4.16 014/113] xhci: Fix Kernel oops in xhci dbgtty

[Greg Kroah-Hartman]

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Zhengjun Xing 

commit 7fc65d4c2ba9e5006c629669146c6876b65aa233 upstream.

tty_unregister_driver may be called more than 1 time in some
hotplug cases,it will cause the kernel oops. This patch checked
dbc_tty_driver to make sure it is unregistered only 1 time.

[  175.741404] BUG: unable to handle kernel NULL pointer dereference at 
0034
[  175.742309] IP: tty_unregister_driver+0x9/0x70
[  175.743148] PGD 0 P4D 0
[  175.743981] Oops:  [#1] SMP PTI
[  175.753904] RIP: 0010:tty_unregister_driver+0x9/0x70
[  175.754817] RSP: 0018:a8ff831d3bb0 EFLAGS: 00010246
[  175.755753] RAX:  RBX:  RCX: 
[  175.756685] RDX: 92089c616000 RSI: e64fe1b26080 RDI: 
[  175.757608] RBP: 92086c988230 R08: 6c982701 R09: 0001801e0016
[  175.758533] R10: a8ff831d3b48 R11: 92086c982100 R12: 92086c98827c
[  175.759462] R13: 92086c988398 R14: 0060 R15: 92089c5e9b40
[  175.760401] FS:  () GS:9208a010() 
knlGS:
[  175.761334] CS:  0010 DS:  ES:  CR0: 80050033
[  175.762270] CR2: 0034 CR3: 00011800a003 CR4: 003606e0
[  175.763225] DR0:  DR1:  DR2: 
[  175.764164] DR3:  DR6: fffe0ff0 DR7: 0400
[  175.765091] Call Trace:
[  175.766014]  xhci_dbc_tty_unregister_driver+0x11/0x30
[  175.766960]  xhci_dbc_exit+0x2a/0x40
[  175.767889]  xhci_stop+0x57/0x1c0
[  175.768824]  usb_remove_hcd+0x100/0x250
[  175.769708]  usb_hcd_pci_remove+0x68/0x130
[  175.770574]  pci_device_remove+0x3b/0xc0
[  175.771435]  device_release_driver_internal+0x157/0x230
[  175.772343]  pci_stop_bus_device+0x74/0xa0
[  175.773205]  pci_stop_bus_device+0x2b/0xa0
[  175.774061]  pci_stop_bus_device+0x2b/0xa0
[  175.774907]  pci_stop_bus_device+0x2b/0xa0
[  175.775741]  pci_stop_bus_device+0x2b/0xa0
[  175.776618]  pci_stop_bus_device+0x2b/0xa0
[  175.777452]  pci_stop_bus_device+0x2b/0xa0
[  175.778273]  pci_stop_bus_device+0x2b/0xa0
[  175.779092]  pci_stop_bus_device+0x2b/0xa0
[  175.779908]  pci_stop_bus_device+0x2b/0xa0
[  175.780750]  pci_stop_bus_device+0x2b/0xa0
[  175.781543]  pci_stop_and_remove_bus_device+0xe/0x20
[  175.782338]  pciehp_unconfigure_device+0xb8/0x160
[  175.783128]  pciehp_disable_slot+0x4f/0xd0
[  175.783920]  pciehp_power_thread+0x82/0xa0
[  175.784766]  process_one_work+0x147/0x3c0
[  175.785564]  worker_thread+0x4a/0x440
[  175.786376]  kthread+0xf8/0x130
[  175.787174]  ? rescuer_thread+0x360/0x360
[  175.787964]  ? kthread_associate_blkcg+0x90/0x90
[  175.788798]  ret_from_fork+0x35/0x40

Cc:  # 4.16
Fixes: dfba2174dc42 ("usb: xhci: Add DbC support in xHCI driver")
Signed-off-by: Zhengjun Xing 
Tested-by: Christian Kellner 
Reviewed-by: Christian Kellner 
Signed-off-by: Mathias Nyman 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/usb/host/xhci-dbgtty.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/usb/host/xhci-dbgtty.c
+++ b/drivers/usb/host/xhci-dbgtty.c
@@ -320,9 +320,11 @@ int xhci_dbc_tty_register_driver(struct
 
 void xhci_dbc_tty_unregister_driver(void)
 {
-   tty_unregister_driver(dbc_tty_driver);
-   put_tty_driver(dbc_tty_driver);
-   dbc_tty_driver = NULL;
+   if (dbc_tty_driver) {
+   tty_unregister_driver(dbc_tty_driver);
+   put_tty_driver(dbc_tty_driver);
+   dbc_tty_driver = NULL;
+   }
 }
 
 static void dbc_rx_push(unsigned long _port)

[PATCH 4.16 57/81] net: aquantia: oops when shutdown on already stopped device

[Greg Kroah-Hartman]

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Igor Russkikh 


[ Upstream commit 9a11aff25fd43d5bd2660ababdc9f564b0ba183a ]

In case netdev is closed at the moment of pci shutdown, aq_nic_stop
gets called second time. napi_disable in that case hangs indefinitely.
In other case, if device was never opened at all, we get oops because
of null pointer access.

We should invoke aq_nic_stop conditionally, only if device is running
at the moment of shutdown.

Reported-by: David Arcari 
Fixes: 90869ddfefeb ("net: aquantia: Implement pci shutdown callback")
Signed-off-by: Igor Russkikh 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/net/ethernet/aquantia/atlantic/aq_nic.c |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

--- a/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
+++ b/drivers/net/ethernet/aquantia/atlantic/aq_nic.c
@@ -951,9 +951,11 @@ void aq_nic_shutdown(struct aq_nic_s *se
 
netif_device_detach(self->ndev);
 
-   err = aq_nic_stop(self);
-   if (err < 0)
-   goto err_exit;
+   if (netif_running(self->ndev)) {
+   err = aq_nic_stop(self);
+   if (err < 0)
+   goto err_exit;
+   }
aq_nic_deinit(self);
 
 err_exit:

[PATCH 4.14 044/183] powerpc: System reset avoid interleaving oops using die synchronisation

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Nicholas Piggin 


[ Upstream commit 4552d128c26e0f0f27a5bd2fadc24092b8f6c1d7 ]

The die() oops path contains a serializing lock to prevent oops
messages from being interleaved. In the case of a system reset
initiated oops (e.g., qemu nmi command), __die was being called
which lacks that synchronisation and oops reports could be
interleaved across CPUs.

A recent patch 4388c9b3a6ee7 ("powerpc: Do not send system reset
request through the oops path") changed this to __die to avoid
the debugger() call, but there is no real harm to calling it twice
if the first time fell through. So go back to using die() here.
This was observed to fix the problem.

Fixes: 4388c9b3a6ee7 ("powerpc: Do not send system reset request through the 
oops path")
Signed-off-by: Nicholas Piggin 
Reviewed-by: David Gibson 
Signed-off-by: Michael Ellerman 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 arch/powerpc/kernel/traps.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -336,7 +336,7 @@ void system_reset_exception(struct pt_re
 * No debugger or crash dump registered, print logs then
 * panic.
 */
-   __die("System Reset", regs, SIGABRT);
+   die("System Reset", regs, SIGABRT);
 
mdelay(2*MSEC_PER_SEC); /* Wait a little while for others to print */
add_taint(TAINT_DIE, LOCKDEP_NOW_UNRELIABLE);

[PATCH 4.16 030/196] media: rc: oops in ir_timer_keyup after device unplug

[Greg Kroah-Hartman]

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Sean Young 

commit 8d4068810d9926250dd2435719a080b889eb44c3 upstream.

If there is IR in the raw kfifo when ir_raw_event_unregister() is called,
then kthread_stop() causes ir_raw_event_thread to be scheduled, decode
some scancodes and re-arm timer_keyup. The timer_keyup then fires when
the rc device is long gone.

Cc: sta...@vger.kernel.org
Signed-off-by: Sean Young 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/media/rc/rc-main.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -1929,12 +1929,12 @@ void rc_unregister_device(struct rc_dev
if (!dev)
return;
 
-   del_timer_sync(&dev->timer_keyup);
-   del_timer_sync(&dev->timer_repeat);
-
if (dev->driver_type == RC_DRIVER_IR_RAW)
ir_raw_event_unregister(dev);
 
+   del_timer_sync(&dev->timer_keyup);
+   del_timer_sync(&dev->timer_repeat);
+
rc_free_rx_device(dev);
 
mutex_lock(&dev->lock);

[PATCH 4.4 01/97] media: v4l2-compat-ioctl32: dont oops on overlay

[Greg Kroah-Hartman]

4.4-stable review patch.  If anyone has any objections, please let me know.

--

From: Mauro Carvalho Chehab 

commit 85ea29f19eab56ec16ec6b92bc67305998706afa upstream.

At put_v4l2_window32(), it tries to access kp->clips. However,
kp points to an userspace pointer. So, it should be obtained
via get_user(), otherwise it can OOPS:

 vivid-000: ==  END STATUS  ==
 BUG: unable to handle kernel paging request at fffb18e0
 IP: [] __put_v4l2_format32+0x169/0x220 [videodev]
 PGD 3f5776067 PUD 3f576f067 PMD 3f5769067 PTE 80042548f067
 Oops: 0001 [#1] SMP
 Modules linked in: vivid videobuf2_vmalloc videobuf2_memops v4l2_dv_timings 
videobuf2_core v4l2_common videodev media xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc 
ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill binfmt_misc 
snd_hda_codec_hdmi i915 snd_hda_intel snd_hda_controller snd_hda_codec 
intel_rapl x86_pkg_temp_thermal snd_hwdep intel_powerclamp snd_pcm coretemp 
snd_seq_midi kvm_intel kvm snd_seq_midi_event snd_rawmidi i2c_algo_bit 
drm_kms_helper snd_seq drm crct10dif_pclmul e1000e snd_seq_device crc32_pclmul 
snd_timer ghash_clmulni_intel snd mei_me mei ptp pps_core soundcore lpc_ich 
video crc32c_intel [last unloaded: media]
 CPU: 2 PID: 28332 Comm: v4l2-compliance Not tainted 3.18.102+ #107
 Hardware name:  /NUC5i7RYB, BIOS 
RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
 task: 8804293f8000 ti: 8803f564 task.ti: 8803f564
 RIP: 0010:[]  [] 
__put_v4l2_format32+0x169/0x220 [videodev]
 RSP: 0018:8803f5643e28  EFLAGS: 00010246
 RAX:  RBX:  RCX: fffb1ab4
 RDX: fffb1a68 RSI: fffb18d8 RDI: fffb1aa8
 RBP: 8803f5643e48 R08: 0001 R09: 8803f54b0378
 R10:  R11: 0168 R12: fffb18c0
 R13: fffb1a94 R14: fffb18c8 R15: 
 FS:  () GS:880456d0(0063) knlGS:f7100980
 CS:  0010 DS: 002b ES: 002b CR0: 80050033
 CR2: fffb18e0 CR3: 0003f552b000 CR4: 003407e0
 Stack:
  fffb1a94 c0cc5640 0056 8804274f3600
  8803f5643ed0 c0547e16 0003 8803f5643eb0
  81301460 88009db44b01 880441942520 8800c0d05640
 Call Trace:
  [] v4l2_compat_ioctl32+0x12d6/0x1b1d [videodev]
  [] ? file_has_perm+0x70/0xc0
  [] compat_SyS_ioctl+0xec/0x1200
  [] sysenter_dispatch+0x7/0x21
 Code: 00 00 48 8b 80 48 c0 ff ff 48 83 e8 38 49 39 c6 0f 87 2b ff ff ff 49 8d 
45 1c e8 a3 ce e3 c0 85 c0 0f 85 1a ff ff ff 41 8d 40 ff <4d> 8b 64 24 20 41 89 
d5 48 8d 44 40 03 4d 8d 34 c4 eb 15 0f 1f
 RIP  [] __put_v4l2_format32+0x169/0x220 [videodev]
 RSP 
 CR2: fffb18e0

Tested with vivid driver on Kernel v3.18.102.

Same bug happens upstream too:

 BUG: KASAN: user-memory-access in __put_v4l2_format32+0x98/0x4d0 [videodev]
 Read of size 8 at addr ffe48400 by task v4l2-compliance/8713

 CPU: 0 PID: 8713 Comm: v4l2-compliance Not tainted 4.16.0-rc4+ #108
 Hardware name:  /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
 Call Trace:
  dump_stack+0x5c/0x7c
  kasan_report+0x164/0x380
  ? __put_v4l2_format32+0x98/0x4d0 [videodev]
  __put_v4l2_format32+0x98/0x4d0 [videodev]
  v4l2_compat_ioctl32+0x1aec/0x27a0 [videodev]
  ? __fsnotify_inode_delete+0x20/0x20
  ? __put_v4l2_format32+0x4d0/0x4d0 [videodev]
  compat_SyS_ioctl+0x646/0x14d0
  ? do_ioctl+0x30/0x30
  do_fast_syscall_32+0x191/0x3f4
  entry_SYSENTER_compat+0x6b/0x7a
 ==
 Disabling lock debugging due to kernel taint
 BUG: unable to handle kernel paging request at ffe48400
 IP: __put_v4l2_format32+0x98/0x4d0 [videodev]
 PGD 3a22fb067 P4D 3a22fb067 PUD 39b6f0067 PMD 39b6f1067 PTE 8003256af067
 Oops: 0001 [#1] SMP KASAN
 Modules linked in: vivid videobuf2_vmalloc videobuf2_dma_contig 
videobuf2_memops v4l2_tpg v4l2_dv_timings videobuf2_v4l2 videobuf2_common 
v4l2_common videodev xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c tun bridge stp llc 
ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill 
ecdh_generic binfmt_misc snd_hda_codec_hdmi intel_rapl x86_pkg_temp_thermal 
intel_powerclamp i915 coretemp snd_hda_intel snd_hda_codec kvm_intel snd_hwdep 
snd_hda_core kvm snd_pcm irqbypass crct10dif_pclmul crc32_pclmul snd_seq_midi 
ghash_clmulni_intel snd_seq_midi_event i2c_algo_bit intel_cstate snd_rawmidi 
intel_uncore snd_seq drm_kms_helper e1000e snd_seq_device snd_timer 
intel_rapl_perf
  drm ptp snd mei_me mei lpc_ich pps_core soundcore video crc32c_intel
 CPU: 0 PID: 8713 Comm: v4l2-compliance T

[PATCH 3.18 01/52] media: v4l2-compat-ioctl32: dont oops on overlay

[Greg Kroah-Hartman]

3.18-stable review patch.  If anyone has any objections, please let me know.

--

From: Mauro Carvalho Chehab 

commit 85ea29f19eab56ec16ec6b92bc67305998706afa upstream.

At put_v4l2_window32(), it tries to access kp->clips. However,
kp points to an userspace pointer. So, it should be obtained
via get_user(), otherwise it can OOPS:

 vivid-000: ==  END STATUS  ==
 BUG: unable to handle kernel paging request at fffb18e0
 IP: [] __put_v4l2_format32+0x169/0x220 [videodev]
 PGD 3f5776067 PUD 3f576f067 PMD 3f5769067 PTE 80042548f067
 Oops: 0001 [#1] SMP
 Modules linked in: vivid videobuf2_vmalloc videobuf2_memops v4l2_dv_timings 
videobuf2_core v4l2_common videodev media xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc 
ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill binfmt_misc 
snd_hda_codec_hdmi i915 snd_hda_intel snd_hda_controller snd_hda_codec 
intel_rapl x86_pkg_temp_thermal snd_hwdep intel_powerclamp snd_pcm coretemp 
snd_seq_midi kvm_intel kvm snd_seq_midi_event snd_rawmidi i2c_algo_bit 
drm_kms_helper snd_seq drm crct10dif_pclmul e1000e snd_seq_device crc32_pclmul 
snd_timer ghash_clmulni_intel snd mei_me mei ptp pps_core soundcore lpc_ich 
video crc32c_intel [last unloaded: media]
 CPU: 2 PID: 28332 Comm: v4l2-compliance Not tainted 3.18.102+ #107
 Hardware name:  /NUC5i7RYB, BIOS 
RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
 task: 8804293f8000 ti: 8803f564 task.ti: 8803f564
 RIP: 0010:[]  [] 
__put_v4l2_format32+0x169/0x220 [videodev]
 RSP: 0018:8803f5643e28  EFLAGS: 00010246
 RAX:  RBX:  RCX: fffb1ab4
 RDX: fffb1a68 RSI: fffb18d8 RDI: fffb1aa8
 RBP: 8803f5643e48 R08: 0001 R09: 8803f54b0378
 R10:  R11: 0168 R12: fffb18c0
 R13: fffb1a94 R14: fffb18c8 R15: 
 FS:  () GS:880456d0(0063) knlGS:f7100980
 CS:  0010 DS: 002b ES: 002b CR0: 80050033
 CR2: fffb18e0 CR3: 0003f552b000 CR4: 003407e0
 Stack:
  fffb1a94 c0cc5640 0056 8804274f3600
  8803f5643ed0 c0547e16 0003 8803f5643eb0
  81301460 88009db44b01 880441942520 8800c0d05640
 Call Trace:
  [] v4l2_compat_ioctl32+0x12d6/0x1b1d [videodev]
  [] ? file_has_perm+0x70/0xc0
  [] compat_SyS_ioctl+0xec/0x1200
  [] sysenter_dispatch+0x7/0x21
 Code: 00 00 48 8b 80 48 c0 ff ff 48 83 e8 38 49 39 c6 0f 87 2b ff ff ff 49 8d 
45 1c e8 a3 ce e3 c0 85 c0 0f 85 1a ff ff ff 41 8d 40 ff <4d> 8b 64 24 20 41 89 
d5 48 8d 44 40 03 4d 8d 34 c4 eb 15 0f 1f
 RIP  [] __put_v4l2_format32+0x169/0x220 [videodev]
 RSP 
 CR2: fffb18e0

Tested with vivid driver on Kernel v3.18.102.

Same bug happens upstream too:

 BUG: KASAN: user-memory-access in __put_v4l2_format32+0x98/0x4d0 [videodev]
 Read of size 8 at addr ffe48400 by task v4l2-compliance/8713

 CPU: 0 PID: 8713 Comm: v4l2-compliance Not tainted 4.16.0-rc4+ #108
 Hardware name:  /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
 Call Trace:
  dump_stack+0x5c/0x7c
  kasan_report+0x164/0x380
  ? __put_v4l2_format32+0x98/0x4d0 [videodev]
  __put_v4l2_format32+0x98/0x4d0 [videodev]
  v4l2_compat_ioctl32+0x1aec/0x27a0 [videodev]
  ? __fsnotify_inode_delete+0x20/0x20
  ? __put_v4l2_format32+0x4d0/0x4d0 [videodev]
  compat_SyS_ioctl+0x646/0x14d0
  ? do_ioctl+0x30/0x30
  do_fast_syscall_32+0x191/0x3f4
  entry_SYSENTER_compat+0x6b/0x7a
 ==
 Disabling lock debugging due to kernel taint
 BUG: unable to handle kernel paging request at ffe48400
 IP: __put_v4l2_format32+0x98/0x4d0 [videodev]
 PGD 3a22fb067 P4D 3a22fb067 PUD 39b6f0067 PMD 39b6f1067 PTE 8003256af067
 Oops: 0001 [#1] SMP KASAN
 Modules linked in: vivid videobuf2_vmalloc videobuf2_dma_contig 
videobuf2_memops v4l2_tpg v4l2_dv_timings videobuf2_v4l2 videobuf2_common 
v4l2_common videodev xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c tun bridge stp llc 
ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill 
ecdh_generic binfmt_misc snd_hda_codec_hdmi intel_rapl x86_pkg_temp_thermal 
intel_powerclamp i915 coretemp snd_hda_intel snd_hda_codec kvm_intel snd_hwdep 
snd_hda_core kvm snd_pcm irqbypass crct10dif_pclmul crc32_pclmul snd_seq_midi 
ghash_clmulni_intel snd_seq_midi_event i2c_algo_bit intel_cstate snd_rawmidi 
intel_uncore snd_seq drm_kms_helper e1000e snd_seq_device snd_timer 
intel_rapl_perf
  drm ptp snd mei_me mei lpc_ich pps_core soundcore video crc32c_intel
 CPU: 0 PID: 8713 Comm: v4l2-complianc

[PATCH 4.16 12/68] media: v4l2-compat-ioctl32: dont oops on overlay

[Greg Kroah-Hartman]

4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Mauro Carvalho Chehab 

commit 85ea29f19eab56ec16ec6b92bc67305998706afa upstream.

At put_v4l2_window32(), it tries to access kp->clips. However,
kp points to an userspace pointer. So, it should be obtained
via get_user(), otherwise it can OOPS:

 vivid-000: ==  END STATUS  ==
 BUG: unable to handle kernel paging request at fffb18e0
 IP: [] __put_v4l2_format32+0x169/0x220 [videodev]
 PGD 3f5776067 PUD 3f576f067 PMD 3f5769067 PTE 80042548f067
 Oops: 0001 [#1] SMP
 Modules linked in: vivid videobuf2_vmalloc videobuf2_memops v4l2_dv_timings 
videobuf2_core v4l2_common videodev media xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc 
ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill binfmt_misc 
snd_hda_codec_hdmi i915 snd_hda_intel snd_hda_controller snd_hda_codec 
intel_rapl x86_pkg_temp_thermal snd_hwdep intel_powerclamp snd_pcm coretemp 
snd_seq_midi kvm_intel kvm snd_seq_midi_event snd_rawmidi i2c_algo_bit 
drm_kms_helper snd_seq drm crct10dif_pclmul e1000e snd_seq_device crc32_pclmul 
snd_timer ghash_clmulni_intel snd mei_me mei ptp pps_core soundcore lpc_ich 
video crc32c_intel [last unloaded: media]
 CPU: 2 PID: 28332 Comm: v4l2-compliance Not tainted 3.18.102+ #107
 Hardware name:  /NUC5i7RYB, BIOS 
RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
 task: 8804293f8000 ti: 8803f564 task.ti: 8803f564
 RIP: 0010:[]  [] 
__put_v4l2_format32+0x169/0x220 [videodev]
 RSP: 0018:8803f5643e28  EFLAGS: 00010246
 RAX:  RBX:  RCX: fffb1ab4
 RDX: fffb1a68 RSI: fffb18d8 RDI: fffb1aa8
 RBP: 8803f5643e48 R08: 0001 R09: 8803f54b0378
 R10:  R11: 0168 R12: fffb18c0
 R13: fffb1a94 R14: fffb18c8 R15: 
 FS:  () GS:880456d0(0063) knlGS:f7100980
 CS:  0010 DS: 002b ES: 002b CR0: 80050033
 CR2: fffb18e0 CR3: 0003f552b000 CR4: 003407e0
 Stack:
  fffb1a94 c0cc5640 0056 8804274f3600
  8803f5643ed0 c0547e16 0003 8803f5643eb0
  81301460 88009db44b01 880441942520 8800c0d05640
 Call Trace:
  [] v4l2_compat_ioctl32+0x12d6/0x1b1d [videodev]
  [] ? file_has_perm+0x70/0xc0
  [] compat_SyS_ioctl+0xec/0x1200
  [] sysenter_dispatch+0x7/0x21
 Code: 00 00 48 8b 80 48 c0 ff ff 48 83 e8 38 49 39 c6 0f 87 2b ff ff ff 49 8d 
45 1c e8 a3 ce e3 c0 85 c0 0f 85 1a ff ff ff 41 8d 40 ff <4d> 8b 64 24 20 41 89 
d5 48 8d 44 40 03 4d 8d 34 c4 eb 15 0f 1f
 RIP  [] __put_v4l2_format32+0x169/0x220 [videodev]
 RSP 
 CR2: fffb18e0

Tested with vivid driver on Kernel v3.18.102.

Same bug happens upstream too:

 BUG: KASAN: user-memory-access in __put_v4l2_format32+0x98/0x4d0 [videodev]
 Read of size 8 at addr ffe48400 by task v4l2-compliance/8713

 CPU: 0 PID: 8713 Comm: v4l2-compliance Not tainted 4.16.0-rc4+ #108
 Hardware name:  /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
 Call Trace:
  dump_stack+0x5c/0x7c
  kasan_report+0x164/0x380
  ? __put_v4l2_format32+0x98/0x4d0 [videodev]
  __put_v4l2_format32+0x98/0x4d0 [videodev]
  v4l2_compat_ioctl32+0x1aec/0x27a0 [videodev]
  ? __fsnotify_inode_delete+0x20/0x20
  ? __put_v4l2_format32+0x4d0/0x4d0 [videodev]
  compat_SyS_ioctl+0x646/0x14d0
  ? do_ioctl+0x30/0x30
  do_fast_syscall_32+0x191/0x3f4
  entry_SYSENTER_compat+0x6b/0x7a
 ==
 Disabling lock debugging due to kernel taint
 BUG: unable to handle kernel paging request at ffe48400
 IP: __put_v4l2_format32+0x98/0x4d0 [videodev]
 PGD 3a22fb067 P4D 3a22fb067 PUD 39b6f0067 PMD 39b6f1067 PTE 8003256af067
 Oops: 0001 [#1] SMP KASAN
 Modules linked in: vivid videobuf2_vmalloc videobuf2_dma_contig 
videobuf2_memops v4l2_tpg v4l2_dv_timings videobuf2_v4l2 videobuf2_common 
v4l2_common videodev xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c tun bridge stp llc 
ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill 
ecdh_generic binfmt_misc snd_hda_codec_hdmi intel_rapl x86_pkg_temp_thermal 
intel_powerclamp i915 coretemp snd_hda_intel snd_hda_codec kvm_intel snd_hwdep 
snd_hda_core kvm snd_pcm irqbypass crct10dif_pclmul crc32_pclmul snd_seq_midi 
ghash_clmulni_intel snd_seq_midi_event i2c_algo_bit intel_cstate snd_rawmidi 
intel_uncore snd_seq drm_kms_helper e1000e snd_seq_device snd_timer 
intel_rapl_perf
  drm ptp snd mei_me mei lpc_ich pps_core soundcore video crc32c_intel
 CPU: 0 PID: 8713 Comm: v4l2-complianc

[PATCH 4.9 01/66] media: v4l2-compat-ioctl32: dont oops on overlay

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Mauro Carvalho Chehab 

commit 85ea29f19eab56ec16ec6b92bc67305998706afa upstream.

At put_v4l2_window32(), it tries to access kp->clips. However,
kp points to an userspace pointer. So, it should be obtained
via get_user(), otherwise it can OOPS:

 vivid-000: ==  END STATUS  ==
 BUG: unable to handle kernel paging request at fffb18e0
 IP: [] __put_v4l2_format32+0x169/0x220 [videodev]
 PGD 3f5776067 PUD 3f576f067 PMD 3f5769067 PTE 80042548f067
 Oops: 0001 [#1] SMP
 Modules linked in: vivid videobuf2_vmalloc videobuf2_memops v4l2_dv_timings 
videobuf2_core v4l2_common videodev media xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc 
ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill binfmt_misc 
snd_hda_codec_hdmi i915 snd_hda_intel snd_hda_controller snd_hda_codec 
intel_rapl x86_pkg_temp_thermal snd_hwdep intel_powerclamp snd_pcm coretemp 
snd_seq_midi kvm_intel kvm snd_seq_midi_event snd_rawmidi i2c_algo_bit 
drm_kms_helper snd_seq drm crct10dif_pclmul e1000e snd_seq_device crc32_pclmul 
snd_timer ghash_clmulni_intel snd mei_me mei ptp pps_core soundcore lpc_ich 
video crc32c_intel [last unloaded: media]
 CPU: 2 PID: 28332 Comm: v4l2-compliance Not tainted 3.18.102+ #107
 Hardware name:  /NUC5i7RYB, BIOS 
RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
 task: 8804293f8000 ti: 8803f564 task.ti: 8803f564
 RIP: 0010:[]  [] 
__put_v4l2_format32+0x169/0x220 [videodev]
 RSP: 0018:8803f5643e28  EFLAGS: 00010246
 RAX:  RBX:  RCX: fffb1ab4
 RDX: fffb1a68 RSI: fffb18d8 RDI: fffb1aa8
 RBP: 8803f5643e48 R08: 0001 R09: 8803f54b0378
 R10:  R11: 0168 R12: fffb18c0
 R13: fffb1a94 R14: fffb18c8 R15: 
 FS:  () GS:880456d0(0063) knlGS:f7100980
 CS:  0010 DS: 002b ES: 002b CR0: 80050033
 CR2: fffb18e0 CR3: 0003f552b000 CR4: 003407e0
 Stack:
  fffb1a94 c0cc5640 0056 8804274f3600
  8803f5643ed0 c0547e16 0003 8803f5643eb0
  81301460 88009db44b01 880441942520 8800c0d05640
 Call Trace:
  [] v4l2_compat_ioctl32+0x12d6/0x1b1d [videodev]
  [] ? file_has_perm+0x70/0xc0
  [] compat_SyS_ioctl+0xec/0x1200
  [] sysenter_dispatch+0x7/0x21
 Code: 00 00 48 8b 80 48 c0 ff ff 48 83 e8 38 49 39 c6 0f 87 2b ff ff ff 49 8d 
45 1c e8 a3 ce e3 c0 85 c0 0f 85 1a ff ff ff 41 8d 40 ff <4d> 8b 64 24 20 41 89 
d5 48 8d 44 40 03 4d 8d 34 c4 eb 15 0f 1f
 RIP  [] __put_v4l2_format32+0x169/0x220 [videodev]
 RSP 
 CR2: fffb18e0

Tested with vivid driver on Kernel v3.18.102.

Same bug happens upstream too:

 BUG: KASAN: user-memory-access in __put_v4l2_format32+0x98/0x4d0 [videodev]
 Read of size 8 at addr ffe48400 by task v4l2-compliance/8713

 CPU: 0 PID: 8713 Comm: v4l2-compliance Not tainted 4.16.0-rc4+ #108
 Hardware name:  /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
 Call Trace:
  dump_stack+0x5c/0x7c
  kasan_report+0x164/0x380
  ? __put_v4l2_format32+0x98/0x4d0 [videodev]
  __put_v4l2_format32+0x98/0x4d0 [videodev]
  v4l2_compat_ioctl32+0x1aec/0x27a0 [videodev]
  ? __fsnotify_inode_delete+0x20/0x20
  ? __put_v4l2_format32+0x4d0/0x4d0 [videodev]
  compat_SyS_ioctl+0x646/0x14d0
  ? do_ioctl+0x30/0x30
  do_fast_syscall_32+0x191/0x3f4
  entry_SYSENTER_compat+0x6b/0x7a
 ==
 Disabling lock debugging due to kernel taint
 BUG: unable to handle kernel paging request at ffe48400
 IP: __put_v4l2_format32+0x98/0x4d0 [videodev]
 PGD 3a22fb067 P4D 3a22fb067 PUD 39b6f0067 PMD 39b6f1067 PTE 8003256af067
 Oops: 0001 [#1] SMP KASAN
 Modules linked in: vivid videobuf2_vmalloc videobuf2_dma_contig 
videobuf2_memops v4l2_tpg v4l2_dv_timings videobuf2_v4l2 videobuf2_common 
v4l2_common videodev xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c tun bridge stp llc 
ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill 
ecdh_generic binfmt_misc snd_hda_codec_hdmi intel_rapl x86_pkg_temp_thermal 
intel_powerclamp i915 coretemp snd_hda_intel snd_hda_codec kvm_intel snd_hwdep 
snd_hda_core kvm snd_pcm irqbypass crct10dif_pclmul crc32_pclmul snd_seq_midi 
ghash_clmulni_intel snd_seq_midi_event i2c_algo_bit intel_cstate snd_rawmidi 
intel_uncore snd_seq drm_kms_helper e1000e snd_seq_device snd_timer 
intel_rapl_perf
  drm ptp snd mei_me mei lpc_ich pps_core soundcore video crc32c_intel
 CPU: 0 PID: 8713 Comm: v4l2-compliance T

[PATCH 4.14 08/49] media: v4l2-compat-ioctl32: dont oops on overlay

[Greg Kroah-Hartman]

4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Mauro Carvalho Chehab 

commit 85ea29f19eab56ec16ec6b92bc67305998706afa upstream.

At put_v4l2_window32(), it tries to access kp->clips. However,
kp points to an userspace pointer. So, it should be obtained
via get_user(), otherwise it can OOPS:

 vivid-000: ==  END STATUS  ==
 BUG: unable to handle kernel paging request at fffb18e0
 IP: [] __put_v4l2_format32+0x169/0x220 [videodev]
 PGD 3f5776067 PUD 3f576f067 PMD 3f5769067 PTE 80042548f067
 Oops: 0001 [#1] SMP
 Modules linked in: vivid videobuf2_vmalloc videobuf2_memops v4l2_dv_timings 
videobuf2_core v4l2_common videodev media xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc 
ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill binfmt_misc 
snd_hda_codec_hdmi i915 snd_hda_intel snd_hda_controller snd_hda_codec 
intel_rapl x86_pkg_temp_thermal snd_hwdep intel_powerclamp snd_pcm coretemp 
snd_seq_midi kvm_intel kvm snd_seq_midi_event snd_rawmidi i2c_algo_bit 
drm_kms_helper snd_seq drm crct10dif_pclmul e1000e snd_seq_device crc32_pclmul 
snd_timer ghash_clmulni_intel snd mei_me mei ptp pps_core soundcore lpc_ich 
video crc32c_intel [last unloaded: media]
 CPU: 2 PID: 28332 Comm: v4l2-compliance Not tainted 3.18.102+ #107
 Hardware name:  /NUC5i7RYB, BIOS 
RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
 task: 8804293f8000 ti: 8803f564 task.ti: 8803f564
 RIP: 0010:[]  [] 
__put_v4l2_format32+0x169/0x220 [videodev]
 RSP: 0018:8803f5643e28  EFLAGS: 00010246
 RAX:  RBX:  RCX: fffb1ab4
 RDX: fffb1a68 RSI: fffb18d8 RDI: fffb1aa8
 RBP: 8803f5643e48 R08: 0001 R09: 8803f54b0378
 R10:  R11: 0168 R12: fffb18c0
 R13: fffb1a94 R14: fffb18c8 R15: 
 FS:  () GS:880456d0(0063) knlGS:f7100980
 CS:  0010 DS: 002b ES: 002b CR0: 80050033
 CR2: fffb18e0 CR3: 0003f552b000 CR4: 003407e0
 Stack:
  fffb1a94 c0cc5640 0056 8804274f3600
  8803f5643ed0 c0547e16 0003 8803f5643eb0
  81301460 88009db44b01 880441942520 8800c0d05640
 Call Trace:
  [] v4l2_compat_ioctl32+0x12d6/0x1b1d [videodev]
  [] ? file_has_perm+0x70/0xc0
  [] compat_SyS_ioctl+0xec/0x1200
  [] sysenter_dispatch+0x7/0x21
 Code: 00 00 48 8b 80 48 c0 ff ff 48 83 e8 38 49 39 c6 0f 87 2b ff ff ff 49 8d 
45 1c e8 a3 ce e3 c0 85 c0 0f 85 1a ff ff ff 41 8d 40 ff <4d> 8b 64 24 20 41 89 
d5 48 8d 44 40 03 4d 8d 34 c4 eb 15 0f 1f
 RIP  [] __put_v4l2_format32+0x169/0x220 [videodev]
 RSP 
 CR2: fffb18e0

Tested with vivid driver on Kernel v3.18.102.

Same bug happens upstream too:

 BUG: KASAN: user-memory-access in __put_v4l2_format32+0x98/0x4d0 [videodev]
 Read of size 8 at addr ffe48400 by task v4l2-compliance/8713

 CPU: 0 PID: 8713 Comm: v4l2-compliance Not tainted 4.16.0-rc4+ #108
 Hardware name:  /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
 Call Trace:
  dump_stack+0x5c/0x7c
  kasan_report+0x164/0x380
  ? __put_v4l2_format32+0x98/0x4d0 [videodev]
  __put_v4l2_format32+0x98/0x4d0 [videodev]
  v4l2_compat_ioctl32+0x1aec/0x27a0 [videodev]
  ? __fsnotify_inode_delete+0x20/0x20
  ? __put_v4l2_format32+0x4d0/0x4d0 [videodev]
  compat_SyS_ioctl+0x646/0x14d0
  ? do_ioctl+0x30/0x30
  do_fast_syscall_32+0x191/0x3f4
  entry_SYSENTER_compat+0x6b/0x7a
 ==
 Disabling lock debugging due to kernel taint
 BUG: unable to handle kernel paging request at ffe48400
 IP: __put_v4l2_format32+0x98/0x4d0 [videodev]
 PGD 3a22fb067 P4D 3a22fb067 PUD 39b6f0067 PMD 39b6f1067 PTE 8003256af067
 Oops: 0001 [#1] SMP KASAN
 Modules linked in: vivid videobuf2_vmalloc videobuf2_dma_contig 
videobuf2_memops v4l2_tpg v4l2_dv_timings videobuf2_v4l2 videobuf2_common 
v4l2_common videodev xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c tun bridge stp llc 
ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill 
ecdh_generic binfmt_misc snd_hda_codec_hdmi intel_rapl x86_pkg_temp_thermal 
intel_powerclamp i915 coretemp snd_hda_intel snd_hda_codec kvm_intel snd_hwdep 
snd_hda_core kvm snd_pcm irqbypass crct10dif_pclmul crc32_pclmul snd_seq_midi 
ghash_clmulni_intel snd_seq_midi_event i2c_algo_bit intel_cstate snd_rawmidi 
intel_uncore snd_seq drm_kms_helper e1000e snd_seq_device snd_timer 
intel_rapl_perf
  drm ptp snd mei_me mei lpc_ich pps_core soundcore video crc32c_intel
 CPU: 0 PID: 8713 Comm: v4l2-complianc

[PATCH 4.15 12/53] media: v4l2-compat-ioctl32: dont oops on overlay

[Greg Kroah-Hartman]

4.15-stable review patch.  If anyone has any objections, please let me know.

--

From: Mauro Carvalho Chehab 

commit 85ea29f19eab56ec16ec6b92bc67305998706afa upstream.

At put_v4l2_window32(), it tries to access kp->clips. However,
kp points to an userspace pointer. So, it should be obtained
via get_user(), otherwise it can OOPS:

 vivid-000: ==  END STATUS  ==
 BUG: unable to handle kernel paging request at fffb18e0
 IP: [] __put_v4l2_format32+0x169/0x220 [videodev]
 PGD 3f5776067 PUD 3f576f067 PMD 3f5769067 PTE 80042548f067
 Oops: 0001 [#1] SMP
 Modules linked in: vivid videobuf2_vmalloc videobuf2_memops v4l2_dv_timings 
videobuf2_core v4l2_common videodev media xt_CHECKSUM iptable_mangle 
ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack tun bridge stp llc 
ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill binfmt_misc 
snd_hda_codec_hdmi i915 snd_hda_intel snd_hda_controller snd_hda_codec 
intel_rapl x86_pkg_temp_thermal snd_hwdep intel_powerclamp snd_pcm coretemp 
snd_seq_midi kvm_intel kvm snd_seq_midi_event snd_rawmidi i2c_algo_bit 
drm_kms_helper snd_seq drm crct10dif_pclmul e1000e snd_seq_device crc32_pclmul 
snd_timer ghash_clmulni_intel snd mei_me mei ptp pps_core soundcore lpc_ich 
video crc32c_intel [last unloaded: media]
 CPU: 2 PID: 28332 Comm: v4l2-compliance Not tainted 3.18.102+ #107
 Hardware name:  /NUC5i7RYB, BIOS 
RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
 task: 8804293f8000 ti: 8803f564 task.ti: 8803f564
 RIP: 0010:[]  [] 
__put_v4l2_format32+0x169/0x220 [videodev]
 RSP: 0018:8803f5643e28  EFLAGS: 00010246
 RAX:  RBX:  RCX: fffb1ab4
 RDX: fffb1a68 RSI: fffb18d8 RDI: fffb1aa8
 RBP: 8803f5643e48 R08: 0001 R09: 8803f54b0378
 R10:  R11: 0168 R12: fffb18c0
 R13: fffb1a94 R14: fffb18c8 R15: 
 FS:  () GS:880456d0(0063) knlGS:f7100980
 CS:  0010 DS: 002b ES: 002b CR0: 80050033
 CR2: fffb18e0 CR3: 0003f552b000 CR4: 003407e0
 Stack:
  fffb1a94 c0cc5640 0056 8804274f3600
  8803f5643ed0 c0547e16 0003 8803f5643eb0
  81301460 88009db44b01 880441942520 8800c0d05640
 Call Trace:
  [] v4l2_compat_ioctl32+0x12d6/0x1b1d [videodev]
  [] ? file_has_perm+0x70/0xc0
  [] compat_SyS_ioctl+0xec/0x1200
  [] sysenter_dispatch+0x7/0x21
 Code: 00 00 48 8b 80 48 c0 ff ff 48 83 e8 38 49 39 c6 0f 87 2b ff ff ff 49 8d 
45 1c e8 a3 ce e3 c0 85 c0 0f 85 1a ff ff ff 41 8d 40 ff <4d> 8b 64 24 20 41 89 
d5 48 8d 44 40 03 4d 8d 34 c4 eb 15 0f 1f
 RIP  [] __put_v4l2_format32+0x169/0x220 [videodev]
 RSP 
 CR2: fffb18e0

Tested with vivid driver on Kernel v3.18.102.

Same bug happens upstream too:

 BUG: KASAN: user-memory-access in __put_v4l2_format32+0x98/0x4d0 [videodev]
 Read of size 8 at addr ffe48400 by task v4l2-compliance/8713

 CPU: 0 PID: 8713 Comm: v4l2-compliance Not tainted 4.16.0-rc4+ #108
 Hardware name:  /NUC5i7RYB, BIOS RYBDWi35.86A.0364.2017.0511.0949 05/11/2017
 Call Trace:
  dump_stack+0x5c/0x7c
  kasan_report+0x164/0x380
  ? __put_v4l2_format32+0x98/0x4d0 [videodev]
  __put_v4l2_format32+0x98/0x4d0 [videodev]
  v4l2_compat_ioctl32+0x1aec/0x27a0 [videodev]
  ? __fsnotify_inode_delete+0x20/0x20
  ? __put_v4l2_format32+0x4d0/0x4d0 [videodev]
  compat_SyS_ioctl+0x646/0x14d0
  ? do_ioctl+0x30/0x30
  do_fast_syscall_32+0x191/0x3f4
  entry_SYSENTER_compat+0x6b/0x7a
 ==
 Disabling lock debugging due to kernel taint
 BUG: unable to handle kernel paging request at ffe48400
 IP: __put_v4l2_format32+0x98/0x4d0 [videodev]
 PGD 3a22fb067 P4D 3a22fb067 PUD 39b6f0067 PMD 39b6f1067 PTE 8003256af067
 Oops: 0001 [#1] SMP KASAN
 Modules linked in: vivid videobuf2_vmalloc videobuf2_dma_contig 
videobuf2_memops v4l2_tpg v4l2_dv_timings videobuf2_v4l2 videobuf2_common 
v4l2_common videodev xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 
nf_defrag_ipv4 xt_conntrack nf_conntrack libcrc32c tun bridge stp llc 
ebtable_filter ebtables ip6table_filter ip6_tables bluetooth rfkill 
ecdh_generic binfmt_misc snd_hda_codec_hdmi intel_rapl x86_pkg_temp_thermal 
intel_powerclamp i915 coretemp snd_hda_intel snd_hda_codec kvm_intel snd_hwdep 
snd_hda_core kvm snd_pcm irqbypass crct10dif_pclmul crc32_pclmul snd_seq_midi 
ghash_clmulni_intel snd_seq_midi_event i2c_algo_bit intel_cstate snd_rawmidi 
intel_uncore snd_seq drm_kms_helper e1000e snd_seq_device snd_timer 
intel_rapl_perf
  drm ptp snd mei_me mei lpc_ich pps_core soundcore video crc32c_intel
 CPU: 0 PID: 8713 Comm: v4l2-complianc

[tip:x86/urgent] x86/mm: Prevent kernel Oops in PTDUMP code with HIGHPTE=y

[tip-bot for Joerg Roedel]

Commit-ID:  d6ef1f194b7569af8b8397876dc9ab07649d63cb
Gitweb: https://git.kernel.org/tip/d6ef1f194b7569af8b8397876dc9ab07649d63cb
Author: Joerg Roedel 
AuthorDate: Tue, 17 Apr 2018 15:27:16 +0200
Committer:  Thomas Gleixner 
CommitDate: Tue, 17 Apr 2018 15:43:01 +0200

x86/mm: Prevent kernel Oops in PTDUMP code with HIGHPTE=y

The walk_pte_level() function just uses __va to get the virtual address of
the PTE page, but that breaks when the PTE page is not in the direct
mapping with HIGHPTE=y.

The result is an unhandled kernel paging request at some random address
when accessing the current_kernel or current_user file.

Use the correct API to access PTE pages.

Fixes: fe770bf0310d ('x86: clean up the page table dumper and add 32-bit 
support')
Signed-off-by: Joerg Roedel 
Signed-off-by: Thomas Gleixner 
Cc: sta...@vger.kernel.org
Cc: jgr...@suse.com
Cc: jbeul...@suse.com
Cc: h...@zytor.com
Cc: aryabi...@virtuozzo.com
Cc: kirill.shute...@linux.intel.com
Link: https://lkml.kernel.org/r/1523971636-4137-1-git-send-email-j...@8bytes.org

---
 arch/x86/mm/dump_pagetables.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 62a7e9f65dec..cc7ff5957194 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -334,16 +335,16 @@ static void walk_pte_level(struct seq_file *m, struct 
pg_state *st, pmd_t addr,
   pgprotval_t eff_in, unsigned long P)
 {
int i;
-   pte_t *start;
+   pte_t *pte;
pgprotval_t prot, eff;
 
-   start = (pte_t *)pmd_page_vaddr(addr);
for (i = 0; i < PTRS_PER_PTE; i++) {
-   prot = pte_flags(*start);
-   eff = effective_prot(eff_in, prot);
st->current_address = normalize_addr(P + i * PTE_LEVEL_MULT);
+   pte = pte_offset_map(&addr, st->current_address);
+   prot = pte_flags(*pte);
+   eff = effective_prot(eff_in, prot);
note_page(m, st, __pgprot(prot), eff, 5);
-   start++;
+   pte_unmap(pte);
}
 }
 #ifdef CONFIG_KASAN

[PATCH] x86/mm: Fix kernel oops in PTDUMP code with HIGHPTE=y

[Joerg Roedel]

From: Joerg Roedel 

The walk_pte_level() function just uses __va to get the
virtual address of the PTE page, but that breaks when
the PTE page is not in the direct mapping with HIGHPTE=y.

The result is an unhandled kernel paging request at some
random address when accessing the current_kernel or
current_user file.

Use the correct API to access PTE pages nd fix the oops.

Fixes: fe770bf0310d ('x86: clean up the page table dumper and add 32-bit 
support')
Signed-off-by: Joerg Roedel 
---
 arch/x86/mm/dump_pagetables.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/x86/mm/dump_pagetables.c b/arch/x86/mm/dump_pagetables.c
index 956c886f5dff..db1d7a0e6335 100644
--- a/arch/x86/mm/dump_pagetables.c
+++ b/arch/x86/mm/dump_pagetables.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -344,16 +345,16 @@ static void walk_pte_level(struct seq_file *m, struct 
pg_state *st, pmd_t addr,
   pgprotval_t eff_in, unsigned long P)
 {
int i;
-   pte_t *start;
+   pte_t *pte;
pgprotval_t prot, eff;
 
-   start = (pte_t *)pmd_page_vaddr(addr);
for (i = 0; i < PTRS_PER_PTE; i++) {
-   prot = pte_flags(*start);
-   eff = effective_prot(eff_in, prot);
st->current_address = normalize_addr(P + i * PTE_LEVEL_MULT);
+   pte = pte_offset_map(&addr, st->current_address);
+   prot = pte_flags(*pte);
+   eff = effective_prot(eff_in, prot);
note_page(m, st, __pgprot(prot), eff, 5);
-   start++;
+   pte_unmap(pte);
}
 }
 #ifdef CONFIG_KASAN
-- 
2.13.6

[PATCH 4.9 262/310] blk-mq: fix kernel oops in blk_mq_tag_idle()

[Greg Kroah-Hartman]

4.9-stable review patch.  If anyone has any objections, please let me know.

--

From: Ming Lei 


[ Upstream commit 8ab0b7dc73e1b3e2987d42554b2bff503f692772 ]

HW queues may be unmapped in some cases, such as blk_mq_update_nr_hw_queues(),
then we need to check it before calling blk_mq_tag_idle(), otherwise
the following kernel oops can be triggered, so fix it by checking if
the hw queue is unmapped since it doesn't make sense to idle the tags
any more after hw queues are unmapped.

[  440.771298] Workqueue: nvme-wq nvme_rdma_del_ctrl_work [nvme_rdma]
[  440.779104] task: 894bae755ee0 ti: 893bf9bc8000 task.ti: 
893bf9bc8000
[  440.788359] RIP: 0010:[]  [] 
__blk_mq_tag_idle+0x24/0x40
[  440.798697] RSP: 0018:893bf9bcbd10  EFLAGS: 00010286
[  440.805538] RAX:  RBX: 895bb131dc00 RCX: 011f
[  440.814426] RDX:  RSI: 0120 RDI: 895bb131dc00
[  440.823301] RBP: 893bf9bcbd10 R08: 0001b860 R09: 4a51d361c00c
[  440.832193] R10: b5907f32b4cc7003 R11: d6cabfb57000 R12: 894bafd1e008
[  440.841091] R13: 0001 R14: 895baf77 R15: 0080
[  440.849988] FS:  () GS:894bbdcc() 
knlGS:
[  440.859955] CS:  0010 DS:  ES:  CR0: 80050033
[  440.867274] CR2: 0008 CR3: 00103d098000 CR4: 001407e0
[  440.876169] Call Trace:
[  440.879818]  [] blk_mq_exit_hctx+0xd8/0xe0
[  440.887051]  [] blk_mq_free_queue+0xf0/0x160
[  440.894465]  [] blk_cleanup_queue+0xd9/0x150
[  440.901881]  [] nvme_ns_remove+0x5b/0xb0 [nvme_core]
[  440.910068]  [] nvme_remove_namespaces+0x3b/0x60 
[nvme_core]
[  440.919026]  [] __nvme_rdma_remove_ctrl+0x2b/0xb0 
[nvme_rdma]
[  440.928079]  [] nvme_rdma_del_ctrl_work+0x17/0x20 
[nvme_rdma]
[  440.937126]  [] process_one_work+0x17a/0x440
[  440.944517]  [] worker_thread+0x278/0x3c0
[  440.951607]  [] ? manage_workers.isra.24+0x2a0/0x2a0
[  440.959760]  [] kthread+0xcf/0xe0
[  440.966055]  [] ? insert_kthread_work+0x40/0x40
[  440.973715]  [] ret_from_fork+0x58/0x90
[  440.980586]  [] ? insert_kthread_work+0x40/0x40
[  440.988229] Code: 5b 41 5c 5d c3 66 90 0f 1f 44 00 00 48 8b 87 20 01 00 00 
f0 0f ba 77 40 01 19 d2 85 d2 75 08 c3 0f 1f 80 00 00 00 00 55 48 89 e5  ff 
48 08 48 8d 78 10 e8 7f 0f 05 00 5d c3 0f 1f 00 66 2e 0f
[  441.011620] RIP  [] __blk_mq_tag_idle+0x24/0x40
[  441.019301]  RSP 
[  441.024052] CR2: 0008

Reported-by: Zhang Yi 
Tested-by: Zhang Yi 
Signed-off-by: Ming Lei 
Signed-off-by: Jens Axboe 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 block/blk-mq.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1592,7 +1592,8 @@ static void blk_mq_exit_hctx(struct requ
 {
unsigned flush_start_tag = set->queue_depth;
 
-   blk_mq_tag_idle(hctx);
+   if (blk_mq_hw_queue_mapped(hctx))
+   blk_mq_tag_idle(hctx);
 
if (set->ops->exit_request)
set->ops->exit_request(set->driver_data,