* 6pack: stack-out-of-bounds in sixpack_receive_buf
@ 2016-09-03 13:38 Dmitry Vyukov
2016-09-03 13:38 ` Dmitry Vyukov
2016-09-05 16:37 ` One Thousand Gnomes
0 siblings, 2 replies; 5+ messages in thread
From: Dmitry Vyukov @ 2016-09-03 13:38 UTC (permalink / raw)
To: Greg Kroah-Hartman, Peter Hurley, Jiri Slaby, LKML,
Andreas Koensgen, linux-hams, netdev, David Miller
Hello,
While running syzkaller fuzzer I've got the following report:
BUG: KASAN: stack-out-of-bounds in sixpack_receive_buf+0xf8a/0x1450 at
addr ffff880037fbf850
Read of size 1 by task syz-executor/6759
page:ffffea0000dfefc0 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x1fffc0000000000()
page dumped because: kasan: bad access detected
CPU: 3 PID: 6759 Comm: syz-executor Not tainted 4.8.0-rc3-next-20160825+ #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffffffff886b6fe0 ffff880037fbf520 ffffffff82db38d9 ffffffff37fbf5b0
fffffbfff10d6dfc ffff880037fbf5b0 ffff880037fbf850 ffff880037fbf850
ffff880037d3f180 dffffc0000000000 ffff880037fbf5a0 ffffffff8180a383
Call Trace:
[<ffffffff8180a3ee>] __asan_report_load1_noabort+0x3e/0x40
mm/kasan/report.c:319
[< inline >] sixpack_decode drivers/net/hamradio/6pack.c:1001
[<ffffffff8425f96a>] sixpack_receive_buf+0xf8a/0x1450
drivers/net/hamradio/6pack.c:462
[<ffffffff8323b368>] tty_ldisc_receive_buf+0x168/0x1b0
drivers/tty/tty_buffer.c:433
[<ffffffff832616de>] paste_selection+0x27e/0x3e0 drivers/tty/vt/selection.c:363
[<ffffffff8327f286>] tioclinux+0x126/0x410 drivers/tty/vt/vt.c:2683
[<ffffffff8325c1ef>] vt_ioctl+0x13ef/0x2910 drivers/tty/vt/vt_ioctl.c:365
[<ffffffff832245cd>] tty_ioctl+0x69d/0x21e0 drivers/tty/tty_io.c:2983
[< inline >] vfs_ioctl fs/ioctl.c:43
[<ffffffff818a1dfc>] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
[< inline >] SYSC_ioctl fs/ioctl.c:690
[<ffffffff818a2d7f>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
[<ffffffff86e10700>] entry_SYSCALL_64_fastpath+0x23/0xc1
Memory state around the buggy address:
ffff880037fbf700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff880037fbf780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff880037fbf800: 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 00 00
^
ffff880037fbf880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff880037fbf900: 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4 f2 f2 f2 f2
==================================================================
It is then followed by similar reports that access subsequent stack bytes.
Unfortunately I can't reproduce it (though, I got 6 similar crashes in
different runs). Looking at code, the following looks suspicious -- we
limit copy by 512 bytes, but use the original count which can be
larger than 512:
static void sixpack_receive_buf(struct tty_struct *tty,
const unsigned char *cp, char *fp, int count)
{
unsigned char buf[512];
....
memcpy(buf, cp, count < sizeof(buf) ? count : sizeof(buf));
....
sixpack_decode(sp, buf, count1);
On commit 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of linux-next.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 6pack: stack-out-of-bounds in sixpack_receive_buf
2016-09-03 13:38 6pack: stack-out-of-bounds in sixpack_receive_buf Dmitry Vyukov
@ 2016-09-03 13:38 ` Dmitry Vyukov
2016-09-05 17:49 ` One Thousand Gnomes
2016-09-05 16:37 ` One Thousand Gnomes
1 sibling, 1 reply; 5+ messages in thread
From: Dmitry Vyukov @ 2016-09-03 13:38 UTC (permalink / raw)
To: Greg Kroah-Hartman, Peter Hurley, Jiri Slaby, LKML,
Andreas Koensgen, linux-hams, netdev, David Miller
Cc: syzkaller
Hello,
While running syzkaller fuzzer I've got the following report:
BUG: KASAN: stack-out-of-bounds in sixpack_receive_buf+0xf8a/0x1450 at
addr ffff880037fbf850
Read of size 1 by task syz-executor/6759
page:ffffea0000dfefc0 count:0 mapcount:0 mapping: (null) index:0x0
flags: 0x1fffc0000000000()
page dumped because: kasan: bad access detected
CPU: 3 PID: 6759 Comm: syz-executor Not tainted 4.8.0-rc3-next-20160825+ #8
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffffffff886b6fe0 ffff880037fbf520 ffffffff82db38d9 ffffffff37fbf5b0
fffffbfff10d6dfc ffff880037fbf5b0 ffff880037fbf850 ffff880037fbf850
ffff880037d3f180 dffffc0000000000 ffff880037fbf5a0 ffffffff8180a383
Call Trace:
[<ffffffff8180a3ee>] __asan_report_load1_noabort+0x3e/0x40
mm/kasan/report.c:319
[< inline >] sixpack_decode drivers/net/hamradio/6pack.c:1001
[<ffffffff8425f96a>] sixpack_receive_buf+0xf8a/0x1450
drivers/net/hamradio/6pack.c:462
[<ffffffff8323b368>] tty_ldisc_receive_buf+0x168/0x1b0
drivers/tty/tty_buffer.c:433
[<ffffffff832616de>] paste_selection+0x27e/0x3e0 drivers/tty/vt/selection.c:363
[<ffffffff8327f286>] tioclinux+0x126/0x410 drivers/tty/vt/vt.c:2683
[<ffffffff8325c1ef>] vt_ioctl+0x13ef/0x2910 drivers/tty/vt/vt_ioctl.c:365
[<ffffffff832245cd>] tty_ioctl+0x69d/0x21e0 drivers/tty/tty_io.c:2983
[< inline >] vfs_ioctl fs/ioctl.c:43
[<ffffffff818a1dfc>] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
[< inline >] SYSC_ioctl fs/ioctl.c:690
[<ffffffff818a2d7f>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
[<ffffffff86e10700>] entry_SYSCALL_64_fastpath+0x23/0xc1
Memory state around the buggy address:
ffff880037fbf700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff880037fbf780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>ffff880037fbf800: 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 00 00
^
ffff880037fbf880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff880037fbf900: 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4 f2 f2 f2 f2
==================================================================
It is then followed by similar reports that access subsequent stack bytes.
Unfortunately I can't reproduce it (though, I got 6 similar crashes in
different runs). Looking at code, the following looks suspicious -- we
limit copy by 512 bytes, but use the original count which can be
larger than 512:
static void sixpack_receive_buf(struct tty_struct *tty,
const unsigned char *cp, char *fp, int count)
{
unsigned char buf[512];
....
memcpy(buf, cp, count < sizeof(buf) ? count : sizeof(buf));
....
sixpack_decode(sp, buf, count1);
On commit 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of linux-next.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 6pack: stack-out-of-bounds in sixpack_receive_buf
2016-09-03 13:38 6pack: stack-out-of-bounds in sixpack_receive_buf Dmitry Vyukov
2016-09-03 13:38 ` Dmitry Vyukov
@ 2016-09-05 16:37 ` One Thousand Gnomes
1 sibling, 0 replies; 5+ messages in thread
From: One Thousand Gnomes @ 2016-09-05 16:37 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Greg Kroah-Hartman, Peter Hurley, Jiri Slaby, LKML,
Andreas Koensgen, linux-hams, netdev, David Miller
On Sat, 3 Sep 2016 15:38:08 +0200
Dmitry Vyukov <dvyukov@google.com> wrote:
> Hello,
>
> While running syzkaller fuzzer I've got the following report:
>
> BUG: KASAN: stack-out-of-bounds in sixpack_receive_buf+0xf8a/0x1450 at
> addr ffff880037fbf850
> Read of size 1 by task syz-executor/6759
> page:ffffea0000dfefc0 count:0 mapcount:0 mapping: (null) index:0x0
> flags: 0x1fffc0000000000()
> page dumped because: kasan: bad access detected
> CPU: 3 PID: 6759 Comm: syz-executor Not tainted 4.8.0-rc3-next-20160825+ #8
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> ffffffff886b6fe0 ffff880037fbf520 ffffffff82db38d9 ffffffff37fbf5b0
> fffffbfff10d6dfc ffff880037fbf5b0 ffff880037fbf850 ffff880037fbf850
> ffff880037d3f180 dffffc0000000000 ffff880037fbf5a0 ffffffff8180a383
> Call Trace:
> [<ffffffff8180a3ee>] __asan_report_load1_noabort+0x3e/0x40
> mm/kasan/report.c:319
> [< inline >] sixpack_decode drivers/net/hamradio/6pack.c:1001
> [<ffffffff8425f96a>] sixpack_receive_buf+0xf8a/0x1450
> drivers/net/hamradio/6pack.c:462
> [<ffffffff8323b368>] tty_ldisc_receive_buf+0x168/0x1b0
> drivers/tty/tty_buffer.c:433
> [<ffffffff832616de>] paste_selection+0x27e/0x3e0 drivers/tty/vt/selection.c:363
> [<ffffffff8327f286>] tioclinux+0x126/0x410 drivers/tty/vt/vt.c:2683
> [<ffffffff8325c1ef>] vt_ioctl+0x13ef/0x2910 drivers/tty/vt/vt_ioctl.c:365
> [<ffffffff832245cd>] tty_ioctl+0x69d/0x21e0 drivers/tty/tty_io.c:2983
> [< inline >] vfs_ioctl fs/ioctl.c:43
> [<ffffffff818a1dfc>] do_vfs_ioctl+0x18c/0x1080 fs/ioctl.c:675
> [< inline >] SYSC_ioctl fs/ioctl.c:690
> [<ffffffff818a2d7f>] SyS_ioctl+0x8f/0xc0 fs/ioctl.c:681
> [<ffffffff86e10700>] entry_SYSCALL_64_fastpath+0x23/0xc1
> Memory state around the buggy address:
> ffff880037fbf700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff880037fbf780: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> >ffff880037fbf800: 00 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 00 00
> ^
> ffff880037fbf880: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> ffff880037fbf900: 00 00 00 00 f1 f1 f1 f1 00 f4 f4 f4 f2 f2 f2 f2
> ==================================================================
>
>
> It is then followed by similar reports that access subsequent stack bytes.
> Unfortunately I can't reproduce it (though, I got 6 similar crashes in
> different runs). Looking at code, the following looks suspicious -- we
> limit copy by 512 bytes, but use the original count which can be
> larger than 512:
>
> static void sixpack_receive_buf(struct tty_struct *tty,
> const unsigned char *cp, char *fp, int count)
> {
> unsigned char buf[512];
> ....
> memcpy(buf, cp, count < sizeof(buf) ? count : sizeof(buf));
> ....
> sixpack_decode(sp, buf, count1);
>
Your suspicion is correct.
Alan
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: 6pack: stack-out-of-bounds in sixpack_receive_buf
2016-09-03 13:38 ` Dmitry Vyukov
@ 2016-09-05 17:49 ` One Thousand Gnomes
2016-09-05 17:55 ` Dmitry Vyukov
0 siblings, 1 reply; 5+ messages in thread
From: One Thousand Gnomes @ 2016-09-05 17:49 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: Greg Kroah-Hartman, Peter Hurley, Jiri Slaby, LKML,
Andreas Koensgen, linux-hams, netdev, David Miller, syzkaller
> different runs). Looking at code, the following looks suspicious -- we
> limit copy by 512 bytes, but use the original count which can be
> larger than 512:
>
> static void sixpack_receive_buf(struct tty_struct *tty,
> const unsigned char *cp, char *fp, int count)
> {
> unsigned char buf[512];
> ....
> memcpy(buf, cp, count < sizeof(buf) ? count : sizeof(buf));
> ....
> sixpack_decode(sp, buf, count1);
>
>
> On commit 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of linux-next.
With the sane tty locking we now have I believe the following is safe as
we consume the bytes and move them into the decoded buffer before
returning.
diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c
index 5a1e985..470b3dc 100644
--- a/drivers/net/hamradio/6pack.c
+++ b/drivers/net/hamradio/6pack.c
@@ -127,7 +127,7 @@ struct sixpack {
#define AX25_6PACK_HEADER_LEN 0
-static void sixpack_decode(struct sixpack *, unsigned char[], int);
+static void sixpack_decode(struct sixpack *, const unsigned char[], int);
static int encode_sixpack(unsigned char *, unsigned char *, int, unsigned char);
/*
@@ -428,7 +428,7 @@ out:
/*
* Handle the 'receiver data ready' interrupt.
- * This function is called by the 'tty_io' module in the kernel when
+ * This function is called by the tty module in the kernel when
* a block of 6pack data has been received, which can now be decapsulated
* and sent on to some IP layer for further processing.
*/
@@ -436,7 +436,6 @@ static void sixpack_receive_buf(struct tty_struct *tty,
const unsigned char *cp, char *fp, int count)
{
struct sixpack *sp;
- unsigned char buf[512];
int count1;
if (!count)
@@ -446,10 +445,7 @@ static void sixpack_receive_buf(struct tty_struct *tty,
if (!sp)
return;
- memcpy(buf, cp, count < sizeof(buf) ? count : sizeof(buf));
-
/* Read the characters out of the buffer */
-
count1 = count;
while (count) {
count--;
@@ -459,7 +455,7 @@ static void sixpack_receive_buf(struct tty_struct *tty,
continue;
}
}
- sixpack_decode(sp, buf, count1);
+ sixpack_decode(sp, cp, count1);
sp_put(sp);
tty_unthrottle(tty);
@@ -992,7 +988,7 @@ static void decode_std_command(struct sixpack *sp, unsigned char cmd)
/* decode a 6pack packet */
static void
-sixpack_decode(struct sixpack *sp, unsigned char *pre_rbuff, int count)
+sixpack_decode(struct sixpack *sp, const unsigned char *pre_rbuff, int count)
{
unsigned char inbyte;
int count1;
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: 6pack: stack-out-of-bounds in sixpack_receive_buf
2016-09-05 17:49 ` One Thousand Gnomes
@ 2016-09-05 17:55 ` Dmitry Vyukov
0 siblings, 0 replies; 5+ messages in thread
From: Dmitry Vyukov @ 2016-09-05 17:55 UTC (permalink / raw)
To: One Thousand Gnomes
Cc: Greg Kroah-Hartman, Peter Hurley, Jiri Slaby, LKML,
Andreas Koensgen, linux-hams, netdev, David Miller, syzkaller
On Mon, Sep 5, 2016 at 7:49 PM, One Thousand Gnomes
<gnomes@lxorguk.ukuu.org.uk> wrote:
>> different runs). Looking at code, the following looks suspicious -- we
>> limit copy by 512 bytes, but use the original count which can be
>> larger than 512:
>>
>> static void sixpack_receive_buf(struct tty_struct *tty,
>> const unsigned char *cp, char *fp, int count)
>> {
>> unsigned char buf[512];
>> ....
>> memcpy(buf, cp, count < sizeof(buf) ? count : sizeof(buf));
>> ....
>> sixpack_decode(sp, buf, count1);
>>
>>
>> On commit 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of linux-next.
>
> With the sane tty locking we now have I believe the following is safe as
> we consume the bytes and move them into the decoded buffer before
> returning.
>
> diff --git a/drivers/net/hamradio/6pack.c b/drivers/net/hamradio/6pack.c
> index 5a1e985..470b3dc 100644
> --- a/drivers/net/hamradio/6pack.c
> +++ b/drivers/net/hamradio/6pack.c
> @@ -127,7 +127,7 @@ struct sixpack {
>
> #define AX25_6PACK_HEADER_LEN 0
>
> -static void sixpack_decode(struct sixpack *, unsigned char[], int);
> +static void sixpack_decode(struct sixpack *, const unsigned char[], int);
> static int encode_sixpack(unsigned char *, unsigned char *, int, unsigned char);
>
> /*
> @@ -428,7 +428,7 @@ out:
>
> /*
> * Handle the 'receiver data ready' interrupt.
> - * This function is called by the 'tty_io' module in the kernel when
> + * This function is called by the tty module in the kernel when
> * a block of 6pack data has been received, which can now be decapsulated
> * and sent on to some IP layer for further processing.
> */
> @@ -436,7 +436,6 @@ static void sixpack_receive_buf(struct tty_struct *tty,
> const unsigned char *cp, char *fp, int count)
> {
> struct sixpack *sp;
> - unsigned char buf[512];
> int count1;
>
> if (!count)
> @@ -446,10 +445,7 @@ static void sixpack_receive_buf(struct tty_struct *tty,
> if (!sp)
> return;
>
> - memcpy(buf, cp, count < sizeof(buf) ? count : sizeof(buf));
> -
> /* Read the characters out of the buffer */
> -
> count1 = count;
> while (count) {
> count--;
> @@ -459,7 +455,7 @@ static void sixpack_receive_buf(struct tty_struct *tty,
> continue;
> }
> }
> - sixpack_decode(sp, buf, count1);
> + sixpack_decode(sp, cp, count1);
>
> sp_put(sp);
> tty_unthrottle(tty);
> @@ -992,7 +988,7 @@ static void decode_std_command(struct sixpack *sp, unsigned char cmd)
> /* decode a 6pack packet */
>
> static void
> -sixpack_decode(struct sixpack *sp, unsigned char *pre_rbuff, int count)
> +sixpack_decode(struct sixpack *sp, const unsigned char *pre_rbuff, int count)
> {
> unsigned char inbyte;
> int count1;
Applied locally for testing. I will notify if I see this bug again.
Thanks!
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-09-05 17:55 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-09-03 13:38 6pack: stack-out-of-bounds in sixpack_receive_buf Dmitry Vyukov
2016-09-03 13:38 ` Dmitry Vyukov
2016-09-05 17:49 ` One Thousand Gnomes
2016-09-05 17:55 ` Dmitry Vyukov
2016-09-05 16:37 ` One Thousand Gnomes
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.