* KASAN: use-after-free Read in sctp_outq_select_transport
@ 2018-10-23 10:13 ` syzbot
0 siblings, 0 replies; 30+ messages in thread
From: syzbot @ 2018-10-23 10:13 UTC (permalink / raw)
To: davem, linux-kernel, linux-sctp, marcelo.leitner, netdev,
nhorman, syzkaller-bugs, vyasevich
Hello,
syzbot found the following crash on:
HEAD commit: 23469de647c4 Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=13580ce5400000
kernel config: https://syzkaller.appspot.com/x/.config?x=b3f55cb3dfcc6c33
dashboard link: https://syzkaller.appspot.com/bug?extid=56a40ceee5fb35932f4d
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+56a40ceee5fb35932f4d@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in sctp_outq_select_transport+0x77e/0x9a0
net/sctp/outqueue.c:840
Read of size 4 at addr ffff8801c5ff2614 by task syz-executor5/8275
CPU: 0 PID: 8275 Comm: syz-executor5 Not tainted 4.19.0-rc8+ #152
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b6 lib/dump_stack.c:113
print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
__asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
sctp_outq_select_transport+0x77e/0x9a0 net/sctp/outqueue.c:840
sctp_outq_flush_data net/sctp/outqueue.c:1100 [inline]
sctp_outq_flush+0x14f7/0x34f0 net/sctp/outqueue.c:1209
sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x608/0x7190 net/sctp/sm_sideeffect.c:1191
sctp_assoc_bh_rcv+0x346/0x670 net/sctp/associola.c:1067
sctp_inq_push+0x280/0x370 net/sctp/inqueue.c:95
sctp_rcv+0x2d93/0x3c00 net/sctp/input.c:268
sctp6_rcv+0x15/0x30 net/sctp/ipv6.c:1061
ip6_input_finish+0x3fc/0x1aa0 net/ipv6/ip6_input.c:383
NF_HOOK include/linux/netfilter.h:289 [inline]
ip6_input+0xe9/0x600 net/ipv6/ip6_input.c:426
dst_input include/net/dst.h:450 [inline]
ip6_rcv_finish+0x17a/0x330 net/ipv6/ip6_input.c:76
NF_HOOK include/linux/netfilter.h:289 [inline]
ipv6_rcv+0x120/0x640 net/ipv6/ip6_input.c:271
__netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
__netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
process_backlog+0x218/0x6f0 net/core/dev.c:5829
napi_poll net/core/dev.c:6249 [inline]
net_rx_action+0x7c5/0x1950 net/core/dev.c:6315
IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
__do_softirq+0x30c/0xb03 kernel/softirq.c:292
do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1047
</IRQ>
do_softirq.part.13+0x126/0x160 kernel/softirq.c:336
do_softirq kernel/softirq.c:328 [inline]
__local_bh_enable_ip+0x21d/0x260 kernel/softirq.c:189
local_bh_enable include/linux/bottom_half.h:32 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:723 [inline]
ip6_finish_output2+0xce4/0x27a0 net/ipv6/ip6_output.c:121
ip6_finish_output+0x58c/0xc60 net/ipv6/ip6_output.c:154
NF_HOOK_COND include/linux/netfilter.h:278 [inline]
ip6_output+0x232/0x9d0 net/ipv6/ip6_output.c:171
dst_output include/net/dst.h:444 [inline]
NF_HOOK include/linux/netfilter.h:289 [inline]
ip6_xmit+0xf69/0x2420 net/ipv6/ip6_output.c:275
sctp_v6_xmit+0x3b2/0x790 net/sctp/ipv6.c:230
sctp_packet_transmit+0x298e/0x3db0 net/sctp/output.c:656
sctp_packet_singleton net/sctp/outqueue.c:791 [inline]
sctp_outq_flush_ctrl.constprop.11+0x7a9/0xe50 net/sctp/outqueue.c:922
sctp_outq_flush+0x310/0x34f0 net/sctp/outqueue.c:1204
sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776
kobject: 'rfkill9' (0000000067be229d): fill_kobj_path: path
= '/devices/virtual/mac80211_hwsim/hwsim7/ieee80211/phy7/rfkill9'
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1349 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x4f25/0x7190 net/sctp/sm_sideeffect.c:1191
ieee80211 phy7: Selected rate control algorithm 'minstrel_ht'
kobject: 'net' (00000000cdd117dc): kobject_add_internal: parent: 'hwsim7',
set: '(null)'
sctp_endpoint_bh_rcv+0x465/0x960 net/sctp/endpointola.c:456
kobject: 'wlan0' (00000000c9d333fc): kobject_add_internal: parent: 'net',
set: 'devices'
sctp_inq_push+0x280/0x370 net/sctp/inqueue.c:95
sctp_backlog_rcv+0x1a8/0xd50 net/sctp/input.c:351
kobject: 'wlan0' (00000000c9d333fc): kobject_uevent_env
kobject: 'wlan0' (00000000c9d333fc): fill_kobj_path: path
= '/devices/virtual/mac80211_hwsim/hwsim7/net/wlan0'
sk_backlog_rcv include/net/sock.h:931 [inline]
__release_sock+0x12f/0x3a0 net/core/sock.c:2336
kobject: 'queues' (00000000c5d009e9): kobject_add_internal:
parent: 'wlan0', set: '<NULL>'
release_sock+0xad/0x2c0 net/core/sock.c:2849
sock_setsockopt+0x60d/0x2280 net/core/sock.c:1054
kobject: 'queues' (00000000c5d009e9): kobject_uevent_env
kobject: 'queues' (00000000c5d009e9): kobject_uevent_env: filter function
caused the event to drop!
__sys_setsockopt+0x304/0x3c0 net/socket.c:1898
kobject: 'rx-0' (000000007736ba36): kobject_add_internal: parent: 'queues',
set: 'queues'
__do_sys_setsockopt net/socket.c:1913 [inline]
__se_sys_setsockopt net/socket.c:1910 [inline]
__x64_sys_setsockopt+0xbe/0x150 net/socket.c:1910
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
kobject: 'rx-0' (000000007736ba36): kobject_uevent_env
entry_SYSCALL_64_after_hwframe+0x49/0xbe
kobject: 'rx-0' (000000007736ba36): fill_kobj_path: path
= '/devices/virtual/mac80211_hwsim/hwsim7/net/wlan0/queues/rx-0'
RIP: 0033:0x457569
Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f0613beec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000457569
RDX: 000000000000001a RSI: 0000000000000001 RDI: 0000000000000003
RBP: 000000000072c040 R08: 0000000000000010 R09: 0000000000000000
R10: 00000000200000c0 R11: 0000000000000246 R12: 00007f0613bef6d4
R13: 00000000004c3b61 R14: 00000000004d5c88 R15: 00000000ffffffff
Allocated by task 8261:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
kobject: 'tx-0' (000000008f0eae4c): kobject_add_internal: parent: 'queues',
set: 'queues'
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
kmem_cache_alloc_trace+0x152/0x750 mm/slab.c:3620
kmalloc include/linux/slab.h:513 [inline]
kzalloc include/linux/slab.h:707 [inline]
sctp_transport_new+0x10a/0x880 net/sctp/transport.c:111
sctp_assoc_add_peer+0x2de/0x10d0 net/sctp/associola.c:630
sctp_process_param net/sctp/sm_make_chunk.c:2540 [inline]
sctp_process_init+0xfc0/0x29e0 net/sctp/sm_make_chunk.c:2356
sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x13b9/0x7190 net/sctp/sm_sideeffect.c:1191
sctp_assoc_bh_rcv+0x346/0x670 net/sctp/associola.c:1067
sctp_inq_push+0x280/0x370 net/sctp/inqueue.c:95
sctp_backlog_rcv+0x1a8/0xd50 net/sctp/input.c:351
sk_backlog_rcv include/net/sock.h:931 [inline]
__release_sock+0x12f/0x3a0 net/core/sock.c:2336
kobject: 'tx-0' (000000008f0eae4c): kobject_uevent_env
release_sock+0xad/0x2c0 net/core/sock.c:2849
sctp_wait_for_connect+0x391/0x640 net/sctp/socket.c:8667
sctp_sendmsg_to_asoc+0x1d0f/0x2230 net/sctp/socket.c:1985
sctp_sendmsg+0x13c2/0x1da0 net/sctp/socket.c:2131
inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:631
__sys_sendto+0x3d7/0x670 net/socket.c:1788
__do_sys_sendto net/socket.c:1800 [inline]
__se_sys_sendto net/socket.c:1796 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1796
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
kobject: 'tx-0' (000000008f0eae4c): fill_kobj_path: path
= '/devices/virtual/mac80211_hwsim/hwsim7/net/wlan0/queues/tx-0'
Freed by task 9:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xcf/0x230 mm/slab.c:3813
sctp_transport_destroy_rcu+0x4a/0x60 net/sctp/transport.c:163
__rcu_reclaim kernel/rcu/rcu.h:236 [inline]
rcu_do_batch kernel/rcu/tree.c:2576 [inline]
invoke_rcu_callbacks kernel/rcu/tree.c:2880 [inline]
__rcu_process_callbacks kernel/rcu/tree.c:2847 [inline]
rcu_process_callbacks+0xf23/0x2670 kernel/rcu/tree.c:2864
__do_softirq+0x30c/0xb03 kernel/softirq.c:292
kobject: 'tx-1' (000000009aaee194): kobject_add_internal: parent: 'queues',
set: 'queues'
The buggy address belongs to the object at ffff8801c5ff24c0
which belongs to the cache kmalloc-1024 of size 1024
The buggy address is located 340 bytes inside of
1024-byte region [ffff8801c5ff24c0, ffff8801c5ff28c0)
The buggy address belongs to the page:
page:ffffea000717fc80 count:1 mapcount:0 mapping:ffff8801da800ac0 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea00070ed808 ffffea00071b2488 ffff8801da800ac0
raw: 0000000000000000 ffff8801c5ff2040 0000000100000007 0000000000000000
kobject: 'tx-1' (000000009aaee194): kobject_uevent_env
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801c5ff2500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801c5ff2580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801c5ff2600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8801c5ff2680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801c5ff2700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply [flat|nested] 30+ messages in thread
* KASAN: use-after-free Read in sctp_outq_select_transport
@ 2018-10-23 10:13 ` syzbot
0 siblings, 0 replies; 30+ messages in thread
From: syzbot @ 2018-10-23 10:13 UTC (permalink / raw)
To: davem, linux-kernel, linux-sctp, marcelo.leitner, netdev,
nhorman, syzkaller-bugs, vyasevich
Hello,
syzbot found the following crash on:
HEAD commit: 23469de647c4 Merge git://git.kernel.org/pub/scm/linux/kern..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x\x13580ce5400000
kernel config: https://syzkaller.appspot.com/x/.config?x³f55cb3dfcc6c33
dashboard link: https://syzkaller.appspot.com/bug?extidVa40ceee5fb35932f4d
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+56a40ceee5fb35932f4d@syzkaller.appspotmail.com
=================================
BUG: KASAN: use-after-free in sctp_outq_select_transport+0x77e/0x9a0
net/sctp/outqueue.c:840
Read of size 4 at addr ffff8801c5ff2614 by task syz-executor5/8275
CPU: 0 PID: 8275 Comm: syz-executor5 Not tainted 4.19.0-rc8+ #152
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1c4/0x2b6 lib/dump_stack.c:113
print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
__asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
sctp_outq_select_transport+0x77e/0x9a0 net/sctp/outqueue.c:840
sctp_outq_flush_data net/sctp/outqueue.c:1100 [inline]
sctp_outq_flush+0x14f7/0x34f0 net/sctp/outqueue.c:1209
sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x608/0x7190 net/sctp/sm_sideeffect.c:1191
sctp_assoc_bh_rcv+0x346/0x670 net/sctp/associola.c:1067
sctp_inq_push+0x280/0x370 net/sctp/inqueue.c:95
sctp_rcv+0x2d93/0x3c00 net/sctp/input.c:268
sctp6_rcv+0x15/0x30 net/sctp/ipv6.c:1061
ip6_input_finish+0x3fc/0x1aa0 net/ipv6/ip6_input.c:383
NF_HOOK include/linux/netfilter.h:289 [inline]
ip6_input+0xe9/0x600 net/ipv6/ip6_input.c:426
dst_input include/net/dst.h:450 [inline]
ip6_rcv_finish+0x17a/0x330 net/ipv6/ip6_input.c:76
NF_HOOK include/linux/netfilter.h:289 [inline]
ipv6_rcv+0x120/0x640 net/ipv6/ip6_input.c:271
__netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
__netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
process_backlog+0x218/0x6f0 net/core/dev.c:5829
napi_poll net/core/dev.c:6249 [inline]
net_rx_action+0x7c5/0x1950 net/core/dev.c:6315
IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
__do_softirq+0x30c/0xb03 kernel/softirq.c:292
do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1047
</IRQ>
do_softirq.part.13+0x126/0x160 kernel/softirq.c:336
do_softirq kernel/softirq.c:328 [inline]
__local_bh_enable_ip+0x21d/0x260 kernel/softirq.c:189
local_bh_enable include/linux/bottom_half.h:32 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:723 [inline]
ip6_finish_output2+0xce4/0x27a0 net/ipv6/ip6_output.c:121
ip6_finish_output+0x58c/0xc60 net/ipv6/ip6_output.c:154
NF_HOOK_COND include/linux/netfilter.h:278 [inline]
ip6_output+0x232/0x9d0 net/ipv6/ip6_output.c:171
dst_output include/net/dst.h:444 [inline]
NF_HOOK include/linux/netfilter.h:289 [inline]
ip6_xmit+0xf69/0x2420 net/ipv6/ip6_output.c:275
sctp_v6_xmit+0x3b2/0x790 net/sctp/ipv6.c:230
sctp_packet_transmit+0x298e/0x3db0 net/sctp/output.c:656
sctp_packet_singleton net/sctp/outqueue.c:791 [inline]
sctp_outq_flush_ctrl.constprop.11+0x7a9/0xe50 net/sctp/outqueue.c:922
sctp_outq_flush+0x310/0x34f0 net/sctp/outqueue.c:1204
sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776
kobject: 'rfkill9' (0000000067be229d): fill_kobj_path: path
= '/devices/virtual/mac80211_hwsim/hwsim7/ieee80211/phy7/rfkill9'
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1349 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x4f25/0x7190 net/sctp/sm_sideeffect.c:1191
ieee80211 phy7: Selected rate control algorithm 'minstrel_ht'
kobject: 'net' (00000000cdd117dc): kobject_add_internal: parent: 'hwsim7',
set: '(null)'
sctp_endpoint_bh_rcv+0x465/0x960 net/sctp/endpointola.c:456
kobject: 'wlan0' (00000000c9d333fc): kobject_add_internal: parent: 'net',
set: 'devices'
sctp_inq_push+0x280/0x370 net/sctp/inqueue.c:95
sctp_backlog_rcv+0x1a8/0xd50 net/sctp/input.c:351
kobject: 'wlan0' (00000000c9d333fc): kobject_uevent_env
kobject: 'wlan0' (00000000c9d333fc): fill_kobj_path: path
= '/devices/virtual/mac80211_hwsim/hwsim7/net/wlan0'
sk_backlog_rcv include/net/sock.h:931 [inline]
__release_sock+0x12f/0x3a0 net/core/sock.c:2336
kobject: 'queues' (00000000c5d009e9): kobject_add_internal:
parent: 'wlan0', set: '<NULL>'
release_sock+0xad/0x2c0 net/core/sock.c:2849
sock_setsockopt+0x60d/0x2280 net/core/sock.c:1054
kobject: 'queues' (00000000c5d009e9): kobject_uevent_env
kobject: 'queues' (00000000c5d009e9): kobject_uevent_env: filter function
caused the event to drop!
__sys_setsockopt+0x304/0x3c0 net/socket.c:1898
kobject: 'rx-0' (000000007736ba36): kobject_add_internal: parent: 'queues',
set: 'queues'
__do_sys_setsockopt net/socket.c:1913 [inline]
__se_sys_setsockopt net/socket.c:1910 [inline]
__x64_sys_setsockopt+0xbe/0x150 net/socket.c:1910
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
kobject: 'rx-0' (000000007736ba36): kobject_uevent_env
entry_SYSCALL_64_after_hwframe+0x49/0xbe
kobject: 'rx-0' (000000007736ba36): fill_kobj_path: path
= '/devices/virtual/mac80211_hwsim/hwsim7/net/wlan0/queues/rx-0'
RIP: 0033:0x457569
Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007f0613beec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000457569
RDX: 000000000000001a RSI: 0000000000000001 RDI: 0000000000000003
RBP: 000000000072c040 R08: 0000000000000010 R09: 0000000000000000
R10: 00000000200000c0 R11: 0000000000000246 R12: 00007f0613bef6d4
R13: 00000000004c3b61 R14: 00000000004d5c88 R15: 00000000ffffffff
Allocated by task 8261:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
kobject: 'tx-0' (000000008f0eae4c): kobject_add_internal: parent: 'queues',
set: 'queues'
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
kmem_cache_alloc_trace+0x152/0x750 mm/slab.c:3620
kmalloc include/linux/slab.h:513 [inline]
kzalloc include/linux/slab.h:707 [inline]
sctp_transport_new+0x10a/0x880 net/sctp/transport.c:111
sctp_assoc_add_peer+0x2de/0x10d0 net/sctp/associola.c:630
sctp_process_param net/sctp/sm_make_chunk.c:2540 [inline]
sctp_process_init+0xfc0/0x29e0 net/sctp/sm_make_chunk.c:2356
sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x13b9/0x7190 net/sctp/sm_sideeffect.c:1191
sctp_assoc_bh_rcv+0x346/0x670 net/sctp/associola.c:1067
sctp_inq_push+0x280/0x370 net/sctp/inqueue.c:95
sctp_backlog_rcv+0x1a8/0xd50 net/sctp/input.c:351
sk_backlog_rcv include/net/sock.h:931 [inline]
__release_sock+0x12f/0x3a0 net/core/sock.c:2336
kobject: 'tx-0' (000000008f0eae4c): kobject_uevent_env
release_sock+0xad/0x2c0 net/core/sock.c:2849
sctp_wait_for_connect+0x391/0x640 net/sctp/socket.c:8667
sctp_sendmsg_to_asoc+0x1d0f/0x2230 net/sctp/socket.c:1985
sctp_sendmsg+0x13c2/0x1da0 net/sctp/socket.c:2131
inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:631
__sys_sendto+0x3d7/0x670 net/socket.c:1788
__do_sys_sendto net/socket.c:1800 [inline]
__se_sys_sendto net/socket.c:1796 [inline]
__x64_sys_sendto+0xe1/0x1a0 net/socket.c:1796
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
kobject: 'tx-0' (000000008f0eae4c): fill_kobj_path: path
= '/devices/virtual/mac80211_hwsim/hwsim7/net/wlan0/queues/tx-0'
Freed by task 9:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kfree+0xcf/0x230 mm/slab.c:3813
sctp_transport_destroy_rcu+0x4a/0x60 net/sctp/transport.c:163
__rcu_reclaim kernel/rcu/rcu.h:236 [inline]
rcu_do_batch kernel/rcu/tree.c:2576 [inline]
invoke_rcu_callbacks kernel/rcu/tree.c:2880 [inline]
__rcu_process_callbacks kernel/rcu/tree.c:2847 [inline]
rcu_process_callbacks+0xf23/0x2670 kernel/rcu/tree.c:2864
__do_softirq+0x30c/0xb03 kernel/softirq.c:292
kobject: 'tx-1' (000000009aaee194): kobject_add_internal: parent: 'queues',
set: 'queues'
The buggy address belongs to the object at ffff8801c5ff24c0
which belongs to the cache kmalloc-1024 of size 1024
The buggy address is located 340 bytes inside of
1024-byte region [ffff8801c5ff24c0, ffff8801c5ff28c0)
The buggy address belongs to the page:
page:ffffea000717fc80 count:1 mapcount:0 mapping:ffff8801da800ac0 index:0x0
compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffffea00070ed808 ffffea00071b2488 ffff8801da800ac0
raw: 0000000000000000 ffff8801c5ff2040 0000000100000007 0000000000000000
kobject: 'tx-1' (000000009aaee194): kobject_uevent_env
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8801c5ff2500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801c5ff2580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801c5ff2600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8801c5ff2680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8801c5ff2700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
=================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_select_transport
2018-10-23 10:13 ` syzbot
@ 2018-10-27 7:33 ` Xin Long
-1 siblings, 0 replies; 30+ messages in thread
From: Xin Long @ 2018-10-27 7:33 UTC (permalink / raw)
To: syzbot+56a40ceee5fb35932f4d
Cc: davem, LKML, linux-sctp, Marcelo Ricardo Leitner, network dev,
Neil Horman, syzkaller-bugs, Vlad Yasevich
On Tue, Oct 23, 2018 at 7:14 PM syzbot
<syzbot+56a40ceee5fb35932f4d@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 23469de647c4 Merge git://git.kernel.org/pub/scm/linux/kern..
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x=13580ce5400000
> kernel config: https://syzkaller.appspot.com/x/.config?x=b3f55cb3dfcc6c33
> dashboard link: https://syzkaller.appspot.com/bug?extid=56a40ceee5fb35932f4d
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+56a40ceee5fb35932f4d@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KASAN: use-after-free in sctp_outq_select_transport+0x77e/0x9a0
> net/sctp/outqueue.c:840
> Read of size 4 at addr ffff8801c5ff2614 by task syz-executor5/8275
>
> CPU: 0 PID: 8275 Comm: syz-executor5 Not tainted 4.19.0-rc8+ #152
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c4/0x2b6 lib/dump_stack.c:113
> print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
> __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
> sctp_outq_select_transport+0x77e/0x9a0 net/sctp/outqueue.c:840
I think we need a fix like:
@@ -586,6 +586,10 @@ void sctp_assoc_rm_peer(struct sctp_association *asoc,
sctp_transport_hold(active);
}
+ list_for_each_entry(ch, &asoc->outqueue.out_chunk_list, list)
+ if (ch->transport == transport)
+ ch->transport = NULL;
+
asoc->peer.transport_count--;
sctp_transport_free(peer);
> sctp_outq_flush_data net/sctp/outqueue.c:1100 [inline]
> sctp_outq_flush+0x14f7/0x34f0 net/sctp/outqueue.c:1209
> sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline]
> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> sctp_do_sm+0x608/0x7190 net/sctp/sm_sideeffect.c:1191
> sctp_assoc_bh_rcv+0x346/0x670 net/sctp/associola.c:1067
> sctp_inq_push+0x280/0x370 net/sctp/inqueue.c:95
> sctp_rcv+0x2d93/0x3c00 net/sctp/input.c:268
> sctp6_rcv+0x15/0x30 net/sctp/ipv6.c:1061
> ip6_input_finish+0x3fc/0x1aa0 net/ipv6/ip6_input.c:383
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ip6_input+0xe9/0x600 net/ipv6/ip6_input.c:426
> dst_input include/net/dst.h:450 [inline]
> ip6_rcv_finish+0x17a/0x330 net/ipv6/ip6_input.c:76
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ipv6_rcv+0x120/0x640 net/ipv6/ip6_input.c:271
> __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
> process_backlog+0x218/0x6f0 net/core/dev.c:5829
> napi_poll net/core/dev.c:6249 [inline]
> net_rx_action+0x7c5/0x1950 net/core/dev.c:6315
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> __do_softirq+0x30c/0xb03 kernel/softirq.c:292
> do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1047
> </IRQ>
> do_softirq.part.13+0x126/0x160 kernel/softirq.c:336
> do_softirq kernel/softirq.c:328 [inline]
> __local_bh_enable_ip+0x21d/0x260 kernel/softirq.c:189
> local_bh_enable include/linux/bottom_half.h:32 [inline]
> rcu_read_unlock_bh include/linux/rcupdate.h:723 [inline]
> ip6_finish_output2+0xce4/0x27a0 net/ipv6/ip6_output.c:121
> ip6_finish_output+0x58c/0xc60 net/ipv6/ip6_output.c:154
> NF_HOOK_COND include/linux/netfilter.h:278 [inline]
> ip6_output+0x232/0x9d0 net/ipv6/ip6_output.c:171
> dst_output include/net/dst.h:444 [inline]
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ip6_xmit+0xf69/0x2420 net/ipv6/ip6_output.c:275
> sctp_v6_xmit+0x3b2/0x790 net/sctp/ipv6.c:230
> sctp_packet_transmit+0x298e/0x3db0 net/sctp/output.c:656
> sctp_packet_singleton net/sctp/outqueue.c:791 [inline]
> sctp_outq_flush_ctrl.constprop.11+0x7a9/0xe50 net/sctp/outqueue.c:922
> sctp_outq_flush+0x310/0x34f0 net/sctp/outqueue.c:1204
> sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776
> kobject: 'rfkill9' (0000000067be229d): fill_kobj_path: path
> = '/devices/virtual/mac80211_hwsim/hwsim7/ieee80211/phy7/rfkill9'
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1349 [inline]
> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> sctp_do_sm+0x4f25/0x7190 net/sctp/sm_sideeffect.c:1191
> ieee80211 phy7: Selected rate control algorithm 'minstrel_ht'
> kobject: 'net' (00000000cdd117dc): kobject_add_internal: parent: 'hwsim7',
> set: '(null)'
> sctp_endpoint_bh_rcv+0x465/0x960 net/sctp/endpointola.c:456
> kobject: 'wlan0' (00000000c9d333fc): kobject_add_internal: parent: 'net',
> set: 'devices'
> sctp_inq_push+0x280/0x370 net/sctp/inqueue.c:95
> sctp_backlog_rcv+0x1a8/0xd50 net/sctp/input.c:351
> kobject: 'wlan0' (00000000c9d333fc): kobject_uevent_env
> kobject: 'wlan0' (00000000c9d333fc): fill_kobj_path: path
> = '/devices/virtual/mac80211_hwsim/hwsim7/net/wlan0'
> sk_backlog_rcv include/net/sock.h:931 [inline]
> __release_sock+0x12f/0x3a0 net/core/sock.c:2336
> kobject: 'queues' (00000000c5d009e9): kobject_add_internal:
> parent: 'wlan0', set: '<NULL>'
> release_sock+0xad/0x2c0 net/core/sock.c:2849
> sock_setsockopt+0x60d/0x2280 net/core/sock.c:1054
> kobject: 'queues' (00000000c5d009e9): kobject_uevent_env
> kobject: 'queues' (00000000c5d009e9): kobject_uevent_env: filter function
> caused the event to drop!
> __sys_setsockopt+0x304/0x3c0 net/socket.c:1898
> kobject: 'rx-0' (000000007736ba36): kobject_add_internal: parent: 'queues',
> set: 'queues'
> __do_sys_setsockopt net/socket.c:1913 [inline]
> __se_sys_setsockopt net/socket.c:1910 [inline]
> __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1910
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> kobject: 'rx-0' (000000007736ba36): kobject_uevent_env
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> kobject: 'rx-0' (000000007736ba36): fill_kobj_path: path
> = '/devices/virtual/mac80211_hwsim/hwsim7/net/wlan0/queues/rx-0'
> RIP: 0033:0x457569
> Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f0613beec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
> RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000457569
> RDX: 000000000000001a RSI: 0000000000000001 RDI: 0000000000000003
> RBP: 000000000072c040 R08: 0000000000000010 R09: 0000000000000000
> R10: 00000000200000c0 R11: 0000000000000246 R12: 00007f0613bef6d4
> R13: 00000000004c3b61 R14: 00000000004d5c88 R15: 00000000ffffffff
>
> Allocated by task 8261:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> kobject: 'tx-0' (000000008f0eae4c): kobject_add_internal: parent: 'queues',
> set: 'queues'
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
> kmem_cache_alloc_trace+0x152/0x750 mm/slab.c:3620
> kmalloc include/linux/slab.h:513 [inline]
> kzalloc include/linux/slab.h:707 [inline]
> sctp_transport_new+0x10a/0x880 net/sctp/transport.c:111
> sctp_assoc_add_peer+0x2de/0x10d0 net/sctp/associola.c:630
> sctp_process_param net/sctp/sm_make_chunk.c:2540 [inline]
> sctp_process_init+0xfc0/0x29e0 net/sctp/sm_make_chunk.c:2356
> sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> sctp_do_sm+0x13b9/0x7190 net/sctp/sm_sideeffect.c:1191
> sctp_assoc_bh_rcv+0x346/0x670 net/sctp/associola.c:1067
> sctp_inq_push+0x280/0x370 net/sctp/inqueue.c:95
> sctp_backlog_rcv+0x1a8/0xd50 net/sctp/input.c:351
> sk_backlog_rcv include/net/sock.h:931 [inline]
> __release_sock+0x12f/0x3a0 net/core/sock.c:2336
> kobject: 'tx-0' (000000008f0eae4c): kobject_uevent_env
> release_sock+0xad/0x2c0 net/core/sock.c:2849
> sctp_wait_for_connect+0x391/0x640 net/sctp/socket.c:8667
> sctp_sendmsg_to_asoc+0x1d0f/0x2230 net/sctp/socket.c:1985
> sctp_sendmsg+0x13c2/0x1da0 net/sctp/socket.c:2131
> inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:631
> __sys_sendto+0x3d7/0x670 net/socket.c:1788
> __do_sys_sendto net/socket.c:1800 [inline]
> __se_sys_sendto net/socket.c:1796 [inline]
> __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1796
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> kobject: 'tx-0' (000000008f0eae4c): fill_kobj_path: path
> = '/devices/virtual/mac80211_hwsim/hwsim7/net/wlan0/queues/tx-0'
>
> Freed by task 9:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> __cache_free mm/slab.c:3498 [inline]
> kfree+0xcf/0x230 mm/slab.c:3813
> sctp_transport_destroy_rcu+0x4a/0x60 net/sctp/transport.c:163
> __rcu_reclaim kernel/rcu/rcu.h:236 [inline]
> rcu_do_batch kernel/rcu/tree.c:2576 [inline]
> invoke_rcu_callbacks kernel/rcu/tree.c:2880 [inline]
> __rcu_process_callbacks kernel/rcu/tree.c:2847 [inline]
> rcu_process_callbacks+0xf23/0x2670 kernel/rcu/tree.c:2864
> __do_softirq+0x30c/0xb03 kernel/softirq.c:292
> kobject: 'tx-1' (000000009aaee194): kobject_add_internal: parent: 'queues',
> set: 'queues'
>
> The buggy address belongs to the object at ffff8801c5ff24c0
> which belongs to the cache kmalloc-1024 of size 1024
> The buggy address is located 340 bytes inside of
> 1024-byte region [ffff8801c5ff24c0, ffff8801c5ff28c0)
> The buggy address belongs to the page:
> page:ffffea000717fc80 count:1 mapcount:0 mapping:ffff8801da800ac0 index:0x0
> compound_mapcount: 0
> flags: 0x2fffc0000008100(slab|head)
> raw: 02fffc0000008100 ffffea00070ed808 ffffea00071b2488 ffff8801da800ac0
> raw: 0000000000000000 ffff8801c5ff2040 0000000100000007 0000000000000000
> kobject: 'tx-1' (000000009aaee194): kobject_uevent_env
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801c5ff2500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801c5ff2580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ffff8801c5ff2600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff8801c5ff2680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801c5ff2700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_select_transport
@ 2018-10-27 7:33 ` Xin Long
0 siblings, 0 replies; 30+ messages in thread
From: Xin Long @ 2018-10-27 7:33 UTC (permalink / raw)
To: syzbot+56a40ceee5fb35932f4d
Cc: davem, LKML, linux-sctp, Marcelo Ricardo Leitner, network dev,
Neil Horman, syzkaller-bugs, Vlad Yasevich
On Tue, Oct 23, 2018 at 7:14 PM syzbot
<syzbot+56a40ceee5fb35932f4d@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 23469de647c4 Merge git://git.kernel.org/pub/scm/linux/kern..
> git tree: net
> console output: https://syzkaller.appspot.com/x/log.txt?x\x13580ce5400000
> kernel config: https://syzkaller.appspot.com/x/.config?x³f55cb3dfcc6c33
> dashboard link: https://syzkaller.appspot.com/bug?extidVa40ceee5fb35932f4d
> compiler: gcc (GCC) 8.0.1 20180413 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+56a40ceee5fb35932f4d@syzkaller.appspotmail.com
>
> =================================
> BUG: KASAN: use-after-free in sctp_outq_select_transport+0x77e/0x9a0
> net/sctp/outqueue.c:840
> Read of size 4 at addr ffff8801c5ff2614 by task syz-executor5/8275
>
> CPU: 0 PID: 8275 Comm: syz-executor5 Not tainted 4.19.0-rc8+ #152
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> <IRQ>
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x1c4/0x2b6 lib/dump_stack.c:113
> print_address_description.cold.8+0x9/0x1ff mm/kasan/report.c:256
> kasan_report_error mm/kasan/report.c:354 [inline]
> kasan_report.cold.9+0x242/0x309 mm/kasan/report.c:412
> __asan_report_load4_noabort+0x14/0x20 mm/kasan/report.c:432
> sctp_outq_select_transport+0x77e/0x9a0 net/sctp/outqueue.c:840
I think we need a fix like:
@@ -586,6 +586,10 @@ void sctp_assoc_rm_peer(struct sctp_association *asoc,
sctp_transport_hold(active);
}
+ list_for_each_entry(ch, &asoc->outqueue.out_chunk_list, list)
+ if (ch->transport = transport)
+ ch->transport = NULL;
+
asoc->peer.transport_count--;
sctp_transport_free(peer);
> sctp_outq_flush_data net/sctp/outqueue.c:1100 [inline]
> sctp_outq_flush+0x14f7/0x34f0 net/sctp/outqueue.c:1209
> sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1820 [inline]
> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> sctp_do_sm+0x608/0x7190 net/sctp/sm_sideeffect.c:1191
> sctp_assoc_bh_rcv+0x346/0x670 net/sctp/associola.c:1067
> sctp_inq_push+0x280/0x370 net/sctp/inqueue.c:95
> sctp_rcv+0x2d93/0x3c00 net/sctp/input.c:268
> sctp6_rcv+0x15/0x30 net/sctp/ipv6.c:1061
> ip6_input_finish+0x3fc/0x1aa0 net/ipv6/ip6_input.c:383
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ip6_input+0xe9/0x600 net/ipv6/ip6_input.c:426
> dst_input include/net/dst.h:450 [inline]
> ip6_rcv_finish+0x17a/0x330 net/ipv6/ip6_input.c:76
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ipv6_rcv+0x120/0x640 net/ipv6/ip6_input.c:271
> __netif_receive_skb_one_core+0x14d/0x200 net/core/dev.c:4913
> __netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5023
> process_backlog+0x218/0x6f0 net/core/dev.c:5829
> napi_poll net/core/dev.c:6249 [inline]
> net_rx_action+0x7c5/0x1950 net/core/dev.c:6315
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> IPv6: ADDRCONF(NETDEV_CHANGE): vcan0: link becomes ready
> __do_softirq+0x30c/0xb03 kernel/softirq.c:292
> do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1047
> </IRQ>
> do_softirq.part.13+0x126/0x160 kernel/softirq.c:336
> do_softirq kernel/softirq.c:328 [inline]
> __local_bh_enable_ip+0x21d/0x260 kernel/softirq.c:189
> local_bh_enable include/linux/bottom_half.h:32 [inline]
> rcu_read_unlock_bh include/linux/rcupdate.h:723 [inline]
> ip6_finish_output2+0xce4/0x27a0 net/ipv6/ip6_output.c:121
> ip6_finish_output+0x58c/0xc60 net/ipv6/ip6_output.c:154
> NF_HOOK_COND include/linux/netfilter.h:278 [inline]
> ip6_output+0x232/0x9d0 net/ipv6/ip6_output.c:171
> dst_output include/net/dst.h:444 [inline]
> NF_HOOK include/linux/netfilter.h:289 [inline]
> ip6_xmit+0xf69/0x2420 net/ipv6/ip6_output.c:275
> sctp_v6_xmit+0x3b2/0x790 net/sctp/ipv6.c:230
> sctp_packet_transmit+0x298e/0x3db0 net/sctp/output.c:656
> sctp_packet_singleton net/sctp/outqueue.c:791 [inline]
> sctp_outq_flush_ctrl.constprop.11+0x7a9/0xe50 net/sctp/outqueue.c:922
> sctp_outq_flush+0x310/0x34f0 net/sctp/outqueue.c:1204
> sctp_outq_uncork+0x6a/0x80 net/sctp/outqueue.c:776
> kobject: 'rfkill9' (0000000067be229d): fill_kobj_path: path
> = '/devices/virtual/mac80211_hwsim/hwsim7/ieee80211/phy7/rfkill9'
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1349 [inline]
> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> sctp_do_sm+0x4f25/0x7190 net/sctp/sm_sideeffect.c:1191
> ieee80211 phy7: Selected rate control algorithm 'minstrel_ht'
> kobject: 'net' (00000000cdd117dc): kobject_add_internal: parent: 'hwsim7',
> set: '(null)'
> sctp_endpoint_bh_rcv+0x465/0x960 net/sctp/endpointola.c:456
> kobject: 'wlan0' (00000000c9d333fc): kobject_add_internal: parent: 'net',
> set: 'devices'
> sctp_inq_push+0x280/0x370 net/sctp/inqueue.c:95
> sctp_backlog_rcv+0x1a8/0xd50 net/sctp/input.c:351
> kobject: 'wlan0' (00000000c9d333fc): kobject_uevent_env
> kobject: 'wlan0' (00000000c9d333fc): fill_kobj_path: path
> = '/devices/virtual/mac80211_hwsim/hwsim7/net/wlan0'
> sk_backlog_rcv include/net/sock.h:931 [inline]
> __release_sock+0x12f/0x3a0 net/core/sock.c:2336
> kobject: 'queues' (00000000c5d009e9): kobject_add_internal:
> parent: 'wlan0', set: '<NULL>'
> release_sock+0xad/0x2c0 net/core/sock.c:2849
> sock_setsockopt+0x60d/0x2280 net/core/sock.c:1054
> kobject: 'queues' (00000000c5d009e9): kobject_uevent_env
> kobject: 'queues' (00000000c5d009e9): kobject_uevent_env: filter function
> caused the event to drop!
> __sys_setsockopt+0x304/0x3c0 net/socket.c:1898
> kobject: 'rx-0' (000000007736ba36): kobject_add_internal: parent: 'queues',
> set: 'queues'
> __do_sys_setsockopt net/socket.c:1913 [inline]
> __se_sys_setsockopt net/socket.c:1910 [inline]
> __x64_sys_setsockopt+0xbe/0x150 net/socket.c:1910
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> kobject: 'rx-0' (000000007736ba36): kobject_uevent_env
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> kobject: 'rx-0' (000000007736ba36): fill_kobj_path: path
> = '/devices/virtual/mac80211_hwsim/hwsim7/net/wlan0/queues/rx-0'
> RIP: 0033:0x457569
> Code: fd b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 cb b3 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007f0613beec78 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
> RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000457569
> RDX: 000000000000001a RSI: 0000000000000001 RDI: 0000000000000003
> RBP: 000000000072c040 R08: 0000000000000010 R09: 0000000000000000
> R10: 00000000200000c0 R11: 0000000000000246 R12: 00007f0613bef6d4
> R13: 00000000004c3b61 R14: 00000000004d5c88 R15: 00000000ffffffff
>
> Allocated by task 8261:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> kobject: 'tx-0' (000000008f0eae4c): kobject_add_internal: parent: 'queues',
> set: 'queues'
> set_track mm/kasan/kasan.c:460 [inline]
> kasan_kmalloc+0xc7/0xe0 mm/kasan/kasan.c:553
> kmem_cache_alloc_trace+0x152/0x750 mm/slab.c:3620
> kmalloc include/linux/slab.h:513 [inline]
> kzalloc include/linux/slab.h:707 [inline]
> sctp_transport_new+0x10a/0x880 net/sctp/transport.c:111
> sctp_assoc_add_peer+0x2de/0x10d0 net/sctp/associola.c:630
> sctp_process_param net/sctp/sm_make_chunk.c:2540 [inline]
> sctp_process_init+0xfc0/0x29e0 net/sctp/sm_make_chunk.c:2356
> sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> sctp_do_sm+0x13b9/0x7190 net/sctp/sm_sideeffect.c:1191
> sctp_assoc_bh_rcv+0x346/0x670 net/sctp/associola.c:1067
> sctp_inq_push+0x280/0x370 net/sctp/inqueue.c:95
> sctp_backlog_rcv+0x1a8/0xd50 net/sctp/input.c:351
> sk_backlog_rcv include/net/sock.h:931 [inline]
> __release_sock+0x12f/0x3a0 net/core/sock.c:2336
> kobject: 'tx-0' (000000008f0eae4c): kobject_uevent_env
> release_sock+0xad/0x2c0 net/core/sock.c:2849
> sctp_wait_for_connect+0x391/0x640 net/sctp/socket.c:8667
> sctp_sendmsg_to_asoc+0x1d0f/0x2230 net/sctp/socket.c:1985
> sctp_sendmsg+0x13c2/0x1da0 net/sctp/socket.c:2131
> inet_sendmsg+0x1a1/0x690 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg+0xd5/0x120 net/socket.c:631
> __sys_sendto+0x3d7/0x670 net/socket.c:1788
> __do_sys_sendto net/socket.c:1800 [inline]
> __se_sys_sendto net/socket.c:1796 [inline]
> __x64_sys_sendto+0xe1/0x1a0 net/socket.c:1796
> do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> kobject: 'tx-0' (000000008f0eae4c): fill_kobj_path: path
> = '/devices/virtual/mac80211_hwsim/hwsim7/net/wlan0/queues/tx-0'
>
> Freed by task 9:
> save_stack+0x43/0xd0 mm/kasan/kasan.c:448
> set_track mm/kasan/kasan.c:460 [inline]
> __kasan_slab_free+0x102/0x150 mm/kasan/kasan.c:521
> kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
> __cache_free mm/slab.c:3498 [inline]
> kfree+0xcf/0x230 mm/slab.c:3813
> sctp_transport_destroy_rcu+0x4a/0x60 net/sctp/transport.c:163
> __rcu_reclaim kernel/rcu/rcu.h:236 [inline]
> rcu_do_batch kernel/rcu/tree.c:2576 [inline]
> invoke_rcu_callbacks kernel/rcu/tree.c:2880 [inline]
> __rcu_process_callbacks kernel/rcu/tree.c:2847 [inline]
> rcu_process_callbacks+0xf23/0x2670 kernel/rcu/tree.c:2864
> __do_softirq+0x30c/0xb03 kernel/softirq.c:292
> kobject: 'tx-1' (000000009aaee194): kobject_add_internal: parent: 'queues',
> set: 'queues'
>
> The buggy address belongs to the object at ffff8801c5ff24c0
> which belongs to the cache kmalloc-1024 of size 1024
> The buggy address is located 340 bytes inside of
> 1024-byte region [ffff8801c5ff24c0, ffff8801c5ff28c0)
> The buggy address belongs to the page:
> page:ffffea000717fc80 count:1 mapcount:0 mapping:ffff8801da800ac0 index:0x0
> compound_mapcount: 0
> flags: 0x2fffc0000008100(slab|head)
> raw: 02fffc0000008100 ffffea00070ed808 ffffea00071b2488 ffff8801da800ac0
> raw: 0000000000000000 ffff8801c5ff2040 0000000100000007 0000000000000000
> kobject: 'tx-1' (000000009aaee194): kobject_uevent_env
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff8801c5ff2500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801c5ff2580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> > ffff8801c5ff2600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ^
> ffff8801c5ff2680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff8801c5ff2700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> =================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
^ permalink raw reply [flat|nested] 30+ messages in thread
* KASAN: use-after-free Read in sctp_outq_tail
2018-10-23 10:13 ` syzbot
@ 2019-02-12 19:04 ` syzbot
-1 siblings, 0 replies; 30+ messages in thread
From: syzbot @ 2019-02-12 19:04 UTC (permalink / raw)
To: davem, linux-kernel, linux-sctp, marcelo.leitner, netdev,
nhorman, syzkaller-bugs, vyasevich
Hello,
syzbot found the following crash on:
HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14140124c00000
kernel config: https://syzkaller.appspot.com/x/.config?x=c8a112d3b0d6719b
dashboard link: https://syzkaller.appspot.com/bug?extid=7823fa3f3e2d69341ea8
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
==================================================================
BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
[inline]
BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
net/sctp/outqueue.c:313
Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
#32
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
list_add_tail include/linux/list.h:93 [inline]
sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x806/0x930 net/socket.c:2136
__sys_sendmsg+0x105/0x1d0 net/socket.c:2174
__do_sys_sendmsg net/socket.c:2183 [inline]
__se_sys_sendmsg net/socket.c:2181 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457e39
Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fa9b8630c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e39
RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000003
RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa9b86316d4
R13: 00000000004c4e2b R14: 00000000004d8ab8 R15: 00000000ffffffff
Allocated by task 30745:
save_stack+0x45/0xd0 mm/kasan/common.c:75
set_track mm/kasan/common.c:87 [inline]
__kasan_kmalloc mm/kasan/common.c:498 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:471
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:506
kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3615
kmalloc include/linux/slab.h:548 [inline]
kzalloc include/linux/slab.h:743 [inline]
sctp_stream_init_ext+0x51/0x110 net/sctp/stream.c:172
sctp_sendmsg_to_asoc+0x1273/0x17b0 net/sctp/socket.c:1896
sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x806/0x930 net/socket.c:2136
__sys_sendmsg+0x105/0x1d0 net/socket.c:2174
__do_sys_sendmsg net/socket.c:2183 [inline]
__se_sys_sendmsg net/socket.c:2181 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 30745:
save_stack+0x45/0xd0 mm/kasan/common.c:75
set_track mm/kasan/common.c:87 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:460
kasan_slab_free+0xe/0x10 mm/kasan/common.c:468
__cache_free mm/slab.c:3491 [inline]
kfree+0xcf/0x230 mm/slab.c:3816
sctp_stream_outq_migrate+0x3e6/0x540 net/sctp/stream.c:88
sctp_stream_init+0xbc/0x410 net/sctp/stream.c:139
sctp_process_init+0x21c3/0x2b20 net/sctp/sm_make_chunk.c:2466
sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x3145/0x5380 net/sctp/sm_sideeffect.c:1191
sctp_assoc_bh_rcv+0x343/0x660 net/sctp/associola.c:1074
sctp_inq_push+0x1ea/0x290 net/sctp/inqueue.c:95
sctp_backlog_rcv+0x196/0xbe0 net/sctp/input.c:354
sk_backlog_rcv include/net/sock.h:937 [inline]
__release_sock+0x12e/0x3a0 net/core/sock.c:2379
release_sock+0x59/0x1c0 net/core/sock.c:2895
sctp_wait_for_connect+0x316/0x540 net/sctp/socket.c:8998
sctp_sendmsg_to_asoc+0x13e3/0x17b0 net/sctp/socket.c:1967
sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x806/0x930 net/socket.c:2136
__sys_sendmsg+0x105/0x1d0 net/socket.c:2174
__do_sys_sendmsg net/socket.c:2183 [inline]
__se_sys_sendmsg net/socket.c:2181 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff88807b19a780
which belongs to the cache kmalloc-96 of size 96
The buggy address is located 56 bytes inside of
96-byte region [ffff88807b19a780, ffff88807b19a7e0)
The buggy address belongs to the page:
page:ffffea0001ec6680 count:1 mapcount:0 mapping:ffff88812c3f04c0
index:0xffff88807b19a800
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea000262acc8 ffffea0001448348 ffff88812c3f04c0
raw: ffff88807b19a800 ffff88807b19a000 000000010000001d 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88807b19a680: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff88807b19a700: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ffff88807b19a780: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
^
ffff88807b19a800: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff88807b19a880: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply [flat|nested] 30+ messages in thread
* KASAN: use-after-free Read in sctp_outq_tail
@ 2019-02-12 19:04 ` syzbot
0 siblings, 0 replies; 30+ messages in thread
From: syzbot @ 2019-02-12 19:04 UTC (permalink / raw)
To: davem, linux-kernel, linux-sctp, marcelo.leitner, netdev,
nhorman, syzkaller-bugs, vyasevich
Hello,
syzbot found the following crash on:
HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x\x14140124c00000
kernel config: https://syzkaller.appspot.com/x/.config?xÈa112d3b0d6719b
dashboard link: https://syzkaller.appspot.com/bug?extidx23fa3f3e2d69341ea8
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
=================================
BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
[inline]
BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
net/sctp/outqueue.c:313
Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
#32
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
__asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
list_add_tail include/linux/list.h:93 [inline]
sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x806/0x930 net/socket.c:2136
__sys_sendmsg+0x105/0x1d0 net/socket.c:2174
__do_sys_sendmsg net/socket.c:2183 [inline]
__se_sys_sendmsg net/socket.c:2181 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457e39
Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fa9b8630c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e39
RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000003
RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa9b86316d4
R13: 00000000004c4e2b R14: 00000000004d8ab8 R15: 00000000ffffffff
Allocated by task 30745:
save_stack+0x45/0xd0 mm/kasan/common.c:75
set_track mm/kasan/common.c:87 [inline]
__kasan_kmalloc mm/kasan/common.c:498 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:471
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:506
kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3615
kmalloc include/linux/slab.h:548 [inline]
kzalloc include/linux/slab.h:743 [inline]
sctp_stream_init_ext+0x51/0x110 net/sctp/stream.c:172
sctp_sendmsg_to_asoc+0x1273/0x17b0 net/sctp/socket.c:1896
sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x806/0x930 net/socket.c:2136
__sys_sendmsg+0x105/0x1d0 net/socket.c:2174
__do_sys_sendmsg net/socket.c:2183 [inline]
__se_sys_sendmsg net/socket.c:2181 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 30745:
save_stack+0x45/0xd0 mm/kasan/common.c:75
set_track mm/kasan/common.c:87 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:460
kasan_slab_free+0xe/0x10 mm/kasan/common.c:468
__cache_free mm/slab.c:3491 [inline]
kfree+0xcf/0x230 mm/slab.c:3816
sctp_stream_outq_migrate+0x3e6/0x540 net/sctp/stream.c:88
sctp_stream_init+0xbc/0x410 net/sctp/stream.c:139
sctp_process_init+0x21c3/0x2b20 net/sctp/sm_make_chunk.c:2466
sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
sctp_do_sm+0x3145/0x5380 net/sctp/sm_sideeffect.c:1191
sctp_assoc_bh_rcv+0x343/0x660 net/sctp/associola.c:1074
sctp_inq_push+0x1ea/0x290 net/sctp/inqueue.c:95
sctp_backlog_rcv+0x196/0xbe0 net/sctp/input.c:354
sk_backlog_rcv include/net/sock.h:937 [inline]
__release_sock+0x12e/0x3a0 net/core/sock.c:2379
release_sock+0x59/0x1c0 net/core/sock.c:2895
sctp_wait_for_connect+0x316/0x540 net/sctp/socket.c:8998
sctp_sendmsg_to_asoc+0x13e3/0x17b0 net/sctp/socket.c:1967
sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x806/0x930 net/socket.c:2136
__sys_sendmsg+0x105/0x1d0 net/socket.c:2174
__do_sys_sendmsg net/socket.c:2183 [inline]
__se_sys_sendmsg net/socket.c:2181 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff88807b19a780
which belongs to the cache kmalloc-96 of size 96
The buggy address is located 56 bytes inside of
96-byte region [ffff88807b19a780, ffff88807b19a7e0)
The buggy address belongs to the page:
page:ffffea0001ec6680 count:1 mapcount:0 mapping:ffff88812c3f04c0
index:0xffff88807b19a800
flags: 0x1fffc0000000200(slab)
raw: 01fffc0000000200 ffffea000262acc8 ffffea0001448348 ffff88812c3f04c0
raw: ffff88807b19a800 ffff88807b19a000 000000010000001d 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff88807b19a680: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff88807b19a700: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ffff88807b19a780: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
^
ffff88807b19a800: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
ffff88807b19a880: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
=================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
2019-02-12 19:04 ` syzbot
@ 2019-02-12 19:19 ` Marcelo Ricardo Leitner
-1 siblings, 0 replies; 30+ messages in thread
From: Marcelo Ricardo Leitner @ 2019-02-12 19:19 UTC (permalink / raw)
To: syzbot
Cc: davem, linux-kernel, linux-sctp, netdev, nhorman, syzkaller-bugs,
vyasevich
On Tue, Feb 12, 2019 at 11:04:27AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> git tree: linux-next
I can't find this commit. How can I know for sure which commits are in?
Recent patches are involved with this code, but not sure what was
included on the test.
Marcelo
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
@ 2019-02-12 19:19 ` Marcelo Ricardo Leitner
0 siblings, 0 replies; 30+ messages in thread
From: Marcelo Ricardo Leitner @ 2019-02-12 19:19 UTC (permalink / raw)
To: syzbot
Cc: davem, linux-kernel, linux-sctp, netdev, nhorman, syzkaller-bugs,
vyasevich
On Tue, Feb 12, 2019 at 11:04:27AM -0800, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> git tree: linux-next
I can't find this commit. How can I know for sure which commits are in?
Recent patches are involved with this code, but not sure what was
included on the test.
Marcelo
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
2019-02-12 19:04 ` syzbot
@ 2019-02-13 4:35 ` Xin Long
-1 siblings, 0 replies; 30+ messages in thread
From: Xin Long @ 2019-02-13 4:35 UTC (permalink / raw)
To: syzbot
Cc: davem, LKML, linux-sctp, Marcelo Ricardo Leitner, network dev,
Neil Horman, syzkaller-bugs, Vlad Yasevich
On Wed, Feb 13, 2019 at 4:00 AM syzbot
<syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=14140124c00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=c8a112d3b0d6719b
> dashboard link: https://syzkaller.appspot.com/bug?extid=7823fa3f3e2d69341ea8
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
>
> ==================================================================
> BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> [inline]
> BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> net/sctp/outqueue.c:313
> Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
>
> CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> #32
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> list_add_tail include/linux/list.h:93 [inline]
> sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
> sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg+0xdd/0x130 net/socket.c:631
> ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> __do_sys_sendmsg net/socket.c:2183 [inline]
> __se_sys_sendmsg net/socket.c:2181 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x457e39
> Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fa9b8630c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e39
> RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000003
> RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa9b86316d4
> R13: 00000000004c4e2b R14: 00000000004d8ab8 R15: 00000000ffffffff
>
> Allocated by task 30745:
> save_stack+0x45/0xd0 mm/kasan/common.c:75
> set_track mm/kasan/common.c:87 [inline]
> __kasan_kmalloc mm/kasan/common.c:498 [inline]
> __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:471
> kasan_kmalloc+0x9/0x10 mm/kasan/common.c:506
> kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3615
> kmalloc include/linux/slab.h:548 [inline]
> kzalloc include/linux/slab.h:743 [inline]
> sctp_stream_init_ext+0x51/0x110 net/sctp/stream.c:172
> sctp_sendmsg_to_asoc+0x1273/0x17b0 net/sctp/socket.c:1896
> sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg+0xdd/0x130 net/socket.c:631
> ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> __do_sys_sendmsg net/socket.c:2183 [inline]
> __se_sys_sendmsg net/socket.c:2181 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 30745:
> save_stack+0x45/0xd0 mm/kasan/common.c:75
> set_track mm/kasan/common.c:87 [inline]
> __kasan_slab_free+0x102/0x150 mm/kasan/common.c:460
> kasan_slab_free+0xe/0x10 mm/kasan/common.c:468
> __cache_free mm/slab.c:3491 [inline]
> kfree+0xcf/0x230 mm/slab.c:3816
> sctp_stream_outq_migrate+0x3e6/0x540 net/sctp/stream.c:88
> sctp_stream_init+0xbc/0x410 net/sctp/stream.c:139
> sctp_process_init+0x21c3/0x2b20 net/sctp/sm_make_chunk.c:2466
> sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> sctp_do_sm+0x3145/0x5380 net/sctp/sm_sideeffect.c:1191
> sctp_assoc_bh_rcv+0x343/0x660 net/sctp/associola.c:1074
> sctp_inq_push+0x1ea/0x290 net/sctp/inqueue.c:95
> sctp_backlog_rcv+0x196/0xbe0 net/sctp/input.c:354
> sk_backlog_rcv include/net/sock.h:937 [inline]
> __release_sock+0x12e/0x3a0 net/core/sock.c:2379
> release_sock+0x59/0x1c0 net/core/sock.c:2895
> sctp_wait_for_connect+0x316/0x540 net/sctp/socket.c:8998
> sctp_sendmsg_to_asoc+0x13e3/0x17b0 net/sctp/socket.c:1967
> sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg+0xdd/0x130 net/socket.c:631
> ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> __do_sys_sendmsg net/socket.c:2183 [inline]
> __se_sys_sendmsg net/socket.c:2181 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff88807b19a780
> which belongs to the cache kmalloc-96 of size 96
> The buggy address is located 56 bytes inside of
> 96-byte region [ffff88807b19a780, ffff88807b19a7e0)
> The buggy address belongs to the page:
> page:ffffea0001ec6680 count:1 mapcount:0 mapping:ffff88812c3f04c0
> index:0xffff88807b19a800
> flags: 0x1fffc0000000200(slab)
> raw: 01fffc0000000200 ffffea000262acc8 ffffea0001448348 ffff88812c3f04c0
> raw: ffff88807b19a800 ffff88807b19a000 000000010000001d 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff88807b19a680: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ffff88807b19a700: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ffff88807b19a780: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ^
> ffff88807b19a800: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ffff88807b19a880: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ==================================================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
@ 2019-02-13 4:35 ` Xin Long
0 siblings, 0 replies; 30+ messages in thread
From: Xin Long @ 2019-02-13 4:35 UTC (permalink / raw)
To: syzbot
Cc: davem, LKML, linux-sctp, Marcelo Ricardo Leitner, network dev,
Neil Horman, syzkaller-bugs, Vlad Yasevich
On Wed, Feb 13, 2019 at 4:00 AM syzbot
<syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x\x14140124c00000
> kernel config: https://syzkaller.appspot.com/x/.config?xÈa112d3b0d6719b
> dashboard link: https://syzkaller.appspot.com/bug?extidx23fa3f3e2d69341ea8
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
>
> Unfortunately, I don't have any reproducer for this crash yet.
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
>
> =================================
> BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> [inline]
> BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> net/sctp/outqueue.c:313
> Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
>
> CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> #32
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> list_add_tail include/linux/list.h:93 [inline]
> sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
> sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg+0xdd/0x130 net/socket.c:631
> ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> __do_sys_sendmsg net/socket.c:2183 [inline]
> __se_sys_sendmsg net/socket.c:2181 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
> RIP: 0033:0x457e39
> Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> RSP: 002b:00007fa9b8630c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e39
> RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000003
> RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa9b86316d4
> R13: 00000000004c4e2b R14: 00000000004d8ab8 R15: 00000000ffffffff
>
> Allocated by task 30745:
> save_stack+0x45/0xd0 mm/kasan/common.c:75
> set_track mm/kasan/common.c:87 [inline]
> __kasan_kmalloc mm/kasan/common.c:498 [inline]
> __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:471
> kasan_kmalloc+0x9/0x10 mm/kasan/common.c:506
> kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3615
> kmalloc include/linux/slab.h:548 [inline]
> kzalloc include/linux/slab.h:743 [inline]
> sctp_stream_init_ext+0x51/0x110 net/sctp/stream.c:172
> sctp_sendmsg_to_asoc+0x1273/0x17b0 net/sctp/socket.c:1896
> sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg+0xdd/0x130 net/socket.c:631
> ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> __do_sys_sendmsg net/socket.c:2183 [inline]
> __se_sys_sendmsg net/socket.c:2181 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> Freed by task 30745:
> save_stack+0x45/0xd0 mm/kasan/common.c:75
> set_track mm/kasan/common.c:87 [inline]
> __kasan_slab_free+0x102/0x150 mm/kasan/common.c:460
> kasan_slab_free+0xe/0x10 mm/kasan/common.c:468
> __cache_free mm/slab.c:3491 [inline]
> kfree+0xcf/0x230 mm/slab.c:3816
> sctp_stream_outq_migrate+0x3e6/0x540 net/sctp/stream.c:88
> sctp_stream_init+0xbc/0x410 net/sctp/stream.c:139
> sctp_process_init+0x21c3/0x2b20 net/sctp/sm_make_chunk.c:2466
> sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> sctp_do_sm+0x3145/0x5380 net/sctp/sm_sideeffect.c:1191
> sctp_assoc_bh_rcv+0x343/0x660 net/sctp/associola.c:1074
> sctp_inq_push+0x1ea/0x290 net/sctp/inqueue.c:95
> sctp_backlog_rcv+0x196/0xbe0 net/sctp/input.c:354
> sk_backlog_rcv include/net/sock.h:937 [inline]
> __release_sock+0x12e/0x3a0 net/core/sock.c:2379
> release_sock+0x59/0x1c0 net/core/sock.c:2895
> sctp_wait_for_connect+0x316/0x540 net/sctp/socket.c:8998
> sctp_sendmsg_to_asoc+0x13e3/0x17b0 net/sctp/socket.c:1967
> sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> sock_sendmsg_nosec net/socket.c:621 [inline]
> sock_sendmsg+0xdd/0x130 net/socket.c:631
> ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> __do_sys_sendmsg net/socket.c:2183 [inline]
> __se_sys_sendmsg net/socket.c:2181 [inline]
> __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> entry_SYSCALL_64_after_hwframe+0x49/0xbe
>
> The buggy address belongs to the object at ffff88807b19a780
> which belongs to the cache kmalloc-96 of size 96
> The buggy address is located 56 bytes inside of
> 96-byte region [ffff88807b19a780, ffff88807b19a7e0)
> The buggy address belongs to the page:
> page:ffffea0001ec6680 count:1 mapcount:0 mapping:ffff88812c3f04c0
> index:0xffff88807b19a800
> flags: 0x1fffc0000000200(slab)
> raw: 01fffc0000000200 ffffea000262acc8 ffffea0001448348 ffff88812c3f04c0
> raw: ffff88807b19a800 ffff88807b19a000 000000010000001d 0000000000000000
> page dumped because: kasan: bad access detected
>
> Memory state around the buggy address:
> ffff88807b19a680: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ffff88807b19a700: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ffff88807b19a780: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ^
> ffff88807b19a800: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> ffff88807b19a880: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> =================================
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> syzbot.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
2019-02-12 19:19 ` Marcelo Ricardo Leitner
@ 2019-02-13 8:27 ` Dmitry Vyukov
-1 siblings, 0 replies; 30+ messages in thread
From: Dmitry Vyukov @ 2019-02-13 8:27 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: syzbot, David Miller, LKML, linux-sctp, netdev, Neil Horman,
syzkaller-bugs, Vladislav Yasevich
On Tue, Feb 12, 2019 at 8:19 PM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> On Tue, Feb 12, 2019 at 11:04:27AM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > git tree: linux-next
>
> I can't find this commit. How can I know for sure which commits are in?
> Recent patches are involved with this code, but not sure what was
> included on the test.
Hi Marcelo,
linux-next is weird. Not sure why a so recent commit is not in
linux-next, maybe one needs to fetch tags or something. Fetching
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git
helped me to get this commit:
$ git show d4104460aec1
commit d4104460aec152e23cf80ab1f950f414bf94f4ea (HEAD, tag: next-20190211)
Author: Stephen Rothwell
Date: Mon Feb 11 18:37:26 2019 +1100
Add linux-next specific files for 20190211
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
@ 2019-02-13 8:27 ` Dmitry Vyukov
0 siblings, 0 replies; 30+ messages in thread
From: Dmitry Vyukov @ 2019-02-13 8:27 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: syzbot, David Miller, LKML, linux-sctp, netdev, Neil Horman,
syzkaller-bugs, Vladislav Yasevich
On Tue, Feb 12, 2019 at 8:19 PM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> On Tue, Feb 12, 2019 at 11:04:27AM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > git tree: linux-next
>
> I can't find this commit. How can I know for sure which commits are in?
> Recent patches are involved with this code, but not sure what was
> included on the test.
Hi Marcelo,
linux-next is weird. Not sure why a so recent commit is not in
linux-next, maybe one needs to fetch tags or something. Fetching
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next-history.git
helped me to get this commit:
$ git show d4104460aec1
commit d4104460aec152e23cf80ab1f950f414bf94f4ea (HEAD, tag: next-20190211)
Author: Stephen Rothwell
Date: Mon Feb 11 18:37:26 2019 +1100
Add linux-next specific files for 20190211
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
2019-02-13 4:35 ` Xin Long
@ 2019-02-13 8:29 ` Dmitry Vyukov
-1 siblings, 0 replies; 30+ messages in thread
From: Dmitry Vyukov @ 2019-02-13 8:29 UTC (permalink / raw)
To: Xin Long
Cc: syzbot, davem, LKML, linux-sctp, Marcelo Ricardo Leitner,
network dev, Neil Horman, syzkaller-bugs, Vlad Yasevich
On Wed, Feb 13, 2019 at 5:36 AM Xin Long <lucien.xin@gmail.com> wrote:
>
> On Wed, Feb 13, 2019 at 4:00 AM syzbot
> <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=14140124c00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=c8a112d3b0d6719b
> > dashboard link: https://syzkaller.appspot.com/bug?extid=7823fa3f3e2d69341ea8
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> >
> > Unfortunately, I don't have any reproducer for this crash yet.
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> >
> > ==================================================================
> > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > [inline]
> > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > net/sctp/outqueue.c:313
> > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
Let's mark it then to not return later:
#syz fix:
sctp: set stream ext to NULL after freeing it in sctp_stream_outq_migrate
> > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > #32
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > list_add_tail include/linux/list.h:93 [inline]
> > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
> > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > sock_sendmsg_nosec net/socket.c:621 [inline]
> > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > __do_sys_sendmsg net/socket.c:2183 [inline]
> > __se_sys_sendmsg net/socket.c:2181 [inline]
> > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > RIP: 0033:0x457e39
> > Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> > ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > RSP: 002b:00007fa9b8630c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> > RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e39
> > RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000003
> > RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa9b86316d4
> > R13: 00000000004c4e2b R14: 00000000004d8ab8 R15: 00000000ffffffff
> >
> > Allocated by task 30745:
> > save_stack+0x45/0xd0 mm/kasan/common.c:75
> > set_track mm/kasan/common.c:87 [inline]
> > __kasan_kmalloc mm/kasan/common.c:498 [inline]
> > __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:471
> > kasan_kmalloc+0x9/0x10 mm/kasan/common.c:506
> > kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3615
> > kmalloc include/linux/slab.h:548 [inline]
> > kzalloc include/linux/slab.h:743 [inline]
> > sctp_stream_init_ext+0x51/0x110 net/sctp/stream.c:172
> > sctp_sendmsg_to_asoc+0x1273/0x17b0 net/sctp/socket.c:1896
> > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > sock_sendmsg_nosec net/socket.c:621 [inline]
> > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > __do_sys_sendmsg net/socket.c:2183 [inline]
> > __se_sys_sendmsg net/socket.c:2181 [inline]
> > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > Freed by task 30745:
> > save_stack+0x45/0xd0 mm/kasan/common.c:75
> > set_track mm/kasan/common.c:87 [inline]
> > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:460
> > kasan_slab_free+0xe/0x10 mm/kasan/common.c:468
> > __cache_free mm/slab.c:3491 [inline]
> > kfree+0xcf/0x230 mm/slab.c:3816
> > sctp_stream_outq_migrate+0x3e6/0x540 net/sctp/stream.c:88
> > sctp_stream_init+0xbc/0x410 net/sctp/stream.c:139
> > sctp_process_init+0x21c3/0x2b20 net/sctp/sm_make_chunk.c:2466
> > sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > sctp_do_sm+0x3145/0x5380 net/sctp/sm_sideeffect.c:1191
> > sctp_assoc_bh_rcv+0x343/0x660 net/sctp/associola.c:1074
> > sctp_inq_push+0x1ea/0x290 net/sctp/inqueue.c:95
> > sctp_backlog_rcv+0x196/0xbe0 net/sctp/input.c:354
> > sk_backlog_rcv include/net/sock.h:937 [inline]
> > __release_sock+0x12e/0x3a0 net/core/sock.c:2379
> > release_sock+0x59/0x1c0 net/core/sock.c:2895
> > sctp_wait_for_connect+0x316/0x540 net/sctp/socket.c:8998
> > sctp_sendmsg_to_asoc+0x13e3/0x17b0 net/sctp/socket.c:1967
> > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > sock_sendmsg_nosec net/socket.c:621 [inline]
> > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > __do_sys_sendmsg net/socket.c:2183 [inline]
> > __se_sys_sendmsg net/socket.c:2181 [inline]
> > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > The buggy address belongs to the object at ffff88807b19a780
> > which belongs to the cache kmalloc-96 of size 96
> > The buggy address is located 56 bytes inside of
> > 96-byte region [ffff88807b19a780, ffff88807b19a7e0)
> > The buggy address belongs to the page:
> > page:ffffea0001ec6680 count:1 mapcount:0 mapping:ffff88812c3f04c0
> > index:0xffff88807b19a800
> > flags: 0x1fffc0000000200(slab)
> > raw: 01fffc0000000200 ffffea000262acc8 ffffea0001448348 ffff88812c3f04c0
> > raw: ffff88807b19a800 ffff88807b19a000 000000010000001d 0000000000000000
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> > ffff88807b19a680: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ffff88807b19a700: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > > ffff88807b19a780: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ^
> > ffff88807b19a800: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ffff88807b19a880: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ==================================================================
> >
> >
> > ---
> > This bug is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkaller@googlegroups.com.
> >
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> > syzbot.
>
> --
> 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 syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CADvbK_dndFMxyUZk%3Dk8qEy9%3DPNbLc81F%2B%2B2L0fbdtUdbupq4Xg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
@ 2019-02-13 8:29 ` Dmitry Vyukov
0 siblings, 0 replies; 30+ messages in thread
From: Dmitry Vyukov @ 2019-02-13 8:29 UTC (permalink / raw)
To: Xin Long
Cc: syzbot, davem, LKML, linux-sctp, Marcelo Ricardo Leitner,
network dev, Neil Horman, syzkaller-bugs, Vlad Yasevich
On Wed, Feb 13, 2019 at 5:36 AM Xin Long <lucien.xin@gmail.com> wrote:
>
> On Wed, Feb 13, 2019 at 4:00 AM syzbot
> <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x\x14140124c00000
> > kernel config: https://syzkaller.appspot.com/x/.config?xÈa112d3b0d6719b
> > dashboard link: https://syzkaller.appspot.com/bug?extidx23fa3f3e2d69341ea8
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> >
> > Unfortunately, I don't have any reproducer for this crash yet.
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> >
> > =================================
> > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > [inline]
> > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > net/sctp/outqueue.c:313
> > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
Let's mark it then to not return later:
#syz fix:
sctp: set stream ext to NULL after freeing it in sctp_stream_outq_migrate
> > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > #32
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > list_add_tail include/linux/list.h:93 [inline]
> > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
> > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > sock_sendmsg_nosec net/socket.c:621 [inline]
> > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > __do_sys_sendmsg net/socket.c:2183 [inline]
> > __se_sys_sendmsg net/socket.c:2181 [inline]
> > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > RIP: 0033:0x457e39
> > Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> > ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > RSP: 002b:00007fa9b8630c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> > RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e39
> > RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000003
> > RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa9b86316d4
> > R13: 00000000004c4e2b R14: 00000000004d8ab8 R15: 00000000ffffffff
> >
> > Allocated by task 30745:
> > save_stack+0x45/0xd0 mm/kasan/common.c:75
> > set_track mm/kasan/common.c:87 [inline]
> > __kasan_kmalloc mm/kasan/common.c:498 [inline]
> > __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:471
> > kasan_kmalloc+0x9/0x10 mm/kasan/common.c:506
> > kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3615
> > kmalloc include/linux/slab.h:548 [inline]
> > kzalloc include/linux/slab.h:743 [inline]
> > sctp_stream_init_ext+0x51/0x110 net/sctp/stream.c:172
> > sctp_sendmsg_to_asoc+0x1273/0x17b0 net/sctp/socket.c:1896
> > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > sock_sendmsg_nosec net/socket.c:621 [inline]
> > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > __do_sys_sendmsg net/socket.c:2183 [inline]
> > __se_sys_sendmsg net/socket.c:2181 [inline]
> > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > Freed by task 30745:
> > save_stack+0x45/0xd0 mm/kasan/common.c:75
> > set_track mm/kasan/common.c:87 [inline]
> > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:460
> > kasan_slab_free+0xe/0x10 mm/kasan/common.c:468
> > __cache_free mm/slab.c:3491 [inline]
> > kfree+0xcf/0x230 mm/slab.c:3816
> > sctp_stream_outq_migrate+0x3e6/0x540 net/sctp/stream.c:88
> > sctp_stream_init+0xbc/0x410 net/sctp/stream.c:139
> > sctp_process_init+0x21c3/0x2b20 net/sctp/sm_make_chunk.c:2466
> > sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > sctp_do_sm+0x3145/0x5380 net/sctp/sm_sideeffect.c:1191
> > sctp_assoc_bh_rcv+0x343/0x660 net/sctp/associola.c:1074
> > sctp_inq_push+0x1ea/0x290 net/sctp/inqueue.c:95
> > sctp_backlog_rcv+0x196/0xbe0 net/sctp/input.c:354
> > sk_backlog_rcv include/net/sock.h:937 [inline]
> > __release_sock+0x12e/0x3a0 net/core/sock.c:2379
> > release_sock+0x59/0x1c0 net/core/sock.c:2895
> > sctp_wait_for_connect+0x316/0x540 net/sctp/socket.c:8998
> > sctp_sendmsg_to_asoc+0x13e3/0x17b0 net/sctp/socket.c:1967
> > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > sock_sendmsg_nosec net/socket.c:621 [inline]
> > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > __do_sys_sendmsg net/socket.c:2183 [inline]
> > __se_sys_sendmsg net/socket.c:2181 [inline]
> > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > The buggy address belongs to the object at ffff88807b19a780
> > which belongs to the cache kmalloc-96 of size 96
> > The buggy address is located 56 bytes inside of
> > 96-byte region [ffff88807b19a780, ffff88807b19a7e0)
> > The buggy address belongs to the page:
> > page:ffffea0001ec6680 count:1 mapcount:0 mapping:ffff88812c3f04c0
> > index:0xffff88807b19a800
> > flags: 0x1fffc0000000200(slab)
> > raw: 01fffc0000000200 ffffea000262acc8 ffffea0001448348 ffff88812c3f04c0
> > raw: ffff88807b19a800 ffff88807b19a000 000000010000001d 0000000000000000
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> > ffff88807b19a680: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ffff88807b19a700: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > > ffff88807b19a780: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ^
> > ffff88807b19a800: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ffff88807b19a880: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > =================================
> >
> >
> > ---
> > This bug is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkaller@googlegroups.com.
> >
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> > syzbot.
>
> --
> 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 syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/CADvbK_dndFMxyUZk%3Dk8qEy9%3DPNbLc81F%2B%2B2L0fbdtUdbupq4Xg%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
2019-02-13 4:35 ` Xin Long
@ 2019-02-13 13:51 ` Marcelo Ricardo Leitner
-1 siblings, 0 replies; 30+ messages in thread
From: Marcelo Ricardo Leitner @ 2019-02-13 13:51 UTC (permalink / raw)
To: Xin Long
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
On Wed, Feb 13, 2019 at 12:35:56PM +0800, Xin Long wrote:
> On Wed, Feb 13, 2019 at 4:00 AM syzbot
> <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x=14140124c00000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=c8a112d3b0d6719b
> > dashboard link: https://syzkaller.appspot.com/bug?extid=7823fa3f3e2d69341ea8
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> >
> > Unfortunately, I don't have any reproducer for this crash yet.
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> >
> > ==================================================================
> > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > [inline]
> > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > net/sctp/outqueue.c:313
> > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
I don't think so. Seems it will switch from use-after-free to NULL deref
instead with that patch.
> > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > #32
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > list_add_tail include/linux/list.h:93 [inline]
> > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
sctp_sendmsg_to_asoc()
...
if (sinfo->sinfo_stream >= asoc->stream.outcnt) {
err = -EINVAL;
goto err;
}
if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
...
It should have aborted even if an old ->ext was still there because
outcnt is correctly updated. So somehow outcnt was wrong here.
sctp_stream_init()
...
/* Filter out chunks queued on streams that won't exist anymore */
sched->unsched_all(stream);
sctp_stream_outq_migrate(stream, NULL, outcnt); <--- [A]
sched->sched_all(stream);
ret = sctp_stream_alloc_out(stream, outcnt, gfp); <--- [B]
if (ret)
goto out;
stream->outcnt = outcnt; <--- [C]
...
We have a problem here because [A] is freeing ->ext, but [B] can fail (ENOMEM),
which would lead it to not update outcnt in [C] even after the
changes already performed in [A].
It should handle the freeing of ->ext in sctp_stream_alloc_out()
instead, or allocate the flexarray earlier (so it can bail out before
freeing stuff).
> > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > sock_sendmsg_nosec net/socket.c:621 [inline]
> > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > __do_sys_sendmsg net/socket.c:2183 [inline]
> > __se_sys_sendmsg net/socket.c:2181 [inline]
> > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > RIP: 0033:0x457e39
> > Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> > ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > RSP: 002b:00007fa9b8630c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> > RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e39
> > RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000003
> > RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa9b86316d4
> > R13: 00000000004c4e2b R14: 00000000004d8ab8 R15: 00000000ffffffff
> >
> > Allocated by task 30745:
> > save_stack+0x45/0xd0 mm/kasan/common.c:75
> > set_track mm/kasan/common.c:87 [inline]
> > __kasan_kmalloc mm/kasan/common.c:498 [inline]
> > __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:471
> > kasan_kmalloc+0x9/0x10 mm/kasan/common.c:506
> > kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3615
> > kmalloc include/linux/slab.h:548 [inline]
> > kzalloc include/linux/slab.h:743 [inline]
> > sctp_stream_init_ext+0x51/0x110 net/sctp/stream.c:172
> > sctp_sendmsg_to_asoc+0x1273/0x17b0 net/sctp/socket.c:1896
> > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > sock_sendmsg_nosec net/socket.c:621 [inline]
> > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > __do_sys_sendmsg net/socket.c:2183 [inline]
> > __se_sys_sendmsg net/socket.c:2181 [inline]
> > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > Freed by task 30745:
> > save_stack+0x45/0xd0 mm/kasan/common.c:75
> > set_track mm/kasan/common.c:87 [inline]
> > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:460
> > kasan_slab_free+0xe/0x10 mm/kasan/common.c:468
> > __cache_free mm/slab.c:3491 [inline]
> > kfree+0xcf/0x230 mm/slab.c:3816
> > sctp_stream_outq_migrate+0x3e6/0x540 net/sctp/stream.c:88
> > sctp_stream_init+0xbc/0x410 net/sctp/stream.c:139
> > sctp_process_init+0x21c3/0x2b20 net/sctp/sm_make_chunk.c:2466
> > sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > sctp_do_sm+0x3145/0x5380 net/sctp/sm_sideeffect.c:1191
> > sctp_assoc_bh_rcv+0x343/0x660 net/sctp/associola.c:1074
> > sctp_inq_push+0x1ea/0x290 net/sctp/inqueue.c:95
> > sctp_backlog_rcv+0x196/0xbe0 net/sctp/input.c:354
> > sk_backlog_rcv include/net/sock.h:937 [inline]
> > __release_sock+0x12e/0x3a0 net/core/sock.c:2379
> > release_sock+0x59/0x1c0 net/core/sock.c:2895
> > sctp_wait_for_connect+0x316/0x540 net/sctp/socket.c:8998
> > sctp_sendmsg_to_asoc+0x13e3/0x17b0 net/sctp/socket.c:1967
> > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > sock_sendmsg_nosec net/socket.c:621 [inline]
> > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > __do_sys_sendmsg net/socket.c:2183 [inline]
> > __se_sys_sendmsg net/socket.c:2181 [inline]
> > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > The buggy address belongs to the object at ffff88807b19a780
> > which belongs to the cache kmalloc-96 of size 96
> > The buggy address is located 56 bytes inside of
> > 96-byte region [ffff88807b19a780, ffff88807b19a7e0)
> > The buggy address belongs to the page:
> > page:ffffea0001ec6680 count:1 mapcount:0 mapping:ffff88812c3f04c0
> > index:0xffff88807b19a800
> > flags: 0x1fffc0000000200(slab)
> > raw: 01fffc0000000200 ffffea000262acc8 ffffea0001448348 ffff88812c3f04c0
> > raw: ffff88807b19a800 ffff88807b19a000 000000010000001d 0000000000000000
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> > ffff88807b19a680: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ffff88807b19a700: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > > ffff88807b19a780: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ^
> > ffff88807b19a800: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ffff88807b19a880: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ==================================================================
> >
> >
> > ---
> > This bug is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkaller@googlegroups.com.
> >
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> > syzbot.
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
@ 2019-02-13 13:51 ` Marcelo Ricardo Leitner
0 siblings, 0 replies; 30+ messages in thread
From: Marcelo Ricardo Leitner @ 2019-02-13 13:51 UTC (permalink / raw)
To: Xin Long
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
On Wed, Feb 13, 2019 at 12:35:56PM +0800, Xin Long wrote:
> On Wed, Feb 13, 2019 at 4:00 AM syzbot
> <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > git tree: linux-next
> > console output: https://syzkaller.appspot.com/x/log.txt?x\x14140124c00000
> > kernel config: https://syzkaller.appspot.com/x/.config?xÈa112d3b0d6719b
> > dashboard link: https://syzkaller.appspot.com/bug?extidx23fa3f3e2d69341ea8
> > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> >
> > Unfortunately, I don't have any reproducer for this crash yet.
> >
> > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> >
> > =================================
> > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > [inline]
> > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > net/sctp/outqueue.c:313
> > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
I don't think so. Seems it will switch from use-after-free to NULL deref
instead with that patch.
> > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > #32
> > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > Google 01/01/2011
> > Call Trace:
> > __dump_stack lib/dump_stack.c:77 [inline]
> > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > list_add_tail include/linux/list.h:93 [inline]
> > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
sctp_sendmsg_to_asoc()
...
if (sinfo->sinfo_stream >= asoc->stream.outcnt) {
err = -EINVAL;
goto err;
}
if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
...
It should have aborted even if an old ->ext was still there because
outcnt is correctly updated. So somehow outcnt was wrong here.
sctp_stream_init()
...
/* Filter out chunks queued on streams that won't exist anymore */
sched->unsched_all(stream);
sctp_stream_outq_migrate(stream, NULL, outcnt); <--- [A]
sched->sched_all(stream);
ret = sctp_stream_alloc_out(stream, outcnt, gfp); <--- [B]
if (ret)
goto out;
stream->outcnt = outcnt; <--- [C]
...
We have a problem here because [A] is freeing ->ext, but [B] can fail (ENOMEM),
which would lead it to not update outcnt in [C] even after the
changes already performed in [A].
It should handle the freeing of ->ext in sctp_stream_alloc_out()
instead, or allocate the flexarray earlier (so it can bail out before
freeing stuff).
> > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > sock_sendmsg_nosec net/socket.c:621 [inline]
> > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > __do_sys_sendmsg net/socket.c:2183 [inline]
> > __se_sys_sendmsg net/socket.c:2181 [inline]
> > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > RIP: 0033:0x457e39
> > Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> > ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > RSP: 002b:00007fa9b8630c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> > RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e39
> > RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000003
> > RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
> > R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa9b86316d4
> > R13: 00000000004c4e2b R14: 00000000004d8ab8 R15: 00000000ffffffff
> >
> > Allocated by task 30745:
> > save_stack+0x45/0xd0 mm/kasan/common.c:75
> > set_track mm/kasan/common.c:87 [inline]
> > __kasan_kmalloc mm/kasan/common.c:498 [inline]
> > __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:471
> > kasan_kmalloc+0x9/0x10 mm/kasan/common.c:506
> > kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3615
> > kmalloc include/linux/slab.h:548 [inline]
> > kzalloc include/linux/slab.h:743 [inline]
> > sctp_stream_init_ext+0x51/0x110 net/sctp/stream.c:172
> > sctp_sendmsg_to_asoc+0x1273/0x17b0 net/sctp/socket.c:1896
> > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > sock_sendmsg_nosec net/socket.c:621 [inline]
> > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > __do_sys_sendmsg net/socket.c:2183 [inline]
> > __se_sys_sendmsg net/socket.c:2181 [inline]
> > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > Freed by task 30745:
> > save_stack+0x45/0xd0 mm/kasan/common.c:75
> > set_track mm/kasan/common.c:87 [inline]
> > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:460
> > kasan_slab_free+0xe/0x10 mm/kasan/common.c:468
> > __cache_free mm/slab.c:3491 [inline]
> > kfree+0xcf/0x230 mm/slab.c:3816
> > sctp_stream_outq_migrate+0x3e6/0x540 net/sctp/stream.c:88
> > sctp_stream_init+0xbc/0x410 net/sctp/stream.c:139
> > sctp_process_init+0x21c3/0x2b20 net/sctp/sm_make_chunk.c:2466
> > sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > sctp_do_sm+0x3145/0x5380 net/sctp/sm_sideeffect.c:1191
> > sctp_assoc_bh_rcv+0x343/0x660 net/sctp/associola.c:1074
> > sctp_inq_push+0x1ea/0x290 net/sctp/inqueue.c:95
> > sctp_backlog_rcv+0x196/0xbe0 net/sctp/input.c:354
> > sk_backlog_rcv include/net/sock.h:937 [inline]
> > __release_sock+0x12e/0x3a0 net/core/sock.c:2379
> > release_sock+0x59/0x1c0 net/core/sock.c:2895
> > sctp_wait_for_connect+0x316/0x540 net/sctp/socket.c:8998
> > sctp_sendmsg_to_asoc+0x13e3/0x17b0 net/sctp/socket.c:1967
> > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > sock_sendmsg_nosec net/socket.c:621 [inline]
> > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > __do_sys_sendmsg net/socket.c:2183 [inline]
> > __se_sys_sendmsg net/socket.c:2181 [inline]
> > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> >
> > The buggy address belongs to the object at ffff88807b19a780
> > which belongs to the cache kmalloc-96 of size 96
> > The buggy address is located 56 bytes inside of
> > 96-byte region [ffff88807b19a780, ffff88807b19a7e0)
> > The buggy address belongs to the page:
> > page:ffffea0001ec6680 count:1 mapcount:0 mapping:ffff88812c3f04c0
> > index:0xffff88807b19a800
> > flags: 0x1fffc0000000200(slab)
> > raw: 01fffc0000000200 ffffea000262acc8 ffffea0001448348 ffff88812c3f04c0
> > raw: ffff88807b19a800 ffff88807b19a000 000000010000001d 0000000000000000
> > page dumped because: kasan: bad access detected
> >
> > Memory state around the buggy address:
> > ffff88807b19a680: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ffff88807b19a700: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > > ffff88807b19a780: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ^
> > ffff88807b19a800: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > ffff88807b19a880: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > =================================
> >
> >
> > ---
> > This bug is generated by a bot. It may contain errors.
> > See https://goo.gl/tpsmEJ for more information about syzbot.
> > syzbot engineers can be reached at syzkaller@googlegroups.com.
> >
> > syzbot will keep track of this bug report. See:
> > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> > syzbot.
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
2019-02-13 13:51 ` Marcelo Ricardo Leitner
@ 2019-02-13 14:00 ` Dmitry Vyukov
-1 siblings, 0 replies; 30+ messages in thread
From: Dmitry Vyukov @ 2019-02-13 14:00 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Xin Long, syzbot, davem, LKML, linux-sctp, network dev,
Neil Horman, syzkaller-bugs, Vlad Yasevich
On Wed, Feb 13, 2019 at 2:52 PM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> On Wed, Feb 13, 2019 at 12:35:56PM +0800, Xin Long wrote:
> > On Wed, Feb 13, 2019 at 4:00 AM syzbot
> > <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > > git tree: linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=14140124c00000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=c8a112d3b0d6719b
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=7823fa3f3e2d69341ea8
> > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > >
> > > Unfortunately, I don't have any reproducer for this crash yet.
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> > >
> > > ==================================================================
> > > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > > [inline]
> > > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > > net/sctp/outqueue.c:313
> > > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> > I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
>
> I don't think so. Seems it will switch from use-after-free to NULL deref
> instead with that patch.
Let's unmark it as fixed for now then so that syzbot does not close it
prematurely
#syz fix: see discussion on the report email thread
> > > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > > #32
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > Call Trace:
> > > __dump_stack lib/dump_stack.c:77 [inline]
> > > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > > list_add_tail include/linux/list.h:93 [inline]
> > > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
>
> sctp_sendmsg_to_asoc()
> ...
> if (sinfo->sinfo_stream >= asoc->stream.outcnt) {
> err = -EINVAL;
> goto err;
> }
>
> if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> ...
>
> It should have aborted even if an old ->ext was still there because
> outcnt is correctly updated. So somehow outcnt was wrong here.
>
> sctp_stream_init()
> ...
> /* Filter out chunks queued on streams that won't exist anymore */
> sched->unsched_all(stream);
> sctp_stream_outq_migrate(stream, NULL, outcnt); <--- [A]
> sched->sched_all(stream);
>
> ret = sctp_stream_alloc_out(stream, outcnt, gfp); <--- [B]
> if (ret)
> goto out;
>
> stream->outcnt = outcnt; <--- [C]
> ...
>
> We have a problem here because [A] is freeing ->ext, but [B] can fail (ENOMEM),
> which would lead it to not update outcnt in [C] even after the
> changes already performed in [A].
>
> It should handle the freeing of ->ext in sctp_stream_alloc_out()
> instead, or allocate the flexarray earlier (so it can bail out before
> freeing stuff).
>
> > > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > > sock_sendmsg_nosec net/socket.c:621 [inline]
> > > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > > __do_sys_sendmsg net/socket.c:2183 [inline]
> > > __se_sys_sendmsg net/socket.c:2181 [inline]
> > > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > > RIP: 0033:0x457e39
> > > Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> > > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> > > ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > > RSP: 002b:00007fa9b8630c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> > > RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e39
> > > RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000003
> > > RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
> > > R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa9b86316d4
> > > R13: 00000000004c4e2b R14: 00000000004d8ab8 R15: 00000000ffffffff
> > >
> > > Allocated by task 30745:
> > > save_stack+0x45/0xd0 mm/kasan/common.c:75
> > > set_track mm/kasan/common.c:87 [inline]
> > > __kasan_kmalloc mm/kasan/common.c:498 [inline]
> > > __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:471
> > > kasan_kmalloc+0x9/0x10 mm/kasan/common.c:506
> > > kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3615
> > > kmalloc include/linux/slab.h:548 [inline]
> > > kzalloc include/linux/slab.h:743 [inline]
> > > sctp_stream_init_ext+0x51/0x110 net/sctp/stream.c:172
> > > sctp_sendmsg_to_asoc+0x1273/0x17b0 net/sctp/socket.c:1896
> > > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > > sock_sendmsg_nosec net/socket.c:621 [inline]
> > > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > > __do_sys_sendmsg net/socket.c:2183 [inline]
> > > __se_sys_sendmsg net/socket.c:2181 [inline]
> > > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > >
> > > Freed by task 30745:
> > > save_stack+0x45/0xd0 mm/kasan/common.c:75
> > > set_track mm/kasan/common.c:87 [inline]
> > > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:460
> > > kasan_slab_free+0xe/0x10 mm/kasan/common.c:468
> > > __cache_free mm/slab.c:3491 [inline]
> > > kfree+0xcf/0x230 mm/slab.c:3816
> > > sctp_stream_outq_migrate+0x3e6/0x540 net/sctp/stream.c:88
> > > sctp_stream_init+0xbc/0x410 net/sctp/stream.c:139
> > > sctp_process_init+0x21c3/0x2b20 net/sctp/sm_make_chunk.c:2466
> > > sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> > > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> > > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > sctp_do_sm+0x3145/0x5380 net/sctp/sm_sideeffect.c:1191
> > > sctp_assoc_bh_rcv+0x343/0x660 net/sctp/associola.c:1074
> > > sctp_inq_push+0x1ea/0x290 net/sctp/inqueue.c:95
> > > sctp_backlog_rcv+0x196/0xbe0 net/sctp/input.c:354
> > > sk_backlog_rcv include/net/sock.h:937 [inline]
> > > __release_sock+0x12e/0x3a0 net/core/sock.c:2379
> > > release_sock+0x59/0x1c0 net/core/sock.c:2895
> > > sctp_wait_for_connect+0x316/0x540 net/sctp/socket.c:8998
> > > sctp_sendmsg_to_asoc+0x13e3/0x17b0 net/sctp/socket.c:1967
> > > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > > sock_sendmsg_nosec net/socket.c:621 [inline]
> > > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > > __do_sys_sendmsg net/socket.c:2183 [inline]
> > > __se_sys_sendmsg net/socket.c:2181 [inline]
> > > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > >
> > > The buggy address belongs to the object at ffff88807b19a780
> > > which belongs to the cache kmalloc-96 of size 96
> > > The buggy address is located 56 bytes inside of
> > > 96-byte region [ffff88807b19a780, ffff88807b19a7e0)
> > > The buggy address belongs to the page:
> > > page:ffffea0001ec6680 count:1 mapcount:0 mapping:ffff88812c3f04c0
> > > index:0xffff88807b19a800
> > > flags: 0x1fffc0000000200(slab)
> > > raw: 01fffc0000000200 ffffea000262acc8 ffffea0001448348 ffff88812c3f04c0
> > > raw: ffff88807b19a800 ffff88807b19a000 000000010000001d 0000000000000000
> > > page dumped because: kasan: bad access detected
> > >
> > > Memory state around the buggy address:
> > > ffff88807b19a680: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > > ffff88807b19a700: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > > > ffff88807b19a780: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > > ^
> > > ffff88807b19a800: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > > ffff88807b19a880: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > > ==================================================================
> > >
> > >
> > > ---
> > > This bug is generated by a bot. It may contain errors.
> > > See https://goo.gl/tpsmEJ for more information about syzbot.
> > > syzbot engineers can be reached at syzkaller@googlegroups.com.
> > >
> > > syzbot will keep track of this bug report. See:
> > > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> > > syzbot.
> >
>
> --
> 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 syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20190213135157.GJ10665%40localhost.localdomain.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
@ 2019-02-13 14:00 ` Dmitry Vyukov
0 siblings, 0 replies; 30+ messages in thread
From: Dmitry Vyukov @ 2019-02-13 14:00 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: Xin Long, syzbot, davem, LKML, linux-sctp, network dev,
Neil Horman, syzkaller-bugs, Vlad Yasevich
On Wed, Feb 13, 2019 at 2:52 PM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> On Wed, Feb 13, 2019 at 12:35:56PM +0800, Xin Long wrote:
> > On Wed, Feb 13, 2019 at 4:00 AM syzbot
> > <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > > git tree: linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x\x14140124c00000
> > > kernel config: https://syzkaller.appspot.com/x/.config?xÈa112d3b0d6719b
> > > dashboard link: https://syzkaller.appspot.com/bug?extidx23fa3f3e2d69341ea8
> > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > >
> > > Unfortunately, I don't have any reproducer for this crash yet.
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> > >
> > > =================================
> > > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > > [inline]
> > > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > > net/sctp/outqueue.c:313
> > > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> > I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
>
> I don't think so. Seems it will switch from use-after-free to NULL deref
> instead with that patch.
Let's unmark it as fixed for now then so that syzbot does not close it
prematurely
#syz fix: see discussion on the report email thread
> > > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > > #32
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > Call Trace:
> > > __dump_stack lib/dump_stack.c:77 [inline]
> > > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > > list_add_tail include/linux/list.h:93 [inline]
> > > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
>
> sctp_sendmsg_to_asoc()
> ...
> if (sinfo->sinfo_stream >= asoc->stream.outcnt) {
> err = -EINVAL;
> goto err;
> }
>
> if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> ...
>
> It should have aborted even if an old ->ext was still there because
> outcnt is correctly updated. So somehow outcnt was wrong here.
>
> sctp_stream_init()
> ...
> /* Filter out chunks queued on streams that won't exist anymore */
> sched->unsched_all(stream);
> sctp_stream_outq_migrate(stream, NULL, outcnt); <--- [A]
> sched->sched_all(stream);
>
> ret = sctp_stream_alloc_out(stream, outcnt, gfp); <--- [B]
> if (ret)
> goto out;
>
> stream->outcnt = outcnt; <--- [C]
> ...
>
> We have a problem here because [A] is freeing ->ext, but [B] can fail (ENOMEM),
> which would lead it to not update outcnt in [C] even after the
> changes already performed in [A].
>
> It should handle the freeing of ->ext in sctp_stream_alloc_out()
> instead, or allocate the flexarray earlier (so it can bail out before
> freeing stuff).
>
> > > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > > sock_sendmsg_nosec net/socket.c:621 [inline]
> > > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > > __do_sys_sendmsg net/socket.c:2183 [inline]
> > > __se_sys_sendmsg net/socket.c:2181 [inline]
> > > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > > RIP: 0033:0x457e39
> > > Code: ad b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
> > > 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
> > > ff 0f 83 7b b8 fb ff c3 66 2e 0f 1f 84 00 00 00 00
> > > RSP: 002b:00007fa9b8630c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
> > > RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000000457e39
> > > RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000003
> > > RBP: 000000000073bf00 R08: 0000000000000000 R09: 0000000000000000
> > > R10: 0000000000000000 R11: 0000000000000246 R12: 00007fa9b86316d4
> > > R13: 00000000004c4e2b R14: 00000000004d8ab8 R15: 00000000ffffffff
> > >
> > > Allocated by task 30745:
> > > save_stack+0x45/0xd0 mm/kasan/common.c:75
> > > set_track mm/kasan/common.c:87 [inline]
> > > __kasan_kmalloc mm/kasan/common.c:498 [inline]
> > > __kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:471
> > > kasan_kmalloc+0x9/0x10 mm/kasan/common.c:506
> > > kmem_cache_alloc_trace+0x151/0x760 mm/slab.c:3615
> > > kmalloc include/linux/slab.h:548 [inline]
> > > kzalloc include/linux/slab.h:743 [inline]
> > > sctp_stream_init_ext+0x51/0x110 net/sctp/stream.c:172
> > > sctp_sendmsg_to_asoc+0x1273/0x17b0 net/sctp/socket.c:1896
> > > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > > sock_sendmsg_nosec net/socket.c:621 [inline]
> > > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > > __do_sys_sendmsg net/socket.c:2183 [inline]
> > > __se_sys_sendmsg net/socket.c:2181 [inline]
> > > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > >
> > > Freed by task 30745:
> > > save_stack+0x45/0xd0 mm/kasan/common.c:75
> > > set_track mm/kasan/common.c:87 [inline]
> > > __kasan_slab_free+0x102/0x150 mm/kasan/common.c:460
> > > kasan_slab_free+0xe/0x10 mm/kasan/common.c:468
> > > __cache_free mm/slab.c:3491 [inline]
> > > kfree+0xcf/0x230 mm/slab.c:3816
> > > sctp_stream_outq_migrate+0x3e6/0x540 net/sctp/stream.c:88
> > > sctp_stream_init+0xbc/0x410 net/sctp/stream.c:139
> > > sctp_process_init+0x21c3/0x2b20 net/sctp/sm_make_chunk.c:2466
> > > sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> > > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
> > > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > sctp_do_sm+0x3145/0x5380 net/sctp/sm_sideeffect.c:1191
> > > sctp_assoc_bh_rcv+0x343/0x660 net/sctp/associola.c:1074
> > > sctp_inq_push+0x1ea/0x290 net/sctp/inqueue.c:95
> > > sctp_backlog_rcv+0x196/0xbe0 net/sctp/input.c:354
> > > sk_backlog_rcv include/net/sock.h:937 [inline]
> > > __release_sock+0x12e/0x3a0 net/core/sock.c:2379
> > > release_sock+0x59/0x1c0 net/core/sock.c:2895
> > > sctp_wait_for_connect+0x316/0x540 net/sctp/socket.c:8998
> > > sctp_sendmsg_to_asoc+0x13e3/0x17b0 net/sctp/socket.c:1967
> > > sctp_sendmsg+0x10a9/0x17e0 net/sctp/socket.c:2113
> > > inet_sendmsg+0x147/0x5d0 net/ipv4/af_inet.c:798
> > > sock_sendmsg_nosec net/socket.c:621 [inline]
> > > sock_sendmsg+0xdd/0x130 net/socket.c:631
> > > ___sys_sendmsg+0x806/0x930 net/socket.c:2136
> > > __sys_sendmsg+0x105/0x1d0 net/socket.c:2174
> > > __do_sys_sendmsg net/socket.c:2183 [inline]
> > > __se_sys_sendmsg net/socket.c:2181 [inline]
> > > __x64_sys_sendmsg+0x78/0xb0 net/socket.c:2181
> > > do_syscall_64+0x103/0x610 arch/x86/entry/common.c:290
> > > entry_SYSCALL_64_after_hwframe+0x49/0xbe
> > >
> > > The buggy address belongs to the object at ffff88807b19a780
> > > which belongs to the cache kmalloc-96 of size 96
> > > The buggy address is located 56 bytes inside of
> > > 96-byte region [ffff88807b19a780, ffff88807b19a7e0)
> > > The buggy address belongs to the page:
> > > page:ffffea0001ec6680 count:1 mapcount:0 mapping:ffff88812c3f04c0
> > > index:0xffff88807b19a800
> > > flags: 0x1fffc0000000200(slab)
> > > raw: 01fffc0000000200 ffffea000262acc8 ffffea0001448348 ffff88812c3f04c0
> > > raw: ffff88807b19a800 ffff88807b19a000 000000010000001d 0000000000000000
> > > page dumped because: kasan: bad access detected
> > >
> > > Memory state around the buggy address:
> > > ffff88807b19a680: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > > ffff88807b19a700: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > > > ffff88807b19a780: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > > ^
> > > ffff88807b19a800: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > > ffff88807b19a880: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc
> > > =================================
> > >
> > >
> > > ---
> > > This bug is generated by a bot. It may contain errors.
> > > See https://goo.gl/tpsmEJ for more information about syzbot.
> > > syzbot engineers can be reached at syzkaller@googlegroups.com.
> > >
> > > syzbot will keep track of this bug report. See:
> > > https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
> > > syzbot.
> >
>
> --
> 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 syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/20190213135157.GJ10665%40localhost.localdomain.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
2019-02-13 13:51 ` Marcelo Ricardo Leitner
@ 2019-02-14 14:03 ` Xin Long
-1 siblings, 0 replies; 30+ messages in thread
From: Xin Long @ 2019-02-14 14:03 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
On Wed, Feb 13, 2019 at 9:52 PM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> On Wed, Feb 13, 2019 at 12:35:56PM +0800, Xin Long wrote:
> > On Wed, Feb 13, 2019 at 4:00 AM syzbot
> > <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > > git tree: linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=14140124c00000
> > > kernel config: https://syzkaller.appspot.com/x/.config?x=c8a112d3b0d6719b
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=7823fa3f3e2d69341ea8
> > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > >
> > > Unfortunately, I don't have any reproducer for this crash yet.
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> > >
> > > ==================================================================
> > > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > > [inline]
> > > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > > net/sctp/outqueue.c:313
> > > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> > I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
>
> I don't think so. Seems it will switch from use-after-free to NULL deref
> instead with that patch.
It will allocate ext for the stream if its ext is NULL in
sctp_sendmsg_to_asoc(), the new data will work fine. As for
the old data on the surplus streams, it has been dropped in
sctp_stream_outq_migrate().
>
> > > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > > #32
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > Call Trace:
> > > __dump_stack lib/dump_stack.c:77 [inline]
> > > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > > list_add_tail include/linux/list.h:93 [inline]
> > > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
>
> sctp_sendmsg_to_asoc()
> ...
> if (sinfo->sinfo_stream >= asoc->stream.outcnt) {
> err = -EINVAL;
> goto err;
> }
>
> if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> ...
>
> It should have aborted even if an old ->ext was still there because
> outcnt is correctly updated. So somehow outcnt was wrong here.
>
> sctp_stream_init()
> ...
> /* Filter out chunks queued on streams that won't exist anymore */
> sched->unsched_all(stream);
> sctp_stream_outq_migrate(stream, NULL, outcnt); <--- [A]
> sched->sched_all(stream);
>
> ret = sctp_stream_alloc_out(stream, outcnt, gfp); <--- [B]
> if (ret)
> goto out;
>
> stream->outcnt = outcnt; <--- [C]
> ...
>
> We have a problem here because [A] is freeing ->ext, but [B] can fail (ENOMEM),
> which would lead it to not update outcnt in [C] even after the
> changes already performed in [A].
>
> It should handle the freeing of ->ext in sctp_stream_alloc_out()
> instead, or allocate the flexarray earlier (so it can bail out before
> freeing stuff).
Agree that it's better to do:
sched->unsched_all(stream);
sctp_stream_outq_migrate(stream, NULL, outcnt);
sched->sched_all(stream);
after the flexarray allocation.
Just sctp_stream_alloc_out() can not be used here anymore, as
stream->out will be set in it.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
@ 2019-02-14 14:03 ` Xin Long
0 siblings, 0 replies; 30+ messages in thread
From: Xin Long @ 2019-02-14 14:03 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
On Wed, Feb 13, 2019 at 9:52 PM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> On Wed, Feb 13, 2019 at 12:35:56PM +0800, Xin Long wrote:
> > On Wed, Feb 13, 2019 at 4:00 AM syzbot
> > <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> > >
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > > git tree: linux-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x\x14140124c00000
> > > kernel config: https://syzkaller.appspot.com/x/.config?xÈa112d3b0d6719b
> > > dashboard link: https://syzkaller.appspot.com/bug?extidx23fa3f3e2d69341ea8
> > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > >
> > > Unfortunately, I don't have any reproducer for this crash yet.
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> > >
> > > =================================
> > > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > > [inline]
> > > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > > net/sctp/outqueue.c:313
> > > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> > I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
>
> I don't think so. Seems it will switch from use-after-free to NULL deref
> instead with that patch.
It will allocate ext for the stream if its ext is NULL in
sctp_sendmsg_to_asoc(), the new data will work fine. As for
the old data on the surplus streams, it has been dropped in
sctp_stream_outq_migrate().
>
> > > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > > #32
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > Call Trace:
> > > __dump_stack lib/dump_stack.c:77 [inline]
> > > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > > list_add_tail include/linux/list.h:93 [inline]
> > > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
>
> sctp_sendmsg_to_asoc()
> ...
> if (sinfo->sinfo_stream >= asoc->stream.outcnt) {
> err = -EINVAL;
> goto err;
> }
>
> if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> ...
>
> It should have aborted even if an old ->ext was still there because
> outcnt is correctly updated. So somehow outcnt was wrong here.
>
> sctp_stream_init()
> ...
> /* Filter out chunks queued on streams that won't exist anymore */
> sched->unsched_all(stream);
> sctp_stream_outq_migrate(stream, NULL, outcnt); <--- [A]
> sched->sched_all(stream);
>
> ret = sctp_stream_alloc_out(stream, outcnt, gfp); <--- [B]
> if (ret)
> goto out;
>
> stream->outcnt = outcnt; <--- [C]
> ...
>
> We have a problem here because [A] is freeing ->ext, but [B] can fail (ENOMEM),
> which would lead it to not update outcnt in [C] even after the
> changes already performed in [A].
>
> It should handle the freeing of ->ext in sctp_stream_alloc_out()
> instead, or allocate the flexarray earlier (so it can bail out before
> freeing stuff).
Agree that it's better to do:
sched->unsched_all(stream);
sctp_stream_outq_migrate(stream, NULL, outcnt);
sched->sched_all(stream);
after the flexarray allocation.
Just sctp_stream_alloc_out() can not be used here anymore, as
stream->out will be set in it.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
2019-02-14 14:03 ` Xin Long
@ 2019-02-14 14:17 ` Marcelo Ricardo Leitner
-1 siblings, 0 replies; 30+ messages in thread
From: Marcelo Ricardo Leitner @ 2019-02-14 14:17 UTC (permalink / raw)
To: Xin Long
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
On Thu, Feb 14, 2019 at 10:03:30PM +0800, Xin Long wrote:
> On Wed, Feb 13, 2019 at 9:52 PM Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> >
> > On Wed, Feb 13, 2019 at 12:35:56PM +0800, Xin Long wrote:
> > > On Wed, Feb 13, 2019 at 4:00 AM syzbot
> > > <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> > > >
> > > > Hello,
> > > >
> > > > syzbot found the following crash on:
> > > >
> > > > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > > > git tree: linux-next
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x=14140124c00000
> > > > kernel config: https://syzkaller.appspot.com/x/.config?x=c8a112d3b0d6719b
> > > > dashboard link: https://syzkaller.appspot.com/bug?extid=7823fa3f3e2d69341ea8
> > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > >
> > > > Unfortunately, I don't have any reproducer for this crash yet.
> > > >
> > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> > > >
> > > > ==================================================================
> > > > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > > > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > > > [inline]
> > > > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > > > net/sctp/outqueue.c:313
> > > > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> > > I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
> >
> > I don't think so. Seems it will switch from use-after-free to NULL deref
> > instead with that patch.
> It will allocate ext for the stream if its ext is NULL in
> sctp_sendmsg_to_asoc(), the new data will work fine. As for
Ehh, right!
> the old data on the surplus streams, it has been dropped in
> sctp_stream_outq_migrate().
Yep.
>
> >
> > > > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > > > #32
> > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > > Google 01/01/2011
> > > > Call Trace:
> > > > __dump_stack lib/dump_stack.c:77 [inline]
> > > > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > > > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > > > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > > > list_add_tail include/linux/list.h:93 [inline]
> > > > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > > > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > > > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > > > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > > > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > > > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > > > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
> >
> > sctp_sendmsg_to_asoc()
> > ...
> > if (sinfo->sinfo_stream >= asoc->stream.outcnt) {
> > err = -EINVAL;
> > goto err;
> > }
> >
> > if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> > ...
> >
> > It should have aborted even if an old ->ext was still there because
> > outcnt is correctly updated. So somehow outcnt was wrong here.
> >
> > sctp_stream_init()
> > ...
> > /* Filter out chunks queued on streams that won't exist anymore */
> > sched->unsched_all(stream);
> > sctp_stream_outq_migrate(stream, NULL, outcnt); <--- [A]
> > sched->sched_all(stream);
> >
> > ret = sctp_stream_alloc_out(stream, outcnt, gfp); <--- [B]
> > if (ret)
> > goto out;
> >
> > stream->outcnt = outcnt; <--- [C]
> > ...
> >
> > We have a problem here because [A] is freeing ->ext, but [B] can fail (ENOMEM),
> > which would lead it to not update outcnt in [C] even after the
> > changes already performed in [A].
> >
> > It should handle the freeing of ->ext in sctp_stream_alloc_out()
> > instead, or allocate the flexarray earlier (so it can bail out before
> > freeing stuff).
> Agree that it's better to do:
> sched->unsched_all(stream);
> sctp_stream_outq_migrate(stream, NULL, outcnt);
> sched->sched_all(stream);
> after the flexarray allocation.
>
> Just sctp_stream_alloc_out() can not be used here anymore, as
> stream->out will be set in it.
What about carving out a sctp_stream_init_out() ? Like
struct flex_array *new_out;
/* just allocate it, nothing more */
new_out = sctp_stream_alloc_out(outcnt, gfp);
if (!new_out)
goto out;
/* Filter out chunks queued on streams that won't exist anymore */
sched->unsched_all(stream);
sctp_stream_outq_migrate(stream, NULL, outcnt);
sched->sched_all(stream);
/* initialization stuff, and it can't fail anymore */
sctp_stream_init_out(stream, outcnt, new_out);
This may hurt a bit more with the genradix migration, but then we
don't end up dropping data for nothing.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
@ 2019-02-14 14:17 ` Marcelo Ricardo Leitner
0 siblings, 0 replies; 30+ messages in thread
From: Marcelo Ricardo Leitner @ 2019-02-14 14:17 UTC (permalink / raw)
To: Xin Long
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
On Thu, Feb 14, 2019 at 10:03:30PM +0800, Xin Long wrote:
> On Wed, Feb 13, 2019 at 9:52 PM Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> >
> > On Wed, Feb 13, 2019 at 12:35:56PM +0800, Xin Long wrote:
> > > On Wed, Feb 13, 2019 at 4:00 AM syzbot
> > > <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> > > >
> > > > Hello,
> > > >
> > > > syzbot found the following crash on:
> > > >
> > > > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > > > git tree: linux-next
> > > > console output: https://syzkaller.appspot.com/x/log.txt?x\x14140124c00000
> > > > kernel config: https://syzkaller.appspot.com/x/.config?xÈa112d3b0d6719b
> > > > dashboard link: https://syzkaller.appspot.com/bug?extidx23fa3f3e2d69341ea8
> > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > >
> > > > Unfortunately, I don't have any reproducer for this crash yet.
> > > >
> > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> > > >
> > > > =================================
> > > > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > > > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > > > [inline]
> > > > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > > > net/sctp/outqueue.c:313
> > > > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> > > I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
> >
> > I don't think so. Seems it will switch from use-after-free to NULL deref
> > instead with that patch.
> It will allocate ext for the stream if its ext is NULL in
> sctp_sendmsg_to_asoc(), the new data will work fine. As for
Ehh, right!
> the old data on the surplus streams, it has been dropped in
> sctp_stream_outq_migrate().
Yep.
>
> >
> > > > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > > > #32
> > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > > Google 01/01/2011
> > > > Call Trace:
> > > > __dump_stack lib/dump_stack.c:77 [inline]
> > > > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > > > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > > > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > > > list_add_tail include/linux/list.h:93 [inline]
> > > > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > > > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > > > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > > > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > > > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > > > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > > > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
> >
> > sctp_sendmsg_to_asoc()
> > ...
> > if (sinfo->sinfo_stream >= asoc->stream.outcnt) {
> > err = -EINVAL;
> > goto err;
> > }
> >
> > if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> > ...
> >
> > It should have aborted even if an old ->ext was still there because
> > outcnt is correctly updated. So somehow outcnt was wrong here.
> >
> > sctp_stream_init()
> > ...
> > /* Filter out chunks queued on streams that won't exist anymore */
> > sched->unsched_all(stream);
> > sctp_stream_outq_migrate(stream, NULL, outcnt); <--- [A]
> > sched->sched_all(stream);
> >
> > ret = sctp_stream_alloc_out(stream, outcnt, gfp); <--- [B]
> > if (ret)
> > goto out;
> >
> > stream->outcnt = outcnt; <--- [C]
> > ...
> >
> > We have a problem here because [A] is freeing ->ext, but [B] can fail (ENOMEM),
> > which would lead it to not update outcnt in [C] even after the
> > changes already performed in [A].
> >
> > It should handle the freeing of ->ext in sctp_stream_alloc_out()
> > instead, or allocate the flexarray earlier (so it can bail out before
> > freeing stuff).
> Agree that it's better to do:
> sched->unsched_all(stream);
> sctp_stream_outq_migrate(stream, NULL, outcnt);
> sched->sched_all(stream);
> after the flexarray allocation.
>
> Just sctp_stream_alloc_out() can not be used here anymore, as
> stream->out will be set in it.
What about carving out a sctp_stream_init_out() ? Like
struct flex_array *new_out;
/* just allocate it, nothing more */
new_out = sctp_stream_alloc_out(outcnt, gfp);
if (!new_out)
goto out;
/* Filter out chunks queued on streams that won't exist anymore */
sched->unsched_all(stream);
sctp_stream_outq_migrate(stream, NULL, outcnt);
sched->sched_all(stream);
/* initialization stuff, and it can't fail anymore */
sctp_stream_init_out(stream, outcnt, new_out);
This may hurt a bit more with the genradix migration, but then we
don't end up dropping data for nothing.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
2019-02-14 14:17 ` Marcelo Ricardo Leitner
@ 2019-02-14 14:23 ` Marcelo Ricardo Leitner
-1 siblings, 0 replies; 30+ messages in thread
From: Marcelo Ricardo Leitner @ 2019-02-14 14:23 UTC (permalink / raw)
To: Xin Long
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
On Thu, Feb 14, 2019 at 12:17:45PM -0200, Marcelo Ricardo Leitner wrote:
> On Thu, Feb 14, 2019 at 10:03:30PM +0800, Xin Long wrote:
> > On Wed, Feb 13, 2019 at 9:52 PM Marcelo Ricardo Leitner
> > <marcelo.leitner@gmail.com> wrote:
> > >
> > > On Wed, Feb 13, 2019 at 12:35:56PM +0800, Xin Long wrote:
> > > > On Wed, Feb 13, 2019 at 4:00 AM syzbot
> > > > <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > syzbot found the following crash on:
> > > > >
> > > > > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > > > > git tree: linux-next
> > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=14140124c00000
> > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=c8a112d3b0d6719b
> > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=7823fa3f3e2d69341ea8
> > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > > >
> > > > > Unfortunately, I don't have any reproducer for this crash yet.
> > > > >
> > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> > > > >
> > > > > ==================================================================
> > > > > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > > > > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > > > > [inline]
> > > > > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > > > > net/sctp/outqueue.c:313
> > > > > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> > > > I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
> > >
> > > I don't think so. Seems it will switch from use-after-free to NULL deref
> > > instead with that patch.
> > It will allocate ext for the stream if its ext is NULL in
> > sctp_sendmsg_to_asoc(), the new data will work fine. As for
>
> Ehh, right!
Marking it as fixed again then, as with this patch it won't crash
anymore.
#syz fix:
sctp: set stream ext to NULL after freeing it in sctp_stream_outq_migrate
>
> > the old data on the surplus streams, it has been dropped in
> > sctp_stream_outq_migrate().
>
> Yep.
>
> >
> > >
> > > > > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > > > > #32
> > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > > > Google 01/01/2011
> > > > > Call Trace:
> > > > > __dump_stack lib/dump_stack.c:77 [inline]
> > > > > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > > > > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > > > > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > > > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > > > > list_add_tail include/linux/list.h:93 [inline]
> > > > > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > > > > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > > > > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > > > > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > > > > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > > > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > > > > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > > > > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
> > >
> > > sctp_sendmsg_to_asoc()
> > > ...
> > > if (sinfo->sinfo_stream >= asoc->stream.outcnt) {
> > > err = -EINVAL;
> > > goto err;
> > > }
> > >
> > > if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> > > ...
> > >
> > > It should have aborted even if an old ->ext was still there because
> > > outcnt is correctly updated. So somehow outcnt was wrong here.
> > >
> > > sctp_stream_init()
> > > ...
> > > /* Filter out chunks queued on streams that won't exist anymore */
> > > sched->unsched_all(stream);
> > > sctp_stream_outq_migrate(stream, NULL, outcnt); <--- [A]
> > > sched->sched_all(stream);
> > >
> > > ret = sctp_stream_alloc_out(stream, outcnt, gfp); <--- [B]
> > > if (ret)
> > > goto out;
> > >
> > > stream->outcnt = outcnt; <--- [C]
> > > ...
> > >
> > > We have a problem here because [A] is freeing ->ext, but [B] can fail (ENOMEM),
> > > which would lead it to not update outcnt in [C] even after the
> > > changes already performed in [A].
> > >
> > > It should handle the freeing of ->ext in sctp_stream_alloc_out()
> > > instead, or allocate the flexarray earlier (so it can bail out before
> > > freeing stuff).
> > Agree that it's better to do:
> > sched->unsched_all(stream);
> > sctp_stream_outq_migrate(stream, NULL, outcnt);
> > sched->sched_all(stream);
> > after the flexarray allocation.
> >
> > Just sctp_stream_alloc_out() can not be used here anymore, as
> > stream->out will be set in it.
>
> What about carving out a sctp_stream_init_out() ? Like
>
> struct flex_array *new_out;
>
> /* just allocate it, nothing more */
> new_out = sctp_stream_alloc_out(outcnt, gfp);
> if (!new_out)
> goto out;
>
> /* Filter out chunks queued on streams that won't exist anymore */
> sched->unsched_all(stream);
> sctp_stream_outq_migrate(stream, NULL, outcnt);
> sched->sched_all(stream);
>
> /* initialization stuff, and it can't fail anymore */
> sctp_stream_init_out(stream, outcnt, new_out);
>
> This may hurt a bit more with the genradix migration, but then we
> don't end up dropping data for nothing.
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
@ 2019-02-14 14:23 ` Marcelo Ricardo Leitner
0 siblings, 0 replies; 30+ messages in thread
From: Marcelo Ricardo Leitner @ 2019-02-14 14:23 UTC (permalink / raw)
To: Xin Long
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
On Thu, Feb 14, 2019 at 12:17:45PM -0200, Marcelo Ricardo Leitner wrote:
> On Thu, Feb 14, 2019 at 10:03:30PM +0800, Xin Long wrote:
> > On Wed, Feb 13, 2019 at 9:52 PM Marcelo Ricardo Leitner
> > <marcelo.leitner@gmail.com> wrote:
> > >
> > > On Wed, Feb 13, 2019 at 12:35:56PM +0800, Xin Long wrote:
> > > > On Wed, Feb 13, 2019 at 4:00 AM syzbot
> > > > <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > syzbot found the following crash on:
> > > > >
> > > > > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > > > > git tree: linux-next
> > > > > console output: https://syzkaller.appspot.com/x/log.txt?x\x14140124c00000
> > > > > kernel config: https://syzkaller.appspot.com/x/.config?xÈa112d3b0d6719b
> > > > > dashboard link: https://syzkaller.appspot.com/bug?extidx23fa3f3e2d69341ea8
> > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > > >
> > > > > Unfortunately, I don't have any reproducer for this crash yet.
> > > > >
> > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> > > > >
> > > > > =================================
> > > > > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > > > > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > > > > [inline]
> > > > > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > > > > net/sctp/outqueue.c:313
> > > > > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> > > > I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
> > >
> > > I don't think so. Seems it will switch from use-after-free to NULL deref
> > > instead with that patch.
> > It will allocate ext for the stream if its ext is NULL in
> > sctp_sendmsg_to_asoc(), the new data will work fine. As for
>
> Ehh, right!
Marking it as fixed again then, as with this patch it won't crash
anymore.
#syz fix:
sctp: set stream ext to NULL after freeing it in sctp_stream_outq_migrate
>
> > the old data on the surplus streams, it has been dropped in
> > sctp_stream_outq_migrate().
>
> Yep.
>
> >
> > >
> > > > > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > > > > #32
> > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > > > Google 01/01/2011
> > > > > Call Trace:
> > > > > __dump_stack lib/dump_stack.c:77 [inline]
> > > > > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > > > > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > > > > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > > > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > > > > list_add_tail include/linux/list.h:93 [inline]
> > > > > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > > > > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > > > > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > > > > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > > > > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > > > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > > > > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > > > > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
> > >
> > > sctp_sendmsg_to_asoc()
> > > ...
> > > if (sinfo->sinfo_stream >= asoc->stream.outcnt) {
> > > err = -EINVAL;
> > > goto err;
> > > }
> > >
> > > if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> > > ...
> > >
> > > It should have aborted even if an old ->ext was still there because
> > > outcnt is correctly updated. So somehow outcnt was wrong here.
> > >
> > > sctp_stream_init()
> > > ...
> > > /* Filter out chunks queued on streams that won't exist anymore */
> > > sched->unsched_all(stream);
> > > sctp_stream_outq_migrate(stream, NULL, outcnt); <--- [A]
> > > sched->sched_all(stream);
> > >
> > > ret = sctp_stream_alloc_out(stream, outcnt, gfp); <--- [B]
> > > if (ret)
> > > goto out;
> > >
> > > stream->outcnt = outcnt; <--- [C]
> > > ...
> > >
> > > We have a problem here because [A] is freeing ->ext, but [B] can fail (ENOMEM),
> > > which would lead it to not update outcnt in [C] even after the
> > > changes already performed in [A].
> > >
> > > It should handle the freeing of ->ext in sctp_stream_alloc_out()
> > > instead, or allocate the flexarray earlier (so it can bail out before
> > > freeing stuff).
> > Agree that it's better to do:
> > sched->unsched_all(stream);
> > sctp_stream_outq_migrate(stream, NULL, outcnt);
> > sched->sched_all(stream);
> > after the flexarray allocation.
> >
> > Just sctp_stream_alloc_out() can not be used here anymore, as
> > stream->out will be set in it.
>
> What about carving out a sctp_stream_init_out() ? Like
>
> struct flex_array *new_out;
>
> /* just allocate it, nothing more */
> new_out = sctp_stream_alloc_out(outcnt, gfp);
> if (!new_out)
> goto out;
>
> /* Filter out chunks queued on streams that won't exist anymore */
> sched->unsched_all(stream);
> sctp_stream_outq_migrate(stream, NULL, outcnt);
> sched->sched_all(stream);
>
> /* initialization stuff, and it can't fail anymore */
> sctp_stream_init_out(stream, outcnt, new_out);
>
> This may hurt a bit more with the genradix migration, but then we
> don't end up dropping data for nothing.
>
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
2019-02-14 14:17 ` Marcelo Ricardo Leitner
@ 2019-02-14 14:39 ` Marcelo Ricardo Leitner
-1 siblings, 0 replies; 30+ messages in thread
From: Marcelo Ricardo Leitner @ 2019-02-14 14:39 UTC (permalink / raw)
To: Xin Long
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
On Thu, Feb 14, 2019 at 12:17:45PM -0200, Marcelo Ricardo Leitner wrote:
> On Thu, Feb 14, 2019 at 10:03:30PM +0800, Xin Long wrote:
> > On Wed, Feb 13, 2019 at 9:52 PM Marcelo Ricardo Leitner
> > <marcelo.leitner@gmail.com> wrote:
> > >
> > > On Wed, Feb 13, 2019 at 12:35:56PM +0800, Xin Long wrote:
> > > > On Wed, Feb 13, 2019 at 4:00 AM syzbot
> > > > <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > syzbot found the following crash on:
> > > > >
> > > > > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > > > > git tree: linux-next
> > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=14140124c00000
> > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=c8a112d3b0d6719b
> > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=7823fa3f3e2d69341ea8
> > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > > >
> > > > > Unfortunately, I don't have any reproducer for this crash yet.
> > > > >
> > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> > > > >
> > > > > ==================================================================
> > > > > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > > > > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > > > > [inline]
> > > > > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > > > > net/sctp/outqueue.c:313
> > > > > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> > > > I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
> > >
> > > I don't think so. Seems it will switch from use-after-free to NULL deref
> > > instead with that patch.
> > It will allocate ext for the stream if its ext is NULL in
> > sctp_sendmsg_to_asoc(), the new data will work fine. As for
>
> Ehh, right!
>
> > the old data on the surplus streams, it has been dropped in
> > sctp_stream_outq_migrate().
>
> Yep.
>
> >
> > >
> > > > > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > > > > #32
> > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > > > Google 01/01/2011
> > > > > Call Trace:
> > > > > __dump_stack lib/dump_stack.c:77 [inline]
> > > > > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > > > > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > > > > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > > > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > > > > list_add_tail include/linux/list.h:93 [inline]
> > > > > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > > > > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > > > > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > > > > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > > > > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > > > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > > > > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > > > > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
> > >
> > > sctp_sendmsg_to_asoc()
> > > ...
> > > if (sinfo->sinfo_stream >= asoc->stream.outcnt) {
> > > err = -EINVAL;
> > > goto err;
> > > }
> > >
> > > if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> > > ...
> > >
> > > It should have aborted even if an old ->ext was still there because
> > > outcnt is correctly updated. So somehow outcnt was wrong here.
> > >
> > > sctp_stream_init()
> > > ...
> > > /* Filter out chunks queued on streams that won't exist anymore */
> > > sched->unsched_all(stream);
> > > sctp_stream_outq_migrate(stream, NULL, outcnt); <--- [A]
> > > sched->sched_all(stream);
> > >
> > > ret = sctp_stream_alloc_out(stream, outcnt, gfp); <--- [B]
> > > if (ret)
> > > goto out;
> > >
> > > stream->outcnt = outcnt; <--- [C]
> > > ...
> > >
> > > We have a problem here because [A] is freeing ->ext, but [B] can fail (ENOMEM),
> > > which would lead it to not update outcnt in [C] even after the
> > > changes already performed in [A].
> > >
> > > It should handle the freeing of ->ext in sctp_stream_alloc_out()
> > > instead, or allocate the flexarray earlier (so it can bail out before
> > > freeing stuff).
> > Agree that it's better to do:
> > sched->unsched_all(stream);
> > sctp_stream_outq_migrate(stream, NULL, outcnt);
> > sched->sched_all(stream);
> > after the flexarray allocation.
> >
> > Just sctp_stream_alloc_out() can not be used here anymore, as
> > stream->out will be set in it.
>
> What about carving out a sctp_stream_init_out() ? Like
>
> struct flex_array *new_out;
>
> /* just allocate it, nothing more */
> new_out = sctp_stream_alloc_out(outcnt, gfp);
> if (!new_out)
> goto out;
>
> /* Filter out chunks queued on streams that won't exist anymore */
> sched->unsched_all(stream);
> sctp_stream_outq_migrate(stream, NULL, outcnt);
> sched->sched_all(stream);
>
> /* initialization stuff, and it can't fail anymore */
> sctp_stream_init_out(stream, outcnt, new_out);
>
> This may hurt a bit more with the genradix migration, but then we
> don't end up dropping data for nothing.
Reviewing calls to this function, if this allocation fails it will
either cause the asoc to be terminated or sendmsg error. So data loss
is not really an issue here.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
@ 2019-02-14 14:39 ` Marcelo Ricardo Leitner
0 siblings, 0 replies; 30+ messages in thread
From: Marcelo Ricardo Leitner @ 2019-02-14 14:39 UTC (permalink / raw)
To: Xin Long
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
On Thu, Feb 14, 2019 at 12:17:45PM -0200, Marcelo Ricardo Leitner wrote:
> On Thu, Feb 14, 2019 at 10:03:30PM +0800, Xin Long wrote:
> > On Wed, Feb 13, 2019 at 9:52 PM Marcelo Ricardo Leitner
> > <marcelo.leitner@gmail.com> wrote:
> > >
> > > On Wed, Feb 13, 2019 at 12:35:56PM +0800, Xin Long wrote:
> > > > On Wed, Feb 13, 2019 at 4:00 AM syzbot
> > > > <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> > > > >
> > > > > Hello,
> > > > >
> > > > > syzbot found the following crash on:
> > > > >
> > > > > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > > > > git tree: linux-next
> > > > > console output: https://syzkaller.appspot.com/x/log.txt?x\x14140124c00000
> > > > > kernel config: https://syzkaller.appspot.com/x/.config?xÈa112d3b0d6719b
> > > > > dashboard link: https://syzkaller.appspot.com/bug?extidx23fa3f3e2d69341ea8
> > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > > >
> > > > > Unfortunately, I don't have any reproducer for this crash yet.
> > > > >
> > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> > > > >
> > > > > =================================
> > > > > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > > > > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > > > > [inline]
> > > > > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > > > > net/sctp/outqueue.c:313
> > > > > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> > > > I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
> > >
> > > I don't think so. Seems it will switch from use-after-free to NULL deref
> > > instead with that patch.
> > It will allocate ext for the stream if its ext is NULL in
> > sctp_sendmsg_to_asoc(), the new data will work fine. As for
>
> Ehh, right!
>
> > the old data on the surplus streams, it has been dropped in
> > sctp_stream_outq_migrate().
>
> Yep.
>
> >
> > >
> > > > > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > > > > #32
> > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > > > Google 01/01/2011
> > > > > Call Trace:
> > > > > __dump_stack lib/dump_stack.c:77 [inline]
> > > > > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > > > > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > > > > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > > > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > > > > list_add_tail include/linux/list.h:93 [inline]
> > > > > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > > > > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > > > > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > > > > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > > > > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > > > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > > > > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > > > > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
> > >
> > > sctp_sendmsg_to_asoc()
> > > ...
> > > if (sinfo->sinfo_stream >= asoc->stream.outcnt) {
> > > err = -EINVAL;
> > > goto err;
> > > }
> > >
> > > if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> > > ...
> > >
> > > It should have aborted even if an old ->ext was still there because
> > > outcnt is correctly updated. So somehow outcnt was wrong here.
> > >
> > > sctp_stream_init()
> > > ...
> > > /* Filter out chunks queued on streams that won't exist anymore */
> > > sched->unsched_all(stream);
> > > sctp_stream_outq_migrate(stream, NULL, outcnt); <--- [A]
> > > sched->sched_all(stream);
> > >
> > > ret = sctp_stream_alloc_out(stream, outcnt, gfp); <--- [B]
> > > if (ret)
> > > goto out;
> > >
> > > stream->outcnt = outcnt; <--- [C]
> > > ...
> > >
> > > We have a problem here because [A] is freeing ->ext, but [B] can fail (ENOMEM),
> > > which would lead it to not update outcnt in [C] even after the
> > > changes already performed in [A].
> > >
> > > It should handle the freeing of ->ext in sctp_stream_alloc_out()
> > > instead, or allocate the flexarray earlier (so it can bail out before
> > > freeing stuff).
> > Agree that it's better to do:
> > sched->unsched_all(stream);
> > sctp_stream_outq_migrate(stream, NULL, outcnt);
> > sched->sched_all(stream);
> > after the flexarray allocation.
> >
> > Just sctp_stream_alloc_out() can not be used here anymore, as
> > stream->out will be set in it.
>
> What about carving out a sctp_stream_init_out() ? Like
>
> struct flex_array *new_out;
>
> /* just allocate it, nothing more */
> new_out = sctp_stream_alloc_out(outcnt, gfp);
> if (!new_out)
> goto out;
>
> /* Filter out chunks queued on streams that won't exist anymore */
> sched->unsched_all(stream);
> sctp_stream_outq_migrate(stream, NULL, outcnt);
> sched->sched_all(stream);
>
> /* initialization stuff, and it can't fail anymore */
> sctp_stream_init_out(stream, outcnt, new_out);
>
> This may hurt a bit more with the genradix migration, but then we
> don't end up dropping data for nothing.
Reviewing calls to this function, if this allocation fails it will
either cause the asoc to be terminated or sendmsg error. So data loss
is not really an issue here.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
2019-02-14 14:39 ` Marcelo Ricardo Leitner
@ 2019-02-14 14:52 ` Xin Long
-1 siblings, 0 replies; 30+ messages in thread
From: Xin Long @ 2019-02-14 14:52 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
On Thu, Feb 14, 2019 at 10:39 PM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> On Thu, Feb 14, 2019 at 12:17:45PM -0200, Marcelo Ricardo Leitner wrote:
> > On Thu, Feb 14, 2019 at 10:03:30PM +0800, Xin Long wrote:
> > > On Wed, Feb 13, 2019 at 9:52 PM Marcelo Ricardo Leitner
> > > <marcelo.leitner@gmail.com> wrote:
> > > >
> > > > On Wed, Feb 13, 2019 at 12:35:56PM +0800, Xin Long wrote:
> > > > > On Wed, Feb 13, 2019 at 4:00 AM syzbot
> > > > > <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > syzbot found the following crash on:
> > > > > >
> > > > > > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > > > > > git tree: linux-next
> > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=14140124c00000
> > > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=c8a112d3b0d6719b
> > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=7823fa3f3e2d69341ea8
> > > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > > > >
> > > > > > Unfortunately, I don't have any reproducer for this crash yet.
> > > > > >
> > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> > > > > >
> > > > > > ==================================================================
> > > > > > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > > > > > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > > > > > [inline]
> > > > > > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > > > > > net/sctp/outqueue.c:313
> > > > > > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> > > > > I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
> > > >
> > > > I don't think so. Seems it will switch from use-after-free to NULL deref
> > > > instead with that patch.
> > > It will allocate ext for the stream if its ext is NULL in
> > > sctp_sendmsg_to_asoc(), the new data will work fine. As for
> >
> > Ehh, right!
> >
> > > the old data on the surplus streams, it has been dropped in
> > > sctp_stream_outq_migrate().
> >
> > Yep.
> >
> > >
> > > >
> > > > > > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > > > > > #32
> > > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > > > > Google 01/01/2011
> > > > > > Call Trace:
> > > > > > __dump_stack lib/dump_stack.c:77 [inline]
> > > > > > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > > > > > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > > > > > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > > > > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > > > > > list_add_tail include/linux/list.h:93 [inline]
> > > > > > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > > > > > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > > > > > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > > > > > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > > > > > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > > > > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > > > > > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > > > > > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
> > > >
> > > > sctp_sendmsg_to_asoc()
> > > > ...
> > > > if (sinfo->sinfo_stream >= asoc->stream.outcnt) {
> > > > err = -EINVAL;
> > > > goto err;
> > > > }
> > > >
> > > > if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> > > > ...
> > > >
> > > > It should have aborted even if an old ->ext was still there because
> > > > outcnt is correctly updated. So somehow outcnt was wrong here.
> > > >
> > > > sctp_stream_init()
> > > > ...
> > > > /* Filter out chunks queued on streams that won't exist anymore */
> > > > sched->unsched_all(stream);
> > > > sctp_stream_outq_migrate(stream, NULL, outcnt); <--- [A]
> > > > sched->sched_all(stream);
> > > >
> > > > ret = sctp_stream_alloc_out(stream, outcnt, gfp); <--- [B]
> > > > if (ret)
> > > > goto out;
> > > >
> > > > stream->outcnt = outcnt; <--- [C]
> > > > ...
> > > >
> > > > We have a problem here because [A] is freeing ->ext, but [B] can fail (ENOMEM),
> > > > which would lead it to not update outcnt in [C] even after the
> > > > changes already performed in [A].
> > > >
> > > > It should handle the freeing of ->ext in sctp_stream_alloc_out()
> > > > instead, or allocate the flexarray earlier (so it can bail out before
> > > > freeing stuff).
> > > Agree that it's better to do:
> > > sched->unsched_all(stream);
> > > sctp_stream_outq_migrate(stream, NULL, outcnt);
> > > sched->sched_all(stream);
> > > after the flexarray allocation.
> > >
> > > Just sctp_stream_alloc_out() can not be used here anymore, as
> > > stream->out will be set in it.
> >
> > What about carving out a sctp_stream_init_out() ? Like
> >
> > struct flex_array *new_out;
> >
> > /* just allocate it, nothing more */
> > new_out = sctp_stream_alloc_out(outcnt, gfp);
> > if (!new_out)
> > goto out;
> >
> > /* Filter out chunks queued on streams that won't exist anymore */
> > sched->unsched_all(stream);
> > sctp_stream_outq_migrate(stream, NULL, outcnt);
> > sched->sched_all(stream);
> >
> > /* initialization stuff, and it can't fail anymore */
> > sctp_stream_init_out(stream, outcnt, new_out);
> >
> > This may hurt a bit more with the genradix migration, but then we
> > don't end up dropping data for nothing.
>
> Reviewing calls to this function, if this allocation fails it will
> either cause the asoc to be terminated or sendmsg error. So data loss
> is not really an issue here.
>
sctp_stream_init+0xbc/0x410 net/sctp/stream.c:139
sctp_process_init+0x21c3/0x2b20 net/sctp/sm_make_chunk.c:2466
sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
on this path, seems that it won't terminate the asoc nor report a sending error.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
@ 2019-02-14 14:52 ` Xin Long
0 siblings, 0 replies; 30+ messages in thread
From: Xin Long @ 2019-02-14 14:52 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
On Thu, Feb 14, 2019 at 10:39 PM Marcelo Ricardo Leitner
<marcelo.leitner@gmail.com> wrote:
>
> On Thu, Feb 14, 2019 at 12:17:45PM -0200, Marcelo Ricardo Leitner wrote:
> > On Thu, Feb 14, 2019 at 10:03:30PM +0800, Xin Long wrote:
> > > On Wed, Feb 13, 2019 at 9:52 PM Marcelo Ricardo Leitner
> > > <marcelo.leitner@gmail.com> wrote:
> > > >
> > > > On Wed, Feb 13, 2019 at 12:35:56PM +0800, Xin Long wrote:
> > > > > On Wed, Feb 13, 2019 at 4:00 AM syzbot
> > > > > <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> > > > > >
> > > > > > Hello,
> > > > > >
> > > > > > syzbot found the following crash on:
> > > > > >
> > > > > > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > > > > > git tree: linux-next
> > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x\x14140124c00000
> > > > > > kernel config: https://syzkaller.appspot.com/x/.config?xÈa112d3b0d6719b
> > > > > > dashboard link: https://syzkaller.appspot.com/bug?extidx23fa3f3e2d69341ea8
> > > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > > > >
> > > > > > Unfortunately, I don't have any reproducer for this crash yet.
> > > > > >
> > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> > > > > >
> > > > > > =================================
> > > > > > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > > > > > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > > > > > [inline]
> > > > > > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > > > > > net/sctp/outqueue.c:313
> > > > > > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> > > > > I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
> > > >
> > > > I don't think so. Seems it will switch from use-after-free to NULL deref
> > > > instead with that patch.
> > > It will allocate ext for the stream if its ext is NULL in
> > > sctp_sendmsg_to_asoc(), the new data will work fine. As for
> >
> > Ehh, right!
> >
> > > the old data on the surplus streams, it has been dropped in
> > > sctp_stream_outq_migrate().
> >
> > Yep.
> >
> > >
> > > >
> > > > > > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > > > > > #32
> > > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > > > > Google 01/01/2011
> > > > > > Call Trace:
> > > > > > __dump_stack lib/dump_stack.c:77 [inline]
> > > > > > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > > > > > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > > > > > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > > > > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > > > > > list_add_tail include/linux/list.h:93 [inline]
> > > > > > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > > > > > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > > > > > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > > > > > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > > > > > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > > > > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > > > > > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > > > > > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
> > > >
> > > > sctp_sendmsg_to_asoc()
> > > > ...
> > > > if (sinfo->sinfo_stream >= asoc->stream.outcnt) {
> > > > err = -EINVAL;
> > > > goto err;
> > > > }
> > > >
> > > > if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> > > > ...
> > > >
> > > > It should have aborted even if an old ->ext was still there because
> > > > outcnt is correctly updated. So somehow outcnt was wrong here.
> > > >
> > > > sctp_stream_init()
> > > > ...
> > > > /* Filter out chunks queued on streams that won't exist anymore */
> > > > sched->unsched_all(stream);
> > > > sctp_stream_outq_migrate(stream, NULL, outcnt); <--- [A]
> > > > sched->sched_all(stream);
> > > >
> > > > ret = sctp_stream_alloc_out(stream, outcnt, gfp); <--- [B]
> > > > if (ret)
> > > > goto out;
> > > >
> > > > stream->outcnt = outcnt; <--- [C]
> > > > ...
> > > >
> > > > We have a problem here because [A] is freeing ->ext, but [B] can fail (ENOMEM),
> > > > which would lead it to not update outcnt in [C] even after the
> > > > changes already performed in [A].
> > > >
> > > > It should handle the freeing of ->ext in sctp_stream_alloc_out()
> > > > instead, or allocate the flexarray earlier (so it can bail out before
> > > > freeing stuff).
> > > Agree that it's better to do:
> > > sched->unsched_all(stream);
> > > sctp_stream_outq_migrate(stream, NULL, outcnt);
> > > sched->sched_all(stream);
> > > after the flexarray allocation.
> > >
> > > Just sctp_stream_alloc_out() can not be used here anymore, as
> > > stream->out will be set in it.
> >
> > What about carving out a sctp_stream_init_out() ? Like
> >
> > struct flex_array *new_out;
> >
> > /* just allocate it, nothing more */
> > new_out = sctp_stream_alloc_out(outcnt, gfp);
> > if (!new_out)
> > goto out;
> >
> > /* Filter out chunks queued on streams that won't exist anymore */
> > sched->unsched_all(stream);
> > sctp_stream_outq_migrate(stream, NULL, outcnt);
> > sched->sched_all(stream);
> >
> > /* initialization stuff, and it can't fail anymore */
> > sctp_stream_init_out(stream, outcnt, new_out);
> >
> > This may hurt a bit more with the genradix migration, but then we
> > don't end up dropping data for nothing.
>
> Reviewing calls to this function, if this allocation fails it will
> either cause the asoc to be terminated or sendmsg error. So data loss
> is not really an issue here.
>
sctp_stream_init+0xbc/0x410 net/sctp/stream.c:139
sctp_process_init+0x21c3/0x2b20 net/sctp/sm_make_chunk.c:2466
sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
on this path, seems that it won't terminate the asoc nor report a sending error.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
2019-02-14 14:52 ` Xin Long
@ 2019-02-14 15:27 ` Marcelo Ricardo Leitner
-1 siblings, 0 replies; 30+ messages in thread
From: Marcelo Ricardo Leitner @ 2019-02-14 15:27 UTC (permalink / raw)
To: Xin Long
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
On Thu, Feb 14, 2019 at 10:52:00PM +0800, Xin Long wrote:
> On Thu, Feb 14, 2019 at 10:39 PM Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> >
> > On Thu, Feb 14, 2019 at 12:17:45PM -0200, Marcelo Ricardo Leitner wrote:
> > > On Thu, Feb 14, 2019 at 10:03:30PM +0800, Xin Long wrote:
> > > > On Wed, Feb 13, 2019 at 9:52 PM Marcelo Ricardo Leitner
> > > > <marcelo.leitner@gmail.com> wrote:
> > > > >
> > > > > On Wed, Feb 13, 2019 at 12:35:56PM +0800, Xin Long wrote:
> > > > > > On Wed, Feb 13, 2019 at 4:00 AM syzbot
> > > > > > <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > syzbot found the following crash on:
> > > > > > >
> > > > > > > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > > > > > > git tree: linux-next
> > > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x=14140124c00000
> > > > > > > kernel config: https://syzkaller.appspot.com/x/.config?x=c8a112d3b0d6719b
> > > > > > > dashboard link: https://syzkaller.appspot.com/bug?extid=7823fa3f3e2d69341ea8
> > > > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > > > > >
> > > > > > > Unfortunately, I don't have any reproducer for this crash yet.
> > > > > > >
> > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > > > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> > > > > > >
> > > > > > > ==================================================================
> > > > > > > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > > > > > > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > > > > > > [inline]
> > > > > > > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > > > > > > net/sctp/outqueue.c:313
> > > > > > > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> > > > > > I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
> > > > >
> > > > > I don't think so. Seems it will switch from use-after-free to NULL deref
> > > > > instead with that patch.
> > > > It will allocate ext for the stream if its ext is NULL in
> > > > sctp_sendmsg_to_asoc(), the new data will work fine. As for
> > >
> > > Ehh, right!
> > >
> > > > the old data on the surplus streams, it has been dropped in
> > > > sctp_stream_outq_migrate().
> > >
> > > Yep.
> > >
> > > >
> > > > >
> > > > > > > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > > > > > > #32
> > > > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > > > > > Google 01/01/2011
> > > > > > > Call Trace:
> > > > > > > __dump_stack lib/dump_stack.c:77 [inline]
> > > > > > > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > > > > > > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > > > > > > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > > > > > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > > > > > > list_add_tail include/linux/list.h:93 [inline]
> > > > > > > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > > > > > > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > > > > > > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > > > > > > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > > > > > > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > > > > > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > > > > > > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > > > > > > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
> > > > >
> > > > > sctp_sendmsg_to_asoc()
> > > > > ...
> > > > > if (sinfo->sinfo_stream >= asoc->stream.outcnt) {
> > > > > err = -EINVAL;
> > > > > goto err;
> > > > > }
> > > > >
> > > > > if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> > > > > ...
> > > > >
> > > > > It should have aborted even if an old ->ext was still there because
> > > > > outcnt is correctly updated. So somehow outcnt was wrong here.
> > > > >
> > > > > sctp_stream_init()
> > > > > ...
> > > > > /* Filter out chunks queued on streams that won't exist anymore */
> > > > > sched->unsched_all(stream);
> > > > > sctp_stream_outq_migrate(stream, NULL, outcnt); <--- [A]
> > > > > sched->sched_all(stream);
> > > > >
> > > > > ret = sctp_stream_alloc_out(stream, outcnt, gfp); <--- [B]
> > > > > if (ret)
> > > > > goto out;
> > > > >
> > > > > stream->outcnt = outcnt; <--- [C]
> > > > > ...
> > > > >
> > > > > We have a problem here because [A] is freeing ->ext, but [B] can fail (ENOMEM),
> > > > > which would lead it to not update outcnt in [C] even after the
> > > > > changes already performed in [A].
> > > > >
> > > > > It should handle the freeing of ->ext in sctp_stream_alloc_out()
> > > > > instead, or allocate the flexarray earlier (so it can bail out before
> > > > > freeing stuff).
> > > > Agree that it's better to do:
> > > > sched->unsched_all(stream);
> > > > sctp_stream_outq_migrate(stream, NULL, outcnt);
> > > > sched->sched_all(stream);
> > > > after the flexarray allocation.
> > > >
> > > > Just sctp_stream_alloc_out() can not be used here anymore, as
> > > > stream->out will be set in it.
> > >
> > > What about carving out a sctp_stream_init_out() ? Like
> > >
> > > struct flex_array *new_out;
> > >
> > > /* just allocate it, nothing more */
> > > new_out = sctp_stream_alloc_out(outcnt, gfp);
> > > if (!new_out)
> > > goto out;
> > >
> > > /* Filter out chunks queued on streams that won't exist anymore */
> > > sched->unsched_all(stream);
> > > sctp_stream_outq_migrate(stream, NULL, outcnt);
> > > sched->sched_all(stream);
> > >
> > > /* initialization stuff, and it can't fail anymore */
> > > sctp_stream_init_out(stream, outcnt, new_out);
> > >
> > > This may hurt a bit more with the genradix migration, but then we
> > > don't end up dropping data for nothing.
> >
> > Reviewing calls to this function, if this allocation fails it will
> > either cause the asoc to be terminated or sendmsg error. So data loss
> > is not really an issue here.
> >
> sctp_stream_init+0xbc/0x410 net/sctp/stream.c:139
> sctp_process_init+0x21c3/0x2b20 net/sctp/sm_make_chunk.c:2466
> sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
>
> on this path, seems that it won't terminate the asoc nor report a sending error.
Seems that's only triggered from sctp_sf_do_5_1C_ack() and quite
interesting. If we can't perform the reduction of the number of output
streams, we will be violating the handshake. Considering the error
will cause it to stop processing the commands from the state machine,
it won't output cookie echo pkt and this asoc will be left in a
somewhat funny state. I think the fact that it won't stop the T1
then, allows it to get corrected later on.
But that err_chunk, if any, gets leaked.
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: KASAN: use-after-free Read in sctp_outq_tail
@ 2019-02-14 15:27 ` Marcelo Ricardo Leitner
0 siblings, 0 replies; 30+ messages in thread
From: Marcelo Ricardo Leitner @ 2019-02-14 15:27 UTC (permalink / raw)
To: Xin Long
Cc: syzbot, davem, LKML, linux-sctp, network dev, Neil Horman,
syzkaller-bugs, Vlad Yasevich
On Thu, Feb 14, 2019 at 10:52:00PM +0800, Xin Long wrote:
> On Thu, Feb 14, 2019 at 10:39 PM Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
> >
> > On Thu, Feb 14, 2019 at 12:17:45PM -0200, Marcelo Ricardo Leitner wrote:
> > > On Thu, Feb 14, 2019 at 10:03:30PM +0800, Xin Long wrote:
> > > > On Wed, Feb 13, 2019 at 9:52 PM Marcelo Ricardo Leitner
> > > > <marcelo.leitner@gmail.com> wrote:
> > > > >
> > > > > On Wed, Feb 13, 2019 at 12:35:56PM +0800, Xin Long wrote:
> > > > > > On Wed, Feb 13, 2019 at 4:00 AM syzbot
> > > > > > <syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com> wrote:
> > > > > > >
> > > > > > > Hello,
> > > > > > >
> > > > > > > syzbot found the following crash on:
> > > > > > >
> > > > > > > HEAD commit: d4104460aec1 Add linux-next specific files for 20190211
> > > > > > > git tree: linux-next
> > > > > > > console output: https://syzkaller.appspot.com/x/log.txt?x\x14140124c00000
> > > > > > > kernel config: https://syzkaller.appspot.com/x/.config?xÈa112d3b0d6719b
> > > > > > > dashboard link: https://syzkaller.appspot.com/bug?extidx23fa3f3e2d69341ea8
> > > > > > > compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> > > > > > >
> > > > > > > Unfortunately, I don't have any reproducer for this crash yet.
> > > > > > >
> > > > > > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > > > > > Reported-by: syzbot+7823fa3f3e2d69341ea8@syzkaller.appspotmail.com
> > > > > > >
> > > > > > > =================================
> > > > > > > BUG: KASAN: use-after-free in list_add_tail include/linux/list.h:93 [inline]
> > > > > > > BUG: KASAN: use-after-free in sctp_outq_tail_data net/sctp/outqueue.c:105
> > > > > > > [inline]
> > > > > > > BUG: KASAN: use-after-free in sctp_outq_tail+0x816/0x930
> > > > > > > net/sctp/outqueue.c:313
> > > > > > > Read of size 8 at addr ffff88807b19a7b8 by task syz-executor.0/30745
> > > > > > I think https://patchwork.ozlabs.org/patch/1040500/ will fix this.
> > > > >
> > > > > I don't think so. Seems it will switch from use-after-free to NULL deref
> > > > > instead with that patch.
> > > > It will allocate ext for the stream if its ext is NULL in
> > > > sctp_sendmsg_to_asoc(), the new data will work fine. As for
> > >
> > > Ehh, right!
> > >
> > > > the old data on the surplus streams, it has been dropped in
> > > > sctp_stream_outq_migrate().
> > >
> > > Yep.
> > >
> > > >
> > > > >
> > > > > > > CPU: 1 PID: 30745 Comm: syz-executor.0 Not tainted 5.0.0-rc5-next-20190211
> > > > > > > #32
> > > > > > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > > > > > Google 01/01/2011
> > > > > > > Call Trace:
> > > > > > > __dump_stack lib/dump_stack.c:77 [inline]
> > > > > > > dump_stack+0x172/0x1f0 lib/dump_stack.c:113
> > > > > > > print_address_description.cold+0x7c/0x20d mm/kasan/report.c:187
> > > > > > > kasan_report.cold+0x1b/0x40 mm/kasan/report.c:317
> > > > > > > __asan_report_load8_noabort+0x14/0x20 mm/kasan/generic_report.c:132
> > > > > > > list_add_tail include/linux/list.h:93 [inline]
> > > > > > > sctp_outq_tail_data net/sctp/outqueue.c:105 [inline]
> > > > > > > sctp_outq_tail+0x816/0x930 net/sctp/outqueue.c:313
> > > > > > > sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1109 [inline]
> > > > > > > sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1784 [inline]
> > > > > > > sctp_side_effects net/sctp/sm_sideeffect.c:1220 [inline]
> > > > > > > sctp_do_sm+0x68e/0x5380 net/sctp/sm_sideeffect.c:1191
> > > > > > > sctp_primitive_SEND+0xa0/0xd0 net/sctp/primitive.c:178
> > > > > > > sctp_sendmsg_to_asoc+0xa63/0x17b0 net/sctp/socket.c:1955
> > > > >
> > > > > sctp_sendmsg_to_asoc()
> > > > > ...
> > > > > if (sinfo->sinfo_stream >= asoc->stream.outcnt) {
> > > > > err = -EINVAL;
> > > > > goto err;
> > > > > }
> > > > >
> > > > > if (unlikely(!SCTP_SO(&asoc->stream, sinfo->sinfo_stream)->ext)) {
> > > > > ...
> > > > >
> > > > > It should have aborted even if an old ->ext was still there because
> > > > > outcnt is correctly updated. So somehow outcnt was wrong here.
> > > > >
> > > > > sctp_stream_init()
> > > > > ...
> > > > > /* Filter out chunks queued on streams that won't exist anymore */
> > > > > sched->unsched_all(stream);
> > > > > sctp_stream_outq_migrate(stream, NULL, outcnt); <--- [A]
> > > > > sched->sched_all(stream);
> > > > >
> > > > > ret = sctp_stream_alloc_out(stream, outcnt, gfp); <--- [B]
> > > > > if (ret)
> > > > > goto out;
> > > > >
> > > > > stream->outcnt = outcnt; <--- [C]
> > > > > ...
> > > > >
> > > > > We have a problem here because [A] is freeing ->ext, but [B] can fail (ENOMEM),
> > > > > which would lead it to not update outcnt in [C] even after the
> > > > > changes already performed in [A].
> > > > >
> > > > > It should handle the freeing of ->ext in sctp_stream_alloc_out()
> > > > > instead, or allocate the flexarray earlier (so it can bail out before
> > > > > freeing stuff).
> > > > Agree that it's better to do:
> > > > sched->unsched_all(stream);
> > > > sctp_stream_outq_migrate(stream, NULL, outcnt);
> > > > sched->sched_all(stream);
> > > > after the flexarray allocation.
> > > >
> > > > Just sctp_stream_alloc_out() can not be used here anymore, as
> > > > stream->out will be set in it.
> > >
> > > What about carving out a sctp_stream_init_out() ? Like
> > >
> > > struct flex_array *new_out;
> > >
> > > /* just allocate it, nothing more */
> > > new_out = sctp_stream_alloc_out(outcnt, gfp);
> > > if (!new_out)
> > > goto out;
> > >
> > > /* Filter out chunks queued on streams that won't exist anymore */
> > > sched->unsched_all(stream);
> > > sctp_stream_outq_migrate(stream, NULL, outcnt);
> > > sched->sched_all(stream);
> > >
> > > /* initialization stuff, and it can't fail anymore */
> > > sctp_stream_init_out(stream, outcnt, new_out);
> > >
> > > This may hurt a bit more with the genradix migration, but then we
> > > don't end up dropping data for nothing.
> >
> > Reviewing calls to this function, if this allocation fails it will
> > either cause the asoc to be terminated or sendmsg error. So data loss
> > is not really an issue here.
> >
> sctp_stream_init+0xbc/0x410 net/sctp/stream.c:139
> sctp_process_init+0x21c3/0x2b20 net/sctp/sm_make_chunk.c:2466
> sctp_cmd_process_init net/sctp/sm_sideeffect.c:682 [inline]
> sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1410 [inline]
>
> on this path, seems that it won't terminate the asoc nor report a sending error.
Seems that's only triggered from sctp_sf_do_5_1C_ack() and quite
interesting. If we can't perform the reduction of the number of output
streams, we will be violating the handshake. Considering the error
will cause it to stop processing the commands from the state machine,
it won't output cookie echo pkt and this asoc will be left in a
somewhat funny state. I think the fact that it won't stop the T1
then, allows it to get corrected later on.
But that err_chunk, if any, gets leaked.
^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2019-02-14 15:27 UTC | newest]
Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-10-23 10:13 KASAN: use-after-free Read in sctp_outq_select_transport syzbot
2018-10-23 10:13 ` syzbot
2018-10-27 7:33 ` Xin Long
2018-10-27 7:33 ` Xin Long
2019-02-12 19:04 KASAN: use-after-free Read in sctp_outq_tail syzbot
2019-02-12 19:04 ` syzbot
2019-02-12 19:19 ` Marcelo Ricardo Leitner
2019-02-12 19:19 ` Marcelo Ricardo Leitner
2019-02-13 8:27 ` Dmitry Vyukov
2019-02-13 8:27 ` Dmitry Vyukov
2019-02-13 4:35 ` Xin Long
2019-02-13 4:35 ` Xin Long
2019-02-13 8:29 ` Dmitry Vyukov
2019-02-13 8:29 ` Dmitry Vyukov
2019-02-13 13:51 ` Marcelo Ricardo Leitner
2019-02-13 13:51 ` Marcelo Ricardo Leitner
2019-02-13 14:00 ` Dmitry Vyukov
2019-02-13 14:00 ` Dmitry Vyukov
2019-02-14 14:03 ` Xin Long
2019-02-14 14:03 ` Xin Long
2019-02-14 14:17 ` Marcelo Ricardo Leitner
2019-02-14 14:17 ` Marcelo Ricardo Leitner
2019-02-14 14:23 ` Marcelo Ricardo Leitner
2019-02-14 14:23 ` Marcelo Ricardo Leitner
2019-02-14 14:39 ` Marcelo Ricardo Leitner
2019-02-14 14:39 ` Marcelo Ricardo Leitner
2019-02-14 14:52 ` Xin Long
2019-02-14 14:52 ` Xin Long
2019-02-14 15:27 ` Marcelo Ricardo Leitner
2019-02-14 15:27 ` Marcelo Ricardo Leitner
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.