Hi,
I encountered the following OOPS when loading a kernel module with insmod. It
occurs
when loading a kernel module with an invalid ELF section header - the Section
name is
invalid and out of bounds into the section name table
access on read at 0x7fc07ec0
Faulting instruction address: 0xc00111d4
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=16K PREEMPT CMPC885
CPU: 0 PID: 353 Comm: sigreturn_vdso Not tainted
5.12.0-rc4-s3k-dev-01553-gb30c310ea220 #4814
NIP: c00111d4 LR
access on read at 0x7fc07ec0
Faulting instruction address: 0xc00111d4
Oops: Kernel access of bad area, sig: 11 [#1]
BE PAGE_SIZE=16K PREEMPT CMPC885
CPU: 0 PID: 353 Comm: sigreturn_vdso Not tainted
5.12.0-rc4-s3k-dev-01553-gb30c310ea220 #4814
NIP: c00111d4 LR
From: Eryk Rybak
[ Upstream commit 347b5650cd158d1d953487cc2bec567af5c5bf96 ]
Fix the reason of kernel oops when i40e driver removed VFs.
Added new __I40E_VFS_RELEASING state to signalize releasing
process by PF, that it makes possible to exit of reset VF procedure.
Without this patch
From: Eryk Rybak
[ Upstream commit 347b5650cd158d1d953487cc2bec567af5c5bf96 ]
Fix the reason of kernel oops when i40e driver removed VFs.
Added new __I40E_VFS_RELEASING state to signalize releasing
process by PF, that it makes possible to exit of reset VF procedure.
Without this patch
From: Eryk Rybak
[ Upstream commit 347b5650cd158d1d953487cc2bec567af5c5bf96 ]
Fix the reason of kernel oops when i40e driver removed VFs.
Added new __I40E_VFS_RELEASING state to signalize releasing
process by PF, that it makes possible to exit of reset VF procedure.
Without this patch
From: Eryk Rybak
[ Upstream commit 347b5650cd158d1d953487cc2bec567af5c5bf96 ]
Fix the reason of kernel oops when i40e driver removed VFs.
Added new __I40E_VFS_RELEASING state to signalize releasing
process by PF, that it makes possible to exit of reset VF procedure.
Without this patch
On Fri, Apr 09, 2021 at 01:02:50PM +0300, Andy Shevchenko wrote:
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> Here is the attempt to start cleaning it up by splitting out panic and
> oops helpers.
>
> There are several purposes of doing thi
On 4/9/21 12:02 PM, Andy Shevchenko wrote:
kernel.h is being used as a dump for all kinds of stuff for a long time.
Here is the attempt to start cleaning it up by splitting out panic and
oops helpers.
There are several purposes of doing this:
- dropping dependency in bug.h
- dropping a loop
On Fri, Apr 09, 2021 at 01:02:50PM +0300, Andy Shevchenko wrote:
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> Here is the attempt to start cleaning it up by splitting out panic and
> oops helpers.
>
> There are several purposes of doing thi
Hi,
On Fri, Apr 09, 2021 at 01:02:50PM +0300, Andy Shevchenko wrote:
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> Here is the attempt to start cleaning it up by splitting out panic and
> oops helpers.
>
> There are several purposes of doing thi
kernel.h is being used as a dump for all kinds of stuff for a long time.
Here is the attempt to start cleaning it up by splitting out panic and
oops helpers.
There are several purposes of doing this:
- dropping dependency in bug.h
- dropping a loop by moving out panic_notifier.h
- unload kernel.h
e:
> > > > kernel.h is being used as a dump for all kinds of stuff for a long time.
> > > > Here is the attempt to start cleaning it up by splitting out panic and
> > > > oops helpers.
> > > >
> > > > At the same time convert users in header and
> Here is the attempt to start cleaning it up by splitting out panic and
> > > oops helpers.
> > >
> > > At the same time convert users in header and lib folder to use new header.
> > > Though for time being include new header back to kernel.h to avoid twisted
On Thu, Apr 08, 2021 at 02:45:12PM +0200, Rasmus Villemoes wrote:
> On 06/04/2021 15.31, Andy Shevchenko wrote:
> > kernel.h is being used as a dump for all kinds of stuff for a long time.
> > Here is the attempt to start cleaning it up by splitting out panic and
> > o
On 06/04/2021 15.31, Andy Shevchenko wrote:
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> Here is the attempt to start cleaning it up by splitting out panic and
> oops helpers.
Yay.
Acked-by: Rasmus Villemoes
> At the same time convert users in he
On Wed, Apr 07, 2021 at 05:59:19PM +0300, Andy Shevchenko wrote:
> On Wed, Apr 7, 2021 at 5:30 PM Luis Chamberlain wrote:
> > On Wed, Apr 07, 2021 at 10:33:44AM +0300, Andy Shevchenko wrote:
> > > On Wed, Apr 7, 2021 at 10:25 AM Luis Chamberlain
> > > wrote:
> > > > On Tue, Apr 06, 2021 at
On Wed, Apr 7, 2021 at 5:30 PM Luis Chamberlain wrote:
> On Wed, Apr 07, 2021 at 10:33:44AM +0300, Andy Shevchenko wrote:
> > On Wed, Apr 7, 2021 at 10:25 AM Luis Chamberlain wrote:
> > > On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
...
> > > Why is it worth it to add
On Wed, Apr 07, 2021 at 10:33:44AM +0300, Andy Shevchenko wrote:
> On Wed, Apr 7, 2021 at 10:25 AM Luis Chamberlain wrote:
> >
> > On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
> > > diff --git a/include/linux/panic_notifier.h
> > > b/include/linux/panic_notifier.h
> > > new
On Wed, Apr 7, 2021 at 11:17 AM Kees Cook wrote:
>
> On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
> > kernel.h is being used as a dump for all kinds of stuff for a long time.
> > Here is the attempt to start cleaning it up by splitting out panic an
On Wed, Apr 7, 2021 at 10:25 AM Luis Chamberlain wrote:
>
> On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
> > diff --git a/include/linux/panic_notifier.h b/include/linux/panic_notifier.h
> > new file mode 100644
> > index ..41e32483d7a7
> > --- /dev/null
> > +++
On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> Here is the attempt to start cleaning it up by splitting out panic and
> oops helpers.
>
> At the same time convert users in header and li
On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> Here is the attempt to start cleaning it up by splitting out panic and
> oops helpers.
>
> At the same time convert users in header and li
On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
> diff --git a/include/linux/panic_notifier.h b/include/linux/panic_notifier.h
> new file mode 100644
> index ..41e32483d7a7
> --- /dev/null
> +++ b/include/linux/panic_notifier.h
> @@ -0,0 +1,12 @@
> +/*
On Tue, Apr 6, 2021 at 3:31 PM Andy Shevchenko
wrote:
>
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> Here is the attempt to start cleaning it up by splitting out panic and
> oops helpers.
>
> At the same time convert users in header and lib folder
On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> Here is the attempt to start cleaning it up by splitting out panic and
> oops helpers.
>
> At the same time convert users in header and li
On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> Here is the attempt to start cleaning it up by splitting out panic and
> oops helpers.
>
> At the same time convert users in header and li
On Tue, Apr 06, 2021 at 04:31:58PM +0300, Andy Shevchenko wrote:
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> Here is the attempt to start cleaning it up by splitting out panic and
> oops helpers.
>
> At the same time convert users in header and li
On Tue 06 Apr 08:31 CDT 2021, Andy Shevchenko wrote:
> kernel.h is being used as a dump for all kinds of stuff for a long time.
> Here is the attempt to start cleaning it up by splitting out panic and
> oops helpers.
>
> At the same time convert users in header and lib folder to
kernel.h is being used as a dump for all kinds of stuff for a long time.
Here is the attempt to start cleaning it up by splitting out panic and
oops helpers.
At the same time convert users in header and lib folder to use new header.
Though for time being include new header back to kernel.h
On 4/3/2021 8:21 AM, Ondrej Mosnacek wrote:
On Sat, Apr 3, 2021 at 4:33 PM Paul Moore wrote:
On Fri, Apr 2, 2021 at 6:35 PM Vijay Balakrishna
wrote:
Seeing oops in 5.4.83 sidtab_context_to_sid(). I checked with Tyler (copied),
he said it might be
https://lore.kernel.org/selinux
On Sat, Apr 3, 2021 at 11:21 AM Ondrej Mosnacek wrote:
> On Sat, Apr 3, 2021 at 4:33 PM Paul Moore wrote:
> > On Fri, Apr 2, 2021 at 6:35 PM Vijay Balakrishna
> > wrote:
> > >
> > > Seeing oops in 5.4.83 sidtab_context_to_sid(). I checked with Tyler
On Sat, Apr 3, 2021 at 4:33 PM Paul Moore wrote:
> On Fri, Apr 2, 2021 at 6:35 PM Vijay Balakrishna
> wrote:
> >
> > Seeing oops in 5.4.83 sidtab_context_to_sid(). I checked with Tyler
> > (copied), he said it might be
> >
>
On Fri, Apr 2, 2021 at 6:35 PM Vijay Balakrishna
wrote:
>
> Seeing oops in 5.4.83 sidtab_context_to_sid(). I checked with Tyler
> (copied), he said it might be
>
> https://lore.kernel.org/selinux/CAFqZXNu8s5edDbSZuSutetTsy58i08vPuP2h-n9=kt34hcp...@mail.gmail.com/
>
> On
ata access on read at 0x7fc07ec0
> Faulting instruction address: 0xc00111d4
> Oops: Kernel access of bad area, sig: 11 [#1]
> BE PAGE_SIZE=16K PREEMPT CMPC885
> CPU: 0 PID: 353 Comm: sigreturn_vdso Not tainted
> 5.12.0-rc4-s3k-dev-01553-gb30c310ea220 #4814
>
PPC32 encounters a KUAP fault when trying to handle a signal with
VDSO unmapped.
Kernel attempted to read user page (7fc07ec0) - exploit attempt? (uid:
0)
BUG: Unable to handle kernel data access on read at 0x7fc07ec0
Faulting instruction address: 0xc00111d4
Oops
Faulting instruction address: 0xc00111d4
> Oops: Kernel access of bad area, sig: 11 [#1]
> BE PAGE_SIZE=16K PREEMPT CMPC885
> CPU: 0 PID: 353 Comm: sigreturn_vdso Not tainted
> 5.12.0-rc4-s3k-dev-01553-gb30c310ea220 #4814
> NIP: c00111d4 LR: c0005a28 CTR:
The oops happens when unbind driver through sysfs as following,
because xhci_mtk_drop_ep() try to drop the endpoint of root hub
which is not added by xhci_add_endpoint() and the virtual device
is not allocated, in fact also needn't drop it, so should skip it.
Call trace:
xhci_mtk_drop_ep+0x1b8
On Thu, 2021-03-11 at 17:09:09 UTC, Kamal Dasu wrote:
> This change makes sure that Broadcom NAND driver moves to interrupt
> polling on the first brcmnand_write() call.
>
> Signed-off-by: Kamal Dasu
Applied to https://git.kernel.org/pub/scm/linux/kernel/git/mtd/linux.git
nand/next, thanks.
PPC32 encounters a KUAP fault when trying to handle a signal with
VDSO unmapped.
Kernel attempted to read user page (7fc07ec0) - exploit attempt? (uid:
0)
BUG: Unable to handle kernel data access on read at 0x7fc07ec0
Faulting instruction address: 0xc00111d4
Oops
The pull request you sent on Mon, 15 Mar 2021 17:24:53 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> tags/afs-fixes-20210315
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1a4431a5db2bf800c647ee0ed87f2727b8d6c29c
Thank you!
--
Hi Linus,
Can you pull these two fixes to the afs filesystem please?
(1) Fix an oops in AFS that can be triggered by accessing one of the
afs.yfs.* xattrs against an OpenAFS server - for instance by "cp
-a"[1], "rsync -X" or getfattr[2]. These try and copy al
This change makes sure that Broadcom NAND driver moves to interrupt
polling on the first brcmnand_write() call.
Signed-off-by: Kamal Dasu
---
drivers/mtd/nand/raw/brcmnand/brcmnand.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/mtd/nand/raw/brcmnand/brcmnand.c
() starting at 128*n bytes before the end of page and
spanning between 8 and 127 bytes into the next page would oops when
the second page is unmapped. It's trivial to reproduce - all
it takes is
main()
{
int fd = open("/dev/zero", O_RDONLY);
char *p = mmap(NULL, 16384, PROT_READ|
() starting at 128*n bytes before the end of page and
spanning between 8 and 127 bytes into the next page would oops when
the second page is unmapped. It's trivial to reproduce - all
it takes is
main()
{
int fd = open("/dev/zero", O_RDONLY);
char *p = mmap(NULL, 16384, PROT_READ|
() starting at 128*n bytes before the end of page and
spanning between 8 and 127 bytes into the next page would oops when
the second page is unmapped. It's trivial to reproduce - all
it takes is
main()
{
int fd = open("/dev/zero", O_RDONLY);
char *p = mmap(NULL, 16384, PROT_READ|
() starting at 128*n bytes before the end of page and
spanning between 8 and 127 bytes into the next page would oops when
the second page is unmapped. It's trivial to reproduce - all
it takes is
main()
{
int fd = open("/dev/zero", O_RDONLY);
char *p = mmap(NULL, 16384, PROT_READ|
() starting at 128*n bytes before the end of page and
spanning between 8 and 127 bytes into the next page would oops when
the second page is unmapped. It's trivial to reproduce - all
it takes is
main()
{
int fd = open("/dev/zero", O_RDONLY);
char *p = mmap(NULL, 16384, PROT_READ|
() starting at 128*n bytes before the end of page and
spanning between 8 and 127 bytes into the next page would oops when
the second page is unmapped. It's trivial to reproduce - all
it takes is
main()
{
int fd = open("/dev/zero", O_RDONLY);
char *p = mmap(NULL, 16384, PROT_READ|
() starting at 128*n bytes before the end of page and
spanning between 8 and 127 bytes into the next page would oops when
the second page is unmapped. It's trivial to reproduce - all
it takes is
main()
{
int fd = open("/dev/zero", O_RDONLY);
char *p = mmap(NULL, 16384, PROT_READ|
From: Russell King
[ Upstream commit 4d62e81b60d4025e2dfcd5ea531cc1394ce9226f ]
Giancarlo Ferrari reports the following oops while trying to use kexec:
Unable to handle kernel paging request at virtual address 80112f38
pgd = fd7ef03e
[80112f38] *pgd=0001141e(bad)
Internal error: Oops: 80d
Jonathan Cameron [2021-02-12 19:12:19]:
Hi Jonathan,
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.96+ #473
>
> So, we moved this into the core a while back (to avoid exactly this sort of
> issue).
> That change predates this introduction of this driver as it went in
> in v5.8
sorry for
From: Russell King
[ Upstream commit 4d62e81b60d4025e2dfcd5ea531cc1394ce9226f ]
Giancarlo Ferrari reports the following oops while trying to use kexec:
Unable to handle kernel paging request at virtual address 80112f38
pgd = fd7ef03e
[80112f38] *pgd=0001141e(bad)
Internal error: Oops: 80d
From: James Smart
[ Upstream commit 8c65830ae1629b03e5d65e9aafae7e2cf5f8b743 ]
In testing, in a configuration with Redfish and native NVMe multipath when
an EEH is injected, a kernel oops is being encountered:
(unreliable)
lpfc_nvme_ls_req+0x328/0x720 [lpfc]
__nvme_fc_send_ls_req.constprop.13
From: Russell King
[ Upstream commit 4d62e81b60d4025e2dfcd5ea531cc1394ce9226f ]
Giancarlo Ferrari reports the following oops while trying to use kexec:
Unable to handle kernel paging request at virtual address 80112f38
pgd = fd7ef03e
[80112f38] *pgd=0001141e(bad)
Internal error: Oops: 80d
On Mon, 8 Feb 2021 23:39:47 +0100
Petr Štetiar wrote:
> My machine Oopsed while testing SCD30 sensor in interrupt driven mode:
>
> Unable to handle kernel NULL pointer dereference at virtual address 0188
> pgd = (ptrval)
> [0188] *pgd=
> Internal error: Oo
: Borislav Petkov
CommitterDate: Wed, 10 Feb 2021 14:33:36 +01:00
x86/fault: Split the OOPS code out from no_context()
Not all callers of no_context() want to run exception fixups.
Separate the OOPS code out from the fixup code in no_context().
Signed-off-by: Andy Lutomirski
Signed-off
Not all callers of no_context() want to run exception fixups.
Separate the OOPS code out from the fixup code in no_context().
Cc: Dave Hansen
Cc: Peter Zijlstra
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 116 +++-
1 file changed, 62
On Wed, Feb 3, 2021 at 10:56 AM Borislav Petkov wrote:
>
> On Sun, Jan 31, 2021 at 09:24:38AM -0800, Andy Lutomirski wrote:
> > Not all callers of no_context() want to run exception fixups.
> > Separate the OOPS code out from the fixup code in no_context().
> >
> >
My machine Oopsed while testing SCD30 sensor in interrupt driven mode:
Unable to handle kernel NULL pointer dereference at virtual address 0188
pgd = (ptrval)
[0188] *pgd=
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted
From: Russell King
[ Upstream commit 4d62e81b60d4025e2dfcd5ea531cc1394ce9226f ]
Giancarlo Ferrari reports the following oops while trying to use kexec:
Unable to handle kernel paging request at virtual address 80112f38
pgd = fd7ef03e
[80112f38] *pgd=0001141e(bad)
Internal error: Oops: 80d
From: Russell King
[ Upstream commit 4d62e81b60d4025e2dfcd5ea531cc1394ce9226f ]
Giancarlo Ferrari reports the following oops while trying to use kexec:
Unable to handle kernel paging request at virtual address 80112f38
pgd = fd7ef03e
[80112f38] *pgd=0001141e(bad)
Internal error: Oops: 80d
From: Russell King
[ Upstream commit 4d62e81b60d4025e2dfcd5ea531cc1394ce9226f ]
Giancarlo Ferrari reports the following oops while trying to use kexec:
Unable to handle kernel paging request at virtual address 80112f38
pgd = fd7ef03e
[80112f38] *pgd=0001141e(bad)
Internal error: Oops: 80d
From: James Smart
[ Upstream commit 8c65830ae1629b03e5d65e9aafae7e2cf5f8b743 ]
In testing, in a configuration with Redfish and native NVMe multipath when
an EEH is injected, a kernel oops is being encountered:
(unreliable)
lpfc_nvme_ls_req+0x328/0x720 [lpfc]
__nvme_fc_send_ls_req.constprop.13
going to oops anyway...
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
> On Feb 3, 2021, at 10:56 AM, Borislav Petkov wrote:
>
> On Sun, Jan 31, 2021 at 09:24:38AM -0800, Andy Lutomirski wrote:
>> Not all callers of no_context() want to run exception fixups.
>> Separate the OOPS code out from the fixup code in no_context().
>>
>&
On Sun, Jan 31, 2021 at 09:24:38AM -0800, Andy Lutomirski wrote:
> Not all callers of no_context() want to run exception fixups.
> Separate the OOPS code out from the fixup code in no_context().
>
> Cc: Dave Hansen
> Cc: Peter Zijlstra
> Signed-off-by: Andy Lutomirski
&g
From: Ricardo Ribalda
[ Upstream commit c1c3ba1f78354a20222d291ed6fedd17b7a74fd7 ]
If dobj->control is not initialized we end up in an OOPs during
skl_tplg_complete:
[ 26.553358] BUG: kernel NULL pointer dereference, address:
0078
[ 26.561151] #PF: supervisor read acc
in kernel mode
#PF: error_code(0x0002) - not-present page
PGD ad001067 P4D ad001067 PUD 0
Oops: 0002 [#1] SMP PTI
CPU: 3 PID: 30 Comm: ksoftirqd/3 Kdump: loaded Not tainted
5.4.52-050452-generic #202007160732
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7
04/01/2014
in kernel mode
#PF: error_code(0x0002) - not-present page
PGD ad001067 P4D ad001067 PUD 0
Oops: 0002 [#1] SMP PTI
CPU: 3 PID: 30 Comm: ksoftirqd/3 Kdump: loaded Not tainted
5.4.52-050452-generic #202007160732
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7
04/01/2014
in kernel mode
#PF: error_code(0x0002) - not-present page
PGD ad001067 P4D ad001067 PUD 0
Oops: 0002 [#1] SMP PTI
CPU: 3 PID: 30 Comm: ksoftirqd/3 Kdump: loaded Not tainted
5.4.52-050452-generic #202007160732
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7
04/01/2014
in kernel mode
#PF: error_code(0x0002) - not-present page
PGD ad001067 P4D ad001067 PUD 0
Oops: 0002 [#1] SMP PTI
CPU: 3 PID: 30 Comm: ksoftirqd/3 Kdump: loaded Not tainted
5.4.52-050452-generic #202007160732
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7
04/01/2014
in kernel mode
#PF: error_code(0x0002) - not-present page
PGD ad001067 P4D ad001067 PUD 0
Oops: 0002 [#1] SMP PTI
CPU: 3 PID: 30 Comm: ksoftirqd/3 Kdump: loaded Not tainted
5.4.52-050452-generic #202007160732
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7
04/01/2014
in kernel mode
#PF: error_code(0x0002) - not-present page
PGD ad001067 P4D ad001067 PUD 0
Oops: 0002 [#1] SMP PTI
CPU: 3 PID: 30 Comm: ksoftirqd/3 Kdump: loaded Not tainted
5.4.52-050452-generic #202007160732
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7
04/01/2014
On Tue, Feb 02, 2021 at 07:37:57AM -0500, Jeff Layton wrote:
> On Tue, 2021-02-02 at 08:47 +0300, Dan Carpenter wrote:
> > The "req" pointer is an error pointer and not NULL so this check needs
> > to be fixed.
> >
> > Fixes: 1cf7fdf52d5a ("ceph: convert readpage to fscache read helper")
> >
On Tue, Feb 02, 2021 at 08:10:41AM -0500, Jeff Layton wrote:
> Dan reported a potential oops in the cleanup if ceph_osdc_new_request
> returns an error. Eliminate the unneeded initialization of "req" and
> then just set it to NULL in the case where it holds an ERR_PTR.
>
>
From: Ricardo Ribalda
[ Upstream commit c1c3ba1f78354a20222d291ed6fedd17b7a74fd7 ]
If dobj->control is not initialized we end up in an OOPs during
skl_tplg_complete:
[ 26.553358] BUG: kernel NULL pointer dereference, address:
0078
[ 26.561151] #PF: supervisor read acc
Dan reported a potential oops in the cleanup if ceph_osdc_new_request
returns an error. Eliminate the unneeded initialization of "req" and
then just set it to NULL in the case where it holds an ERR_PTR.
Also, drop the unneeded NULL check before calling
ceph_osdc_put_request.
Fixes: 1c
On Tue, 2021-02-02 at 08:47 +0300, Dan Carpenter wrote:
> The "req" pointer is an error pointer and not NULL so this check needs
> to be fixed.
>
> Fixes: 1cf7fdf52d5a ("ceph: convert readpage to fscache read helper")
> Signed-off-by: Dan Carpenter
> ---
> fs/ceph/addr.c | 2 +-
> 1 file
On Tue, Feb 2, 2021 at 6:47 AM Dan Carpenter wrote:
>
> The "req" pointer is an error pointer and not NULL so this check needs
> to be fixed.
>
> Fixes: 1cf7fdf52d5a ("ceph: convert readpage to fscache read helper")
> Signed-off-by: Dan Carpenter
> ---
> fs/ceph/addr.c | 2 +-
> 1 file changed,
The "req" pointer is an error pointer and not NULL so this check needs
to be fixed.
Fixes: 1cf7fdf52d5a ("ceph: convert readpage to fscache read helper")
Signed-off-by: Dan Carpenter
---
fs/ceph/addr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ceph/addr.c
Not all callers of no_context() want to run exception fixups.
Separate the OOPS code out from the fixup code in no_context().
Cc: Dave Hansen
Cc: Peter Zijlstra
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 116 +++-
1 file changed, 62
From: Xiaoming Ni
commit 697edcb0e4eadc41645fe88c991fe6a206b1a08d upstream.
The process_sysctl_arg() does not check whether val is empty before
invoking strlen(val). If the command line parameter () is incorrectly
configured and val is empty, oops is triggered.
For example:
"hung_task_
On Fri, Jan 22, 2021 at 09:16:38PM +0530, Naresh Kamboju wrote:
> On Fri, 22 Jan 2021 at 21:07, Paul E. McKenney wrote:
> >
> > On Fri, Jan 22, 2021 at 03:21:07PM +0530, Naresh Kamboju wrote:
> > > On Fri, 22 Jan 2021 at 03:13, Paul E. McKenney wrote:
> > > >
> > > > On Thu, Jan 21, 2021 at
On Fri, 22 Jan 2021 at 21:07, Paul E. McKenney wrote:
>
> On Fri, Jan 22, 2021 at 03:21:07PM +0530, Naresh Kamboju wrote:
> > On Fri, 22 Jan 2021 at 03:13, Paul E. McKenney wrote:
> > >
> > > On Thu, Jan 21, 2021 at 09:31:10PM +, Will Deacon wrote:
> > > > On Thu, Jan 21, 2021 at 10:55:21AM
On Fri, Jan 22, 2021 at 03:21:07PM +0530, Naresh Kamboju wrote:
> On Fri, 22 Jan 2021 at 03:13, Paul E. McKenney wrote:
> >
> > On Thu, Jan 21, 2021 at 09:31:10PM +, Will Deacon wrote:
> > > On Thu, Jan 21, 2021 at 10:55:21AM -0800, Paul E. McKenney wrote:
> > > > On Thu, Jan 21, 2021 at
On 1/22/21 10:02 AM, Mark Rutland wrote:
> On Thu, Jan 21, 2021 at 01:43:14PM -0800, Paul E. McKenney wrote:
>> On Thu, Jan 21, 2021 at 09:31:10PM +, Will Deacon wrote:
>>> On Thu, Jan 21, 2021 at 10:55:21AM -0800, Paul E. McKenney wrote:
On Thu, Jan 21, 2021 at 10:37:21PM +0530,
On Thu, Jan 21, 2021 at 01:43:14PM -0800, Paul E. McKenney wrote:
> On Thu, Jan 21, 2021 at 09:31:10PM +, Will Deacon wrote:
> > On Thu, Jan 21, 2021 at 10:55:21AM -0800, Paul E. McKenney wrote:
> > > On Thu, Jan 21, 2021 at 10:37:21PM +0530, Naresh Kamboju wrote:
> > > > While running
On Fri, 22 Jan 2021 at 03:13, Paul E. McKenney wrote:
>
> On Thu, Jan 21, 2021 at 09:31:10PM +, Will Deacon wrote:
> > On Thu, Jan 21, 2021 at 10:55:21AM -0800, Paul E. McKenney wrote:
> > > On Thu, Jan 21, 2021 at 10:37:21PM +0530, Naresh Kamboju wrote:
> > > > While running rcu-torture test
On Thu, Jan 21, 2021 at 09:31:10PM +, Will Deacon wrote:
> On Thu, Jan 21, 2021 at 10:55:21AM -0800, Paul E. McKenney wrote:
> > On Thu, Jan 21, 2021 at 10:37:21PM +0530, Naresh Kamboju wrote:
> > > While running rcu-torture test on qemu_arm64 and arm64 Juno-r2 device
> > > the following
On Thu, Jan 21, 2021 at 10:55:21AM -0800, Paul E. McKenney wrote:
> On Thu, Jan 21, 2021 at 10:37:21PM +0530, Naresh Kamboju wrote:
> > While running rcu-torture test on qemu_arm64 and arm64 Juno-r2 device
> > the following kernel crash noticed. This started happening from Linux next
> >
On Thu, 21 Jan 2021 18:16:43 +0100, Ricardo Ribalda wrote:
> If dobj->control is not initialized we end up in an OOPs during
> skl_tplg_complete:
>
> [ 26.553358] BUG: kernel NULL pointer dereference, address:
> 0078
> [ 26.561151] #PF: supervisor read
nR = 0
> [ 621.569571] user pgtable: 4k pages, 48-bit VAs, pgdp=000101ef
> [ 621.572446] [0008] pgd=000102ee1003,
> p4d=000102ee1003, pud=000100b25003, pmd=
> [ 621.577007] Internal error: Oops: 9606 [#1] PREEMPT SMP
> [ 621.579359] Modul
If dobj->control is not initialized we end up in an OOPs during
skl_tplg_complete:
[ 26.553358] BUG: kernel NULL pointer dereference, address:
0078
[ 26.561151] #PF: supervisor read access in kernel mode
[ 26.566897] #PF: error_code(0x) - not-present page
[ 26.572642]
On Thu, Jan 21, 2021 at 06:16:43PM +0100, Ricardo Ribalda wrote:
> If dobj->control is not initialized we end up in an OOPs during
> skl_tplg_complete:
>
> [ 26.553358] BUG: kernel NULL pointer dereference, address:
> 0078
> [ 26.561151] #PF: supervisor read
Thanks Ricardo - I have checked it on Eve/Google Pixelbook
Tested-by: Lukasz Majczak
czw., 21 sty 2021 o 18:33 Rojewski, Cezary
napisał(a):
>
> On 2021-01-21 6:16 PM, Ricardo Ribalda wrote:
> > If dobj->control is not initialized we end up in an OOPs during
> &
On 2021-01-21 6:16 PM, Ricardo Ribalda wrote:
> If dobj->control is not initialized we end up in an OOPs during
> skl_tplg_complete:
>
> [ 26.553358] BUG: kernel NULL pointer dereference, address:
> 0078
> [ 26.561151] #PF: supervisor read access in kernel
Hi,
This is just a v2 from my patch from December with the ={}: in a second patch.
Best regards!
On Thu, Jan 21, 2021 at 6:16 PM Ricardo Ribalda wrote:
>
> If dobj->control is not initialized we end up in an OOPs during
> skl_tplg_complete:
>
> [ 26.553358] BUG: k
If dobj->control is not initialized we end up in an OOPs during
skl_tplg_complete:
[ 26.553358] BUG: kernel NULL pointer dereference, address:
0078
[ 26.561151] #PF: supervisor read access in kernel mode
[ 26.566897] #PF: error_code(0x) - not-present page
[ 26.572642]
[ 621.577007] Internal error: Oops: 9606 [#1] PREEMPT SMP
[ 621.579359] Modules linked in: rcutorture(-) torture rfkill crct10dif_ce fuse
[ 621.582549] CPU: 2 PID: 422 Comm: rcu_torture_sta Not tainted
5.11.0-rc2-next-20210111 #2
[ 621.585294] Hardware name: linux,dummy-virt (DT)
[ 621.586671] pstate
1 - 100 of 16129 matches
Mail list logo
