sparc64: fix incorrect sign extension in sys_sparc64_personality

The value returned by sys_personality has type "long int". It is saved to a variable of type "int", which is not a problem yet because the type of task_struct->pesonality is "unsigned int". The problem is the sign extension from "int" to "long int" that happens on return from sys_sparc64_personality.

For example, a userspace call personality((unsigned) -EINVAL) will result to any subsequent personality call, including absolutely harmless read-only personality(0xffffffff) call, failing with errno set to EINVAL.

---
 arch/sparc/kernel/sys_sparc_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 30e7ddb..c690c8e 100644
@@ -413,15 +413,15 @@ out:
 
 SYSCALL_DEFINE1(sparc64_personality, unsigned long, personality)
 {
-	int ret;
+	long ret;
 
 	if (personality(current->personality) = PER_LINUX32 &&
 	    personality(personality) = PER_LINUX)
 		personality |= PER_LINUX32;
 	ret = sys_personality(personality);
 	if (personality(ret) = PER_LINUX32)
 		ret &= ~PER_LINUX32;
 
 	return ret;
 }
 

ldv

Date: Sat Dec 26 22:35:13 2015 +0000

The value returned by sys_personality has type "long int". It is saved to a variable of type "int", which is not a problem yet because the type of task_struct->pesonality is "unsigned int". The problem is the sign extension from "int" to "long int" that happens on return from sys_sparc64_personality.

For example, a userspace call personality((unsigned) -EINVAL) will result to any subsequent personality call, including absolutely harmless read-only personality(0xffffffff) call, failing with errno set to EINVAL.

---
 arch/sparc/kernel/sys_sparc_64.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

index 30e7ddb..c690c8e 100644
@@ -413,15 +413,15 @@ out:
 
 SYSCALL_DEFINE1(sparc64_personality, unsigned long, personality)
 {
-	int ret;
+	long ret;
 
 	if (personality(current->personality) = PER_LINUX32 &&
 	    personality(personality) = PER_LINUX)
 		personality |= PER_LINUX32;
 	ret = sys_personality(personality);
 	if (personality(ret) = PER_LINUX32)
 		ret &= ~PER_LINUX32;
 
 	return ret;
 }
 

ldv

You never need to resubmit a patch which is properly queued up in patchwork, which you can check here:

http://patchwork.ozlabs.org/project/sparclinux/list/

I work on sparc patches with a secondary priority compared to my networking duties, and right now I've been backlogged on the networking side for a week or two.

You simply need to be patient.