LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* KASAN: stack-out-of-bounds in iov_iter_revert
@ 2021-07-31 18:21 Sudip Mukherjee
  2021-08-01  0:10 ` Pavel Begunkov
  0 siblings, 1 reply; 9+ messages in thread
From: Sudip Mukherjee @ 2021-07-31 18:21 UTC (permalink / raw)
  To: Jens Axboe, Pavel Begunkov; +Cc: io-uring, linux-kernel

Hi Jens, Pavel,

We had been running syzkaller on v5.10.y and a "KASAN:
stack-out-of-bounds in iov_iter_revert" was being reported on it. I
got some time to check that today and have managed to get a syzkaller
reproducer. I dont have a C reproducer which I can share but I can use
the syz-reproducer to reproduce this with v5.14-rc3 and also with
next-20210730.

==================================================================
[   74.211232] BUG: KASAN: stack-out-of-bounds in iov_iter_revert+0x809/0x900
[   74.212778] Read of size 8 at addr ffff888025dc78b8 by task
syz-executor.0/828

[   74.214756] CPU: 0 PID: 828 Comm: syz-executor.0 Not tainted
5.14.0-rc3-next-20210730 #1
[   74.216525] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[   74.219033] Call Trace:
[   74.219683]  dump_stack_lvl+0x8b/0xb3
[   74.220706]  print_address_description.constprop.0+0x1f/0x140
[   74.222272]  ? iov_iter_revert+0x809/0x900
[   74.223285]  ? iov_iter_revert+0x809/0x900
[   74.224226]  kasan_report.cold+0x7f/0x11b
[   74.225147]  ? iov_iter_revert+0x809/0x900
[   74.226085]  iov_iter_revert+0x809/0x900
[   74.227002]  ? lock_is_held_type+0x98/0x110
[   74.227960]  io_write+0x57d/0xe40
[   74.228730]  ? io_read+0x10d0/0x10d0
[   74.229550]  ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0
[   74.230746]  ? lock_is_held_type+0x98/0x110
[   74.231699]  ? __lock_acquire+0xbb1/0x5b00
[   74.232647]  io_issue_sqe+0x4da/0x6a80
[   74.233507]  ? mark_lock+0xfc/0x2d80
[   74.234349]  ? __is_insn_slot_addr+0x14d/0x250
[   74.235385]  ? lock_chain_count+0x20/0x20
[   74.236312]  ? io_write+0xe40/0xe40
[   74.237119]  ? lock_is_held_type+0x98/0x110
[   74.238076]  ? find_held_lock+0x2c/0x110
[   74.238992]  ? lock_release+0x1dd/0x6b0
[   74.239874]  ? __fget_files+0x21c/0x3e0
[   74.240757]  ? lock_downgrade+0x6d0/0x6d0
[   74.241672]  ? lock_release+0x1dd/0x6b0
[   74.242578]  __io_queue_sqe+0x1ac/0xe60
[   74.243471]  ? io_issue_sqe+0x6a80/0x6a80
[   74.244402]  ? lock_is_held_type+0x98/0x110
[   74.245358]  io_submit_sqes+0x3f6e/0x76a0
[   74.246281]  ? xa_load+0x158/0x290
[   74.247113]  ? __do_sys_io_uring_enter+0x90c/0x1a20
[   74.248207]  __do_sys_io_uring_enter+0x90c/0x1a20
[   74.249277]  ? vm_mmap_pgoff+0xe8/0x280
[   74.250163]  ? io_submit_sqes+0x76a0/0x76a0
[   74.251149]  ? randomize_stack_top+0x100/0x100
[   74.252178]  ? __do_sys_futex+0xf2/0x3d0
[   74.253074]  ? __do_sys_futex+0xfb/0x3d0
[   74.253980]  ? do_futex+0x18c0/0x18c0
[   74.254852]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[   74.256022]  ? syscall_enter_from_user_mode+0x1d/0x50
[   74.257167]  do_syscall_64+0x3b/0x90
[   74.257984]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[   74.259125] RIP: 0033:0x466609
[   74.259830] Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40
00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89
01 48
[   74.263910] RSP: 002b:00007ffdb23903f8 EFLAGS: 00000246 ORIG_RAX:
00000000000001aa
[   74.265579] RAX: ffffffffffffffda RBX: 000000000056bf80 RCX: 0000000000466609
[   74.267162] RDX: 0000000000000000 RSI: 00000000000058ab RDI: 0000000000000003
[   74.268745] RBP: 00000000004bfcb9 R08: 0000000000000000 R09: 0000000000000000
[   74.270303] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056bf80
[   74.271899] R13: 00007ffdb2390590 R14: 000000000056bf80 R15: 000000000001215c

[   74.273856] The buggy address belongs to the page:
[   74.274948] page:00000000bd0ec836 refcount:0 mapcount:0
mapping:0000000000000000 index:0x0 pfn:0x25dc7
[   74.277000] flags: 0x100000000000000(node=0|zone=1)
[   74.278119] raw: 0100000000000000 0000000000000000 ffffea00009771c8
0000000000000000
[   74.279853] raw: 0000000000000000 0000000000000000 00000000ffffffff
0000000000000000
[   74.281553] page dumped because: kasan: bad access detected

[   74.283166] addr ffff888025dc78b8 is located in stack of task
syz-executor.0/828 at offset 152 in frame:
[   74.285238]  io_write+0x0/0xe40

[   74.286338] this frame has 3 objects:
[   74.287170]  [48, 56) 'iovec'
[   74.287185]  [80, 120) '__iter'
[   74.287863]  [160, 288) 'inline_vecs'

[   74.289751] Memory state around the buggy address:
[   74.290825]  ffff888025dc7780: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[   74.292421]  ffff888025dc7800: 00 00 00 00 f1 f1 f1 f1 00 00 00 f2
f2 f2 00 00
[   74.294022] >ffff888025dc7880: 00 00 00 f2 f2 f2 f2 f2 00 00 00 00
00 00 00 00
[   74.295639]                                         ^
[   74.296766]  ffff888025dc7900: 00 00 00 00 00 00 00 00 f3 f3 f3 f3
00 00 00 00
[   74.298373]  ffff888025dc7980: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[   74.299959] ==================================================================


Not sure if this has been already reported or not, but I will be happy
to test if you have a fix for this.


-- 
Regards
Sudip

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: KASAN: stack-out-of-bounds in iov_iter_revert
  2021-07-31 18:21 KASAN: stack-out-of-bounds in iov_iter_revert Sudip Mukherjee
@ 2021-08-01  0:10 ` Pavel Begunkov
  2021-08-01  8:52   ` Pavel Begunkov
  0 siblings, 1 reply; 9+ messages in thread
From: Pavel Begunkov @ 2021-08-01  0:10 UTC (permalink / raw)
  To: Sudip Mukherjee, Jens Axboe; +Cc: io-uring, linux-kernel

On 7/31/21 7:21 PM, Sudip Mukherjee wrote:
> Hi Jens, Pavel,
> 
> We had been running syzkaller on v5.10.y and a "KASAN:
> stack-out-of-bounds in iov_iter_revert" was being reported on it. I
> got some time to check that today and have managed to get a syzkaller
> reproducer. I dont have a C reproducer which I can share but I can use
> the syz-reproducer to reproduce this with v5.14-rc3 and also with
> next-20210730.

Can you try out the diff below? Not a full-fledged fix, but need to
check a hunch.

If that's important, I was using this branch:
git://git.kernel.dk/linux-block io_uring-5.14


diff --git a/fs/io_uring.c b/fs/io_uring.c
index bf548af0426c..fdcd25eca67d 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -3316,6 +3316,10 @@ static int io_read(struct io_kiocb *req, unsigned int issue_flags)
 		/* no retry on NONBLOCK nor RWF_NOWAIT */
 		if (req->flags & REQ_F_NOWAIT)
 			goto done;
+		if (WARN_ON_ONCE(iter->truncated)) {
+			iov_iter_reexpand(iter, iov_iter_count(iter) + iter->truncated);
+			iter->truncated = 0;
+		}
 		/* some cases will consume bytes even on error returns */
 		iov_iter_revert(iter, io_size - iov_iter_count(iter));
 		ret = 0;
@@ -3455,6 +3459,10 @@ static int io_write(struct io_kiocb *req, unsigned int issue_flags)
 		kiocb_done(kiocb, ret2, issue_flags);
 	} else {
 copy_iov:
+		if (WARN_ON_ONCE(iter->truncated)) {
+			iov_iter_reexpand(iter, iov_iter_count(iter) + iter->truncated);
+			iter->truncated = 0;
+		}
 		/* some cases will consume bytes even on error returns */
 		iov_iter_revert(iter, io_size - iov_iter_count(iter));
 		ret = io_setup_async_rw(req, iovec, inline_vecs, iter, false);
diff --git a/include/linux/uio.h b/include/linux/uio.h
index 82c3c3e819e0..eff06d139fd4 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -30,6 +30,7 @@ enum iter_type {
 struct iov_iter {
 	u8 iter_type;
 	bool data_source;
+	u16 truncated;
 	size_t iov_offset;
 	size_t count;
 	union {
@@ -254,8 +255,10 @@ static inline void iov_iter_truncate(struct iov_iter *i, u64 count)
 	 * conversion in assignement is by definition greater than all
 	 * values of size_t, including old i->count.
 	 */
-	if (i->count > count)
+	if (i->count > count) {
+		i->truncated += i->count - count;
 		i->count = count;
+	}
 }
 
 /*
@@ -264,6 +267,8 @@ static inline void iov_iter_truncate(struct iov_iter *i, u64 count)
  */
 static inline void iov_iter_reexpand(struct iov_iter *i, size_t count)
 {
+	WARN_ON_ONCE(i->count > count);
+	i->truncated -= count - i->count;
 	i->count = count;
 }

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: KASAN: stack-out-of-bounds in iov_iter_revert
  2021-08-01  0:10 ` Pavel Begunkov
