Skip to contentSkip to conversation

SCTP: Fix sctp_auth_asoc_get_hmac() to avoid kernel panic

PATCH In review Wei Yongjun 2 participants 3 messages Mar 20, 2008 – Mar 21, 2008

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

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)

#1 lore raw

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.

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)
#2 lore raw

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() 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.

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.