From: Wei Yongjun <yjwei@cn.fujitsu.com>
To: Vlad Yasevich <vladislav.yasevich@hp.com>
Cc: lksctp-developers@lists.sourceforge.net, netdev@vger.kernel.org,
David Miller <davem@davemloft.net>
Subject: Re: [PATCH] SCTP: Fix sctp_auth_asoc_get_hmac() to avoid kernel panic
Date: Fri, 21 Mar 2008 09:51:10 +0800 [thread overview]
Message-ID: <47E3148E.1080205@cn.fujitsu.com> (raw)
In-Reply-To: <47E2567C.7080105@hp.com>
Hi Vlad:
Vlad Yasevich wrote:
> Hi Wei
>
> Wei Yongjun wrote:
>> If association is setup with HMAC-ALGO parameter in which there is no
>> HMAC algorithm supported by the endpoint, send a chunk with AUTH will
>> cause kernel panic.
>>
>> This is because when send chunk with AUTH, sctp_auth_asoc_get_hmac()
>> will be used to get the hmac. In this function, if the HMAC-ALGO is
>> empty, it return NULL. If is not empty, it will find a valid hmac for
>> using. But if all of the HMAC-ALGOs is not supported by endpoint, it
>> will return a bogus pointer, not expected NULL pointer.
>
> This is a workaround, but this problem must never never happen.
This can happened under attack. I have a test case to found this problem.
> RFC 4890 has the following text:
>
> The HMAC algorithm based on SHA-1 MUST be supported and
> included in the HMAC-ALGO parameter.
>
> As a result, we need to check in sctp_verify_param() that HMAC_SHA1 is
> present in the list. If not, we should probably treat this as a protocol
> violation.
>
> It should also be a protocol violation if the HMAC parameter is empty.
Agree, I will make a patch to fix this.
>
> That could almost remove the need for the sctp-auth_asoc_get_hmac()
> function.
If we do the above check, this function can be removed. I do a test
after the new patch is create.
prev parent reply other threads:[~2008-03-21 1:49 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-20 5:53 [PATCH] SCTP: Fix sctp_auth_asoc_get_hmac() to avoid kernel panic Wei Yongjun
2008-03-20 12:20 ` Vlad Yasevich
2008-03-21 1:51 ` Wei Yongjun [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=47E3148E.1080205@cn.fujitsu.com \
--to=yjwei@cn.fujitsu.com \
--cc=davem@davemloft.net \
--cc=lksctp-developers@lists.sourceforge.net \
--cc=netdev@vger.kernel.org \
--cc=vladislav.yasevich@hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.