@ 2021-08-01  8:52   ` Pavel Begunkov
  2021-08-01 20:28     ` Sudip Mukherjee
  0 siblings, 1 reply; 9+ messages in thread
From: Pavel Begunkov @ 2021-08-01  8:52 UTC (permalink / raw)
  To: Sudip Mukherjee, Jens Axboe; +Cc: io-uring, linux-kernel

On 8/1/21 1:10 AM, Pavel Begunkov wrote:
> On 7/31/21 7:21 PM, Sudip Mukherjee wrote:
>> Hi Jens, Pavel,
>>
>> We had been running syzkaller on v5.10.y and a "KASAN:
>> stack-out-of-bounds in iov_iter_revert" was being reported on it. I
>> got some time to check that today and have managed to get a syzkaller
>> reproducer. I dont have a C reproducer which I can share but I can use
>> the syz-reproducer to reproduce this with v5.14-rc3 and also with
>> next-20210730.
> 
> Can you try out the diff below? Not a full-fledged fix, but need to
> check a hunch.
> 
> If that's important, I was using this branch:
> git://git.kernel.dk/linux-block io_uring-5.14

Or better this one, just in case it ooopses on warnings.

diff --git a/fs/io_uring.c b/fs/io_uring.c
index bf548af0426c..12284616854b 100644
--- a/fs/io_uring.c
+++ b/fs/io_uring.c
@@ -3316,6 +3316,11 @@ static int io_read(struct io_kiocb *req, unsigned int issue_flags)
 		/* no retry on NONBLOCK nor RWF_NOWAIT */
 		if (req->flags & REQ_F_NOWAIT)
 			goto done;
