On Thu, Jan 11, 2018 at 11:17 AM, syzbot
<[email protected]> wrote:
> Hello,
>
> syzkaller hit the following crash on
> 4147d50978df60f34d444c647dde9e5b34a4315e
> git://git.cmpxchg.org/linux-mmots.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
> Unfortunately, I don't have any reproducer for this bug yet.
>
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: [email protected]
> It will help syzbot understand when the bug is fixed. See footer for
> details.
> If you forward the report, please keep this part and the footer.
>
> netlink: 3 bytes leftover after parsing attributes in process
> `syz-executor5'.
> ==================================================================
> BUG: KASAN: use-after-free in __bpf_prog_put+0x5e8/0x640
> kernel/bpf/syscall.c:944
> netlink: 'syz-executor5': attribute type 5 has an invalid length.
> Read of size 8 at addr ffff8801d3619658 by task syz-executor0/12398
>
> CPU: 1 PID: 12398 Comm: syz-executor0 Not tainted 4.15.0-rc7-mm1+ #53
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:17 [inline]
> dump_stack+0x194/0x257 lib/dump_stack.c:53
> print_address_description+0x73/0x250 mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report+0x23b/0x360 mm/kasan/report.c:412
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> __bpf_prog_put+0x5e8/0x640 kernel/bpf/syscall.c:944
> bpf_prog_put+0x1a/0x20 kernel/bpf/syscall.c:961
> prog_fd_array_put_ptr+0x15/0x20 kernel/bpf/arraymap.c:446
> fd_array_map_delete_elem+0xc8/0x110 kernel/bpf/arraymap.c:420
> map_delete_elem kernel/bpf/syscall.c:737 [inline]
> SYSC_bpf kernel/bpf/syscall.c:1814 [inline]
> SyS_bpf+0x22ea/0x4400 kernel/bpf/syscall.c:1782
> entry_SYSCALL_64_fastpath+0x29/0xa0
> RIP: 0033:0x452ac9
> RSP: 002b:00007fb70df60c58 EFLAGS: 00000212 ORIG_RAX: 0000000000000141
> RAX: ffffffffffffffda RBX: 000000000071bea0 RCX: 0000000000452ac9
> RDX: 0000000000000010 RSI: 0000000020f02ff0 RDI: 0000000000000003
> RBP: 00000000000003aa R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f3890
> R13: 00000000ffffffff R14: 00007fb70df616d4 R15: 0000000000000000
>
> Allocated by task 11996:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> set_track mm/kasan/kasan.c:459 [inline]
> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
> kmem_cache_alloc+0x12e/0x760 mm/slab.c:3541
> kmem_cache_zalloc include/linux/slab.h:694 [inline]
> get_empty_filp+0xfb/0x4f0 fs/file_table.c:122
> path_openat+0xed/0x3530 fs/namei.c:3514
> do_filp_open+0x25b/0x3b0 fs/namei.c:3572
> do_sys_open+0x502/0x6d0 fs/open.c:1059
> SYSC_open fs/open.c:1077 [inline]
> SyS_open+0x2d/0x40 fs/open.c:1072
> entry_SYSCALL_64_fastpath+0x29/0xa0
>
> Freed by task 11994:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> set_track mm/kasan/kasan.c:459 [inline]
> __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
> __cache_free mm/slab.c:3485 [inline]
> kmem_cache_free+0x86/0x2b0 mm/slab.c:3743
> file_free_rcu+0x5c/0x70 fs/file_table.c:49
> __rcu_reclaim kernel/rcu/rcu.h:172 [inline]
> rcu_do_batch kernel/rcu/tree.c:2675 [inline]
> invoke_rcu_callbacks kernel/rcu/tree.c:2934 [inline]
> __rcu_process_callbacks kernel/rcu/tree.c:2901 [inline]
> rcu_process_callbacks+0xd6c/0x17f0 kernel/rcu/tree.c:2918
> __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>
> The buggy address belongs to the object at ffff8801d36195c0
> which belongs to the cache filp of size 456
> The buggy address is located 152 bytes inside of
> 456-byte region [ffff8801d36195c0, ffff8801d3619788)
> The buggy address belongs to the page:
> page:ffffea00074d8640 count:1 mapcount:0 mapping:ffff8801d36190c0 index:0x0
> flags: 0x2fffc0000000100(slab)
> raw: 02fffc0000000100 ffff8801d36190c0 0000000000000000 0000000100000006
> raw: ffffea00074c49a0 ffffea000747a160 ffff8801dae30180 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801d3619500: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ffff8801d3619580: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
>>
>> ffff8801d3619600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>
> ^
> ffff8801d3619680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801d3619700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
Is it the same as "general protection fault in __bpf_prog_put"?
https://groups.google.com/forum/#!topic/syzkaller-bugs/jUsNMmVgms0
The first stack looks similar, but alloc/free stacks looks unrelated.
What's the root cause of this? Is prog->aux an uninitialized pointer?
I wonder if initializing memory in kmalloc would help to prevent this
bug from duplicating? E.g. if we init memory to 0, it would always
cause GPFs, or if we init to an invalid pointer, always cause a bad
paging fault. Is it's the case, then I think we should do it to reduce
number of failure modes and syzbot reports.
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to [email protected].
>
> syzbot will keep track of this bug report.
> If you forgot to add the Reported-by tag, once the fix for this bug is
> merged
> into any tree, please reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.
>
> --
> You received this message because you are subscribed to the Google Groups
> "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/syzkaller-bugs/001a1140bf605479be05627d75c7%40google.com.
> For more options, visit https://groups.google.com/d/optout.
Hi Dmitry,
On 01/11/2018 11:22 AM, Dmitry Vyukov wrote:
> On Thu, Jan 11, 2018 at 11:17 AM, syzbot
> <[email protected]> wrote:
>> Hello,
>>
>> syzkaller hit the following crash on
>> 4147d50978df60f34d444c647dde9e5b34a4315e
>> git://git.cmpxchg.org/linux-mmots.git/master
>> compiler: gcc (GCC) 7.1.1 20170620
>> .config is attached
>> Raw console output is attached.
>> Unfortunately, I don't have any reproducer for this bug yet.
>>
>>
>> IMPORTANT: if you fix the bug, please add the following tag to the commit:
>> Reported-by: [email protected]
>> It will help syzbot understand when the bug is fixed. See footer for
>> details.
>> If you forward the report, please keep this part and the footer.
>>
>> netlink: 3 bytes leftover after parsing attributes in process
>> `syz-executor5'.
>> ==================================================================
>> BUG: KASAN: use-after-free in __bpf_prog_put+0x5e8/0x640
>> kernel/bpf/syscall.c:944
>> netlink: 'syz-executor5': attribute type 5 has an invalid length.
>> Read of size 8 at addr ffff8801d3619658 by task syz-executor0/12398
>>
>> CPU: 1 PID: 12398 Comm: syz-executor0 Not tainted 4.15.0-rc7-mm1+ #53
>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>> Google 01/01/2011
>> Call Trace:
>> __dump_stack lib/dump_stack.c:17 [inline]
>> dump_stack+0x194/0x257 lib/dump_stack.c:53
>> print_address_description+0x73/0x250 mm/kasan/report.c:256
>> kasan_report_error mm/kasan/report.c:354 [inline]
>> kasan_report+0x23b/0x360 mm/kasan/report.c:412
>> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
>> __bpf_prog_put+0x5e8/0x640 kernel/bpf/syscall.c:944
>> bpf_prog_put+0x1a/0x20 kernel/bpf/syscall.c:961
>> prog_fd_array_put_ptr+0x15/0x20 kernel/bpf/arraymap.c:446
>> fd_array_map_delete_elem+0xc8/0x110 kernel/bpf/arraymap.c:420
>> map_delete_elem kernel/bpf/syscall.c:737 [inline]
>> SYSC_bpf kernel/bpf/syscall.c:1814 [inline]
>> SyS_bpf+0x22ea/0x4400 kernel/bpf/syscall.c:1782
>> entry_SYSCALL_64_fastpath+0x29/0xa0
>> RIP: 0033:0x452ac9
>> RSP: 002b:00007fb70df60c58 EFLAGS: 00000212 ORIG_RAX: 0000000000000141
>> RAX: ffffffffffffffda RBX: 000000000071bea0 RCX: 0000000000452ac9
>> RDX: 0000000000000010 RSI: 0000000020f02ff0 RDI: 0000000000000003
>> RBP: 00000000000003aa R08: 0000000000000000 R09: 0000000000000000
>> R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f3890
>> R13: 00000000ffffffff R14: 00007fb70df616d4 R15: 0000000000000000
>>
>> Allocated by task 11996:
>> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>> set_track mm/kasan/kasan.c:459 [inline]
>> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
>> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>> kmem_cache_alloc+0x12e/0x760 mm/slab.c:3541
>> kmem_cache_zalloc include/linux/slab.h:694 [inline]
>> get_empty_filp+0xfb/0x4f0 fs/file_table.c:122
>> path_openat+0xed/0x3530 fs/namei.c:3514
>> do_filp_open+0x25b/0x3b0 fs/namei.c:3572
>> do_sys_open+0x502/0x6d0 fs/open.c:1059
>> SYSC_open fs/open.c:1077 [inline]
>> SyS_open+0x2d/0x40 fs/open.c:1072
>> entry_SYSCALL_64_fastpath+0x29/0xa0
>>
>> Freed by task 11994:
>> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>> set_track mm/kasan/kasan.c:459 [inline]
>> __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
>> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
>> __cache_free mm/slab.c:3485 [inline]
>> kmem_cache_free+0x86/0x2b0 mm/slab.c:3743
>> file_free_rcu+0x5c/0x70 fs/file_table.c:49
>> __rcu_reclaim kernel/rcu/rcu.h:172 [inline]
>> rcu_do_batch kernel/rcu/tree.c:2675 [inline]
>> invoke_rcu_callbacks kernel/rcu/tree.c:2934 [inline]
>> __rcu_process_callbacks kernel/rcu/tree.c:2901 [inline]
>> rcu_process_callbacks+0xd6c/0x17f0 kernel/rcu/tree.c:2918
>> __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
>>
>> The buggy address belongs to the object at ffff8801d36195c0
>> which belongs to the cache filp of size 456
>> The buggy address is located 152 bytes inside of
>> 456-byte region [ffff8801d36195c0, ffff8801d3619788)
>> The buggy address belongs to the page:
>> page:ffffea00074d8640 count:1 mapcount:0 mapping:ffff8801d36190c0 index:0x0
>> flags: 0x2fffc0000000100(slab)
>> raw: 02fffc0000000100 ffff8801d36190c0 0000000000000000 0000000100000006
>> raw: ffffea00074c49a0 ffffea000747a160 ffff8801dae30180 0000000000000000
>> page dumped because: kasan: bad access detected
>>
>> Memory state around the buggy address:
>> ffff8801d3619500: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>> ffff8801d3619580: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
>>>
>>> ffff8801d3619600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>
>> ^
>> ffff8801d3619680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ffff8801d3619700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ==================================================================
>
>
> Is it the same as "general protection fault in __bpf_prog_put"?
> https://groups.google.com/forum/#!topic/syzkaller-bugs/jUsNMmVgms0
>
> The first stack looks similar, but alloc/free stacks looks unrelated.
> What's the root cause of this? Is prog->aux an uninitialized pointer?
> I wonder if initializing memory in kmalloc would help to prevent this
> bug from duplicating? E.g. if we init memory to 0, it would always
> cause GPFs, or if we init to an invalid pointer, always cause a bad
> paging fault. Is it's the case, then I think we should do it to reduce
> number of failure modes and syzbot reports.
This one in bpf tree fixes it:
https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=bbeb6e4323dad9b5e0ee9f60c223dd532e2403b1
Despite this one not having a reproducer, I'm pretty certain it's very
much related to all the ones coming in yesterday (which the above fixes).
>> This bug is generated by a dumb bot. It may contain errors.
>> See https://goo.gl/tpsmEJ for details.
>> Direct all questions to [email protected].
>>
>> syzbot will keep track of this bug report.
>> If you forgot to add the Reported-by tag, once the fix for this bug is
>> merged
>> into any tree, please reply to this email with:
>> #syz fix: exact-commit-title
>> To mark this as a duplicate of another syzbot report, please reply with:
>> #syz dup: exact-subject-of-another-report
>> If it's a one-off invalid bug report, please reply with:
>> #syz invalid
>> Note: if the crash happens again, it will cause creation of a new bug
>> report.
>> Note: all commands must start from beginning of the line in the email body.
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "syzkaller-bugs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/syzkaller-bugs/001a1140bf605479be05627d75c7%40google.com.
>> For more options, visit https://groups.google.com/d/optout.
On Thu, Jan 11, 2018 at 11:48:28AM +0100, Daniel Borkmann wrote:
> Hi Dmitry,
>
> On 01/11/2018 11:22 AM, Dmitry Vyukov wrote:
> > On Thu, Jan 11, 2018 at 11:17 AM, syzbot
> > <[email protected]> wrote:
> >> Hello,
> >>
> >> syzkaller hit the following crash on
> >> 4147d50978df60f34d444c647dde9e5b34a4315e
> >> git://git.cmpxchg.org/linux-mmots.git/master
> >> compiler: gcc (GCC) 7.1.1 20170620
> >> .config is attached
> >> Raw console output is attached.
> >> Unfortunately, I don't have any reproducer for this bug yet.
> >>
> >>
> >> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> >> Reported-by: [email protected]
> >> It will help syzbot understand when the bug is fixed. See footer for
> >> details.
> >> If you forward the report, please keep this part and the footer.
> >>
> >> netlink: 3 bytes leftover after parsing attributes in process
> >> `syz-executor5'.
> >> ==================================================================
> >> BUG: KASAN: use-after-free in __bpf_prog_put+0x5e8/0x640
> >> kernel/bpf/syscall.c:944
> >> netlink: 'syz-executor5': attribute type 5 has an invalid length.
> >> Read of size 8 at addr ffff8801d3619658 by task syz-executor0/12398
> >>
> >> CPU: 1 PID: 12398 Comm: syz-executor0 Not tainted 4.15.0-rc7-mm1+ #53
> >> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> >> Google 01/01/2011
> >> Call Trace:
> >> __dump_stack lib/dump_stack.c:17 [inline]
> >> dump_stack+0x194/0x257 lib/dump_stack.c:53
> >> print_address_description+0x73/0x250 mm/kasan/report.c:256
> >> kasan_report_error mm/kasan/report.c:354 [inline]
> >> kasan_report+0x23b/0x360 mm/kasan/report.c:412
> >> __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
> >> __bpf_prog_put+0x5e8/0x640 kernel/bpf/syscall.c:944
> >> bpf_prog_put+0x1a/0x20 kernel/bpf/syscall.c:961
> >> prog_fd_array_put_ptr+0x15/0x20 kernel/bpf/arraymap.c:446
> >> fd_array_map_delete_elem+0xc8/0x110 kernel/bpf/arraymap.c:420
> >> map_delete_elem kernel/bpf/syscall.c:737 [inline]
> >> SYSC_bpf kernel/bpf/syscall.c:1814 [inline]
> >> SyS_bpf+0x22ea/0x4400 kernel/bpf/syscall.c:1782
> >> entry_SYSCALL_64_fastpath+0x29/0xa0
> >> RIP: 0033:0x452ac9
> >> RSP: 002b:00007fb70df60c58 EFLAGS: 00000212 ORIG_RAX: 0000000000000141
> >> RAX: ffffffffffffffda RBX: 000000000071bea0 RCX: 0000000000452ac9
> >> RDX: 0000000000000010 RSI: 0000000020f02ff0 RDI: 0000000000000003
> >> RBP: 00000000000003aa R08: 0000000000000000 R09: 0000000000000000
> >> R10: 0000000000000000 R11: 0000000000000212 R12: 00000000006f3890
> >> R13: 00000000ffffffff R14: 00007fb70df616d4 R15: 0000000000000000
> >>
> >> Allocated by task 11996:
> >> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> >> set_track mm/kasan/kasan.c:459 [inline]
> >> kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:552
> >> kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
> >> kmem_cache_alloc+0x12e/0x760 mm/slab.c:3541
> >> kmem_cache_zalloc include/linux/slab.h:694 [inline]
> >> get_empty_filp+0xfb/0x4f0 fs/file_table.c:122
> >> path_openat+0xed/0x3530 fs/namei.c:3514
> >> do_filp_open+0x25b/0x3b0 fs/namei.c:3572
> >> do_sys_open+0x502/0x6d0 fs/open.c:1059
> >> SYSC_open fs/open.c:1077 [inline]
> >> SyS_open+0x2d/0x40 fs/open.c:1072
> >> entry_SYSCALL_64_fastpath+0x29/0xa0
> >>
> >> Freed by task 11994:
> >> save_stack+0x43/0xd0 mm/kasan/kasan.c:447
> >> set_track mm/kasan/kasan.c:459 [inline]
> >> __kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:520
> >> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:527
> >> __cache_free mm/slab.c:3485 [inline]
> >> kmem_cache_free+0x86/0x2b0 mm/slab.c:3743
> >> file_free_rcu+0x5c/0x70 fs/file_table.c:49
> >> __rcu_reclaim kernel/rcu/rcu.h:172 [inline]
> >> rcu_do_batch kernel/rcu/tree.c:2675 [inline]
> >> invoke_rcu_callbacks kernel/rcu/tree.c:2934 [inline]
> >> __rcu_process_callbacks kernel/rcu/tree.c:2901 [inline]
> >> rcu_process_callbacks+0xd6c/0x17f0 kernel/rcu/tree.c:2918
> >> __do_softirq+0x2d7/0xb85 kernel/softirq.c:285
> >>
> >> The buggy address belongs to the object at ffff8801d36195c0
> >> which belongs to the cache filp of size 456
> >> The buggy address is located 152 bytes inside of
> >> 456-byte region [ffff8801d36195c0, ffff8801d3619788)
> >> The buggy address belongs to the page:
> >> page:ffffea00074d8640 count:1 mapcount:0 mapping:ffff8801d36190c0 index:0x0
> >> flags: 0x2fffc0000000100(slab)
> >> raw: 02fffc0000000100 ffff8801d36190c0 0000000000000000 0000000100000006
> >> raw: ffffea00074c49a0 ffffea000747a160 ffff8801dae30180 0000000000000000
> >> page dumped because: kasan: bad access detected
> >>
> >> Memory state around the buggy address:
> >> ffff8801d3619500: fb fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >> ffff8801d3619580: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> >>>
> >>> ffff8801d3619600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >>
> >> ^
> >> ffff8801d3619680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >> ffff8801d3619700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> >> ==================================================================
> >
> >
> > Is it the same as "general protection fault in __bpf_prog_put"?
> > https://groups.google.com/forum/#!topic/syzkaller-bugs/jUsNMmVgms0
> >
> > The first stack looks similar, but alloc/free stacks looks unrelated.
> > What's the root cause of this? Is prog->aux an uninitialized pointer?
> > I wonder if initializing memory in kmalloc would help to prevent this
> > bug from duplicating? E.g. if we init memory to 0, it would always
> > cause GPFs, or if we init to an invalid pointer, always cause a bad
> > paging fault. Is it's the case, then I think we should do it to reduce
> > number of failure modes and syzbot reports.
>
> This one in bpf tree fixes it:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=bbeb6e4323dad9b5e0ee9f60c223dd532e2403b1
>
> Despite this one not having a reproducer, I'm pretty certain it's very
> much related to all the ones coming in yesterday (which the above fixes).
>
> >> This bug is generated by a dumb bot. It may contain errors.
> >> See https://goo.gl/tpsmEJ for details.
> >> Direct all questions to [email protected].
> >>
> >> syzbot will keep track of this bug report.
> >> If you forgot to add the Reported-by tag, once the fix for this bug is
> >> merged
> >> into any tree, please reply to this email with:
> >> #syz fix: exact-commit-title
This particular crash has not re-occurred following the initial report, so I'll
assume the above analysis is correct and it was indeed fixed by:
#syz fix: bpf, array: fix overflow in max_entries and undefined behavior in index_mask
- Eric