On Wed, Dec 02, 2020 at 11:19:46AM -0600, Eric W. Biederman wrote:
> Alakesh Haloi writes:
>
> > There has been at least one occurrence where a null pointer derefernce
> > panic was seen with following stack trace.
> >
> > #0 [ff800bcd3800] machine_kexec at ff8008095fb4
> > #1
Alakesh Haloi writes:
> There has been at least one occurrence where a null pointer derefernce
> panic was seen with following stack trace.
>
> #0 [ff800bcd3800] machine_kexec at ff8008095fb4
> #1 [ff800bcd3860] __crash_kexec at ff8008122a30
> #2 [ff800bcd39f0] panic at
Alakesh Haloi writes:
> There has been at least one occurrence where a null pointer derefernce
> panic was seen with following stack trace.
>
> #0 [ff800bcd3800] machine_kexec at ff8008095fb4
> #1 [ff800bcd3860] __crash_kexec at ff8008122a30
> #2 [ff800bcd39f0] panic at
There has been at least one occurrence where a null pointer derefernce
panic was seen with following stack trace.
#0 [ff800bcd3800] machine_kexec at ff8008095fb4
#1 [ff800bcd3860] __crash_kexec at ff8008122a30
#2 [ff800bcd39f0] panic at ff80080aa054
#3
If the task is NULL and the if condition is true
then task->pid would cause null pointer dereference.
Fix this by adding additional null check.
Signed-off-by: Gaurav Singh
---
arch/ia64/kernel/perfmon_default_smpl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Em Wed, Mar 18, 2020 at 10:34:35AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Wed, Mar 18, 2020 at 11:32:24AM +0100, Jiri Olsa escreveu:
> > On Sun, Mar 08, 2020 at 06:59:17PM +0800, zhe...@windriver.com wrote:
> > > From: He Zhe
> > >
> > > NULL pointer may be passed to perf_cpu_map__cpu
On Thu, Nov 9, 2017 at 7:29 PM, Colin King wrote:
> From: Colin Ian King
>
> upcall may be assigned a NULL pointer as genlmsg_put can potentially
> return a NULL. Add a null check to avoid a null pointer dereference
> on upcall.
>
> Detected
On Thu, Nov 9, 2017 at 7:29 PM, Colin King wrote:
> From: Colin Ian King
>
> upcall may be assigned a NULL pointer as genlmsg_put can potentially
> return a NULL. Add a null check to avoid a null pointer dereference
> on upcall.
>
> Detected by CoverityScan, CID#728404 ("Dereference null return
From: Colin Ian King
upcall may be assigned a NULL pointer as genlmsg_put can potentially
return a NULL. Add a null check to avoid a null pointer dereference
on upcall.
Detected by CoverityScan, CID#728404 ("Dereference null return value")
Fixes: commit ccb1352e76cf
From: Colin Ian King
upcall may be assigned a NULL pointer as genlmsg_put can potentially
return a NULL. Add a null check to avoid a null pointer dereference
on upcall.
Detected by CoverityScan, CID#728404 ("Dereference null return value")
Fixes: commit ccb1352e76cf ("net: Add Open vSwitch
+-- On Thu, 4 Apr 2013, Jaegeuk Kim wrote --+
| Why should we take unnecessary locks and an f2fs_submit_bio call?
Yep, we should not. I wasn't sure if these are unnecessary when
a_ops->writepage = NULL.
Thank you.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB
Hi,
2013-04-03 (수), 14:43 +0530, P J P:
> +-- On Wed, 3 Apr 2013, Jaegeuk Kim wrote --+
> | I'm confusing the question because f2fs doesn't use generic_writepages(),
> | since f2fs_write_data_pages() is linked to a_ops->writepages. In
> | do_writepages(), always f2fs_write_data_pages() is
+-- On Wed, 3 Apr 2013, Jaegeuk Kim wrote --+
| I'm confusing the question because f2fs doesn't use generic_writepages(),
| since f2fs_write_data_pages() is linked to a_ops->writepages. In
| do_writepages(), always f2fs_write_data_pages() is triggered instead of
| generic_writepages(). Isn't
Hi,
2013-04-03 (수), 12:30 +0530, P J P:
> +-- On Wed, 3 Apr 2013, Jaegeuk Kim wrote --+
> | diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> | index 47a2d7c..cf9ff5f 100644
> | --- a/fs/f2fs/data.c
> | +++ b/fs/f2fs/data.c
> | @@ -559,6 +559,10 @@ static int f2fs_write_data_pages(struct
> |
+-- On Wed, 3 Apr 2013, Jaegeuk Kim wrote --+
| diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
| index 47a2d7c..cf9ff5f 100644
| --- a/fs/f2fs/data.c
| +++ b/fs/f2fs/data.c
| @@ -559,6 +559,10 @@ static int f2fs_write_data_pages(struct
| address_space *mapping,
| int ret;
| long
Hello Jaegeuk,
+-- On Wed, 3 Apr 2013, Jaegeuk Kim wrote --+
| Therefore, I think f2fs_write_data_pages() is better to handle this. Please
| review the modified patch. Thanks,
|
| diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
| index 47a2d7c..cf9ff5f 100644
| --- a/fs/f2fs/data.c
| +++
+-- On Thu, 4 Apr 2013, Jaegeuk Kim wrote --+
| Why should we take unnecessary locks and an f2fs_submit_bio call?
Yep, we should not. I wasn't sure if these are unnecessary when
a_ops-writepage = NULL.
Thank you.
--
Prasad J Pandit / Red Hat Security Response Team
DB7A 84C5 D3F9 7CD1 B5EB
Hello Jaegeuk,
+-- On Wed, 3 Apr 2013, Jaegeuk Kim wrote --+
| Therefore, I think f2fs_write_data_pages() is better to handle this. Please
| review the modified patch. Thanks,
|
| diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
| index 47a2d7c..cf9ff5f 100644
| --- a/fs/f2fs/data.c
| +++
+-- On Wed, 3 Apr 2013, Jaegeuk Kim wrote --+
| diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
| index 47a2d7c..cf9ff5f 100644
| --- a/fs/f2fs/data.c
| +++ b/fs/f2fs/data.c
| @@ -559,6 +559,10 @@ static int f2fs_write_data_pages(struct
| address_space *mapping,
| int ret;
| long
Hi,
2013-04-03 (수), 12:30 +0530, P J P:
+-- On Wed, 3 Apr 2013, Jaegeuk Kim wrote --+
| diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
| index 47a2d7c..cf9ff5f 100644
| --- a/fs/f2fs/data.c
| +++ b/fs/f2fs/data.c
| @@ -559,6 +559,10 @@ static int f2fs_write_data_pages(struct
| address_space
+-- On Wed, 3 Apr 2013, Jaegeuk Kim wrote --+
| I'm confusing the question because f2fs doesn't use generic_writepages(),
| since f2fs_write_data_pages() is linked to a_ops-writepages. In
| do_writepages(), always f2fs_write_data_pages() is triggered instead of
| generic_writepages(). Isn't it?
Hi,
2013-04-03 (수), 14:43 +0530, P J P:
+-- On Wed, 3 Apr 2013, Jaegeuk Kim wrote --+
| I'm confusing the question because f2fs doesn't use generic_writepages(),
| since f2fs_write_data_pages() is linked to a_ops-writepages. In
| do_writepages(), always f2fs_write_data_pages() is triggered
; Thanks,
>
> ---
> From d3c811a51c7062fb1b66bec910ed346447c02032 Mon Sep 17 00:00:00 2001
> From: P J P
> Date: Wed, 3 Apr 2013 11:38:00 +0900
> Subject: [PATCH] f2fs: add NULL pointer check
> Cc: linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org,
> linux-f2fs-de...@lists.so
:00 2001
From: P J P
Date: Wed, 3 Apr 2013 11:38:00 +0900
Subject: [PATCH] f2fs: add NULL pointer check
Cc: linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-f2fs-de...@lists.sourceforge.net
Commit - fa9150a84c - replaces a call to generic_writepages() in
f2fs_write_data_pages
Hello,
Commit - fa9150a84c - replaces a call to generic_writepages() in
f2fs_write_data_pages() with write_cache_pages(), with a function pointer
argument pointing to routine: __f2fs_writepage.
-> https://git.kernel.org/linus/fa9150a84ca333f68127097c4fa1eda4b3913a22
The patch below adds
Hello,
Commit - fa9150a84c - replaces a call to generic_writepages() in
f2fs_write_data_pages() with write_cache_pages(), with a function pointer
argument pointing to routine: __f2fs_writepage.
- https://git.kernel.org/linus/fa9150a84ca333f68127097c4fa1eda4b3913a22
The patch below adds
:00 2001
From: P J P ppan...@redhat.com
Date: Wed, 3 Apr 2013 11:38:00 +0900
Subject: [PATCH] f2fs: add NULL pointer check
Cc: linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-f2fs-de...@lists.sourceforge.net
Commit - fa9150a84c - replaces a call to generic_writepages
d3c811a51c7062fb1b66bec910ed346447c02032 Mon Sep 17 00:00:00 2001
From: P J P ppan...@redhat.com
Date: Wed, 3 Apr 2013 11:38:00 +0900
Subject: [PATCH] f2fs: add NULL pointer check
Cc: linux-fsde...@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-f2fs-de...@lists.sourceforge.net
Commit
28 matches
Mail list logo