[PATCH gnumach] copyinmsg: allow for the last message element to have msgt_number = 0.

[Flavio Cruz]

When copying messages from user space, some messages may have
mach_msg_type_t with msgt_number = 0 and no data after. This is a valid
message and we want to allow that.

I found this bug when testing "[PATCH gnumach] Update the
64bit RPC ABI to be simpler" and attempting to run a basic Hurd x86_64 that can 
start a
bash shell. When mach_msg_type_long_t is the same size as
mach_msg_type_t this bug happens quite frequently and prevents the
system from starting properly.
---
 x86_64/copy_user.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/x86_64/copy_user.c b/x86_64/copy_user.c
index f76e44c9..6ff50e12 100644
--- a/x86_64/copy_user.c
+++ b/x86_64/copy_user.c
@@ -332,7 +332,7 @@ int copyinmsg (const void *userbuf, void *kernelbuf, const 
size_t usize)
   if (usize > sizeof(mach_msg_user_header_t))
     {
       /* check we have at least space for an empty descryptor */
-      while (usaddr < (ueaddr - sizeof(mach_msg_user_type_t)))
+      while (usaddr <= (ueaddr - sizeof(mach_msg_user_type_t)))
         {
           vm_size_t user_amount, kernel_amount;
           mach_msg_type_name_t name;
@@ -401,7 +401,6 @@ int copyinmsg (const void *userbuf, void *kernelbuf, const 
size_t usize)
     }
 
   kmsg->msgh_size = sizeof(mach_msg_header_t) + ksaddr - (vm_offset_t)(kmsg + 
1);
-  kmsg->msgh_size = kmsg->msgh_size;
   return 0;
 }
 
-- 
2.39.2