+		if (iter->truncated) {
+			printk("truncated rd: %i\n", (int)iter->truncated);
+			iov_iter_reexpand(iter, iov_iter_count(iter) + iter->truncated);
+			iter->truncated = 0;
+		}
 		/* some cases will consume bytes even on error returns */
 		iov_iter_revert(iter, io_size - iov_iter_count(iter));
 		ret = 0;
@@ -3455,6 +3460,11 @@ static int io_write(struct io_kiocb *req, unsigned int issue_flags)
 		kiocb_done(kiocb, ret2, issue_flags);
 	} else {
 copy_iov:
+		if (iter->truncated) {
+			printk("truncated wr: %i\n", (int)iter->truncated);
+			iov_iter_reexpand(iter, iov_iter_count(iter) + iter->truncated);
+			iter->truncated = 0;
+		}
 		/* some cases will consume bytes even on error returns */
 		iov_iter_revert(iter, io_size - iov_iter_count(iter));
 		ret = io_setup_async_rw(req, iovec, inline_vecs, iter, false);
diff --git a/include/linux/uio.h b/include/linux/uio.h
index 82c3c3e819e0..eff06d139fd4 100644
--- a/include/linux/uio.h
+++ b/include/linux/uio.h
@@ -30,6 +30,7 @@ enum iter_type {
 struct iov_iter {
 	u8 iter_type;
 	bool data_source;
+	u16 truncated;
 	size_t iov_offset;
 	size_t count;
 	union {
@@ -254,8 +255,10 @@ static inline void iov_iter_truncate(struct iov_iter *i, u64 count)
 	 * conversion in assignement is by definition greater than all
 	 * values of size_t, including old i->count.
 	 */
-	if (i->count > count)
+	if (i->count > count) {
+		i->truncated += i->count - count;
 		i->count = count;
+	}
 }
 
 /*
@@ -264,6 +267,8 @@ static inline void iov_iter_truncate(struct iov_iter *i, u64 count)
  */
 static inline void iov_iter_reexpand(struct iov_iter *i, size_t count)
 {
+	WARN_ON_ONCE(i->count > count);
+	i->truncated -= count - i->count;
 	i->count = count;
 }
 


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: KASAN: stack-out-of-bounds in iov_iter_revert
  2021-08-01  8:52   ` Pavel Begunkov
@ 2021-08-01 20:28     ` Sudip Mukherjee
  2021-08-02 11:55       ` Pavel Begunkov
  0 siblings, 1 reply; 9+ messages in thread
From: Sudip Mukherjee @ 2021-08-01 20:28 UTC (permalink / raw)
  To: Pavel Begunkov; +Cc: Jens Axboe, io-uring, linux-kernel

Hi Pavel,

On Sun, Aug 1, 2021 at 9:52 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>
> On 8/1/21 1:10 AM, Pavel Begunkov wrote:
> > On 7/31/21 7:21 PM, Sudip Mukherjee wrote:
> >> Hi Jens, Pavel,
> >>
> >> We had been running syzkaller on v5.10.y and a "KASAN:
> >> stack-out-of-bounds in iov_iter_revert" was being reported on it. I
> >> got some time to check that today and have managed to get a syzkaller
> >> reproducer. I dont have a C reproducer which I can share but I can use
> >> the syz-reproducer to reproduce this with v5.14-rc3 and also with
> >> next-20210730.
> >
> > Can you try out the diff below? Not a full-fledged fix, but need to
> > check a hunch.
> >
> > If that's important, I was using this branch:
> > git://git.kernel.dk/linux-block io_uring-5.14
>
> Or better this one, just in case it ooopses on warnings.

I tested this one on top of "git://git.kernel.dk/linux-block
io_uring-5.14" and the issue was still seen, but after the BUG trace I
got lots of "truncated wr" message. The trace is:

[   80.722255] BUG: KASAN: stack-out-of-bounds in iov_iter_revert+0x809/0x900
[   80.723126] Read of size 8 at addr ffff8880246ff8b8 by task
syz-executor.10/7001
[   80.724070]
[   80.724274] CPU: 0 PID: 7001 Comm: syz-executor.10 Not tainted 5.14.0-rc1 #1
[   80.725200] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
[   80.726688] Call Trace:
[   80.727031]  dump_stack_lvl+0x8b/0xb3
[   80.727520]  print_address_description.constprop.0+0x1f/0x140
[   80.728307]  ? iov_iter_revert+0x809/0x900
[   80.728840]  ? iov_iter_revert+0x809/0x900
[   80.729358]  kasan_report.cold+0x7f/0x11b
[   80.729873]  ? iov_iter_revert+0x809/0x900
[   80.730406]  iov_iter_revert+0x809/0x900
[   80.730908]  io_write+0x5c9/0xe90
[   80.731356]  ? io_read+0x1140/0x1140
[   80.731835]  ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0
[   80.732486]  ? lock_is_held_type+0x98/0x110
[   80.733029]  ? __lock_acquire+0xbb1/0x5b00
[   80.733541]  io_issue_sqe+0x4da/0x6a80
[   80.734063]  ? mark_lock+0xfc/0x2d80
[   80.734539]  ? __is_insn_slot_addr+0x14d/0x250
[   80.735169]  ? lock_chain_count+0x20/0x20
[   80.735702]  ? io_write+0xe90/0xe90
[   80.736167]  ? lock_is_held_type+0x98/0x110
[   80.736797]  ? find_held_lock+0x2c/0x110
[   80.737363]  ? lock_release+0x1dd/0x6b0
[   80.737897]  ? __fget_files+0x21c/0x3e0
[   80.738445]  ? lock_downgrade+0x6d0/0x6d0
[   80.738993]  ? lock_release+0x1dd/0x6b0
[   80.739507]  __io_queue_sqe+0x1ac/0xe50
[   80.740017]  ? io_issue_sqe+0x6a80/0x6a80
[   80.740564]  ? lock_is_held_type+0x98/0x110
[   80.741142]  io_submit_sqes+0x3f6e/0x76a0
[   80.741688]  ? xa_load+0x158/0x290
[   80.742173]  ? __do_sys_io_uring_enter+0x90c/0x1a20
[   80.742817]  __do_sys_io_uring_enter+0x90c/0x1a20
[   80.743436]  ? vm_mmap_pgoff+0xe8/0x280
[   80.743981]  ? io_submit_sqes+0x76a0/0x76a0
[   80.744539]  ? randomize_stack_top+0x100/0x100
[   80.745228]  ? __do_sys_futex+0xf2/0x3d0
[   80.745763]  ? __do_sys_futex+0xfb/0x3d0
[   80.746339]  ? __restore_fpregs_from_fpstate+0xa0/0xe0
[   80.747183]  ? trace_event_raw_event_x86_fpu+0x3a0/0x3a0
[   80.747960]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[   80.748672]  ? syscall_enter_from_user_mode+0x1d/0x50
[   80.749422]  do_syscall_64+0x3b/0x90
[   80.750030]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[   80.750880] RIP: 0033:0x466609
[   80.751402] Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40
00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89
01 48
[   80.754298] RSP: 002b:00007f22e8d3a188 EFLAGS: 00000246 ORIG_RAX:
00000000000001aa
[   80.755441] RAX: ffffffffffffffda RBX: 000000000056bf80 RCX: 0000000000466609
[   80.756510] RDX: 0000000000000000 RSI: 00000000000058ab RDI: 0000000000000003
[   80.757492] RBP: 00000000004bfcb9 R08: 0000000000000000 R09: 0000000000000000
[   80.758474] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056bf80
[   80.759487] R13: 00007ffca119d4ef R14: 00007f22e8d3a300 R15: 0000000000022000
[   80.760646]
[   80.760908] The buggy address belongs to the page:
[   80.761689] page:000000005ec48a9f refcount:0 mapcount:0
mapping:0000000000000000 index:0x0 pfn:0x246ff
[   80.763184] flags: 0x100000000000000(node=0|zone=1)
[   80.763966] raw: 0100000000000000 0000000000000000 ffffea000091bfc8
0000000000000000
[   80.765064] raw: 0000000000000000 0000000000000000 00000000ffffffff
0000000000000000
[   80.766127] page dumped because: kasan: bad access detected
[   80.767038]
[   80.767302] addr ffff8880246ff8b8 is located in stack of task
syz-executor.10/7001 at offset 152 in frame:
[   80.768587]  io_write+0x0/0xe90
[   80.769039]
[   80.769283] this frame has 3 objects:
[   80.769776]  [48, 56) 'iovec'
[   80.769785]  [80, 120) '__iter'
[   80.770195]  [160, 288) 'inline_vecs'
[   80.770642]
[   80.771323] Memory state around the buggy address:
[   80.771975]  ffff8880246ff780: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[   80.772970]  ffff8880246ff800: 00 00 00 00 f1 f1 f1 f1 00 00 00 f2
f2 f2 00 00
[   80.774020] >ffff8880246ff880: 00 00 00 f2 f2 f2 f2 f2 00 00 00 00
00 00 00 00
[   80.775119]                                         ^
[   80.775963]  ffff8880246ff900: 00 00 00 00 00 00 00 00 f3 f3 f3 f3
00 00 00 00
[   80.777154]  ffff8880246ff980: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00

Lots of "truncated wr: 61440" and others.
[   82.690641] truncated wr: 36864
[   82.692929] truncated wr: 4096
[   82.695404] truncated wr: 61440
[   82.697840] truncated wr: 45056
[   82.700011] truncated wr: 61440
[   82.702401] truncated wr: 28672
[   82.704855] truncated wr: 12288
[   82.707070] truncated wr: 12288
[   82.709388] truncated wr: 36864
[   82.711758] truncated wr: 36864
[   82.713977] truncated wr: 28672
[   82.716176] truncated wr: 28672
and lots more.

-- 
Regards
Sudip

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: KASAN: stack-out-of-bounds in iov_iter_revert
  2021-08-01 20:28     ` Sudip Mukherjee
@ 2021-08-02 11:55       ` Pavel Begunkov
  2021-08-03  7:47         ` Sudip Mukherjee
  0 siblings, 1 reply; 9+ messages in thread
From: Pavel Begunkov @ 2021-08-02 11:55 UTC (permalink / raw)
  To: Sudip Mukherjee; +Cc: Jens Axboe, io-uring, linux-kernel

On 8/1/21 9:28 PM, Sudip Mukherjee wrote:
> Hi Pavel,
> 
> On Sun, Aug 1, 2021 at 9:52 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>
>> On 8/1/21 1:10 AM, Pavel Begunkov wrote:
>>> On 7/31/21 7:21 PM, Sudip Mukherjee wrote:
>>>> Hi Jens, Pavel,
>>>>
>>>> We had been running syzkaller on v5.10.y and a "KASAN:
>>>> stack-out-of-bounds in iov_iter_revert" was being reported on it. I
>>>> got some time to check that today and have managed to get a syzkaller
>>>> reproducer. I dont have a C reproducer which I can share but I can use
>>>> the syz-reproducer to reproduce this with v5.14-rc3 and also with
>>>> next-20210730.
>>>
>>> Can you try out the diff below? Not a full-fledged fix, but need to
>>> check a hunch.
>>>
>>> If that's important, I was using this branch:
>>> git://git.kernel.dk/linux-block io_uring-5.14
>>
>> Or better this one, just in case it ooopses on warnings.
> 
> I tested this one on top of "git://git.kernel.dk/linux-block
> io_uring-5.14" and the issue was still seen, but after the BUG trace I
> got lots of "truncated wr" message. The trace is:

That's interesting, thanks
Can you share the syz reproducer?


> [   80.722255] BUG: KASAN: stack-out-of-bounds in iov_iter_revert+0x809/0x900
> [   80.723126] Read of size 8 at addr ffff8880246ff8b8 by task
> syz-executor.10/7001
> [   80.724070]
> [   80.724274] CPU: 0 PID: 7001 Comm: syz-executor.10 Not tainted 5.14.0-rc1 #1
> [   80.725200] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
> [   80.726688] Call Trace:
> [   80.727031]  dump_stack_lvl+0x8b/0xb3
> [   80.727520]  print_address_description.constprop.0+0x1f/0x140
> [   80.728307]  ? iov_iter_revert+0x809/0x900
> [   80.728840]  ? iov_iter_revert+0x809/0x900
> [   80.729358]  kasan_report.cold+0x7f/0x11b
> [   80.729873]  ? iov_iter_revert+0x809/0x900
> [   80.730406]  iov_iter_revert+0x809/0x900
> [   80.730908]  io_write+0x5c9/0xe90
> [   80.731356]  ? io_read+0x1140/0x1140
> [   80.731835]  ? lockdep_hardirqs_on_prepare+0x3e0/0x3e0
> [   80.732486]  ? lock_is_held_type+0x98/0x110
> [   80.733029]  ? __lock_acquire+0xbb1/0x5b00
> [   80.733541]  io_issue_sqe+0x4da/0x6a80
> [   80.734063]  ? mark_lock+0xfc/0x2d80
> [   80.734539]  ? __is_insn_slot_addr+0x14d/0x250
> [   80.735169]  ? lock_chain_count+0x20/0x20
> [   80.735702]  ? io_write+0xe90/0xe90
> [   80.736167]  ? lock_is_held_type+0x98/0x110
> [   80.736797]  ? find_held_lock+0x2c/0x110
> [   80.737363]  ? lock_release+0x1dd/0x6b0
> [   80.737897]  ? __fget_files+0x21c/0x3e0
> [   80.738445]  ? lock_downgrade+0x6d0/0x6d0
> [   80.738993]  ? lock_release+0x1dd/0x6b0
> [   80.739507]  __io_queue_sqe+0x1ac/0xe50
> [   80.740017]  ? io_issue_sqe+0x6a80/0x6a80
> [   80.740564]  ? lock_is_held_type+0x98/0x110
> [   80.741142]  io_submit_sqes+0x3f6e/0x76a0
> [   80.741688]  ? xa_load+0x158/0x290
> [   80.742173]  ? __do_sys_io_uring_enter+0x90c/0x1a20
> [   80.742817]  __do_sys_io_uring_enter+0x90c/0x1a20
> [   80.743436]  ? vm_mmap_pgoff+0xe8/0x280
> [   80.743981]  ? io_submit_sqes+0x76a0/0x76a0
> [   80.744539]  ? randomize_stack_top+0x100/0x100
> [   80.745228]  ? __do_sys_futex+0xf2/0x3d0
> [   80.745763]  ? __do_sys_futex+0xfb/0x3d0
> [   80.746339]  ? __restore_fpregs_from_fpstate+0xa0/0xe0
> [   80.747183]  ? trace_event_raw_event_x86_fpu+0x3a0/0x3a0
> [   80.747960]  ? lockdep_hardirqs_on_prepare+0x273/0x3e0
> [   80.748672]  ? syscall_enter_from_user_mode+0x1d/0x50
> [   80.749422]  do_syscall_64+0x3b/0x90
> [   80.750030]  entry_SYSCALL_64_after_hwframe+0x44/0xae
> [   80.750880] RIP: 0033:0x466609
> [   80.751402] Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40
> 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24
> 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89
> 01 48
> [   80.754298] RSP: 002b:00007f22e8d3a188 EFLAGS: 00000246 ORIG_RAX:
> 00000000000001aa
> [   80.755441] RAX: ffffffffffffffda RBX: 000000000056bf80 RCX: 0000000000466609
> [   80.756510] RDX: 0000000000000000 RSI: 00000000000058ab RDI: 0000000000000003
> [   80.757492] RBP: 00000000004bfcb9 R08: 0000000000000000 R09: 0000000000000000
> [   80.758474] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056bf80
> [   80.759487] R13: 00007ffca119d4ef R14: 00007f22e8d3a300 R15: 0000000000022000
> [   80.760646]
> [   80.760908] The buggy address belongs to the page:
> [   80.761689] page:000000005ec48a9f refcount:0 mapcount:0
> mapping:0000000000000000 index:0x0 pfn:0x246ff
> [   80.763184] flags: 0x100000000000000(node=0|zone=1)
> [   80.763966] raw: 0100000000000000 0000000000000000 ffffea000091bfc8
> 0000000000000000
> [   80.765064] raw: 0000000000000000 0000000000000000 00000000ffffffff
> 0000000000000000
> [   80.766127] page dumped because: kasan: bad access detected
> [   80.767038]
> [   80.767302] addr ffff8880246ff8b8 is located in stack of task
> syz-executor.10/7001 at offset 152 in frame:
> [   80.768587]  io_write+0x0/0xe90
> [   80.769039]
> [   80.769283] this frame has 3 objects:
> [   80.769776]  [48, 56) 'iovec'
> [   80.769785]  [80, 120) '__iter'
> [   80.770195]  [160, 288) 'inline_vecs'
> [   80.770642]
> [   80.771323] Memory state around the buggy address:
> [   80.771975]  ffff8880246ff780: 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00
> [   80.772970]  ffff8880246ff800: 00 00 00 00 f1 f1 f1 f1 00 00 00 f2
> f2 f2 00 00
> [   80.774020] >ffff8880246ff880: 00 00 00 f2 f2 f2 f2 f2 00 00 00 00
> 00 00 00 00
> [   80.775119]                                         ^
> [   80.775963]  ffff8880246ff900: 00 00 00 00 00 00 00 00 f3 f3 f3 f3
> 00 00 00 00
> [   80.777154]  ffff8880246ff980: 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00
> 
> Lots of "truncated wr: 61440" and others.
> [   82.690641] truncated wr: 36864
> [   82.692929] truncated wr: 4096
> [   82.695404] truncated wr: 61440
> [   82.697840] truncated wr: 45056
> [   82.700011] truncated wr: 61440
> [   82.702401] truncated wr: 28672
> [   82.704855] truncated wr: 12288
> [   82.707070] truncated wr: 12288
> [   82.709388] truncated wr: 36864
> [   82.711758] truncated wr: 36864
> [   82.713977] truncated wr: 28672
> [   82.716176] truncated wr: 28672
> and lots more.
> 

-- 
Pavel Begunkov

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: KASAN: stack-out-of-bounds in iov_iter_revert
  2021-08-02 11:55       ` Pavel Begunkov
@ 2021-08-03  7:47         ` Sudip Mukherjee
  2021-08-03 10:34           ` Pavel Begunkov
  0 siblings, 1 reply; 9+ messages in thread
From: Sudip Mukherjee @ 2021-08-03  7:47 UTC (permalink / raw)
  To: Pavel Begunkov; +Cc: Jens Axboe, io-uring, linux-kernel

On Mon, Aug 2, 2021 at 12:55 PM Pavel Begunkov <asml.silence@gmail.com> wrote:
>
> On 8/1/21 9:28 PM, Sudip Mukherjee wrote:
> > Hi Pavel,
> >
> > On Sun, Aug 1, 2021 at 9:52 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
> >>
> >> On 8/1/21 1:10 AM, Pavel Begunkov wrote:
> >>> On 7/31/21 7:21 PM, Sudip Mukherjee wrote:
> >>>> Hi Jens, Pavel,
> >>>>
> >>>> We had been running syzkaller on v5.10.y and a "KASAN:
> >>>> stack-out-of-bounds in iov_iter_revert" was being reported on it. I
> >>>> got some time to check that today and have managed to get a syzkaller
> >>>> reproducer. I dont have a C reproducer which I can share but I can use
> >>>> the syz-reproducer to reproduce this with v5.14-rc3 and also with
> >>>> next-20210730.
> >>>
> >>> Can you try out the diff below? Not a full-fledged fix, but need to
> >>> check a hunch.
> >>>
> >>> If that's important, I was using this branch:
> >>> git://git.kernel.dk/linux-block io_uring-5.14
> >>
> >> Or better this one, just in case it ooopses on warnings.
> >
> > I tested this one on top of "git://git.kernel.dk/linux-block
> > io_uring-5.14" and the issue was still seen, but after the BUG trace I
> > got lots of "truncated wr" message. The trace is:
>
> That's interesting, thanks
> Can you share the syz reproducer?

Unfortunately I dont have a C reproducer, but this is the reproducer
for syzkaller:

r0 = syz_io_uring_setup(0x4d4f, &(0x7f0000000080)={0x0, 0x0, 0x1},
&(0x7f00000a0000)=nil, &(0x7f0000ffc000/0x1000)=nil,
&(0x7f0000000000)=<r1=>0x0, &(0x7f0000000140))
r2 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x46e2, 0x0)
syz_io_uring_setup(0x1, &(0x7f0000000080),
&(0x7f0000ffd000/0x2000)=nil, &(0x7f0000ffc000/0x2000)=nil,
&(0x7f0000000100), &(0x7f0000000140)=<r3=>0x0)
syz_io_uring_submit(r1, r3, &(0x7f0000000100)=@IORING_OP_WRITE={0x17,
0x0, 0x0, @fd=r2, 0x0, &(0x7f0000000200)="e2", 0xffffffffffffff98},
0x200)
io_uring_enter(r0, 0x58ab, 0x0, 0x0, 0x0, 0x0)


-- 
Regards
Sudip

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: KASAN: stack-out-of-bounds in iov_iter_revert
  2021-08-03  7:47         ` Sudip Mukherjee
@ 2021-08-03 10:34           ` Pavel Begunkov
  2021-08-03 13:18             ` Pavel Begunkov
  2021-08-03 14:56             ` Sudip Mukherjee
  0 siblings, 2 replies; 9+ messages in thread
From: Pavel Begunkov @ 2021-08-03 10:34 UTC (permalink / raw)
  To: Sudip Mukherjee; +Cc: Jens Axboe, io-uring, linux-kernel

On 8/3/21 8:47 AM, Sudip Mukherjee wrote:
> On Mon, Aug 2, 2021 at 12:55 PM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>
>> On 8/1/21 9:28 PM, Sudip Mukherjee wrote:
>>> Hi Pavel,
>>>
>>> On Sun, Aug 1, 2021 at 9:52 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>>>
>>>> On 8/1/21 1:10 AM, Pavel Begunkov wrote:
>>>>> On 7/31/21 7:21 PM, Sudip Mukherjee wrote:
>>>>>> Hi Jens, Pavel,
>>>>>>
>>>>>> We had been running syzkaller on v5.10.y and a "KASAN:
>>>>>> stack-out-of-bounds in iov_iter_revert" was being reported on it. I
>>>>>> got some time to check that today and have managed to get a syzkaller
>>>>>> reproducer. I dont have a C reproducer which I can share but I can use
>>>>>> the syz-reproducer to reproduce this with v5.14-rc3 and also with
>>>>>> next-20210730.
>>>>>
>>>>> Can you try out the diff below? Not a full-fledged fix, but need to
>>>>> check a hunch.
>>>>>
>>>>> If that's important, I was using this branch:
>>>>> git://git.kernel.dk/linux-block io_uring-5.14
>>>>
>>>> Or better this one, just in case it ooopses on warnings.
>>>
>>> I tested this one on top of "git://git.kernel.dk/linux-block
>>> io_uring-5.14" and the issue was still seen, but after the BUG trace I
>>> got lots of "truncated wr" message. The trace is:
>>
>> That's interesting, thanks
>> Can you share the syz reproducer?
> 
> Unfortunately I dont have a C reproducer, but this is the reproducer
> for syzkaller:

Thanks. Maybe I'm not perfectly familiar with syz, but were there
any options? Like threaded, collide, etc.?


> 
> r0 = syz_io_uring_setup(0x4d4f, &(0x7f0000000080)={0x0, 0x0, 0x1},
> &(0x7f00000a0000)=nil, &(0x7f0000ffc000/0x1000)=nil,
> &(0x7f0000000000)=<r1=>0x0, &(0x7f0000000140))
> r2 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x46e2, 0x0)
> syz_io_uring_setup(0x1, &(0x7f0000000080),
> &(0x7f0000ffd000/0x2000)=nil, &(0x7f0000ffc000/0x2000)=nil,
> &(0x7f0000000100), &(0x7f0000000140)=<r3=>0x0)
> syz_io_uring_submit(r1, r3, &(0x7f0000000100)=@IORING_OP_WRITE={0x17,
> 0x0, 0x0, @fd=r2, 0x0, &(0x7f0000000200)="e2", 0xffffffffffffff98},
> 0x200)
> io_uring_enter(r0, 0x58ab, 0x0, 0x0, 0x0, 0x0)
> 
> 

-- 
Pavel Begunkov

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: KASAN: stack-out-of-bounds in iov_iter_revert
  2021-08-03 10:34           ` Pavel Begunkov
@ 2021-08-03 13:18             ` Pavel Begunkov
  2021-08-03 14:56             ` Sudip Mukherjee
  1 sibling, 0 replies; 9+ messages in thread
From: Pavel Begunkov @ 2021-08-03 13:18 UTC (permalink / raw)
  To: Sudip Mukherjee; +Cc: Jens Axboe, io-uring, linux-kernel

On 8/3/21 11:34 AM, Pavel Begunkov wrote:
> On 8/3/21 8:47 AM, Sudip Mukherjee wrote:
>> On Mon, Aug 2, 2021 at 12:55 PM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>> On 8/1/21 9:28 PM, Sudip Mukherjee wrote:
>>>> On Sun, Aug 1, 2021 at 9:52 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>>>>> On 8/1/21 1:10 AM, Pavel Begunkov wrote:
>>>>>> On 7/31/21 7:21 PM, Sudip Mukherjee wrote:
>>>>>>> Hi Jens, Pavel,
>>>>>>>
>>>>>>> We had been running syzkaller on v5.10.y and a "KASAN:
>>>>>>> stack-out-of-bounds in iov_iter_revert" was being reported on it. I
>>>>>>> got some time to check that today and have managed to get a syzkaller
>>>>>>> reproducer. I dont have a C reproducer which I can share but I can use
>>>>>>> the syz-reproducer to reproduce this with v5.14-rc3 and also with
>>>>>>> next-20210730.
>>>>>>
>>>>>> Can you try out the diff below? Not a full-fledged fix, but need to
>>>>>> check a hunch.
>>>>>>
>>>>>> If that's important, I was using this branch:
>>>>>> git://git.kernel.dk/linux-block io_uring-5.14
>>>>>
>>>>> Or better this one, just in case it ooopses on warnings.
>>>>
>>>> I tested this one on top of "git://git.kernel.dk/linux-block
>>>> io_uring-5.14" and the issue was still seen, but after the BUG trace I
>>>> got lots of "truncated wr" message. The trace is:
>>>
>>> That's interesting, thanks
>>> Can you share the syz reproducer?
>>
>> Unfortunately I dont have a C reproducer, but this is the reproducer
>> for syzkaller:
> 
> Thanks. Maybe I'm not perfectly familiar with syz, but were there
> any options? Like threaded, collide, etc.?

Never mind, reproduced the issue.

fwiw, I was too optimistic with u16 in the diff, but if
replaced with size_t, it solves the out-of-bounds bug,
but it has another issue.

In any case, need to patch it up, thanks

-- 
Pavel Begunkov

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: KASAN: stack-out-of-bounds in iov_iter_revert
  2021-08-03 10:34           ` Pavel Begunkov
  2021-08-03 13:18             ` Pavel Begunkov
@ 2021-08-03 14:56             ` Sudip Mukherjee
  1 sibling, 0 replies; 9+ messages in thread
From: Sudip Mukherjee @ 2021-08-03 14:56 UTC (permalink / raw)
  To: Pavel Begunkov; +Cc: Jens Axboe, io-uring, linux-kernel

On Tue, Aug 3, 2021 at 11:34 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
>
> On 8/3/21 8:47 AM, Sudip Mukherjee wrote:
> > On Mon, Aug 2, 2021 at 12:55 PM Pavel Begunkov <asml.silence@gmail.com> wrote:
> >>
> >> On 8/1/21 9:28 PM, Sudip Mukherjee wrote:
> >>> Hi Pavel,
> >>>
> >>> On Sun, Aug 1, 2021 at 9:52 AM Pavel Begunkov <asml.silence@gmail.com> wrote:
> >>>>
> >>>> On 8/1/21 1:10 AM, Pavel Begunkov wrote:
> >>>>> On 7/31/21 7:21 PM, Sudip Mukherjee wrote:
> >>>>>> Hi Jens, Pavel,
> >>>>>>
> >>>>>> We had been running syzkaller on v5.10.y and a "KASAN:
> >>>>>> stack-out-of-bounds in iov_iter_revert" was being reported on it. I
> >>>>>> got some time to check that today and have managed to get a syzkaller
> >>>>>> reproducer. I dont have a C reproducer which I can share but I can use
> >>>>>> the syz-reproducer to reproduce this with v5.14-rc3 and also with
> >>>>>> next-20210730.
> >>>>>
> >>>>> Can you try out the diff below? Not a full-fledged fix, but need to
> >>>>> check a hunch.
> >>>>>
> >>>>> If that's important, I was using this branch:
> >>>>> git://git.kernel.dk/linux-block io_uring-5.14
> >>>>
> >>>> Or better this one, just in case it ooopses on warnings.
> >>>
> >>> I tested this one on top of "git://git.kernel.dk/linux-block
> >>> io_uring-5.14" and the issue was still seen, but after the BUG trace I
> >>> got lots of "truncated wr" message. The trace is:
> >>
> >> That's interesting, thanks
> >> Can you share the syz reproducer?
> >
> > Unfortunately I dont have a C reproducer, but this is the reproducer
> > for syzkaller:
>
> Thanks. Maybe I'm not perfectly familiar with syz, but were there
> any options? Like threaded, collide, etc.?

Sorry, my  mistake. I am still learning how syzkaller works. And I
should have given the link to the report with my mail.
https://elisa-builder-00.iol.unh.edu/syzkaller/report?id=959057ecd2886ff0c38cc53fa9c8eae46c1d7496

And also, I now have a C reproducer also, if that helps.


-- 
Regards
Sudip

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2021-08-03 14:57 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-31 18:21 KASAN: stack-out-of-bounds in iov_iter_revert Sudip Mukherjee
2021-08-01  0:10 ` Pavel Begunkov
2021-08-01  8:52   ` Pavel Begunkov
2021-08-01 20:28     ` Sudip Mukherjee
2021-08-02 11:55       ` Pavel Begunkov
2021-08-03  7:47         ` Sudip Mukherjee
2021-08-03 10:34           ` Pavel Begunkov
2021-08-03 13:18             ` Pavel Begunkov
2021-08-03 14:56             ` Sudip Mukherjee

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox