* 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.870
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
> [
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
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_sa
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 L
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; si
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; si
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 inst
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
. 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
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
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 pag
uld 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 80042548f
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
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.
Signe
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
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,
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 remov
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
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: ce5624f
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 derefe
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 derefe
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 derefer
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 tea
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
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);
>
> resul
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]
>
>
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 fir
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 fir
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 fir
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
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
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
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
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
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
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
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
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)
hutdown(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_s
layed 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/
rtl8
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
hutdown(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_s
layed 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/
rtl8
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 ioc
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 ioct
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 ioct
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 ioc
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 ioc
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
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
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 o
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
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 all
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
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
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"):
BU
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
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
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
&
> 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 eithe
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
Veluthakkal, Sreeram would like to recall the message, "PROBLEM: JFFS2 Empty
summary info causes OOPS".
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
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, b
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
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 derefe
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
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://syz
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
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
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
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 hi
>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 t
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
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
&
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 t
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 t
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
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
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
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
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
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
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
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
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
> pa
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
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: Implemen
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
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
uld 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
O
uld 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 80042548f
uld 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 80042548f
uld 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
O
uld 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 80042548f
uld 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 80042548f
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_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 deletion
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]
901 - 1000 of 8581 matches
Mail list logo
