On Sun, Mar 11, 2018 at 12:22:32AM +0800, Xin Long wrote:
On Sat, Mar 10, 2018 at 9:13 PM, Neil Horman [off-list ref] wrote:
quoted
On Sat, Mar 10, 2018 at 03:58:04PM +0800, Xin Long wrote:
quoted
On Sat, Mar 10, 2018 at 6:08 AM, Neil Horman [off-list ref] wrote:
quoted
On Fri, Mar 09, 2018 at 12:59:06PM -0800, syzbot wrote:
quoted
Hello,
syzbot hit the following crash on net-next commit
fd372a7a9e5e9d8011a0222d10edd3523abcd3b1 (Thu Mar 8 19:43:48 2018 +0000)
Merge tag 'mlx5-updates-2018-02-28-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux
So far this crash happened 2 times on net-next.
C reproducer is attached.
syzkaller reproducer is attached.
Raw console output is attached.
compiler: gcc (GCC) 7.1.1 20170620
.config is attached.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: <redacted>
It will help syzbot understand when the bug is fixed. See footer for
details.
If you forward the report, please keep this part and the footer.
IPVS: ftp: loaded support on port[0] = 21
IPVS: ftp: loaded support on port[0] = 21
IPVS: ftp: loaded support on port[0] = 21
IPVS: ftp: loaded support on port[0] = 21
==================================================================
BUG: KASAN: use-after-free in sctp_association_free+0x7b7/0x930
net/sctp/associola.c:332
Read of size 8 at addr ffff8801d8006ae0 by task syzkaller914861/4202
CPU: 1 PID: 4202 Comm: syzkaller914861 Not tainted 4.16.0-rc4+ #258
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:17 [inline]
dump_stack+0x194/0x24d lib/dump_stack.c:53
print_address_description+0x73/0x250 mm/kasan/report.c:256
68 more quoted lines
I agree with you on the uglyness aspect of the return code check, but I really
don't like the idea of placing the call to wait_for_sndbuf to guarantee a given
error code isn't returned, It just feels rickety to me.
And also, I think I moved sctp_primitive_ASSOCIATE before
sctp_wait_for_sndbuf by accident in that patch(Sorry), which may
already change some behavior. We have to move it back.
It seemed to me you did that specifically to enable the check for peeloff
events. That is to say, if you check the socket write space first on a new
association, and then get a peeloff event, the write space might have changed
(though I suppose in fairness, we will always be operating the old socket, so
the write space will only grow larger). Either way there should be nothing
really wrong with checking write space after we preform the association.
But I suppose that moving it back is the safer approach. It would be nice to
eliminate that odd error check as well if we can, but I'll start with just
returning the positioning to the way it was, and look to improve it later. I'll
post the patch once I confirm the build works
Neil