general protection fault in klist_iter_exit
Hi, I am fuzzing Linux 4.17-rc4 with Syzkaller and found the below crash. I don't have a reproducer but this crash happened twice. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN PTI Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 0 PID: 36 Comm: kworker/0:1 Not tainted 4.17.0-rc4+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events netlink_sock_destruct_work RIP: 0010:klist_iter_exit+0x26/0x90 lib/klist.c:314 RSP: 0018:880103f57c30 EFLAGS: 00010202 RAX: dc00 RBX: RCX: 8490f6d5 RDX: 0001 RSI: 0008 RDI: RBP: 880103f57c48 R08: fbfff0c133d9 R09: 0001 R10: 880103f57c78 R11: 86099ec7 R12: 0008 R13: 854a2ba0 R14: R15: 880103ec9400 FS: () GS:880104e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 2031d000 CR3: 05a22003 CR4: 001606f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0600 Call Trace: class_dev_iter_exit+0x15/0x20 drivers/base/class.c:323 nfc_device_iter_exit net/nfc/nfc.h:133 [inline] nfc_genl_dump_devices_done+0x34/0x50 net/nfc/netlink.c:666 genl_lock_done+0x89/0xd0 net/netlink/genetlink.c:493 netlink_sock_destruct+0x98/0x2a0 net/netlink/af_netlink.c:397 __sk_destruct+0x53/0x5e0 net/core/sock.c:1566 sk_destruct+0x47/0x80 net/core/sock.c:1601 __sk_free+0xf1/0x2b0 net/core/sock.c:1612 sk_free+0x2a/0x40 net/core/sock.c:1623 netlink_sock_destruct_work+0x19/0x20 net/netlink/af_netlink.c:419 process_one_work+0x827/0x1550 kernel/workqueue.c:2145 worker_thread+0xd2/0xcc0 kernel/workqueue.c:2279 kthread+0x33c/0x400 kernel/kthread.c:238 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412 Code: 5d c3 0f 1f 00 55 48 89 e5 41 55 41 54 53 48 89 fb 4c 8d 63 08 e8 4b 62 cf fc 4c 89 e2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 75 43 4c 8b 6b 08 4d 85 ed 74 2e e8 26 62 cf fc 31 RIP: klist_iter_exit+0x26/0x90 lib/klist.c:314 RSP: 880103f57c30 ---[ end trace 69831a3bb9e34eca ]--- Kernel panic - not syncing: Fatal exception Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. Regards, Shankara
general protection fault in klist_iter_exit
Hi, I am fuzzing Linux 4.17-rc4 with Syzkaller and found the below crash. I don't have a reproducer but this crash happened twice. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN PTI Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 0 PID: 36 Comm: kworker/0:1 Not tainted 4.17.0-rc4+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events netlink_sock_destruct_work RIP: 0010:klist_iter_exit+0x26/0x90 lib/klist.c:314 RSP: 0018:880103f57c30 EFLAGS: 00010202 RAX: dc00 RBX: RCX: 8490f6d5 RDX: 0001 RSI: 0008 RDI: RBP: 880103f57c48 R08: fbfff0c133d9 R09: 0001 R10: 880103f57c78 R11: 86099ec7 R12: 0008 R13: 854a2ba0 R14: R15: 880103ec9400 FS: () GS:880104e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 2031d000 CR3: 05a22003 CR4: 001606f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0600 Call Trace: class_dev_iter_exit+0x15/0x20 drivers/base/class.c:323 nfc_device_iter_exit net/nfc/nfc.h:133 [inline] nfc_genl_dump_devices_done+0x34/0x50 net/nfc/netlink.c:666 genl_lock_done+0x89/0xd0 net/netlink/genetlink.c:493 netlink_sock_destruct+0x98/0x2a0 net/netlink/af_netlink.c:397 __sk_destruct+0x53/0x5e0 net/core/sock.c:1566 sk_destruct+0x47/0x80 net/core/sock.c:1601 __sk_free+0xf1/0x2b0 net/core/sock.c:1612 sk_free+0x2a/0x40 net/core/sock.c:1623 netlink_sock_destruct_work+0x19/0x20 net/netlink/af_netlink.c:419 process_one_work+0x827/0x1550 kernel/workqueue.c:2145 worker_thread+0xd2/0xcc0 kernel/workqueue.c:2279 kthread+0x33c/0x400 kernel/kthread.c:238 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412 Code: 5d c3 0f 1f 00 55 48 89 e5 41 55 41 54 53 48 89 fb 4c 8d 63 08 e8 4b 62 cf fc 4c 89 e2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 75 43 4c 8b 6b 08 4d 85 ed 74 2e e8 26 62 cf fc 31 RIP: klist_iter_exit+0x26/0x90 lib/klist.c:314 RSP: 880103f57c30 ---[ end trace 69831a3bb9e34eca ]--- Kernel panic - not syncing: Fatal exception Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. Regards, Shankara
general protection fault in klist_iter_exit
Hi, I am fuzzing Linux 4.17-rc4 with Syzkaller and found the below crash. I don't have a reproducer but this crash happened twice. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN PTI Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 0 PID: 36 Comm: kworker/0:1 Not tainted 4.17.0-rc4+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events netlink_sock_destruct_work RIP: 0010:klist_iter_exit+0x26/0x90 lib/klist.c:314 RSP: 0018:880103f57c30 EFLAGS: 00010202 RAX: dc00 RBX: RCX: 8490f6d5 RDX: 0001 RSI: 0008 RDI: RBP: 880103f57c48 R08: fbfff0c133d9 R09: 0001 R10: 880103f57c78 R11: 86099ec7 R12: 0008 R13: 854a2ba0 R14: R15: 880103ec9400 FS: () GS:880104e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 2031d000 CR3: 05a22003 CR4: 001606f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0600 Call Trace: class_dev_iter_exit+0x15/0x20 drivers/base/class.c:323 nfc_device_iter_exit net/nfc/nfc.h:133 [inline] nfc_genl_dump_devices_done+0x34/0x50 net/nfc/netlink.c:666 genl_lock_done+0x89/0xd0 net/netlink/genetlink.c:493 netlink_sock_destruct+0x98/0x2a0 net/netlink/af_netlink.c:397 __sk_destruct+0x53/0x5e0 net/core/sock.c:1566 sk_destruct+0x47/0x80 net/core/sock.c:1601 __sk_free+0xf1/0x2b0 net/core/sock.c:1612 sk_free+0x2a/0x40 net/core/sock.c:1623 netlink_sock_destruct_work+0x19/0x20 net/netlink/af_netlink.c:419 process_one_work+0x827/0x1550 kernel/workqueue.c:2145 worker_thread+0xd2/0xcc0 kernel/workqueue.c:2279 kthread+0x33c/0x400 kernel/kthread.c:238 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412 Code: 5d c3 0f 1f 00 55 48 89 e5 41 55 41 54 53 48 89 fb 4c 8d 63 08 e8 4b 62 cf fc 4c 89 e2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 75 43 4c 8b 6b 08 4d 85 ed 74 2e e8 26 62 cf fc 31 RIP: klist_iter_exit+0x26/0x90 lib/klist.c:314 RSP: 880103f57c30 ---[ end trace 69831a3bb9e34eca ]--- Kernel panic - not syncing: Fatal exception Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. Regards, Shankara
general protection fault in klist_iter_exit
Hi, I am fuzzing Linux 4.17-rc4 with Syzkaller and found the below crash. I don't have a reproducer but this crash happened twice. kasan: CONFIG_KASAN_INLINE enabled kasan: GPF could be caused by NULL-ptr deref or user memory access general protection fault: [#1] SMP KASAN PTI Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: CPU: 0 PID: 36 Comm: kworker/0:1 Not tainted 4.17.0-rc4+ #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: events netlink_sock_destruct_work RIP: 0010:klist_iter_exit+0x26/0x90 lib/klist.c:314 RSP: 0018:880103f57c30 EFLAGS: 00010202 RAX: dc00 RBX: RCX: 8490f6d5 RDX: 0001 RSI: 0008 RDI: RBP: 880103f57c48 R08: fbfff0c133d9 R09: 0001 R10: 880103f57c78 R11: 86099ec7 R12: 0008 R13: 854a2ba0 R14: R15: 880103ec9400 FS: () GS:880104e0() knlGS: CS: 0010 DS: ES: CR0: 80050033 CR2: 2031d000 CR3: 05a22003 CR4: 001606f0 DR0: DR1: DR2: DR3: DR6: fffe0ff0 DR7: 0600 Call Trace: class_dev_iter_exit+0x15/0x20 drivers/base/class.c:323 nfc_device_iter_exit net/nfc/nfc.h:133 [inline] nfc_genl_dump_devices_done+0x34/0x50 net/nfc/netlink.c:666 genl_lock_done+0x89/0xd0 net/netlink/genetlink.c:493 netlink_sock_destruct+0x98/0x2a0 net/netlink/af_netlink.c:397 __sk_destruct+0x53/0x5e0 net/core/sock.c:1566 sk_destruct+0x47/0x80 net/core/sock.c:1601 __sk_free+0xf1/0x2b0 net/core/sock.c:1612 sk_free+0x2a/0x40 net/core/sock.c:1623 netlink_sock_destruct_work+0x19/0x20 net/netlink/af_netlink.c:419 process_one_work+0x827/0x1550 kernel/workqueue.c:2145 worker_thread+0xd2/0xcc0 kernel/workqueue.c:2279 kthread+0x33c/0x400 kernel/kthread.c:238 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412 Code: 5d c3 0f 1f 00 55 48 89 e5 41 55 41 54 53 48 89 fb 4c 8d 63 08 e8 4b 62 cf fc 4c 89 e2 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <80> 3c 02 00 75 43 4c 8b 6b 08 4d 85 ed 74 2e e8 26 62 cf fc 31 RIP: klist_iter_exit+0x26/0x90 lib/klist.c:314 RSP: 880103f57c30 ---[ end trace 69831a3bb9e34eca ]--- Kernel panic - not syncing: Fatal exception Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: disabled Rebooting in 86400 seconds.. Regards, Shankara
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
Below is a reproducer.
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#define KCOV_INIT_TRACE _IOR('c', 1, unsigned long)
#define KCOV_ENABLE _IO('c', 100)
#define KCOV_DISABLE _IO('c', 101)
#define COVER_SIZE (16 << 20)
void kcov_setup() {
unsigned long *cover;
int fd;
fd = open("/sys/kernel/debug/kcov", O_RDWR);
if (fd == -1)
perror("open"), exit(1);
if (ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE))
perror("ioctl"), exit(1);
cover = (unsigned long*)mmap(NULL,
COVER_SIZE * sizeof(unsigned long),
PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if ((void*)cover == MAP_FAILED)
perror("mmap"), exit(1);
if (ioctl(fd, KCOV_ENABLE, 0))
perror("ioctl"), exit(1);
}
void main() {
int i;
for (i = 0; i < 4; i++)
kcov_setup();
sleep(10);
}
On Sun, Jan 21, 2018 at 1:11 AM, Shankara Pailoor <sp3...@columbia.edu> wrote:
> Hi Dmitry,
>
> The leaks went away when I disabled and closed the old file
> descriptors before opening new ones.
>
> The patch you sent wouldn't work because t is not initialized at the
> line. This seems to work for me
>
> diff --git a/kernel/kcov.c b/kernel/kcov.c
> index 7594c03..1397006 100644
> --- a/kernel/kcov.c
> +++ b/kernel/kcov.c
> @@ -371,6 +371,8 @@ static int kcov_ioctl_locked(struct kcov *kcov,
> unsigned int cmd,
> else
> return -EINVAL;
> t = current;
> + if (!t->kcov)
> + return -EBUSY;
> /* Cache in task struct for performance. */
> t->kcov_size = kcov->size;
> t->kcov_area = kcov->area;
>
> On Sat, Jan 20, 2018 at 7:06 AM, Dmitry Vyukov <dvyu...@google.com> wrote:
>> On Sat, Jan 20, 2018 at 4:01 PM, Shankara Pailoor <sp3...@columbia.edu>
>> wrote:
>>> Hi Dmitry,
>>>
>>> I will try and get something to you tomorrow. Just wondering, but what
>>> happens to the old struct kcov if a task opens /sys/kernel/debug/kcov
>>> twice? I am looking here
>>> https://elixir.free-electrons.com/linux/v4.15-rc8/source/kernel/kcov.c#L381
>>> and I don't see where the previous struct would get freed.
>>
>> Good question. Perhaps we need something like:
>>
>> diff --git a/kernel/kcov.c b/kernel/kcov.c
>> index 7594c033d98a..c76498018500 100644
>> --- a/kernel/kcov.c
>> +++ b/kernel/kcov.c
>> @@ -358,7 +358,7 @@ static int kcov_ioctl_locked(struct kcov *kcov,
>> unsigned int cmd,
>> */
>> if (kcov->mode != KCOV_MODE_INIT || !kcov->area)
>> return -EINVAL;
>> - if (kcov->t != NULL)
>> + if (kcov->t != NULL || t->kcov != NULL)
>> return -EBUSY;
>> if (arg == KCOV_TRACE_PC)
>> kcov->mode = KCOV_MODE_TRACE_PC;
>>
>>
>>
>>> On Sat, Jan 20, 2018 at 4:38 AM, Dmitry Vyukov <dvyu...@google.com> wrote:
>>>> On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoor <sp3...@columbia.edu>
>>>> wrote:
>>>>> Hi Dmitry,
>>>>>
>>>>> I added support for kcov in strace and I have been tracing a fairly
>>>>> large program but after a little while, I notice that when I mmap a
>>>>> new cover buffer, the call fails with ENOMEM. After killing the
>>>>> program, I try and rerun and I notice that there is nearly no memory
>>>>> on the system. When I do a kmemleak scan I get the following reports:
>>>>>
>>>>> I believe the problem occurs when I try and setup the kcov buffer
>>>>> again after an exec. Instead of reusing the old file descriptor I open
>>>>> kcov again within that process. In that case, I don't know what
>>>>> happens to the old kcov struct.
>>>>>
>>>>> I don't see a maintainers list for kcov so I decided to email you
>>>>> directly. Let me know what more information I can provide.
>>>>
>>>>
>>>> Hi Shankara,
>>>>
>>>> Looks bad. Can you provide a reproducer?
>>>> We extensively use kcov with syzkaller, but have not observed such
>>>> leaks. Also I don't see anything obvious in the code.
>>>>
>>>> Thanks
>>>
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
Below is a reproducer.
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#define KCOV_INIT_TRACE _IOR('c', 1, unsigned long)
#define KCOV_ENABLE _IO('c', 100)
#define KCOV_DISABLE _IO('c', 101)
#define COVER_SIZE (16 << 20)
void kcov_setup() {
unsigned long *cover;
int fd;
fd = open("/sys/kernel/debug/kcov", O_RDWR);
if (fd == -1)
perror("open"), exit(1);
if (ioctl(fd, KCOV_INIT_TRACE, COVER_SIZE))
perror("ioctl"), exit(1);
cover = (unsigned long*)mmap(NULL,
COVER_SIZE * sizeof(unsigned long),
PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if ((void*)cover == MAP_FAILED)
perror("mmap"), exit(1);
if (ioctl(fd, KCOV_ENABLE, 0))
perror("ioctl"), exit(1);
}
void main() {
int i;
for (i = 0; i < 4; i++)
kcov_setup();
sleep(10);
}
On Sun, Jan 21, 2018 at 1:11 AM, Shankara Pailoor wrote:
> Hi Dmitry,
>
> The leaks went away when I disabled and closed the old file
> descriptors before opening new ones.
>
> The patch you sent wouldn't work because t is not initialized at the
> line. This seems to work for me
>
> diff --git a/kernel/kcov.c b/kernel/kcov.c
> index 7594c03..1397006 100644
> --- a/kernel/kcov.c
> +++ b/kernel/kcov.c
> @@ -371,6 +371,8 @@ static int kcov_ioctl_locked(struct kcov *kcov,
> unsigned int cmd,
> else
> return -EINVAL;
> t = current;
> + if (!t->kcov)
> + return -EBUSY;
> /* Cache in task struct for performance. */
> t->kcov_size = kcov->size;
> t->kcov_area = kcov->area;
>
> On Sat, Jan 20, 2018 at 7:06 AM, Dmitry Vyukov wrote:
>> On Sat, Jan 20, 2018 at 4:01 PM, Shankara Pailoor
>> wrote:
>>> Hi Dmitry,
>>>
>>> I will try and get something to you tomorrow. Just wondering, but what
>>> happens to the old struct kcov if a task opens /sys/kernel/debug/kcov
>>> twice? I am looking here
>>> https://elixir.free-electrons.com/linux/v4.15-rc8/source/kernel/kcov.c#L381
>>> and I don't see where the previous struct would get freed.
>>
>> Good question. Perhaps we need something like:
>>
>> diff --git a/kernel/kcov.c b/kernel/kcov.c
>> index 7594c033d98a..c76498018500 100644
>> --- a/kernel/kcov.c
>> +++ b/kernel/kcov.c
>> @@ -358,7 +358,7 @@ static int kcov_ioctl_locked(struct kcov *kcov,
>> unsigned int cmd,
>> */
>> if (kcov->mode != KCOV_MODE_INIT || !kcov->area)
>> return -EINVAL;
>> - if (kcov->t != NULL)
>> + if (kcov->t != NULL || t->kcov != NULL)
>> return -EBUSY;
>> if (arg == KCOV_TRACE_PC)
>> kcov->mode = KCOV_MODE_TRACE_PC;
>>
>>
>>
>>> On Sat, Jan 20, 2018 at 4:38 AM, Dmitry Vyukov wrote:
>>>> On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoor
>>>> wrote:
>>>>> Hi Dmitry,
>>>>>
>>>>> I added support for kcov in strace and I have been tracing a fairly
>>>>> large program but after a little while, I notice that when I mmap a
>>>>> new cover buffer, the call fails with ENOMEM. After killing the
>>>>> program, I try and rerun and I notice that there is nearly no memory
>>>>> on the system. When I do a kmemleak scan I get the following reports:
>>>>>
>>>>> I believe the problem occurs when I try and setup the kcov buffer
>>>>> again after an exec. Instead of reusing the old file descriptor I open
>>>>> kcov again within that process. In that case, I don't know what
>>>>> happens to the old kcov struct.
>>>>>
>>>>> I don't see a maintainers list for kcov so I decided to email you
>>>>> directly. Let me know what more information I can provide.
>>>>
>>>>
>>>> Hi Shankara,
>>>>
>>>> Looks bad. Can you provide a reproducer?
>>>> We extensively use kcov with syzkaller, but have not observed such
>>>> leaks. Also I don't see anything obvious in the code.
>>>>
>>>> Thanks
>>>
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
Hi Dmitry, The leaks went away when I disabled and closed the old file descriptors before opening new ones. The patch you sent wouldn't work because t is not initialized at the line. This seems to work for me diff --git a/kernel/kcov.c b/kernel/kcov.c index 7594c03..1397006 100644 --- a/kernel/kcov.c +++ b/kernel/kcov.c @@ -371,6 +371,8 @@ static int kcov_ioctl_locked(struct kcov *kcov, unsigned int cmd, else return -EINVAL; t = current; + if (!t->kcov) + return -EBUSY; /* Cache in task struct for performance. */ t->kcov_size = kcov->size; t->kcov_area = kcov->area; On Sat, Jan 20, 2018 at 7:06 AM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Sat, Jan 20, 2018 at 4:01 PM, Shankara Pailoor <sp3...@columbia.edu> wrote: >> Hi Dmitry, >> >> I will try and get something to you tomorrow. Just wondering, but what >> happens to the old struct kcov if a task opens /sys/kernel/debug/kcov >> twice? I am looking here >> https://elixir.free-electrons.com/linux/v4.15-rc8/source/kernel/kcov.c#L381 >> and I don't see where the previous struct would get freed. > > Good question. Perhaps we need something like: > > diff --git a/kernel/kcov.c b/kernel/kcov.c > index 7594c033d98a..c76498018500 100644 > --- a/kernel/kcov.c > +++ b/kernel/kcov.c > @@ -358,7 +358,7 @@ static int kcov_ioctl_locked(struct kcov *kcov, > unsigned int cmd, > */ > if (kcov->mode != KCOV_MODE_INIT || !kcov->area) > return -EINVAL; > - if (kcov->t != NULL) > + if (kcov->t != NULL || t->kcov != NULL) > return -EBUSY; > if (arg == KCOV_TRACE_PC) > kcov->mode = KCOV_MODE_TRACE_PC; > > > >> On Sat, Jan 20, 2018 at 4:38 AM, Dmitry Vyukov <dvyu...@google.com> wrote: >>> On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoor <sp3...@columbia.edu> >>> wrote: >>>> Hi Dmitry, >>>> >>>> I added support for kcov in strace and I have been tracing a fairly >>>> large program but after a little while, I notice that when I mmap a >>>> new cover buffer, the call fails with ENOMEM. After killing the >>>> program, I try and rerun and I notice that there is nearly no memory >>>> on the system. When I do a kmemleak scan I get the following reports: >>>> >>>> I believe the problem occurs when I try and setup the kcov buffer >>>> again after an exec. Instead of reusing the old file descriptor I open >>>> kcov again within that process. In that case, I don't know what >>>> happens to the old kcov struct. >>>> >>>> I don't see a maintainers list for kcov so I decided to email you >>>> directly. Let me know what more information I can provide. >>> >>> >>> Hi Shankara, >>> >>> Looks bad. Can you provide a reproducer? >>> We extensively use kcov with syzkaller, but have not observed such >>> leaks. Also I don't see anything obvious in the code. >>> >>> Thanks >>
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
Hi Dmitry, The leaks went away when I disabled and closed the old file descriptors before opening new ones. The patch you sent wouldn't work because t is not initialized at the line. This seems to work for me diff --git a/kernel/kcov.c b/kernel/kcov.c index 7594c03..1397006 100644 --- a/kernel/kcov.c +++ b/kernel/kcov.c @@ -371,6 +371,8 @@ static int kcov_ioctl_locked(struct kcov *kcov, unsigned int cmd, else return -EINVAL; t = current; + if (!t->kcov) + return -EBUSY; /* Cache in task struct for performance. */ t->kcov_size = kcov->size; t->kcov_area = kcov->area; On Sat, Jan 20, 2018 at 7:06 AM, Dmitry Vyukov wrote: > On Sat, Jan 20, 2018 at 4:01 PM, Shankara Pailoor wrote: >> Hi Dmitry, >> >> I will try and get something to you tomorrow. Just wondering, but what >> happens to the old struct kcov if a task opens /sys/kernel/debug/kcov >> twice? I am looking here >> https://elixir.free-electrons.com/linux/v4.15-rc8/source/kernel/kcov.c#L381 >> and I don't see where the previous struct would get freed. > > Good question. Perhaps we need something like: > > diff --git a/kernel/kcov.c b/kernel/kcov.c > index 7594c033d98a..c76498018500 100644 > --- a/kernel/kcov.c > +++ b/kernel/kcov.c > @@ -358,7 +358,7 @@ static int kcov_ioctl_locked(struct kcov *kcov, > unsigned int cmd, > */ > if (kcov->mode != KCOV_MODE_INIT || !kcov->area) > return -EINVAL; > - if (kcov->t != NULL) > + if (kcov->t != NULL || t->kcov != NULL) > return -EBUSY; > if (arg == KCOV_TRACE_PC) > kcov->mode = KCOV_MODE_TRACE_PC; > > > >> On Sat, Jan 20, 2018 at 4:38 AM, Dmitry Vyukov wrote: >>> On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoor >>> wrote: >>>> Hi Dmitry, >>>> >>>> I added support for kcov in strace and I have been tracing a fairly >>>> large program but after a little while, I notice that when I mmap a >>>> new cover buffer, the call fails with ENOMEM. After killing the >>>> program, I try and rerun and I notice that there is nearly no memory >>>> on the system. When I do a kmemleak scan I get the following reports: >>>> >>>> I believe the problem occurs when I try and setup the kcov buffer >>>> again after an exec. Instead of reusing the old file descriptor I open >>>> kcov again within that process. In that case, I don't know what >>>> happens to the old kcov struct. >>>> >>>> I don't see a maintainers list for kcov so I decided to email you >>>> directly. Let me know what more information I can provide. >>> >>> >>> Hi Shankara, >>> >>> Looks bad. Can you provide a reproducer? >>> We extensively use kcov with syzkaller, but have not observed such >>> leaks. Also I don't see anything obvious in the code. >>> >>> Thanks >>
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
Hi Dmitry, I will try and get something to you tomorrow. Just wondering, but what happens to the old struct kcov if a task opens /sys/kernel/debug/kcov twice? I am looking here https://elixir.free-electrons.com/linux/v4.15-rc8/source/kernel/kcov.c#L381 and I don't see where the previous struct would get freed. Regards, Shankara On Sat, Jan 20, 2018 at 4:38 AM, Dmitry Vyukov <dvyu...@google.com> wrote: > On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoor <sp3...@columbia.edu> wrote: >> Hi Dmitry, >> >> I added support for kcov in strace and I have been tracing a fairly >> large program but after a little while, I notice that when I mmap a >> new cover buffer, the call fails with ENOMEM. After killing the >> program, I try and rerun and I notice that there is nearly no memory >> on the system. When I do a kmemleak scan I get the following reports: >> >> I believe the problem occurs when I try and setup the kcov buffer >> again after an exec. Instead of reusing the old file descriptor I open >> kcov again within that process. In that case, I don't know what >> happens to the old kcov struct. >> >> I don't see a maintainers list for kcov so I decided to email you >> directly. Let me know what more information I can provide. > > > Hi Shankara, > > Looks bad. Can you provide a reproducer? > We extensively use kcov with syzkaller, but have not observed such > leaks. Also I don't see anything obvious in the code. > > Thanks
Re: Possible Memory Leak in KCOV Linux 4.15-rc1
Hi Dmitry, I will try and get something to you tomorrow. Just wondering, but what happens to the old struct kcov if a task opens /sys/kernel/debug/kcov twice? I am looking here https://elixir.free-electrons.com/linux/v4.15-rc8/source/kernel/kcov.c#L381 and I don't see where the previous struct would get freed. Regards, Shankara On Sat, Jan 20, 2018 at 4:38 AM, Dmitry Vyukov wrote: > On Fri, Jan 19, 2018 at 8:29 PM, Shankara Pailoor wrote: >> Hi Dmitry, >> >> I added support for kcov in strace and I have been tracing a fairly >> large program but after a little while, I notice that when I mmap a >> new cover buffer, the call fails with ENOMEM. After killing the >> program, I try and rerun and I notice that there is nearly no memory >> on the system. When I do a kmemleak scan I get the following reports: >> >> I believe the problem occurs when I try and setup the kcov buffer >> again after an exec. Instead of reusing the old file descriptor I open >> kcov again within that process. In that case, I don't know what >> happens to the old kcov struct. >> >> I don't see a maintainers list for kcov so I decided to email you >> directly. Let me know what more information I can provide. > > > Hi Shankara, > > Looks bad. Can you provide a reproducer? > We extensively use kcov with syzkaller, but have not observed such > leaks. Also I don't see anything obvious in the code. > > Thanks
Possible Memory Leak in KCOV Linux 4.15-rc1
Hi Dmitry, I added support for kcov in strace and I have been tracing a fairly large program but after a little while, I notice that when I mmap a new cover buffer, the call fails with ENOMEM. After killing the program, I try and rerun and I notice that there is nearly no memory on the system. When I do a kmemleak scan I get the following reports: I believe the problem occurs when I try and setup the kcov buffer again after an exec. Instead of reusing the old file descriptor I open kcov again within that process. In that case, I don't know what happens to the old kcov struct. I don't see a maintainers list for kcov so I decided to email you directly. Let me know what more information I can provide. unreferenced object 0x8800633f6378 (size 96): comm "runltp", pid 1847, jiffies 4294957922 (age 190.320s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .N.. ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff backtrace: [] kmem_cache_alloc_trace+0x146/0x2e0 [] kcov_open+0x25/0x80 [] open_proxy_open+0x1e4/0x2b0 [] do_dentry_open+0x682/0xd70 [] vfs_open+0x107/0x230 [] path_openat+0x1157/0x3520 [] do_filp_open+0x25b/0x3b0 [] do_sys_open+0x4fc/0x6c0 [] SyS_open+0x2d/0x40 [] do_syscall_64+0x23b/0x820 [] return_from_SYSCALL_64+0x0/0x75 [] 0x unreferenced object 0xc90008679000 (size 134217728): comm "runltp", pid 1847, jiffies 4294957981 (age 190.261s) hex dump (first 32 bytes): e0 d2 46 00 00 00 00 00 22 05 73 81 ff ff ff ff ..F.".s. 47 16 73 81 ff ff ff ff 11 16 73 81 ff ff ff ff G.s...s. backtrace: [] __vmalloc_node_range+0x387/0x6a0 [] vmalloc_user+0x6c/0x140 [] kcov_mmap+0x2e/0x170 [] mmap_region+0xa9c/0x15a0 [] do_mmap+0x6c6/0xe10 [] vm_mmap_pgoff+0x1de/0x270 [] SyS_mmap_pgoff+0x469/0x610 [] SyS_mmap+0x16/0x20 [] do_syscall_64+0x23b/0x820 [] return_from_SYSCALL_64+0x0/0x75 [] 0x unreferenced object 0x8800633f6a58 (size 96): comm "runltp", pid 1848, jiffies 4294958935 (age 189.307s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .N.. ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff backtrace: [] kmem_cache_alloc_trace+0x146/0x2e0 [] kcov_open+0x25/0x80 [] open_proxy_open+0x1e4/0x2b0 [] do_dentry_open+0x682/0xd70 [] vfs_open+0x107/0x230 [] path_openat+0x1157/0x3520 [] do_filp_open+0x25b/0x3b0 [] do_sys_open+0x4fc/0x6c0 [] SyS_open+0x2d/0x40 [] do_syscall_64+0x23b/0x820 [] return_from_SYSCALL_64+0x0/0x75 [] 0x unreferenced object 0xc9001067a000 (size 134217728): comm "runltp", pid 1848, jiffies 4294958994 (age 189.248s) hex dump (first 32 bytes): 76 db 46 00 00 00 00 00 22 05 73 81 ff ff ff ff v.F.".s. 47 16 73 81 ff ff ff ff 11 16 73 81 ff ff ff ff G.s...s. backtrace: [] __vmalloc_node_range+0x387/0x6a0 [] vmalloc_user+0x6c/0x140 [] kcov_mmap+0x2e/0x170 [] mmap_region+0xa9c/0x15a0 [] do_mmap+0x6c6/0xe10 [] vm_mmap_pgoff+0x1de/0x270 [] SyS_mmap_pgoff+0x469/0x610 [] SyS_mmap+0x16/0x20 [] do_syscall_64+0x23b/0x820 [] return_from_SYSCALL_64+0x0/0x75 [] 0x unreferenced object 0x88006516c6e8 (size 96): comm "runltp", pid 1849, jiffies 4294960010 (age 188.242s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .N.. ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff backtrace: [] kmem_cache_alloc_trace+0x146/0x2e0 [] kcov_open+0x25/0x80 [] open_proxy_open+0x1e4/0x2b0 [] do_dentry_open+0x682/0xd70 [] vfs_open+0x107/0x230 [] path_openat+0x1157/0x3520 [] do_filp_open+0x25b/0x3b0 [] do_sys_open+0x4fc/0x6c0 [] SyS_open+0x2d/0x40 [] do_syscall_64+0x23b/0x820 [] return_from_SYSCALL_64+0x0/0x75 [] 0x unreferenced object 0xc9001867b000 (size 134217728): comm "runltp", pid 1849, jiffies 4294960071 (age 188.181s) hex dump (first 32 bytes): 5d ee 46 00 00 00 00 00 22 05 73 81 ff ff ff ff ].F.".s. 47 16 73 81 ff ff ff ff 11 16 73 81 ff ff ff ff G.s...s. backtrace: [] __vmalloc_node_range+0x387/0x6a0 [] vmalloc_user+0x6c/0x140 [] kcov_mmap+0x2e/0x170 [] mmap_region+0xa9c/0x15a0 [] do_mmap+0x6c6/0xe10 [] vm_mmap_pgoff+0x1de/0x270 [] SyS_mmap_pgoff+0x469/0x610 [] SyS_mmap+0x16/0x20 [] do_syscall_64+0x23b/0x820 [] return_from_SYSCALL_64+0x0/0x75 [] 0x unreferenced object 0x88003ed519d0 (size 96): comm "runltp", pid 1850, jiffies 4294961128 (age 187.124s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .N.. ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff backtrace: []
Possible Memory Leak in KCOV Linux 4.15-rc1
Hi Dmitry, I added support for kcov in strace and I have been tracing a fairly large program but after a little while, I notice that when I mmap a new cover buffer, the call fails with ENOMEM. After killing the program, I try and rerun and I notice that there is nearly no memory on the system. When I do a kmemleak scan I get the following reports: I believe the problem occurs when I try and setup the kcov buffer again after an exec. Instead of reusing the old file descriptor I open kcov again within that process. In that case, I don't know what happens to the old kcov struct. I don't see a maintainers list for kcov so I decided to email you directly. Let me know what more information I can provide. unreferenced object 0x8800633f6378 (size 96): comm "runltp", pid 1847, jiffies 4294957922 (age 190.320s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .N.. ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff backtrace: [] kmem_cache_alloc_trace+0x146/0x2e0 [] kcov_open+0x25/0x80 [] open_proxy_open+0x1e4/0x2b0 [] do_dentry_open+0x682/0xd70 [] vfs_open+0x107/0x230 [] path_openat+0x1157/0x3520 [] do_filp_open+0x25b/0x3b0 [] do_sys_open+0x4fc/0x6c0 [] SyS_open+0x2d/0x40 [] do_syscall_64+0x23b/0x820 [] return_from_SYSCALL_64+0x0/0x75 [] 0x unreferenced object 0xc90008679000 (size 134217728): comm "runltp", pid 1847, jiffies 4294957981 (age 190.261s) hex dump (first 32 bytes): e0 d2 46 00 00 00 00 00 22 05 73 81 ff ff ff ff ..F.".s. 47 16 73 81 ff ff ff ff 11 16 73 81 ff ff ff ff G.s...s. backtrace: [] __vmalloc_node_range+0x387/0x6a0 [] vmalloc_user+0x6c/0x140 [] kcov_mmap+0x2e/0x170 [] mmap_region+0xa9c/0x15a0 [] do_mmap+0x6c6/0xe10 [] vm_mmap_pgoff+0x1de/0x270 [] SyS_mmap_pgoff+0x469/0x610 [] SyS_mmap+0x16/0x20 [] do_syscall_64+0x23b/0x820 [] return_from_SYSCALL_64+0x0/0x75 [] 0x unreferenced object 0x8800633f6a58 (size 96): comm "runltp", pid 1848, jiffies 4294958935 (age 189.307s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .N.. ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff backtrace: [] kmem_cache_alloc_trace+0x146/0x2e0 [] kcov_open+0x25/0x80 [] open_proxy_open+0x1e4/0x2b0 [] do_dentry_open+0x682/0xd70 [] vfs_open+0x107/0x230 [] path_openat+0x1157/0x3520 [] do_filp_open+0x25b/0x3b0 [] do_sys_open+0x4fc/0x6c0 [] SyS_open+0x2d/0x40 [] do_syscall_64+0x23b/0x820 [] return_from_SYSCALL_64+0x0/0x75 [] 0x unreferenced object 0xc9001067a000 (size 134217728): comm "runltp", pid 1848, jiffies 4294958994 (age 189.248s) hex dump (first 32 bytes): 76 db 46 00 00 00 00 00 22 05 73 81 ff ff ff ff v.F.".s. 47 16 73 81 ff ff ff ff 11 16 73 81 ff ff ff ff G.s...s. backtrace: [] __vmalloc_node_range+0x387/0x6a0 [] vmalloc_user+0x6c/0x140 [] kcov_mmap+0x2e/0x170 [] mmap_region+0xa9c/0x15a0 [] do_mmap+0x6c6/0xe10 [] vm_mmap_pgoff+0x1de/0x270 [] SyS_mmap_pgoff+0x469/0x610 [] SyS_mmap+0x16/0x20 [] do_syscall_64+0x23b/0x820 [] return_from_SYSCALL_64+0x0/0x75 [] 0x unreferenced object 0x88006516c6e8 (size 96): comm "runltp", pid 1849, jiffies 4294960010 (age 188.242s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .N.. ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff backtrace: [] kmem_cache_alloc_trace+0x146/0x2e0 [] kcov_open+0x25/0x80 [] open_proxy_open+0x1e4/0x2b0 [] do_dentry_open+0x682/0xd70 [] vfs_open+0x107/0x230 [] path_openat+0x1157/0x3520 [] do_filp_open+0x25b/0x3b0 [] do_sys_open+0x4fc/0x6c0 [] SyS_open+0x2d/0x40 [] do_syscall_64+0x23b/0x820 [] return_from_SYSCALL_64+0x0/0x75 [] 0x unreferenced object 0xc9001867b000 (size 134217728): comm "runltp", pid 1849, jiffies 4294960071 (age 188.181s) hex dump (first 32 bytes): 5d ee 46 00 00 00 00 00 22 05 73 81 ff ff ff ff ].F.".s. 47 16 73 81 ff ff ff ff 11 16 73 81 ff ff ff ff G.s...s. backtrace: [] __vmalloc_node_range+0x387/0x6a0 [] vmalloc_user+0x6c/0x140 [] kcov_mmap+0x2e/0x170 [] mmap_region+0xa9c/0x15a0 [] do_mmap+0x6c6/0xe10 [] vm_mmap_pgoff+0x1de/0x270 [] SyS_mmap_pgoff+0x469/0x610 [] SyS_mmap+0x16/0x20 [] do_syscall_64+0x23b/0x820 [] return_from_SYSCALL_64+0x0/0x75 [] 0x unreferenced object 0x88003ed519d0 (size 96): comm "runltp", pid 1850, jiffies 4294961128 (age 187.124s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .N.. ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff backtrace: []
Re: RCU stall in 8250 serial driver Linux 4.15-rc1
NOMEM || e == EAGAIN) ? kRetryStatus : kFailStatus);
}
NORETURN static void exitf(const char* msg, ...)
{
int e = errno;
fflush(stdout);
va_list args;
va_start(args, msg);
vfprintf(stderr, msg, args);
va_end(args);
fprintf(stderr, " (errno %d)\n", e);
doexit(kRetryStatus);
}
static uint64_t current_time_ms()
{
struct timespec ts;
if (clock_gettime(CLOCK_MONOTONIC, ))
fail("clock_gettime failed");
return (uint64_t)ts.tv_sec * 1000 + (uint64_t)ts.tv_nsec / 100;
}
static void test();
void loop()
{
int iter;
for (iter = 0;; iter++) {
int pid = fork();
if (pid < 0)
fail("clone failed");
if (pid == 0) {
prctl(PR_SET_PDEATHSIG, SIGKILL, 0, 0, 0);
setpgrp();
test();
doexit(0);
}
int status = 0;
uint64_t start = current_time_ms();
for (;;) {
int res = waitpid(-1, , __WALL | WNOHANG);
if (res == pid)
break;
usleep(1000);
if (current_time_ms() - start > 5 * 1000) {
kill(-pid, SIGKILL);
kill(pid, SIGKILL);
while (waitpid(-1, , __WALL) != pid) {
}
break;
}
}
}
}
long r[28];
void test()
{
memset(r, -1, sizeof(r));
r[0] = syscall(__NR_mmap, 0x2000ul, 0x3b8000ul, 0x3ul, 0x32ul,
0xul, 0x0ul);
r[1] = syscall(__NR_socket, 0x2ul, 0x1ul, 0x0ul);
*(uint16_t*)0x27b6 = (uint16_t)0x2;
*(uint16_t*)0x27b8 = (uint16_t)0x234e;
*(uint32_t*)0x27ba = (uint32_t)0x0;
*(uint8_t*)0x27be = (uint8_t)0x0;
*(uint8_t*)0x27bf = (uint8_t)0x0;
*(uint8_t*)0x27c0 = (uint8_t)0x0;
*(uint8_t*)0x27c1 = (uint8_t)0x0;
*(uint8_t*)0x27c2 = (uint8_t)0x0;
*(uint8_t*)0x27c3 = (uint8_t)0x0;
*(uint8_t*)0x27c4 = (uint8_t)0x0;
*(uint8_t*)0x27c5 = (uint8_t)0x0;
r[13] = syscall(__NR_bind, r[1], 0x27b6ul, 0x10ul);
r[14] = syscall(__NR_listen, r[1], 0x0ul);
r[15] = syscall(__NR_socket, 0x2ul, 0x1ul, 0x0ul);
*(uint16_t*)0x28e6 = (uint16_t)0x2;
*(uint16_t*)0x28e8 = (uint16_t)0x234e;
*(uint32_t*)0x28ea = (uint32_t)0x17f;
*(uint8_t*)0x28ee = (uint8_t)0x0;
*(uint8_t*)0x28ef = (uint8_t)0x0;
*(uint8_t*)0x28f0 = (uint8_t)0x0;
*(uint8_t*)0x28f1 = (uint8_t)0x0;
*(uint8_t*)0x28f2 = (uint8_t)0x0;
*(uint8_t*)0x28f3 = (uint8_t)0x0;
*(uint8_t*)0x28f4 = (uint8_t)0x0;
*(uint8_t*)0x28f5 = (uint8_t)0x0;
r[27] = syscall(__NR_connect, r[15], 0x28e6ul, 0x10ul);
}
int main()
{
int i; for (i = 0; i < 8; i++) {
if (fork() == 0) {
loop();
return 0;
}
}
sleep(100);
return 0;
}
Regards,
Shankara
On Wed, Jan 17, 2018 at 9:05 AM, Greg KH <gre...@linuxfoundation.org> wrote:
> On Wed, Jan 17, 2018 at 08:53:06AM -0800, Shankara Pailoor wrote:
>> Hi,
>>
>> Syzkaller found the following rcu stall report in Linux 4.15-rc1:
>> https://pastebin.com/NyZ9JdRv
>>
>> The following C program reproduces it: https://pastebin.com/gqwDWWpA
>>
>> Configs Here: https://pastebin.com/v6M3iKi1
>
> I don't visit random web sites for random bugs. Please include all of
> the information in the email itself.
>
> thanks,
>
> greg k-h
Re: RCU stall in 8250 serial driver Linux 4.15-rc1
NOMEM || e == EAGAIN) ? kRetryStatus : kFailStatus);
}
NORETURN static void exitf(const char* msg, ...)
{
int e = errno;
fflush(stdout);
va_list args;
va_start(args, msg);
vfprintf(stderr, msg, args);
va_end(args);
fprintf(stderr, " (errno %d)\n", e);
doexit(kRetryStatus);
}
static uint64_t current_time_ms()
{
struct timespec ts;
if (clock_gettime(CLOCK_MONOTONIC, ))
fail("clock_gettime failed");
return (uint64_t)ts.tv_sec * 1000 + (uint64_t)ts.tv_nsec / 100;
}
static void test();
void loop()
{
int iter;
for (iter = 0;; iter++) {
int pid = fork();
if (pid < 0)
fail("clone failed");
if (pid == 0) {
prctl(PR_SET_PDEATHSIG, SIGKILL, 0, 0, 0);
setpgrp();
test();
doexit(0);
}
int status = 0;
uint64_t start = current_time_ms();
for (;;) {
int res = waitpid(-1, , __WALL | WNOHANG);
if (res == pid)
break;
usleep(1000);
if (current_time_ms() - start > 5 * 1000) {
kill(-pid, SIGKILL);
kill(pid, SIGKILL);
while (waitpid(-1, , __WALL) != pid) {
}
break;
}
}
}
}
long r[28];
void test()
{
memset(r, -1, sizeof(r));
r[0] = syscall(__NR_mmap, 0x2000ul, 0x3b8000ul, 0x3ul, 0x32ul,
0xul, 0x0ul);
r[1] = syscall(__NR_socket, 0x2ul, 0x1ul, 0x0ul);
*(uint16_t*)0x27b6 = (uint16_t)0x2;
*(uint16_t*)0x27b8 = (uint16_t)0x234e;
*(uint32_t*)0x27ba = (uint32_t)0x0;
*(uint8_t*)0x27be = (uint8_t)0x0;
*(uint8_t*)0x27bf = (uint8_t)0x0;
*(uint8_t*)0x27c0 = (uint8_t)0x0;
*(uint8_t*)0x27c1 = (uint8_t)0x0;
*(uint8_t*)0x27c2 = (uint8_t)0x0;
*(uint8_t*)0x27c3 = (uint8_t)0x0;
*(uint8_t*)0x27c4 = (uint8_t)0x0;
*(uint8_t*)0x27c5 = (uint8_t)0x0;
r[13] = syscall(__NR_bind, r[1], 0x27b6ul, 0x10ul);
r[14] = syscall(__NR_listen, r[1], 0x0ul);
r[15] = syscall(__NR_socket, 0x2ul, 0x1ul, 0x0ul);
*(uint16_t*)0x28e6 = (uint16_t)0x2;
*(uint16_t*)0x28e8 = (uint16_t)0x234e;
*(uint32_t*)0x28ea = (uint32_t)0x17f;
*(uint8_t*)0x28ee = (uint8_t)0x0;
*(uint8_t*)0x28ef = (uint8_t)0x0;
*(uint8_t*)0x28f0 = (uint8_t)0x0;
*(uint8_t*)0x28f1 = (uint8_t)0x0;
*(uint8_t*)0x28f2 = (uint8_t)0x0;
*(uint8_t*)0x28f3 = (uint8_t)0x0;
*(uint8_t*)0x28f4 = (uint8_t)0x0;
*(uint8_t*)0x28f5 = (uint8_t)0x0;
r[27] = syscall(__NR_connect, r[15], 0x28e6ul, 0x10ul);
}
int main()
{
int i; for (i = 0; i < 8; i++) {
if (fork() == 0) {
loop();
return 0;
}
}
sleep(100);
return 0;
}
Regards,
Shankara
On Wed, Jan 17, 2018 at 9:05 AM, Greg KH wrote:
> On Wed, Jan 17, 2018 at 08:53:06AM -0800, Shankara Pailoor wrote:
>> Hi,
>>
>> Syzkaller found the following rcu stall report in Linux 4.15-rc1:
>> https://pastebin.com/NyZ9JdRv
>>
>> The following C program reproduces it: https://pastebin.com/gqwDWWpA
>>
>> Configs Here: https://pastebin.com/v6M3iKi1
>
> I don't visit random web sites for random bugs. Please include all of
> the information in the email itself.
>
> thanks,
>
> greg k-h
RCU stall in 8250 serial driver Linux 4.15-rc1
Hi, Syzkaller found the following rcu stall report in Linux 4.15-rc1: https://pastebin.com/NyZ9JdRv The following C program reproduces it: https://pastebin.com/gqwDWWpA Configs Here: https://pastebin.com/v6M3iKi1 Regards, Shankara
RCU stall in 8250 serial driver Linux 4.15-rc1
Hi, Syzkaller found the following rcu stall report in Linux 4.15-rc1: https://pastebin.com/NyZ9JdRv The following C program reproduces it: https://pastebin.com/gqwDWWpA Configs Here: https://pastebin.com/v6M3iKi1 Regards, Shankara
WARNING: at net/core/stream.c:204
Hi, We encountered the following warning when fuzzing with Syzkaller on Linux 4.14-rc4. Syzkaller was able to isolate the sequence of calls which caused the bug but couldn't create a C program that could regularly trigger it. Here are the logs from the reproducer attempts: https://pastebin.com/QWQZK6hW Here is the original stack trace: https://pastebin.com/7L4WciRr Regards, Shankara
WARNING: at net/core/stream.c:204
Hi, We encountered the following warning when fuzzing with Syzkaller on Linux 4.14-rc4. Syzkaller was able to isolate the sequence of calls which caused the bug but couldn't create a C program that could regularly trigger it. Here are the logs from the reproducer attempts: https://pastebin.com/QWQZK6hW Here is the original stack trace: https://pastebin.com/7L4WciRr Regards, Shankara
Re: KASAN: use-after-free in move_expired_inodes
Hi Al, etc, I was unable to find a reproducer but I was looking at move_expired_inodes (fs/fs-writeback.c 1093.c) and how do you ensure that the inode can't be freed after retrieving it from the work queue? Any insights would be appreciated. Regards, Shankara On Tue, Oct 31, 2017 at 9:24 AM, Shankara Pailoor <sp3...@columbia.edu> wrote: > Hi, > > We got the following error: > > BUG: KASAN: use-after-free in move_expired_inodes+0xce6/0xdf0 > Write of size 8 at addr 8800a3a36bf8 by task kworker/u8:0/5 > > while fuzzing with Syzkaller on 4.14-rc4 on x86_64. Included is the > trace of the crash along with the programs running around the time of > the crash. > > Programs can be found here: https://pastebin.com/RYGtNn3z > > Stack trace here: https://pastebin.com/SaJXWMg3 > > We don't have a C reproducer but we will send one if we have it. > > Regards, > Shankara
Re: KASAN: use-after-free in move_expired_inodes
Hi Al, etc, I was unable to find a reproducer but I was looking at move_expired_inodes (fs/fs-writeback.c 1093.c) and how do you ensure that the inode can't be freed after retrieving it from the work queue? Any insights would be appreciated. Regards, Shankara On Tue, Oct 31, 2017 at 9:24 AM, Shankara Pailoor wrote: > Hi, > > We got the following error: > > BUG: KASAN: use-after-free in move_expired_inodes+0xce6/0xdf0 > Write of size 8 at addr 8800a3a36bf8 by task kworker/u8:0/5 > > while fuzzing with Syzkaller on 4.14-rc4 on x86_64. Included is the > trace of the crash along with the programs running around the time of > the crash. > > Programs can be found here: https://pastebin.com/RYGtNn3z > > Stack trace here: https://pastebin.com/SaJXWMg3 > > We don't have a C reproducer but we will send one if we have it. > > Regards, > Shankara
KASAN: use-after-free in move_expired_inodes
Hi, We got the following error: BUG: KASAN: use-after-free in move_expired_inodes+0xce6/0xdf0 Write of size 8 at addr 8800a3a36bf8 by task kworker/u8:0/5 while fuzzing with Syzkaller on 4.14-rc4 on x86_64. Included is the trace of the crash along with the programs running around the time of the crash. Programs can be found here: https://pastebin.com/RYGtNn3z Stack trace here: https://pastebin.com/SaJXWMg3 We don't have a C reproducer but we will send one if we have it. Regards, Shankara
KASAN: use-after-free in move_expired_inodes
Hi, We got the following error: BUG: KASAN: use-after-free in move_expired_inodes+0xce6/0xdf0 Write of size 8 at addr 8800a3a36bf8 by task kworker/u8:0/5 while fuzzing with Syzkaller on 4.14-rc4 on x86_64. Included is the trace of the crash along with the programs running around the time of the crash. Programs can be found here: https://pastebin.com/RYGtNn3z Stack trace here: https://pastebin.com/SaJXWMg3 We don't have a C reproducer but we will send one if we have it. Regards, Shankara
WARNING in per_cpu_alloc
Hi, We found the warning when fuzzing with Syzkaller on Linux 4-14-rc4. illegal size (32776) or align (8) for percpu allocation [ cut here ] WARNING: CPU: 0 PID: 22596 at mm/percpu.c:1365 pcpu_alloc+0x140/0x10f0 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 22596 Comm: syz-executor1 Not tainted 4.14.0-rc4 #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: dump_stack+0x115/0x1da panic+0x1b4/0x3a7 __warn+0x1c4/0x1d9 report_bug+0x211/0x2d0 fixup_bug+0x40/0x90 do_trap+0x260/0x390 do_error_trap+0x11c/0x350 do_invalid_op+0x1b/0x20 invalid_op+0x18/0x20 RIP: 0010:pcpu_alloc+0x140/0x10f0 RSP: 0018:8800a752f6a8 EFLAGS: 00010286 RAX: 0037 RBX: RCX: RDX: 0037 RSI: c90001a32000 RDI: ed0014ea5ec9 RBP: 8800a752f920 R08: 8800a752ed98 R09: R10: R11: R12: 8007 R13: R14: 8800a752fec0 R15: 0008 __alloc_percpu+0x24/0x30 dev_map_alloc+0x68e/0xb70 SyS_bpf+0xd25/0x4500 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x452349 RSP: 002b:7f8c38897be8 EFLAGS: 0212 ORIG_RAX: 0141 RAX: ffda RBX: 00968000 RCX: 00452349 RDX: 001c RSI: 20038000 RDI: RBP: 0046 R08: R09: R10: R11: 0212 R12: 006f25a8 R13: R14: 00968070 R15: Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: 0x2380 from 0x8100 (relocation range: 0x8000-0xbfff) Rebooting in 86400 seconds.. Here is the reproducer program: https://pastebin.com/TdSTCu5E
WARNING in per_cpu_alloc
Hi, We found the warning when fuzzing with Syzkaller on Linux 4-14-rc4. illegal size (32776) or align (8) for percpu allocation [ cut here ] WARNING: CPU: 0 PID: 22596 at mm/percpu.c:1365 pcpu_alloc+0x140/0x10f0 Kernel panic - not syncing: panic_on_warn set ... CPU: 0 PID: 22596 Comm: syz-executor1 Not tainted 4.14.0-rc4 #1 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: dump_stack+0x115/0x1da panic+0x1b4/0x3a7 __warn+0x1c4/0x1d9 report_bug+0x211/0x2d0 fixup_bug+0x40/0x90 do_trap+0x260/0x390 do_error_trap+0x11c/0x350 do_invalid_op+0x1b/0x20 invalid_op+0x18/0x20 RIP: 0010:pcpu_alloc+0x140/0x10f0 RSP: 0018:8800a752f6a8 EFLAGS: 00010286 RAX: 0037 RBX: RCX: RDX: 0037 RSI: c90001a32000 RDI: ed0014ea5ec9 RBP: 8800a752f920 R08: 8800a752ed98 R09: R10: R11: R12: 8007 R13: R14: 8800a752fec0 R15: 0008 __alloc_percpu+0x24/0x30 dev_map_alloc+0x68e/0xb70 SyS_bpf+0xd25/0x4500 entry_SYSCALL_64_fastpath+0x1f/0xbe RIP: 0033:0x452349 RSP: 002b:7f8c38897be8 EFLAGS: 0212 ORIG_RAX: 0141 RAX: ffda RBX: 00968000 RCX: 00452349 RDX: 001c RSI: 20038000 RDI: RBP: 0046 R08: R09: R10: R11: 0212 R12: 006f25a8 R13: R14: 00968070 R15: Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: 0x2380 from 0x8100 (relocation range: 0x8000-0xbfff) Rebooting in 86400 seconds.. Here is the reproducer program: https://pastebin.com/TdSTCu5E
Memory Leak in nf_conntrack_in
Hi, I am fuzzing linux 4.13-rc7 and I got a report about a memory leak. Here is the alloc stack: 2017/10/01 02:08:59 BUG: memory leak: unreferenced object 0x880069cf0300 (size 312): comm "syz-executor0", pid 3032, jiffies 4294722144 (age 10.773s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .N.. ff ff ff ff 6d 01 80 f2 ff ff ff ff ff ff ff ff m... backtrace: [] kmemleak_alloc+0x23/0x40 [] kmem_cache_alloc+0x127/0x2d0 [] __nf_conntrack_alloc.isra.51+0x141/0x5a0 [] init_conntrack+0xd7/0x920 [] nf_conntrack_in+0xb20/0xf00 [] ipv4_conntrack_local+0x18c/0x1e0 [] nf_hook_slow+0xc3/0x290 [] __ip_local_out+0x421/0x7a0 [] ip_local_out+0x2d/0x160 [] ip_queue_xmit+0x8c6/0x1810 [] tcp_transmit_skb+0x1963/0x3320 [] tcp_connect+0x26e8/0x35e0 [] tcp_v4_connect+0x15f5/0x1e80 [] __inet_stream_connect+0x2d4/0xf00 [] inet_stream_connect+0x58/0xa0 [] SYSC_connect+0x204/0x470 unreferenced object 0x880069cf0480 (size 312): comm "syz-executor0", pid 3038, jiffies 4294722168 (age 10.749s) hex dump (first 32 bytes): 01 00 00 00 ff ff ff ff 00 00 00 00 ad 4e ad de .N.. ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff My configs are the following: https://pastebin.com/srCGHknL Regards, Shankara
Memory Leak in nf_conntrack_in
Hi, I am fuzzing linux 4.13-rc7 and I got a report about a memory leak. Here is the alloc stack: 2017/10/01 02:08:59 BUG: memory leak: unreferenced object 0x880069cf0300 (size 312): comm "syz-executor0", pid 3032, jiffies 4294722144 (age 10.773s) hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 ad 4e ad de .N.. ff ff ff ff 6d 01 80 f2 ff ff ff ff ff ff ff ff m... backtrace: [] kmemleak_alloc+0x23/0x40 [] kmem_cache_alloc+0x127/0x2d0 [] __nf_conntrack_alloc.isra.51+0x141/0x5a0 [] init_conntrack+0xd7/0x920 [] nf_conntrack_in+0xb20/0xf00 [] ipv4_conntrack_local+0x18c/0x1e0 [] nf_hook_slow+0xc3/0x290 [] __ip_local_out+0x421/0x7a0 [] ip_local_out+0x2d/0x160 [] ip_queue_xmit+0x8c6/0x1810 [] tcp_transmit_skb+0x1963/0x3320 [] tcp_connect+0x26e8/0x35e0 [] tcp_v4_connect+0x15f5/0x1e80 [] __inet_stream_connect+0x2d4/0xf00 [] inet_stream_connect+0x58/0xa0 [] SYSC_connect+0x204/0x470 unreferenced object 0x880069cf0480 (size 312): comm "syz-executor0", pid 3038, jiffies 4294722168 (age 10.749s) hex dump (first 32 bytes): 01 00 00 00 ff ff ff ff 00 00 00 00 ad 4e ad de .N.. ff ff ff ff 00 00 00 00 ff ff ff ff ff ff ff ff My configs are the following: https://pastebin.com/srCGHknL Regards, Shankara
Re: Hung Task Linux 4.13-rc7 Reiserfs
Hi, I have a reproducer program. It takes about 3-5 minutes to trigger the hang. The only calls are mmap, open, write, and readahead and the writes are fairly small (512 bytes). Reproducer Program: https://pastebin.com/cx1cgABc Report: https://pastebin.com/uGTAw45E Logs: https://pastebin.com/EaiE0JLf Kernel Configs: https://pastebin.com/i6URdADw Regards, Shankara On Fri, Sep 29, 2017 at 11:56 PM, Shankara Pailoor <sp3...@columbia.edu> wrote: > Hi, > > I am fuzzing the kernel 4.13-rc7 with Syzkaller with Reiserfs. I am > getting the following crash: > > INFO: task kworker/0:3:1103 blocked for more than 120 seconds. > > > Here is the full stack trace. I noticed that there are a few tasks > holding a sbi->lock. Below are a report and a log of all the programs > executing at the time of the incident. > > > Report: https://pastebin.com/uGTAw45E > Logs: https://pastebin.com/EaiE0JLf > Kernel Configs: https://pastebin.com/i6URdADw > > I don't have a reproducer yet and any assistance would be appreciated. > > Regards, > Shankara
Re: Hung Task Linux 4.13-rc7 Reiserfs
Hi, I have a reproducer program. It takes about 3-5 minutes to trigger the hang. The only calls are mmap, open, write, and readahead and the writes are fairly small (512 bytes). Reproducer Program: https://pastebin.com/cx1cgABc Report: https://pastebin.com/uGTAw45E Logs: https://pastebin.com/EaiE0JLf Kernel Configs: https://pastebin.com/i6URdADw Regards, Shankara On Fri, Sep 29, 2017 at 11:56 PM, Shankara Pailoor wrote: > Hi, > > I am fuzzing the kernel 4.13-rc7 with Syzkaller with Reiserfs. I am > getting the following crash: > > INFO: task kworker/0:3:1103 blocked for more than 120 seconds. > > > Here is the full stack trace. I noticed that there are a few tasks > holding a sbi->lock. Below are a report and a log of all the programs > executing at the time of the incident. > > > Report: https://pastebin.com/uGTAw45E > Logs: https://pastebin.com/EaiE0JLf > Kernel Configs: https://pastebin.com/i6URdADw > > I don't have a reproducer yet and any assistance would be appreciated. > > Regards, > Shankara
Hung Task Linux 4.13-rc7 Reiserfs
Hi, I am fuzzing the kernel 4.13-rc7 with Syzkaller with Reiserfs. I am getting the following crash: INFO: task kworker/0:3:1103 blocked for more than 120 seconds. Here is the full stack trace. I noticed that there are a few tasks holding a sbi->lock. Below are a report and a log of all the programs executing at the time of the incident. Report: https://pastebin.com/uGTAw45E Logs: https://pastebin.com/EaiE0JLf Kernel Configs: https://pastebin.com/i6URdADw I don't have a reproducer yet and any assistance would be appreciated. Regards, Shankara
Hung Task Linux 4.13-rc7 Reiserfs
Hi, I am fuzzing the kernel 4.13-rc7 with Syzkaller with Reiserfs. I am getting the following crash: INFO: task kworker/0:3:1103 blocked for more than 120 seconds. Here is the full stack trace. I noticed that there are a few tasks holding a sbi->lock. Below are a report and a log of all the programs executing at the time of the incident. Report: https://pastebin.com/uGTAw45E Logs: https://pastebin.com/EaiE0JLf Kernel Configs: https://pastebin.com/i6URdADw I don't have a reproducer yet and any assistance would be appreciated. Regards, Shankara
Re: WARNING: CPU: 2 PID: 4277 at lib/refcount.c:186
Hi Eric, I applied your patch and I no longer observed the warning. Thanks! I will let you know if any further problems show up during fuzzing. Regards, Shankara On Sun, Sep 10, 2017 at 11:34 PM, Eric Dumazet <eric.duma...@gmail.com> wrote: > On Fri, 2017-09-08 at 11:46 -0700, Eric Dumazet wrote: >> On Fri, 2017-09-08 at 10:21 -0700, Cong Wang wrote: >> > (Cc'ing netdev) >> > >> > On Fri, Sep 8, 2017 at 5:59 AM, Shankara Pailoor <sp3...@columbia.edu> >> > wrote: >> > > Hi, >> > > >> > > I found a warning while fuzzing with Syzkaller on linux 4.13-rc7 on >> > > x86_64. The full stack trace is below: >> > > >> > > WARNING: CPU: 2 PID: 4277 at lib/refcount.c:186 >> > > refcount_sub_and_test+0x167/0x1b0 lib/refcount.c:186 >> > > Kernel panic - not syncing: panic_on_warn set ... >> > > >> > > CPU: 2 PID: 4277 Comm: syz-executor0 Not tainted 4.13.0-rc7 #3 >> > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS >> > > Ubuntu-1.8.2-1ubuntu1 04/01/2014 >> > > Call Trace: >> > > >> > > __dump_stack lib/dump_stack.c:16 [inline] >> > > dump_stack+0xf7/0x1aa lib/dump_stack.c:52 >> > > panic+0x1ae/0x3a7 kernel/panic.c:180 >> > > __warn+0x1c4/0x1d9 kernel/panic.c:541 >> > > report_bug+0x211/0x2d0 lib/bug.c:183 >> > > fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:190 >> > > do_trap_no_signal arch/x86/kernel/traps.c:224 [inline] >> > > do_trap+0x260/0x390 arch/x86/kernel/traps.c:273 >> > > do_error_trap+0x118/0x340 arch/x86/kernel/traps.c:310 >> > > do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:323 >> > > invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:846 >> > > RIP: 0010:refcount_sub_and_test+0x167/0x1b0 lib/refcount.c:186 >> > > RSP: 0018:88006e006b60 EFLAGS: 00010286 >> > > RAX: 0026 RBX: RCX: >> > > RDX: 0026 RSI: 11000dc00d2c RDI: ed000dc00d60 >> > > RBP: 88006e006bf0 R08: 0001 R09: >> > > R10: R11: R12: 11000dc00d6d >> > > R13: R14: 0001 R15: 88006ce9d340 >> > > refcount_dec_and_test+0x1a/0x20 lib/refcount.c:211 >> > > reqsk_put+0x71/0x2b0 include/net/request_sock.h:123 >> > > tcp_v4_rcv+0x259e/0x2e20 net/ipv4/tcp_ipv4.c:1729 >> > > ip_local_deliver_finish+0x2e2/0xba0 net/ipv4/ip_input.c:216 >> > > NF_HOOK include/linux/netfilter.h:248 [inline] >> > > ip_local_deliver+0x1ce/0x6d0 net/ipv4/ip_input.c:257 >> > > dst_input include/net/dst.h:477 [inline] >> > > ip_rcv_finish+0x8db/0x19c0 net/ipv4/ip_input.c:397 >> > > NF_HOOK include/linux/netfilter.h:248 [inline] >> > > ip_rcv+0xc3f/0x17d0 net/ipv4/ip_input.c:488 >> > > __netif_receive_skb_core+0x1fb7/0x31f0 net/core/dev.c:4298 >> > > __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4336 >> > > process_backlog+0x1c5/0x6d0 net/core/dev.c:5102 >> > > napi_poll net/core/dev.c:5499 [inline] >> > > net_rx_action+0x6d3/0x14a0 net/core/dev.c:5565 >> > > __do_softirq+0x2cb/0xb2d kernel/softirq.c:284 >> > > do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:898 >> > > >> > > do_softirq.part.16+0x63/0x80 kernel/softirq.c:328 >> > > do_softirq kernel/softirq.c:176 [inline] >> > > __local_bh_enable_ip+0x84/0x90 kernel/softirq.c:181 >> > > local_bh_enable include/linux/bottom_half.h:31 [inline] >> > > rcu_read_unlock_bh include/linux/rcupdate.h:705 [inline] >> > > ip_finish_output2+0x8ad/0x1360 net/ipv4/ip_output.c:231 >> > > ip_finish_output+0x74e/0xb80 net/ipv4/ip_output.c:317 >> > > NF_HOOK_COND include/linux/netfilter.h:237 [inline] >> > > ip_output+0x1cc/0x850 net/ipv4/ip_output.c:405 >> > > dst_output include/net/dst.h:471 [inline] >> > > ip_local_out+0x95/0x160 net/ipv4/ip_output.c:124 >> > > ip_queue_xmit+0x8c6/0x1810 net/ipv4/ip_output.c:504 >> > > tcp_transmit_skb+0x1963/0x3320 net/ipv4/tcp_output.c:1123 >> > > tcp_send_ack.part.35+0x38c/0x620 net/ipv4/tcp_output.c:3575 >> > > tcp_send_ack+0x49/0x60 net/ipv4/tcp_output.c:3545 >> > > tcp_rcv_synsent_state_process net/ipv4/tcp_input.c:5795 [inline] >> > > tcp_rcv_state_process+0x4876/0x4b60 net/ipv4/tcp_input.c:5930 >> > > tcp_v4
Re: WARNING: CPU: 2 PID: 4277 at lib/refcount.c:186
Hi Eric, I applied your patch and I no longer observed the warning. Thanks! I will let you know if any further problems show up during fuzzing. Regards, Shankara On Sun, Sep 10, 2017 at 11:34 PM, Eric Dumazet wrote: > On Fri, 2017-09-08 at 11:46 -0700, Eric Dumazet wrote: >> On Fri, 2017-09-08 at 10:21 -0700, Cong Wang wrote: >> > (Cc'ing netdev) >> > >> > On Fri, Sep 8, 2017 at 5:59 AM, Shankara Pailoor >> > wrote: >> > > Hi, >> > > >> > > I found a warning while fuzzing with Syzkaller on linux 4.13-rc7 on >> > > x86_64. The full stack trace is below: >> > > >> > > WARNING: CPU: 2 PID: 4277 at lib/refcount.c:186 >> > > refcount_sub_and_test+0x167/0x1b0 lib/refcount.c:186 >> > > Kernel panic - not syncing: panic_on_warn set ... >> > > >> > > CPU: 2 PID: 4277 Comm: syz-executor0 Not tainted 4.13.0-rc7 #3 >> > > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS >> > > Ubuntu-1.8.2-1ubuntu1 04/01/2014 >> > > Call Trace: >> > > >> > > __dump_stack lib/dump_stack.c:16 [inline] >> > > dump_stack+0xf7/0x1aa lib/dump_stack.c:52 >> > > panic+0x1ae/0x3a7 kernel/panic.c:180 >> > > __warn+0x1c4/0x1d9 kernel/panic.c:541 >> > > report_bug+0x211/0x2d0 lib/bug.c:183 >> > > fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:190 >> > > do_trap_no_signal arch/x86/kernel/traps.c:224 [inline] >> > > do_trap+0x260/0x390 arch/x86/kernel/traps.c:273 >> > > do_error_trap+0x118/0x340 arch/x86/kernel/traps.c:310 >> > > do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:323 >> > > invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:846 >> > > RIP: 0010:refcount_sub_and_test+0x167/0x1b0 lib/refcount.c:186 >> > > RSP: 0018:88006e006b60 EFLAGS: 00010286 >> > > RAX: 0026 RBX: RCX: >> > > RDX: 0026 RSI: 11000dc00d2c RDI: ed000dc00d60 >> > > RBP: 88006e006bf0 R08: 0001 R09: >> > > R10: R11: R12: 11000dc00d6d >> > > R13: R14: 0001 R15: 88006ce9d340 >> > > refcount_dec_and_test+0x1a/0x20 lib/refcount.c:211 >> > > reqsk_put+0x71/0x2b0 include/net/request_sock.h:123 >> > > tcp_v4_rcv+0x259e/0x2e20 net/ipv4/tcp_ipv4.c:1729 >> > > ip_local_deliver_finish+0x2e2/0xba0 net/ipv4/ip_input.c:216 >> > > NF_HOOK include/linux/netfilter.h:248 [inline] >> > > ip_local_deliver+0x1ce/0x6d0 net/ipv4/ip_input.c:257 >> > > dst_input include/net/dst.h:477 [inline] >> > > ip_rcv_finish+0x8db/0x19c0 net/ipv4/ip_input.c:397 >> > > NF_HOOK include/linux/netfilter.h:248 [inline] >> > > ip_rcv+0xc3f/0x17d0 net/ipv4/ip_input.c:488 >> > > __netif_receive_skb_core+0x1fb7/0x31f0 net/core/dev.c:4298 >> > > __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4336 >> > > process_backlog+0x1c5/0x6d0 net/core/dev.c:5102 >> > > napi_poll net/core/dev.c:5499 [inline] >> > > net_rx_action+0x6d3/0x14a0 net/core/dev.c:5565 >> > > __do_softirq+0x2cb/0xb2d kernel/softirq.c:284 >> > > do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:898 >> > > >> > > do_softirq.part.16+0x63/0x80 kernel/softirq.c:328 >> > > do_softirq kernel/softirq.c:176 [inline] >> > > __local_bh_enable_ip+0x84/0x90 kernel/softirq.c:181 >> > > local_bh_enable include/linux/bottom_half.h:31 [inline] >> > > rcu_read_unlock_bh include/linux/rcupdate.h:705 [inline] >> > > ip_finish_output2+0x8ad/0x1360 net/ipv4/ip_output.c:231 >> > > ip_finish_output+0x74e/0xb80 net/ipv4/ip_output.c:317 >> > > NF_HOOK_COND include/linux/netfilter.h:237 [inline] >> > > ip_output+0x1cc/0x850 net/ipv4/ip_output.c:405 >> > > dst_output include/net/dst.h:471 [inline] >> > > ip_local_out+0x95/0x160 net/ipv4/ip_output.c:124 >> > > ip_queue_xmit+0x8c6/0x1810 net/ipv4/ip_output.c:504 >> > > tcp_transmit_skb+0x1963/0x3320 net/ipv4/tcp_output.c:1123 >> > > tcp_send_ack.part.35+0x38c/0x620 net/ipv4/tcp_output.c:3575 >> > > tcp_send_ack+0x49/0x60 net/ipv4/tcp_output.c:3545 >> > > tcp_rcv_synsent_state_process net/ipv4/tcp_input.c:5795 [inline] >> > > tcp_rcv_state_process+0x4876/0x4b60 net/ipv4/tcp_input.c:5930 >> > > tcp_v4_do_rcv+0x58a/0x820 net/ipv4/tcp_ipv4.c:1483 >> &g
WARN_ON_ONCE in fs/iomap.c:993
Hi, I am fuzzing linux 4.13-rc7 with XFS using syzkaller on x86_64 and I found the following warning: WARNING: CPU: 2 PID: 5391 at fs/iomap.c:993 iomap_dio_rw+0xc79/0xe70 fs/iomap.c:993 Kernel panic - not syncing: panic_on_warn set ... CPU: 2 PID: 5391 Comm: syz-executor1 Not tainted 4.13.0-rc7 #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0xf7/0x1aa lib/dump_stack.c:52 panic+0x1ae/0x3a7 kernel/panic.c:180 __warn+0x1c4/0x1d9 kernel/panic.c:541 report_bug+0x211/0x2d0 lib/bug.c:183 fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:190 do_trap_no_signal arch/x86/kernel/traps.c:224 [inline] do_trap+0x260/0x390 arch/x86/kernel/traps.c:273 do_error_trap+0x118/0x340 arch/x86/kernel/traps.c:310 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:323 invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:846 RIP: 0010:iomap_dio_rw+0xc79/0xe70 fs/iomap.c:993 RSP: 0018:88006d13f6d0 EFLAGS: 00010297 RAX: 880069c3da00 RBX: 88006d04c000 RCX: RDX: RSI: 0003 RDI: ed000da27ed0 RBP: 88006d13f8c0 R08: 0001 R09: 11000da27ddb R10: 88006d13eea0 R11: 0002 R12: 11000da27eea R13: 7000 R14: R15: 88006d13fac8 xfs_file_dio_aio_read+0x19c/0x5a0 fs/xfs/xfs_file.c:220 xfs_file_read_iter+0x369/0x460 fs/xfs/xfs_file.c:286 call_read_iter include/linux/fs.h:1737 [inline] generic_file_splice_read+0x3f9/0x7b0 fs/splice.c:307 do_splice_to+0x10a/0x160 fs/splice.c:896 splice_direct_to_actor+0x23e/0x870 fs/splice.c:968 do_splice_direct+0x29b/0x3c0 fs/splice.c:1077 do_sendfile+0x5c9/0xe80 fs/read_write.c:1412 SYSC_sendfile64 fs/read_write.c:1467 [inline] SyS_sendfile64+0xbd/0x160 fs/read_write.c:1459 entry_SYSCALL_64_fastpath+0x18/0xad RIP: 0033:0x451e59 RSP: 002b:7fa4a3718c08 EFLAGS: 0216 ORIG_RAX: 0028 RAX: ffda RBX: 00718000 RCX: 00451e59 RDX: 20005ff8 RSI: 0003 RDI: 0003 RBP: 0046 R08: R09: R10: 0008 R11: 0216 R12: R13: 7ffde54a34ef R14: 7fa4a37199c0 R15: Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: 0x18a0 from 0x8100 (relocation range: 0x8000-0xbfff) Rebooting in 86400 seconds.. Here is a reproducer program: https://pastebin.com/tc014k97 Here are my configs: https://pastebin.com/PWtYUiHD
WARN_ON_ONCE in fs/iomap.c:993
Hi, I am fuzzing linux 4.13-rc7 with XFS using syzkaller on x86_64 and I found the following warning: WARNING: CPU: 2 PID: 5391 at fs/iomap.c:993 iomap_dio_rw+0xc79/0xe70 fs/iomap.c:993 Kernel panic - not syncing: panic_on_warn set ... CPU: 2 PID: 5391 Comm: syz-executor1 Not tainted 4.13.0-rc7 #4 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0xf7/0x1aa lib/dump_stack.c:52 panic+0x1ae/0x3a7 kernel/panic.c:180 __warn+0x1c4/0x1d9 kernel/panic.c:541 report_bug+0x211/0x2d0 lib/bug.c:183 fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:190 do_trap_no_signal arch/x86/kernel/traps.c:224 [inline] do_trap+0x260/0x390 arch/x86/kernel/traps.c:273 do_error_trap+0x118/0x340 arch/x86/kernel/traps.c:310 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:323 invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:846 RIP: 0010:iomap_dio_rw+0xc79/0xe70 fs/iomap.c:993 RSP: 0018:88006d13f6d0 EFLAGS: 00010297 RAX: 880069c3da00 RBX: 88006d04c000 RCX: RDX: RSI: 0003 RDI: ed000da27ed0 RBP: 88006d13f8c0 R08: 0001 R09: 11000da27ddb R10: 88006d13eea0 R11: 0002 R12: 11000da27eea R13: 7000 R14: R15: 88006d13fac8 xfs_file_dio_aio_read+0x19c/0x5a0 fs/xfs/xfs_file.c:220 xfs_file_read_iter+0x369/0x460 fs/xfs/xfs_file.c:286 call_read_iter include/linux/fs.h:1737 [inline] generic_file_splice_read+0x3f9/0x7b0 fs/splice.c:307 do_splice_to+0x10a/0x160 fs/splice.c:896 splice_direct_to_actor+0x23e/0x870 fs/splice.c:968 do_splice_direct+0x29b/0x3c0 fs/splice.c:1077 do_sendfile+0x5c9/0xe80 fs/read_write.c:1412 SYSC_sendfile64 fs/read_write.c:1467 [inline] SyS_sendfile64+0xbd/0x160 fs/read_write.c:1459 entry_SYSCALL_64_fastpath+0x18/0xad RIP: 0033:0x451e59 RSP: 002b:7fa4a3718c08 EFLAGS: 0216 ORIG_RAX: 0028 RAX: ffda RBX: 00718000 RCX: 00451e59 RDX: 20005ff8 RSI: 0003 RDI: 0003 RBP: 0046 R08: R09: R10: 0008 R11: 0216 R12: R13: 7ffde54a34ef R14: 7fa4a37199c0 R15: Dumping ftrace buffer: (ftrace buffer empty) Kernel Offset: 0x18a0 from 0x8100 (relocation range: 0x8000-0xbfff) Rebooting in 86400 seconds.. Here is a reproducer program: https://pastebin.com/tc014k97 Here are my configs: https://pastebin.com/PWtYUiHD
WARNING: CPU: 2 PID: 4277 at lib/refcount.c:186
Hi, I found a warning while fuzzing with Syzkaller on linux 4.13-rc7 on x86_64. The full stack trace is below: WARNING: CPU: 2 PID: 4277 at lib/refcount.c:186 refcount_sub_and_test+0x167/0x1b0 lib/refcount.c:186 Kernel panic - not syncing: panic_on_warn set ... CPU: 2 PID: 4277 Comm: syz-executor0 Not tainted 4.13.0-rc7 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0xf7/0x1aa lib/dump_stack.c:52 panic+0x1ae/0x3a7 kernel/panic.c:180 __warn+0x1c4/0x1d9 kernel/panic.c:541 report_bug+0x211/0x2d0 lib/bug.c:183 fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:190 do_trap_no_signal arch/x86/kernel/traps.c:224 [inline] do_trap+0x260/0x390 arch/x86/kernel/traps.c:273 do_error_trap+0x118/0x340 arch/x86/kernel/traps.c:310 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:323 invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:846 RIP: 0010:refcount_sub_and_test+0x167/0x1b0 lib/refcount.c:186 RSP: 0018:88006e006b60 EFLAGS: 00010286 RAX: 0026 RBX: RCX: RDX: 0026 RSI: 11000dc00d2c RDI: ed000dc00d60 RBP: 88006e006bf0 R08: 0001 R09: R10: R11: R12: 11000dc00d6d R13: R14: 0001 R15: 88006ce9d340 refcount_dec_and_test+0x1a/0x20 lib/refcount.c:211 reqsk_put+0x71/0x2b0 include/net/request_sock.h:123 tcp_v4_rcv+0x259e/0x2e20 net/ipv4/tcp_ipv4.c:1729 ip_local_deliver_finish+0x2e2/0xba0 net/ipv4/ip_input.c:216 NF_HOOK include/linux/netfilter.h:248 [inline] ip_local_deliver+0x1ce/0x6d0 net/ipv4/ip_input.c:257 dst_input include/net/dst.h:477 [inline] ip_rcv_finish+0x8db/0x19c0 net/ipv4/ip_input.c:397 NF_HOOK include/linux/netfilter.h:248 [inline] ip_rcv+0xc3f/0x17d0 net/ipv4/ip_input.c:488 __netif_receive_skb_core+0x1fb7/0x31f0 net/core/dev.c:4298 __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4336 process_backlog+0x1c5/0x6d0 net/core/dev.c:5102 napi_poll net/core/dev.c:5499 [inline] net_rx_action+0x6d3/0x14a0 net/core/dev.c:5565 __do_softirq+0x2cb/0xb2d kernel/softirq.c:284 do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:898 do_softirq.part.16+0x63/0x80 kernel/softirq.c:328 do_softirq kernel/softirq.c:176 [inline] __local_bh_enable_ip+0x84/0x90 kernel/softirq.c:181 local_bh_enable include/linux/bottom_half.h:31 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:705 [inline] ip_finish_output2+0x8ad/0x1360 net/ipv4/ip_output.c:231 ip_finish_output+0x74e/0xb80 net/ipv4/ip_output.c:317 NF_HOOK_COND include/linux/netfilter.h:237 [inline] ip_output+0x1cc/0x850 net/ipv4/ip_output.c:405 dst_output include/net/dst.h:471 [inline] ip_local_out+0x95/0x160 net/ipv4/ip_output.c:124 ip_queue_xmit+0x8c6/0x1810 net/ipv4/ip_output.c:504 tcp_transmit_skb+0x1963/0x3320 net/ipv4/tcp_output.c:1123 tcp_send_ack.part.35+0x38c/0x620 net/ipv4/tcp_output.c:3575 tcp_send_ack+0x49/0x60 net/ipv4/tcp_output.c:3545 tcp_rcv_synsent_state_process net/ipv4/tcp_input.c:5795 [inline] tcp_rcv_state_process+0x4876/0x4b60 net/ipv4/tcp_input.c:5930 tcp_v4_do_rcv+0x58a/0x820 net/ipv4/tcp_ipv4.c:1483 sk_backlog_rcv include/net/sock.h:907 [inline] __release_sock+0x124/0x360 net/core/sock.c:2223 release_sock+0xa4/0x2a0 net/core/sock.c:2715 inet_wait_for_connect net/ipv4/af_inet.c:557 [inline] __inet_stream_connect+0x671/0xf00 net/ipv4/af_inet.c:643 inet_stream_connect+0x58/0xa0 net/ipv4/af_inet.c:682 SYSC_connect+0x204/0x470 net/socket.c:1628 SyS_connect+0x24/0x30 net/socket.c:1609 entry_SYSCALL_64_fastpath+0x18/0xad RIP: 0033:0x451e59 RSP: 002b:7f474843fc08 EFLAGS: 0216 ORIG_RAX: 002a RAX: ffda RBX: 00718000 RCX: 00451e59 RDX: 0010 RSI: 20002000 RDI: 0007 RBP: 0046 R08: R09: R10: R11: 0216 R12: R13: 7ffc040a0f8f R14: 7f47484409c0 R15: I found that the following program is able to reproduce the warning: Pastebin: https://pastebin.com/B75BdYKz Here are my configs: https://pastebin.com/zRYCXbak Regards, Shankara
WARNING: CPU: 2 PID: 4277 at lib/refcount.c:186
Hi, I found a warning while fuzzing with Syzkaller on linux 4.13-rc7 on x86_64. The full stack trace is below: WARNING: CPU: 2 PID: 4277 at lib/refcount.c:186 refcount_sub_and_test+0x167/0x1b0 lib/refcount.c:186 Kernel panic - not syncing: panic_on_warn set ... CPU: 2 PID: 4277 Comm: syz-executor0 Not tainted 4.13.0-rc7 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0xf7/0x1aa lib/dump_stack.c:52 panic+0x1ae/0x3a7 kernel/panic.c:180 __warn+0x1c4/0x1d9 kernel/panic.c:541 report_bug+0x211/0x2d0 lib/bug.c:183 fixup_bug+0x40/0x90 arch/x86/kernel/traps.c:190 do_trap_no_signal arch/x86/kernel/traps.c:224 [inline] do_trap+0x260/0x390 arch/x86/kernel/traps.c:273 do_error_trap+0x118/0x340 arch/x86/kernel/traps.c:310 do_invalid_op+0x1b/0x20 arch/x86/kernel/traps.c:323 invalid_op+0x18/0x20 arch/x86/entry/entry_64.S:846 RIP: 0010:refcount_sub_and_test+0x167/0x1b0 lib/refcount.c:186 RSP: 0018:88006e006b60 EFLAGS: 00010286 RAX: 0026 RBX: RCX: RDX: 0026 RSI: 11000dc00d2c RDI: ed000dc00d60 RBP: 88006e006bf0 R08: 0001 R09: R10: R11: R12: 11000dc00d6d R13: R14: 0001 R15: 88006ce9d340 refcount_dec_and_test+0x1a/0x20 lib/refcount.c:211 reqsk_put+0x71/0x2b0 include/net/request_sock.h:123 tcp_v4_rcv+0x259e/0x2e20 net/ipv4/tcp_ipv4.c:1729 ip_local_deliver_finish+0x2e2/0xba0 net/ipv4/ip_input.c:216 NF_HOOK include/linux/netfilter.h:248 [inline] ip_local_deliver+0x1ce/0x6d0 net/ipv4/ip_input.c:257 dst_input include/net/dst.h:477 [inline] ip_rcv_finish+0x8db/0x19c0 net/ipv4/ip_input.c:397 NF_HOOK include/linux/netfilter.h:248 [inline] ip_rcv+0xc3f/0x17d0 net/ipv4/ip_input.c:488 __netif_receive_skb_core+0x1fb7/0x31f0 net/core/dev.c:4298 __netif_receive_skb+0x2c/0x1b0 net/core/dev.c:4336 process_backlog+0x1c5/0x6d0 net/core/dev.c:5102 napi_poll net/core/dev.c:5499 [inline] net_rx_action+0x6d3/0x14a0 net/core/dev.c:5565 __do_softirq+0x2cb/0xb2d kernel/softirq.c:284 do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:898 do_softirq.part.16+0x63/0x80 kernel/softirq.c:328 do_softirq kernel/softirq.c:176 [inline] __local_bh_enable_ip+0x84/0x90 kernel/softirq.c:181 local_bh_enable include/linux/bottom_half.h:31 [inline] rcu_read_unlock_bh include/linux/rcupdate.h:705 [inline] ip_finish_output2+0x8ad/0x1360 net/ipv4/ip_output.c:231 ip_finish_output+0x74e/0xb80 net/ipv4/ip_output.c:317 NF_HOOK_COND include/linux/netfilter.h:237 [inline] ip_output+0x1cc/0x850 net/ipv4/ip_output.c:405 dst_output include/net/dst.h:471 [inline] ip_local_out+0x95/0x160 net/ipv4/ip_output.c:124 ip_queue_xmit+0x8c6/0x1810 net/ipv4/ip_output.c:504 tcp_transmit_skb+0x1963/0x3320 net/ipv4/tcp_output.c:1123 tcp_send_ack.part.35+0x38c/0x620 net/ipv4/tcp_output.c:3575 tcp_send_ack+0x49/0x60 net/ipv4/tcp_output.c:3545 tcp_rcv_synsent_state_process net/ipv4/tcp_input.c:5795 [inline] tcp_rcv_state_process+0x4876/0x4b60 net/ipv4/tcp_input.c:5930 tcp_v4_do_rcv+0x58a/0x820 net/ipv4/tcp_ipv4.c:1483 sk_backlog_rcv include/net/sock.h:907 [inline] __release_sock+0x124/0x360 net/core/sock.c:2223 release_sock+0xa4/0x2a0 net/core/sock.c:2715 inet_wait_for_connect net/ipv4/af_inet.c:557 [inline] __inet_stream_connect+0x671/0xf00 net/ipv4/af_inet.c:643 inet_stream_connect+0x58/0xa0 net/ipv4/af_inet.c:682 SYSC_connect+0x204/0x470 net/socket.c:1628 SyS_connect+0x24/0x30 net/socket.c:1609 entry_SYSCALL_64_fastpath+0x18/0xad RIP: 0033:0x451e59 RSP: 002b:7f474843fc08 EFLAGS: 0216 ORIG_RAX: 002a RAX: ffda RBX: 00718000 RCX: 00451e59 RDX: 0010 RSI: 20002000 RDI: 0007 RBP: 0046 R08: R09: R10: R11: 0216 R12: R13: 7ffc040a0f8f R14: 7f47484409c0 R15: I found that the following program is able to reproduce the warning: Pastebin: https://pastebin.com/B75BdYKz Here are my configs: https://pastebin.com/zRYCXbak Regards, Shankara
UBSAN undefined behavior in arch/x86/include/futex.h
Hi, I encountered this bug in kernel 4.13-rc7 while fuzzing with Syzkaller: UBSAN: Undefined behaviour in ./arch/x86/include/asm/futex.h:53:13 shift exponent -1 is negative CPU: 0 PID: 8469 Comm: syz-executor2 Not tainted 4.13.0-rc7 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0xf7/0x1ae lib/dump_stack.c:52 ubsan_epilogue+0x12/0x8f lib/ubsan.c:164 __ubsan_handle_shift_out_of_bounds+0x2b2/0x32c lib/ubsan.c:421 futex_atomic_op_inuser arch/x86/include/asm/futex.h:53 [inline] futex_wake_op kernel/futex.c:1577 [inline] do_futex+0x1a7f/0x2600 kernel/futex.c:3404 SYSC_futex kernel/futex.c:3454 [inline] SyS_futex+0x285/0x380 kernel/futex.c:3422 entry_SYSCALL_64_fastpath+0x18/0xad RIP: 0033:0x451e59 RSP: 002b:7f6cbefecc08 EFLAGS: 0216 ORIG_RAX: 00ca RAX: ffda RBX: 00718000 RCX: 00451e59 RDX: RSI: 8005 RDI: 20005000 RBP: 0046 R08: 20005ffc R09: fffe R10: 20005ff0 R11: 0216 R12: R13: 7ffe5d358caf R14: 7f6cbefed9c0 R15: Here is the link to the repro program: https://pastebin.com/RDX3q4nM Regards, Shankara
UBSAN undefined behavior in arch/x86/include/futex.h
Hi, I encountered this bug in kernel 4.13-rc7 while fuzzing with Syzkaller: UBSAN: Undefined behaviour in ./arch/x86/include/asm/futex.h:53:13 shift exponent -1 is negative CPU: 0 PID: 8469 Comm: syz-executor2 Not tainted 4.13.0-rc7 #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Ubuntu-1.8.2-1ubuntu1 04/01/2014 Call Trace: __dump_stack lib/dump_stack.c:16 [inline] dump_stack+0xf7/0x1ae lib/dump_stack.c:52 ubsan_epilogue+0x12/0x8f lib/ubsan.c:164 __ubsan_handle_shift_out_of_bounds+0x2b2/0x32c lib/ubsan.c:421 futex_atomic_op_inuser arch/x86/include/asm/futex.h:53 [inline] futex_wake_op kernel/futex.c:1577 [inline] do_futex+0x1a7f/0x2600 kernel/futex.c:3404 SYSC_futex kernel/futex.c:3454 [inline] SyS_futex+0x285/0x380 kernel/futex.c:3422 entry_SYSCALL_64_fastpath+0x18/0xad RIP: 0033:0x451e59 RSP: 002b:7f6cbefecc08 EFLAGS: 0216 ORIG_RAX: 00ca RAX: ffda RBX: 00718000 RCX: 00451e59 RDX: RSI: 8005 RDI: 20005000 RBP: 0046 R08: 20005ffc R09: fffe R10: 20005ff0 R11: 0216 R12: R13: 7ffe5d358caf R14: 7f6cbefed9c0 R15: Here is the link to the repro program: https://pastebin.com/RDX3q4nM Regards, Shankara
UBSAN: Undefined error in log2.h
Hi,
I am hitting this bug when running the syzkaller fuzzer on kernel 4.13-rc7
Syzkaller hit 'UBSAN: Undefined behaviour in ./include/linux/log2.h:LINE' bug.
Guilty file: fs/pipe.c
Maintainers: []
UBSAN: Undefined behaviour in ./include/linux/log2.h:57:13
shift exponent 64 is too large for 64-bit type 'long unsigned int'
CPU: 3 PID: 2712 Comm: syz-executor0 Not tainted 4.13.0-rc7 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0xf7/0x1ae lib/dump_stack.c:52
ubsan_epilogue+0x12/0x8f lib/ubsan.c:164
__ubsan_handle_shift_out_of_bounds+0x2b2/0x32c lib/ubsan.c:421
__roundup_pow_of_two include/linux/log2.h:57 [inline]
round_pipe_size fs/pipe.c:1027 [inline]
pipe_set_size fs/pipe.c:1041 [inline]
pipe_fcntl+0x6b6/0x7b0 fs/pipe.c:1158
do_fcntl+0x362/0x1250 fs/fcntl.c:416
SYSC_fcntl fs/fcntl.c:462 [inline]
SyS_fcntl+0xd6/0x110 fs/fcntl.c:447
entry_SYSCALL_64_fastpath+0x18/0xad
RIP: 0033:0x451e59
RSP: 002b:7ffe1469d358 EFLAGS: 0212 ORIG_RAX: 0048
RAX: ffda RBX: 00718000 RCX: 00451e59
RDX: RSI: 0407 RDI: 0003
RBP: 0046 R08: R09:
R10: R11: 0212 R12: 20011ff8
R13: 00718000 R14: R15:
I have the full reproducer program here: https://pastebin.com/mLZx0ySS
The main code is below:
long r[4];
void loop()
{
syscall(SYS_write, 1, "executing program\n", strlen("executing program\n"));
memset(r, -1, sizeof(r));
r[0] = syscall(__NR_mmap, 0x2000ul, 0x12000ul, 0x3ul, 0x32ul,
0xul, 0x0ul);
r[1] = syscall(__NR_pipe, 0x20011ff8ul);
if (r[1] != -1)
NONFAILING(r[2] = *(uint32_t*)0x20011ff8);
r[3] = syscall(__NR_fcntl, r[2], 0x407ul, 0x0ul);
}
UBSAN: Undefined error in log2.h
Hi,
I am hitting this bug when running the syzkaller fuzzer on kernel 4.13-rc7
Syzkaller hit 'UBSAN: Undefined behaviour in ./include/linux/log2.h:LINE' bug.
Guilty file: fs/pipe.c
Maintainers: []
UBSAN: Undefined behaviour in ./include/linux/log2.h:57:13
shift exponent 64 is too large for 64-bit type 'long unsigned int'
CPU: 3 PID: 2712 Comm: syz-executor0 Not tainted 4.13.0-rc7 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0xf7/0x1ae lib/dump_stack.c:52
ubsan_epilogue+0x12/0x8f lib/ubsan.c:164
__ubsan_handle_shift_out_of_bounds+0x2b2/0x32c lib/ubsan.c:421
__roundup_pow_of_two include/linux/log2.h:57 [inline]
round_pipe_size fs/pipe.c:1027 [inline]
pipe_set_size fs/pipe.c:1041 [inline]
pipe_fcntl+0x6b6/0x7b0 fs/pipe.c:1158
do_fcntl+0x362/0x1250 fs/fcntl.c:416
SYSC_fcntl fs/fcntl.c:462 [inline]
SyS_fcntl+0xd6/0x110 fs/fcntl.c:447
entry_SYSCALL_64_fastpath+0x18/0xad
RIP: 0033:0x451e59
RSP: 002b:7ffe1469d358 EFLAGS: 0212 ORIG_RAX: 0048
RAX: ffda RBX: 00718000 RCX: 00451e59
RDX: RSI: 0407 RDI: 0003
RBP: 0046 R08: R09:
R10: R11: 0212 R12: 20011ff8
R13: 00718000 R14: R15:
I have the full reproducer program here: https://pastebin.com/mLZx0ySS
The main code is below:
long r[4];
void loop()
{
syscall(SYS_write, 1, "executing program\n", strlen("executing program\n"));
memset(r, -1, sizeof(r));
r[0] = syscall(__NR_mmap, 0x2000ul, 0x12000ul, 0x3ul, 0x32ul,
0xul, 0x0ul);
r[1] = syscall(__NR_pipe, 0x20011ff8ul);
if (r[1] != -1)
NONFAILING(r[2] = *(uint32_t*)0x20011ff8);
r[3] = syscall(__NR_fcntl, r[2], 0x407ul, 0x0ul);
}
UBSAN: Undefined error in time.h signed integer overflow
Hi,
I encountered this bug while fuzzing linux kernel 4.13-rc7 with syzkaller.
UBSAN: Undefined behaviour in ./include/linux/time.h:233:27
signed integer overflow:
8391720337152500783 * 10 cannot be represented in type 'long int'
CPU: 0 PID: 31798 Comm: syz-executor2 Not tainted 4.13.0-rc7 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0xf7/0x1ae lib/dump_stack.c:52
ubsan_epilogue+0x12/0x8f lib/ubsan.c:164
handle_overflow+0x21e/0x292 lib/ubsan.c:195
__ubsan_handle_mul_overflow+0x2a/0x3e lib/ubsan.c:219
timespec_to_ns include/linux/time.h:233 [inline]
posix_cpu_timer_set+0xb5c/0xf20 kernel/time/posix-cpu-timers.c:686
do_timer_settime+0x1f4/0x390 kernel/time/posix-timers.c:890
SYSC_timer_settime kernel/time/posix-timers.c:916 [inline]
SyS_timer_settime+0xea/0x170 kernel/time/posix-timers.c:902
entry_SYSCALL_64_fastpath+0x18/0xad
RIP: 0033:0x451e59
RSP: 002b:7fb62af4fc08 EFLAGS: 0216 ORIG_RAX: 00df
RAX: ffda RBX: 00718000 RCX: 00451e59
RDX: 20006000 RSI: RDI:
RBP: 0046 R08: R09:
R10: 20003fe0 R11: 0216 R12: 004be920
R13: R14: R15:
Here is the full reproducer program: https://pastebin.com/xucAtmbD
Below is the core of the reproducer:
long r[16];
void *thr(void *arg)
{
switch ((long)arg) {
case 0:
r[0] = syscall(__NR_mmap, 0x2000ul, 0xd000ul, 0x3ul, 0x32ul,
0xul, 0x0ul);
break;
case 1:
NONFAILING(*(uint64_t*)0x20001fb0 = (uint64_t)0x0);
NONFAILING(*(uint32_t*)0x20001fb8 = (uint32_t)0x1);
NONFAILING(*(uint32_t*)0x20001fbc = (uint32_t)0x0);
NONFAILING(*(uint64_t*)0x20001fc0 = (uint64_t)0x20007fcd);
NONFAILING(*(uint64_t*)0x20001fc8 = (uint64_t)0x20005000);
r[6] = syscall(__NR_timer_create, 0x3ul, 0x20001fb0ul, 0x2000ul);
break;
case 2:
r[7] = syscall(__NR_clock_gettime, 0x0ul, 0x20004000ul);
if (r[7] != -1)
NONFAILING(r[8] = *(uint64_t*)0x20004008);
break;
case 3:
NONFAILING(*(uint64_t*)0x20006000 = (uint64_t)0x0);
NONFAILING(*(uint64_t*)0x20006008 = (uint64_t)0x0);
NONFAILING(*(uint64_t*)0x20006010 = (uint64_t)0x0);
NONFAILING(*(uint64_t*)0x20006018 = r[8]+1000);
r[13] = syscall(__NR_timer_settime, 0x0ul, 0x0ul, 0x20006000ul, 0x20003fe0ul);
break;
case 4:
NONFAILING(memcpy((void*)0x20006000,
"\x2f\x64\x65\x76\x2f\x61\x75\x74\x6f\x66\x73\x00", 12));
r[15] = syscall(__NR_openat, 0xff9cul, 0x20006000ul,
0x8000ul, 0x0ul);
break;
}
return 0;
}
UBSAN: Undefined error in time.h signed integer overflow
Hi,
I encountered this bug while fuzzing linux kernel 4.13-rc7 with syzkaller.
UBSAN: Undefined behaviour in ./include/linux/time.h:233:27
signed integer overflow:
8391720337152500783 * 10 cannot be represented in type 'long int'
CPU: 0 PID: 31798 Comm: syz-executor2 Not tainted 4.13.0-rc7 #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
Ubuntu-1.8.2-1ubuntu1 04/01/2014
Call Trace:
__dump_stack lib/dump_stack.c:16 [inline]
dump_stack+0xf7/0x1ae lib/dump_stack.c:52
ubsan_epilogue+0x12/0x8f lib/ubsan.c:164
handle_overflow+0x21e/0x292 lib/ubsan.c:195
__ubsan_handle_mul_overflow+0x2a/0x3e lib/ubsan.c:219
timespec_to_ns include/linux/time.h:233 [inline]
posix_cpu_timer_set+0xb5c/0xf20 kernel/time/posix-cpu-timers.c:686
do_timer_settime+0x1f4/0x390 kernel/time/posix-timers.c:890
SYSC_timer_settime kernel/time/posix-timers.c:916 [inline]
SyS_timer_settime+0xea/0x170 kernel/time/posix-timers.c:902
entry_SYSCALL_64_fastpath+0x18/0xad
RIP: 0033:0x451e59
RSP: 002b:7fb62af4fc08 EFLAGS: 0216 ORIG_RAX: 00df
RAX: ffda RBX: 00718000 RCX: 00451e59
RDX: 20006000 RSI: RDI:
RBP: 0046 R08: R09:
R10: 20003fe0 R11: 0216 R12: 004be920
R13: R14: R15:
Here is the full reproducer program: https://pastebin.com/xucAtmbD
Below is the core of the reproducer:
long r[16];
void *thr(void *arg)
{
switch ((long)arg) {
case 0:
r[0] = syscall(__NR_mmap, 0x2000ul, 0xd000ul, 0x3ul, 0x32ul,
0xul, 0x0ul);
break;
case 1:
NONFAILING(*(uint64_t*)0x20001fb0 = (uint64_t)0x0);
NONFAILING(*(uint32_t*)0x20001fb8 = (uint32_t)0x1);
NONFAILING(*(uint32_t*)0x20001fbc = (uint32_t)0x0);
NONFAILING(*(uint64_t*)0x20001fc0 = (uint64_t)0x20007fcd);
NONFAILING(*(uint64_t*)0x20001fc8 = (uint64_t)0x20005000);
r[6] = syscall(__NR_timer_create, 0x3ul, 0x20001fb0ul, 0x2000ul);
break;
case 2:
r[7] = syscall(__NR_clock_gettime, 0x0ul, 0x20004000ul);
if (r[7] != -1)
NONFAILING(r[8] = *(uint64_t*)0x20004008);
break;
case 3:
NONFAILING(*(uint64_t*)0x20006000 = (uint64_t)0x0);
NONFAILING(*(uint64_t*)0x20006008 = (uint64_t)0x0);
NONFAILING(*(uint64_t*)0x20006010 = (uint64_t)0x0);
NONFAILING(*(uint64_t*)0x20006018 = r[8]+1000);
r[13] = syscall(__NR_timer_settime, 0x0ul, 0x0ul, 0x20006000ul, 0x20003fe0ul);
break;
case 4:
NONFAILING(memcpy((void*)0x20006000,
"\x2f\x64\x65\x76\x2f\x61\x75\x74\x6f\x66\x73\x00", 12));
r[15] = syscall(__NR_openat, 0xff9cul, 0x20006000ul,
0x8000ul, 0x0ul);
break;
}
return 0;
}
