* pagevec: Fix array-index-out-of-bounds error
@ 2023-08-25 0:17 ` Atul Raut
0 siblings, 0 replies; 6+ messages in thread
From: Atul Raut @ 2023-08-25 0:17 UTC (permalink / raw)
To: linux-fsdevel; +Cc: syzbot+e295147e14b474e4ad70, linux-kernel-mentees, willy
Syzkaller reported the following issue:
UBSAN: array-index-out-of-bounds in ./include/linux/pagevec.h:74:2
index 255 is out of range for type 'struct folio *[15]'
CPU: 1 PID: 12841 Comm: syz-executor402 Not tainted 6.5.0-rc7-syzkaller-g35e2132122ba #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
Call trace:
dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233
show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106
dump_stack+0x1c/0x28 lib/dump_stack.c:113
ubsan_epilogue lib/ubsan.c:217 [inline]
__ubsan_handle_out_of_bounds+0xfc/0x148 lib/ubsan.c:348
folio_batch_add include/linux/pagevec.h:74 [inline]
find_lock_entries+0x8fc/0xd84 mm/filemap.c:2089
truncate_inode_pages_range+0x1b0/0xf74 mm/truncate.c:364
truncate_inode_pages mm/truncate.c:449 [inline]
truncate_inode_pages_final+0x90/0xc0 mm/truncate.c:484
ntfs_evict_inode+0x20/0x48 fs/ntfs3/inode.c:1790
evict+0x260/0x68c fs/inode.c:664
iput_final fs/inode.c:1788 [inline]
iput+0x734/0x818 fs/inode.c:1814
ntfs_fill_super+0x3648/0x3f90 fs/ntfs3/super.c:1420
get_tree_bdev+0x378/0x570 fs/super.c:1318
ntfs_fs_get_tree+0x28/0x38 fs/ntfs3/super.c:1647
vfs_get_tree+0x90/0x274 fs/super.c:1519
do_new_mount+0x25c/0x8c8 fs/namespace.c:3335
path_mount+0x590/0xe04 fs/namespace.c:3662
do_mount fs/namespace.c:3675 [inline]
__do_sys_mount fs/namespace.c:3884 [inline]
__se_sys_mount fs/namespace.c:3861 [inline]
__arm64_sys_mount+0x45c/0x594 fs/namespace.c:3861
__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
el0_svc+0x58/0x16c arch/arm64/kernel/entry-common.c:678
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
In folio_batch_add, which contains folios rather
than fixed-size pages, there is a chance that the
array index will fall outside of bounds.
Before adding folios, examine the available space to fix.
The patch is tested via syzbot.
Reported-by: syzbot+e295147e14b474e4ad70@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=e295147e14b474e4ad70
Signed-off-by: Atul Raut <rauji.raut@gmail.com>
---
include/linux/pagevec.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/pagevec.h b/include/linux/pagevec.h
index 87cc678adc85..208f9a99889f 100644
--- a/include/linux/pagevec.h
+++ b/include/linux/pagevec.h
@@ -71,7 +71,9 @@ static inline unsigned int folio_batch_space(struct folio_batch *fbatch)
static inline unsigned folio_batch_add(struct folio_batch *fbatch,
struct folio *folio)
{
- fbatch->folios[fbatch->nr++] = folio;
+ if (folio_batch_space(fbatch))
+ fbatch->folios[fbatch->nr++] = folio;
+
return folio_batch_space(fbatch);
}
--
2.34.1
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply related [flat|nested] 6+ messages in thread
* pagevec: Fix array-index-out-of-bounds error
@ 2023-08-25 0:17 ` Atul Raut
0 siblings, 0 replies; 6+ messages in thread
From: Atul Raut @ 2023-08-25 0:17 UTC (permalink / raw)
To: linux-fsdevel; +Cc: willy, linux-kernel-mentees, syzbot+e295147e14b474e4ad70
Syzkaller reported the following issue:
UBSAN: array-index-out-of-bounds in ./include/linux/pagevec.h:74:2
index 255 is out of range for type 'struct folio *[15]'
CPU: 1 PID: 12841 Comm: syz-executor402 Not tainted 6.5.0-rc7-syzkaller-g35e2132122ba #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023
Call trace:
dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233
show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240
__dump_stack lib/dump_stack.c:88 [inline]
dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106
dump_stack+0x1c/0x28 lib/dump_stack.c:113
ubsan_epilogue lib/ubsan.c:217 [inline]
__ubsan_handle_out_of_bounds+0xfc/0x148 lib/ubsan.c:348
folio_batch_add include/linux/pagevec.h:74 [inline]
find_lock_entries+0x8fc/0xd84 mm/filemap.c:2089
truncate_inode_pages_range+0x1b0/0xf74 mm/truncate.c:364
truncate_inode_pages mm/truncate.c:449 [inline]
truncate_inode_pages_final+0x90/0xc0 mm/truncate.c:484
ntfs_evict_inode+0x20/0x48 fs/ntfs3/inode.c:1790
evict+0x260/0x68c fs/inode.c:664
iput_final fs/inode.c:1788 [inline]
iput+0x734/0x818 fs/inode.c:1814
ntfs_fill_super+0x3648/0x3f90 fs/ntfs3/super.c:1420
get_tree_bdev+0x378/0x570 fs/super.c:1318
ntfs_fs_get_tree+0x28/0x38 fs/ntfs3/super.c:1647
vfs_get_tree+0x90/0x274 fs/super.c:1519
do_new_mount+0x25c/0x8c8 fs/namespace.c:3335
path_mount+0x590/0xe04 fs/namespace.c:3662
do_mount fs/namespace.c:3675 [inline]
__do_sys_mount fs/namespace.c:3884 [inline]
__se_sys_mount fs/namespace.c:3861 [inline]
__arm64_sys_mount+0x45c/0x594 fs/namespace.c:3861
__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
el0_svc+0x58/0x16c arch/arm64/kernel/entry-common.c:678
el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591
In folio_batch_add, which contains folios rather
than fixed-size pages, there is a chance that the
array index will fall outside of bounds.
Before adding folios, examine the available space to fix.
The patch is tested via syzbot.
Reported-by: syzbot+e295147e14b474e4ad70@syzkaller.appspotmail.com
Link: https://syzkaller.appspot.com/bug?extid=e295147e14b474e4ad70
Signed-off-by: Atul Raut <rauji.raut@gmail.com>
---
include/linux/pagevec.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/pagevec.h b/include/linux/pagevec.h
index 87cc678adc85..208f9a99889f 100644
--- a/include/linux/pagevec.h
+++ b/include/linux/pagevec.h
@@ -71,7 +71,9 @@ static inline unsigned int folio_batch_space(struct folio_batch *fbatch)
static inline unsigned folio_batch_add(struct folio_batch *fbatch,
struct folio *folio)
{
- fbatch->folios[fbatch->nr++] = folio;
+ if (folio_batch_space(fbatch))
+ fbatch->folios[fbatch->nr++] = folio;
+
return folio_batch_space(fbatch);
}
--
2.34.1
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: pagevec: Fix array-index-out-of-bounds error
2023-08-25 0:17 ` Atul Raut
@ 2023-08-25 1:56 ` Matthew Wilcox
-1 siblings, 0 replies; 6+ messages in thread
From: Matthew Wilcox @ 2023-08-25 1:56 UTC (permalink / raw)
To: Atul Raut
Cc: linux-fsdevel, linux-kernel-mentees, syzbot+e295147e14b474e4ad70
On Thu, Aug 24, 2023 at 05:17:21PM -0700, Atul Raut wrote:
> ntfs_evict_inode+0x20/0x48 fs/ntfs3/inode.c:1790
No. This is your clue. ntfs corrupts memory. You can't take bug
reports involving ntfs seriously. Ignore everything tagged with ntfs.
> In folio_batch_add, which contains folios rather
> than fixed-size pages, there is a chance that the
> array index will fall outside of bounds.
> Before adding folios, examine the available space to fix.
This is definitely the wrong fix.
> static inline unsigned folio_batch_add(struct folio_batch *fbatch,
> struct folio *folio)
> {
> - fbatch->folios[fbatch->nr++] = folio;
> + if (folio_batch_space(fbatch))
> + fbatch->folios[fbatch->nr++] = folio;
Did you look at what folio_batch_space() actually does?
static inline unsigned int folio_batch_space(struct folio_batch *fbatch)
{
return PAGEVEC_SIZE - fbatch->nr;
}
So if fbatch->nr is 255, what will it return? How will
folio_batch_add() behave?
The right way to fix this problem is to find the data corrupter in NTFS.
You can't "fix" it anywhere else.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: pagevec: Fix array-index-out-of-bounds error
@ 2023-08-25 1:56 ` Matthew Wilcox
0 siblings, 0 replies; 6+ messages in thread
From: Matthew Wilcox @ 2023-08-25 1:56 UTC (permalink / raw)
To: Atul Raut
Cc: linux-fsdevel, syzbot+e295147e14b474e4ad70, linux-kernel-mentees
On Thu, Aug 24, 2023 at 05:17:21PM -0700, Atul Raut wrote:
> ntfs_evict_inode+0x20/0x48 fs/ntfs3/inode.c:1790
No. This is your clue. ntfs corrupts memory. You can't take bug
reports involving ntfs seriously. Ignore everything tagged with ntfs.
> In folio_batch_add, which contains folios rather
> than fixed-size pages, there is a chance that the
> array index will fall outside of bounds.
> Before adding folios, examine the available space to fix.
This is definitely the wrong fix.
> static inline unsigned folio_batch_add(struct folio_batch *fbatch,
> struct folio *folio)
> {
> - fbatch->folios[fbatch->nr++] = folio;
> + if (folio_batch_space(fbatch))
> + fbatch->folios[fbatch->nr++] = folio;
Did you look at what folio_batch_space() actually does?
static inline unsigned int folio_batch_space(struct folio_batch *fbatch)
{
return PAGEVEC_SIZE - fbatch->nr;
}
So if fbatch->nr is 255, what will it return? How will
folio_batch_add() behave?
The right way to fix this problem is to find the data corrupter in NTFS.
You can't "fix" it anywhere else.
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: pagevec: Fix array-index-out-of-bounds error
2023-08-25 1:56 ` Matthew Wilcox
@ 2023-08-25 2:05 ` Atul Raut
-1 siblings, 0 replies; 6+ messages in thread
From: Atul Raut @ 2023-08-25 2:05 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-fsdevel, syzbot+e295147e14b474e4ad70, linux-kernel-mentees
[-- Attachment #1.1: Type: text/plain, Size: 1329 bytes --]
Hello Matthew,
Thank you for your reply, agree with you its seems wrong fix,
will take a look at it.
-Atul
On Fri, Aug 25, 2023 at 02:56:28AM +0100, Matthew Wilcox wrote:
>On Thu, Aug 24, 2023 at 05:17:21PM -0700, Atul Raut wrote:
>> ntfs_evict_inode+0x20/0x48 fs/ntfs3/inode.c:1790
>
>No. This is your clue. ntfs corrupts memory. You can't take bug
>reports involving ntfs seriously. Ignore everything tagged with ntfs.
>
>> In folio_batch_add, which contains folios rather
>> than fixed-size pages, there is a chance that the
>> array index will fall outside of bounds.
>> Before adding folios, examine the available space to fix.
>
>This is definitely the wrong fix.
>
>> static inline unsigned folio_batch_add(struct folio_batch *fbatch,
>> struct folio *folio)
>> {
>> - fbatch->folios[fbatch->nr++] = folio;
>> + if (folio_batch_space(fbatch))
>> + fbatch->folios[fbatch->nr++] = folio;
>
>Did you look at what folio_batch_space() actually does?
>
>static inline unsigned int folio_batch_space(struct folio_batch *fbatch)
>{
> return PAGEVEC_SIZE - fbatch->nr;
>}
>
>So if fbatch->nr is 255, what will it return? How will
>folio_batch_add() behave?
>
>The right way to fix this problem is to find the data corrupter in NTFS.
>You can't "fix" it anywhere else.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
[-- Attachment #2: Type: text/plain, Size: 201 bytes --]
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: pagevec: Fix array-index-out-of-bounds error
@ 2023-08-25 2:05 ` Atul Raut
0 siblings, 0 replies; 6+ messages in thread
From: Atul Raut @ 2023-08-25 2:05 UTC (permalink / raw)
To: Matthew Wilcox
Cc: linux-fsdevel, linux-kernel-mentees, syzbot+e295147e14b474e4ad70
[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]
Hello Matthew,
Thank you for your reply, agree with you its seems wrong fix,
will take a look at it.
-Atul
On Fri, Aug 25, 2023 at 02:56:28AM +0100, Matthew Wilcox wrote:
>On Thu, Aug 24, 2023 at 05:17:21PM -0700, Atul Raut wrote:
>> ntfs_evict_inode+0x20/0x48 fs/ntfs3/inode.c:1790
>
>No. This is your clue. ntfs corrupts memory. You can't take bug
>reports involving ntfs seriously. Ignore everything tagged with ntfs.
>
>> In folio_batch_add, which contains folios rather
>> than fixed-size pages, there is a chance that the
>> array index will fall outside of bounds.
>> Before adding folios, examine the available space to fix.
>
>This is definitely the wrong fix.
>
>> static inline unsigned folio_batch_add(struct folio_batch *fbatch,
>> struct folio *folio)
>> {
>> - fbatch->folios[fbatch->nr++] = folio;
>> + if (folio_batch_space(fbatch))
>> + fbatch->folios[fbatch->nr++] = folio;
>
>Did you look at what folio_batch_space() actually does?
>
>static inline unsigned int folio_batch_space(struct folio_batch *fbatch)
>{
> return PAGEVEC_SIZE - fbatch->nr;
>}
>
>So if fbatch->nr is 255, what will it return? How will
>folio_batch_add() behave?
>
>The right way to fix this problem is to find the data corrupter in NTFS.
>You can't "fix" it anywhere else.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-08-25 2:12 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-08-25 0:17 pagevec: Fix array-index-out-of-bounds error Atul Raut
2023-08-25 0:17 ` Atul Raut
2023-08-25 1:56 ` Matthew Wilcox
2023-08-25 1:56 ` Matthew Wilcox
2023-08-25 2:05 ` Atul Raut
2023-08-25 2:05 ` Atul Raut
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.