* [MPTCP] Re: BUG: KASAN: slab-out-of-bounds in subflow_ulp_init+0xa6/0x190
@ 2020-03-10 16:15 Christoph Paasch
0 siblings, 0 replies; 6+ messages in thread
From: Christoph Paasch @ 2020-03-10 16:15 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 1610 bytes --]
Thanks, I will try this out as well.
On a different note, I'm not 100% sure if my syzkaller descriptions are
correct for the Netlink-PM.
Should the following be correct?
r0 = socket$netlink(0x10, 0x3, 0x0)
r1 = syz_genetlink_get_family_id$mptcp(&(0x7f0000000100)='mptcp_pm\x00')
sendmsg$MPTCP_PM_CMD_ADD_ADDR(r0, &(0x7f0000000200)={0x0, 0x0, &(0x7f00000001c0)={&(0x7f0000000140)={0x20, r1, 0x1, 0x0, 0x0, {0x1, 0x2}, [@MPTCP_PM_ATTR_ADDR={0xc, 0x1, @MPTCP_PM_ADDR_ATTR_FAMILY={0x5}}]}, 0x20}}, 0x0)
I will try to add some BUG()s in the PM to verify this.
Christoph
On 09/03/20 - 08:12:23, Paolo Abeni wrote:
> On Fri, 2020-03-06 at 15:08 -0800, Christoph Paasch wrote:
> > Hello,
> >
> > I wanted to do some testing on netnext so I did a little hack to
> > force-enable MPTCP without the need for the app to use IPPROTO_MPTCP:
> >
> > diff --git a/net/socket.c b/net/socket.c
> > index b79a05de7c6e..56c656b4f867 100644
> > --- a/net/socket.c
> > +++ b/net/socket.c
> > @@ -1374,6 +1374,9 @@ int __sock_create(struct net *net, int family, int type, int protocol,
> > if (type < 0 || type >= SOCK_MAX)
> > return -EINVAL;
> >
> > + if (protocol == IPPROTO_TCP && type == SOCK_STREAM && (family == AF_INET || family == AF_INET6))
> > + protocol = IPPROTO_MPTCP;
> > +
> > /* Compatibility.
> >
> > This uglymoron is moved from INET layer to here to avoid
>
> Or you can use this:
>
> https://github.com/pabeni/mptcp-tools
>
> cd mptcp-tools
>
> ./use_mptcp.sh <app> ...
>
> (will force mptcp usage via syscall hijaking)
>
> /P
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* [MPTCP] Re: BUG: KASAN: slab-out-of-bounds in subflow_ulp_init+0xa6/0x190
@ 2020-03-10 20:45 Christoph Paasch
0 siblings, 0 replies; 6+ messages in thread
From: Christoph Paasch @ 2020-03-10 20:45 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 932 bytes --]
On 10/03/20 - 18:48:06, Paolo Abeni wrote:
> On Tue, 2020-03-10 at 09:15 -0700, Christoph Paasch wrote:
> > Should the following be correct?
> >
> > r0 = socket$netlink(0x10, 0x3, 0x0)
> > r1 = syz_genetlink_get_family_id$mptcp(&(0x7f0000000100)='mptcp_pm\x00')
> > sendmsg$MPTCP_PM_CMD_ADD_ADDR(r0, &(0x7f0000000200)={0x0, 0x0,
> > &(0x7f00000001c0)={&(0x7f0000000140)={0x20, r1, 0x1, 0x0, 0x0, {0x1,
> > 0x2}, [@MPTCP_PM_ATTR_ADDR={0xc, 0x1,
> > @MPTCP_PM_ADDR_ATTR_FAMILY={0x5}}]}, 0x20}}, 0x0)
>
> I'm unsure I parse correctly the syzkaller syntax... are you creating a
> NL attr, type nested, id MPTCP_PM_ATTR_ADDR, with a single nested
> attribute type uint8, id MPTCP_PM_ADDR_ATTR_FAMILY, value 5?
>
> if so, than is correct ;)
Thanks! I might not be getting very far in the coverage because syzkaller is
not chaining a family followed by an address. I need to find out how to do
this.
Christoph
^ permalink raw reply [flat|nested] 6+ messages in thread
* [MPTCP] Re: BUG: KASAN: slab-out-of-bounds in subflow_ulp_init+0xa6/0x190
@ 2020-03-10 17:48 Paolo Abeni
0 siblings, 0 replies; 6+ messages in thread
From: Paolo Abeni @ 2020-03-10 17:48 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 700 bytes --]
On Tue, 2020-03-10 at 09:15 -0700, Christoph Paasch wrote:
> Should the following be correct?
>
> r0 = socket$netlink(0x10, 0x3, 0x0)
> r1 = syz_genetlink_get_family_id$mptcp(&(0x7f0000000100)='mptcp_pm\x00')
> sendmsg$MPTCP_PM_CMD_ADD_ADDR(r0, &(0x7f0000000200)={0x0, 0x0,
> &(0x7f00000001c0)={&(0x7f0000000140)={0x20, r1, 0x1, 0x0, 0x0, {0x1,
> 0x2}, [@MPTCP_PM_ATTR_ADDR={0xc, 0x1,
> @MPTCP_PM_ADDR_ATTR_FAMILY={0x5}}]}, 0x20}}, 0x0)
I'm unsure I parse correctly the syzkaller syntax... are you creating a
NL attr, type nested, id MPTCP_PM_ATTR_ADDR, with a single nested
attribute type uint8, id MPTCP_PM_ADDR_ATTR_FAMILY, value 5?
if so, than is correct ;)
Cheers,
Paolo
^ permalink raw reply [flat|nested] 6+ messages in thread
* [MPTCP] Re: BUG: KASAN: slab-out-of-bounds in subflow_ulp_init+0xa6/0x190
@ 2020-03-09 7:12 Paolo Abeni
0 siblings, 0 replies; 6+ messages in thread
From: Paolo Abeni @ 2020-03-09 7:12 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 908 bytes --]
On Fri, 2020-03-06 at 15:08 -0800, Christoph Paasch wrote:
> Hello,
>
> I wanted to do some testing on netnext so I did a little hack to
> force-enable MPTCP without the need for the app to use IPPROTO_MPTCP:
>
> diff --git a/net/socket.c b/net/socket.c
> index b79a05de7c6e..56c656b4f867 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -1374,6 +1374,9 @@ int __sock_create(struct net *net, int family, int type, int protocol,
> if (type < 0 || type >= SOCK_MAX)
> return -EINVAL;
>
> + if (protocol == IPPROTO_TCP && type == SOCK_STREAM && (family == AF_INET || family == AF_INET6))
> + protocol = IPPROTO_MPTCP;
> +
> /* Compatibility.
>
> This uglymoron is moved from INET layer to here to avoid
Or you can use this:
https://github.com/pabeni/mptcp-tools
cd mptcp-tools
./use_mptcp.sh <app> ...
(will force mptcp usage via syscall hijaking)
/P
^ permalink raw reply [flat|nested] 6+ messages in thread
* [MPTCP] Re: BUG: KASAN: slab-out-of-bounds in subflow_ulp_init+0xa6/0x190
@ 2020-03-06 23:25 Christoph Paasch
0 siblings, 0 replies; 6+ messages in thread
From: Christoph Paasch @ 2020-03-06 23:25 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 6223 bytes --]
On 06/03/20 - 15:18:25, Mat Martineau wrote:
>
> On Fri, 6 Mar 2020, Christoph Paasch wrote:
>
> > Hello,
> >
> > I wanted to do some testing on netnext so I did a little hack to
> > force-enable MPTCP without the need for the app to use IPPROTO_MPTCP:
> >
> > diff --git a/net/socket.c b/net/socket.c
> > index b79a05de7c6e..56c656b4f867 100644
> > --- a/net/socket.c
> > +++ b/net/socket.c
> > @@ -1374,6 +1374,9 @@ int __sock_create(struct net *net, int family, int type, int protocol,
> > if (type < 0 || type >= SOCK_MAX)
> > return -EINVAL;
> >
> > + if (protocol == IPPROTO_TCP && type == SOCK_STREAM && (family == AF_INET || family == AF_INET6))
> > + protocol = IPPROTO_MPTCP;
> > +
>
> I think the subflow kernel sockets go down this code path too, maybe add
> !kern to the conditions?
Good point! Thanks!
Christoph
>
>
> Mat
>
>
> > /* Compatibility.
> >
> > This uglymoron is moved from INET layer to here to avoid
> >
> >
> >
> > Now, when I boot I panic right away because sshd binds a socket:
> >
> > [ 14.759548] ==================================================================
> > [ 14.760746] BUG: KASAN: slab-out-of-bounds in subflow_ulp_init+0xa6/0x190
> > [ 14.762025] Write of size 1 at addr ffff888114e40f04 by task sshd/1229
> > [ 14.763222]
> > [ 14.763506] CPU: 3 PID: 1229 Comm: sshd Not tainted 5.6.0-rc3.mptcp #67
> > [ 14.764546] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
> > [ 14.766340] Call Trace:
> > [ 14.766716] dump_stack+0x76/0xa0
> > [ 14.767302] print_address_description.constprop.0+0x36/0x50
> > [ 14.768309] ? subflow_ulp_init+0xa6/0x190
> > [ 14.768916] __kasan_report.cold+0x1c/0x3f
> > [ 14.769805] ? subflow_ulp_init+0xa6/0x190
> > [ 14.770450] ? subflow_ulp_init+0xa6/0x190
> > [ 14.771014] kasan_report+0xe/0x20
> > [ 14.771537] subflow_ulp_init+0xa6/0x190
> > [ 14.772095] tcp_set_ulp+0xeb/0x180
> > [ 14.772605] mptcp_subflow_create_socket+0x178/0x260
> > [ 14.773337] ? mptcpv6_handle_mapped+0x90/0x90
> > [ 14.773965] ? __kasan_kmalloc.constprop.0+0xc2/0xd0
> > [ 14.774687] ? __might_sleep+0x2c/0xc0
> > [ 14.775448] ? mptcp_release_cb+0x3b/0x110
> > [ 14.776030] __mptcp_socket_create+0x11c/0x1e0
> > [ 14.776685] ? _raw_spin_lock_bh+0x80/0xd0
> > [ 14.777282] ? mptcp_shutdown+0x150/0x150
> > [ 14.778136] ? __might_sleep+0x2c/0xc0
> > [ 14.778912] ? ___might_sleep+0xb5/0xd0
> > [ 14.779687] mptcp_bind+0x3a/0xc0
> > [ 14.780350] __sys_bind+0x13b/0x160
> > [ 14.780886] ? __x64_sys_socketpair+0x60/0x60
> > [ 14.781565] ? __sys_setsockopt+0x15b/0x170
> > [ 14.782211] ? __x64_sys_fcntl+0x76c/0x890
> > [ 14.782870] ? kernel_accept+0x140/0x140
> > [ 14.783493] ? f_getown+0x70/0x70
> > [ 14.784017] ? __sys_socket+0xf0/0x160
> > [ 14.784614] ? move_addr_to_kernel+0x20/0x20
> > [ 14.785212] __x64_sys_bind+0x39/0x40
> > [ 14.785732] do_syscall_64+0xbc/0x790
> > [ 14.786247] ? syscall_return_slowpath+0x320/0x320
> > [ 14.786924] ? up_read+0x10/0x70
> > [ 14.787400] ? do_page_fault+0x447/0x5ef
> > [ 14.787960] ? fpregs_assert_state_consistent+0x4d/0x60
> > [ 14.788690] ? prepare_exit_to_usermode+0xab/0x1c0
> > [ 14.789391] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> > [ 14.790281] RIP: 0033:0x7f420ce3e497
> > [ 14.790927] Code: ff ff ff ff c3 48 8b 15 f7 09 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb ba 66 2e 0f 1f 84 00 00 00 00 00 90 b8 31 008
> > [ 14.793565] RSP: 002b:00007ffed3aab688 EFLAGS: 00000206 ORIG_RAX: 0000000000000031
> > [ 14.793574] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f420ce3e497
> > [ 14.793575] RDX: 0000000000000010 RSI: 0000559b2d76c720 RDI: 0000000000000003
> > [ 14.793576] RBP: 00007ffed3aaba70 R08: 0000000000000004 R09: 00007ffed3aaad76
> > [ 14.793577] R10: 00007ffed3aab664 R11: 0000000000000206 R12: 00007ffed3aabb70
> > [ 14.793579] R13: 0000559b2d76f410 R14: 0000559b2d76c6f0 R15: 0000559b2d57c5c0
> > [ 14.793581]
> > [ 14.793586] Allocated by task 0:
> > [ 14.715787] k[ 14.793586] (stack is not available)
> > dump-tools[ 14.793587]
> > [ 14.793590] Freed by task 0:
> > [ 14.793590] (stack is not available)
> > [ 14.793591]
> > [ 14.793593] The buggy address belongs to the object at ffff888114e40d00
> > [ 14.793593] which belongs to the cache MPTCP of size 1480
> > [1200]: [ 14.793594] The buggy address is located 516 bytes inside of
> > [ 14.793594] 1480-byte region [ffff888114e40d00, ffff888114e412c8)
> > [ 14.793595] The buggy address belongs to the page:
> > [ 14.793602] page:ffffea0004539000 refcount:1 mapcount:0 mapping:ffff88811a645cc0 index:0x0 compound_mapcount: 0
> > [ 14.793609] flags: 0x8000000000010200(slab|head)
> > Starting kdump-t[ 14.809675] raw: 8000000000010200 dead000000000100 dead000000000122 ffff88811a645cc0
> > ools: no crashke[ 14.809677] raw: 0000000000000000 0000000080130013 00000001ffffffff 0000000000000000
> > rnel= parameter [ 14.809678] page dumped because: kasan: bad access detected
> > in the kernel cm[ 14.809679]
> > dline ... failed[ 14.809679] Memory state around the buggy address:
> > ![ 14.809682] ffff888114e40e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > [ 14.809683] ffff888114e40e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > [ 14.809685] >ffff888114e40f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > [ 14.809686] ^
> > [ 14.809687] ffff888114e40f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >
> > [ 14.809689] ffff888114e41000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> > [ 14.809689] ==================================================================
> >
> >
> > Do you think this is just due to me forcing IPPROTO_MPTCP ?
> >
> >
> > Christoph
> > _______________________________________________
> > mptcp mailing list -- mptcp(a)lists.01.org
> > To unsubscribe send an email to mptcp-leave(a)lists.01.org
> >
>
> --
> Mat Martineau
> Intel
^ permalink raw reply [flat|nested] 6+ messages in thread
* [MPTCP] Re: BUG: KASAN: slab-out-of-bounds in subflow_ulp_init+0xa6/0x190
@ 2020-03-06 23:18 Mat Martineau
0 siblings, 0 replies; 6+ messages in thread
From: Mat Martineau @ 2020-03-06 23:18 UTC (permalink / raw)
To: mptcp
[-- Attachment #1: Type: text/plain, Size: 5870 bytes --]
On Fri, 6 Mar 2020, Christoph Paasch wrote:
> Hello,
>
> I wanted to do some testing on netnext so I did a little hack to
> force-enable MPTCP without the need for the app to use IPPROTO_MPTCP:
>
> diff --git a/net/socket.c b/net/socket.c
> index b79a05de7c6e..56c656b4f867 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -1374,6 +1374,9 @@ int __sock_create(struct net *net, int family, int type, int protocol,
> if (type < 0 || type >= SOCK_MAX)
> return -EINVAL;
>
> + if (protocol == IPPROTO_TCP && type == SOCK_STREAM && (family == AF_INET || family == AF_INET6))
> + protocol = IPPROTO_MPTCP;
> +
I think the subflow kernel sockets go down this code path too, maybe add
!kern to the conditions?
Mat
> /* Compatibility.
>
> This uglymoron is moved from INET layer to here to avoid
>
>
>
> Now, when I boot I panic right away because sshd binds a socket:
>
> [ 14.759548] ==================================================================
> [ 14.760746] BUG: KASAN: slab-out-of-bounds in subflow_ulp_init+0xa6/0x190
> [ 14.762025] Write of size 1 at addr ffff888114e40f04 by task sshd/1229
> [ 14.763222]
> [ 14.763506] CPU: 3 PID: 1229 Comm: sshd Not tainted 5.6.0-rc3.mptcp #67
> [ 14.764546] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
> [ 14.766340] Call Trace:
> [ 14.766716] dump_stack+0x76/0xa0
> [ 14.767302] print_address_description.constprop.0+0x36/0x50
> [ 14.768309] ? subflow_ulp_init+0xa6/0x190
> [ 14.768916] __kasan_report.cold+0x1c/0x3f
> [ 14.769805] ? subflow_ulp_init+0xa6/0x190
> [ 14.770450] ? subflow_ulp_init+0xa6/0x190
> [ 14.771014] kasan_report+0xe/0x20
> [ 14.771537] subflow_ulp_init+0xa6/0x190
> [ 14.772095] tcp_set_ulp+0xeb/0x180
> [ 14.772605] mptcp_subflow_create_socket+0x178/0x260
> [ 14.773337] ? mptcpv6_handle_mapped+0x90/0x90
> [ 14.773965] ? __kasan_kmalloc.constprop.0+0xc2/0xd0
> [ 14.774687] ? __might_sleep+0x2c/0xc0
> [ 14.775448] ? mptcp_release_cb+0x3b/0x110
> [ 14.776030] __mptcp_socket_create+0x11c/0x1e0
> [ 14.776685] ? _raw_spin_lock_bh+0x80/0xd0
> [ 14.777282] ? mptcp_shutdown+0x150/0x150
> [ 14.778136] ? __might_sleep+0x2c/0xc0
> [ 14.778912] ? ___might_sleep+0xb5/0xd0
> [ 14.779687] mptcp_bind+0x3a/0xc0
> [ 14.780350] __sys_bind+0x13b/0x160
> [ 14.780886] ? __x64_sys_socketpair+0x60/0x60
> [ 14.781565] ? __sys_setsockopt+0x15b/0x170
> [ 14.782211] ? __x64_sys_fcntl+0x76c/0x890
> [ 14.782870] ? kernel_accept+0x140/0x140
> [ 14.783493] ? f_getown+0x70/0x70
> [ 14.784017] ? __sys_socket+0xf0/0x160
> [ 14.784614] ? move_addr_to_kernel+0x20/0x20
> [ 14.785212] __x64_sys_bind+0x39/0x40
> [ 14.785732] do_syscall_64+0xbc/0x790
> [ 14.786247] ? syscall_return_slowpath+0x320/0x320
> [ 14.786924] ? up_read+0x10/0x70
> [ 14.787400] ? do_page_fault+0x447/0x5ef
> [ 14.787960] ? fpregs_assert_state_consistent+0x4d/0x60
> [ 14.788690] ? prepare_exit_to_usermode+0xab/0x1c0
> [ 14.789391] entry_SYSCALL_64_after_hwframe+0x44/0xa9
> [ 14.790281] RIP: 0033:0x7f420ce3e497
> [ 14.790927] Code: ff ff ff ff c3 48 8b 15 f7 09 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb ba 66 2e 0f 1f 84 00 00 00 00 00 90 b8 31 008
> [ 14.793565] RSP: 002b:00007ffed3aab688 EFLAGS: 00000206 ORIG_RAX: 0000000000000031
> [ 14.793574] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f420ce3e497
> [ 14.793575] RDX: 0000000000000010 RSI: 0000559b2d76c720 RDI: 0000000000000003
> [ 14.793576] RBP: 00007ffed3aaba70 R08: 0000000000000004 R09: 00007ffed3aaad76
> [ 14.793577] R10: 00007ffed3aab664 R11: 0000000000000206 R12: 00007ffed3aabb70
> [ 14.793579] R13: 0000559b2d76f410 R14: 0000559b2d76c6f0 R15: 0000559b2d57c5c0
> [ 14.793581]
> [ 14.793586] Allocated by task 0:
> [ 14.715787] k[ 14.793586] (stack is not available)
> dump-tools[ 14.793587]
> [ 14.793590] Freed by task 0:
> [ 14.793590] (stack is not available)
> [ 14.793591]
> [ 14.793593] The buggy address belongs to the object at ffff888114e40d00
> [ 14.793593] which belongs to the cache MPTCP of size 1480
> [1200]: [ 14.793594] The buggy address is located 516 bytes inside of
> [ 14.793594] 1480-byte region [ffff888114e40d00, ffff888114e412c8)
> [ 14.793595] The buggy address belongs to the page:
> [ 14.793602] page:ffffea0004539000 refcount:1 mapcount:0 mapping:ffff88811a645cc0 index:0x0 compound_mapcount: 0
> [ 14.793609] flags: 0x8000000000010200(slab|head)
> Starting kdump-t[ 14.809675] raw: 8000000000010200 dead000000000100 dead000000000122 ffff88811a645cc0
> ools: no crashke[ 14.809677] raw: 0000000000000000 0000000080130013 00000001ffffffff 0000000000000000
> rnel= parameter [ 14.809678] page dumped because: kasan: bad access detected
> in the kernel cm[ 14.809679]
> dline ... failed[ 14.809679] Memory state around the buggy address:
> ![ 14.809682] ffff888114e40e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [ 14.809683] ffff888114e40e80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [ 14.809685] >ffff888114e40f00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [ 14.809686] ^
> [ 14.809687] ffff888114e40f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>
> [ 14.809689] ffff888114e41000: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> [ 14.809689] ==================================================================
>
>
> Do you think this is just due to me forcing IPPROTO_MPTCP ?
>
>
> Christoph
> _______________________________________________
> mptcp mailing list -- mptcp(a)lists.01.org
> To unsubscribe send an email to mptcp-leave(a)lists.01.org
>
--
Mat Martineau
Intel
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-03-10 20:45 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-03-10 16:15 [MPTCP] Re: BUG: KASAN: slab-out-of-bounds in subflow_ulp_init+0xa6/0x190 Christoph Paasch
-- strict thread matches above, loose matches on Subject: below --
2020-03-10 20:45 Christoph Paasch
2020-03-10 17:48 Paolo Abeni
2020-03-09 7:12 Paolo Abeni
2020-03-06 23:25 Christoph Paasch
2020-03-06 23:18 Mat Martineau
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.