SCTP: Fix sctp_auth_asoc_get_hmac() to avoid kernel panic
Subsystems (3)
PATCH 1/1 SCTP: Fix sctp_auth_asoc_get_hmac() to avoid kernel panic
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 patch fix this problem.
net/sctp/auth.c +0 -0
@@ -549,13 +549,10 @@ struct sctp_hmac *sctp_auth_asoc_get_hma
if (!sctp_hmac_list[id].hmac_name) continue;
- break;
+ return &sctp_hmac_list[id]; }
- if (id == 0)
- return NULL;
-
- return &sctp_hmac_list[id];
+ return NULL;
}
static int __sctp_auth_find_hmacid(__be16 *hmacs, int n_elts, __be16 hmac_id)
Hi Wei
Quoted 3 lines · Wei Yongjun
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. 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.
That could almost remove the need for the sctp-auth_asoc_get_hmac() function.
-vlad
Quoted 25 lines
This patch fix this problem.
Signed-off-by Wei Yongjun <[email protected]>net/sctp/auth.c 2008-02-14 02:01:18.000000000 -0500 renamed from net/sctp/auth.c 2008-02-11 17:14:05.000000000 -0500 +2
-5@@ -549,13 +549,10 @@ struct sctp_hmac *sctp_auth_asoc_get_hma if (!sctp_hmac_list[id].hmac_name) continue; - break; + return &sctp_hmac_list[id]; } - if (id == 0) - return NULL; - - return &sctp_hmac_list[id]; + return NULL; } static int __sctp_auth_find_hmacid(__be16 *hmacs, int n_elts, __be16 hmac_id)
Hi Vlad:
Quoted 8 lines · Vlad Yasevich
Hi Wei
Quoted 3 lines · Wei Yongjun
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.
Quoted 10 lines
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()thatHMAC_SHA1is 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.
Quoted 2 lines
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.