diff options
| author | Flavio Cruz <flaviocruz@gmail.com> | 2023-06-12 00:42:06 -0400 |
|---|---|---|
| committer | Samuel Thibault <samuel.thibault@ens-lyon.org> | 2023-06-12 07:56:27 +0200 |
| commit | 2e6b257f39ab90938ac9d425629cdf0897a47e48 (patch) | |
| tree | 9985bec998ed815352b41e6a3b3783d5804d11c0 /kern/boot_script.c | |
| parent | f09a574a331527ccebdef88d5cc2e2c45fa072b4 (diff) | |
| download | gnumach-2e6b257f39ab90938ac9d425629cdf0897a47e48.tar.gz gnumach-2e6b257f39ab90938ac9d425629cdf0897a47e48.tar.bz2 gnumach-2e6b257f39ab90938ac9d425629cdf0897a47e48.zip | |
copyinmsg: allow for the last message element to have msgt_number = 0.
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.
Message-Id: <ZIaiHnfrv6Y9hEel@jupiter.lan>
Diffstat (limited to 'kern/boot_script.c')
0 files changed, 0 insertions, 0 deletions