sysdeps/managarm: ioctl will crash rather than EFAULT if given a bad buffer

[ArsenArsen]

Test code: struct.unpack('HHHH', fcntl.ioctl(0, termios.TIOCGWINSZ, 0)), working: struct.unpack('HHHH', fcntl.ioctl(0, termios.TIOCGWINSZ, b"aaaaaaaa"))

ioctl in userspace won't check the buffer address, and hence will not return EFAULT and will crash instead.

[avdgrinten]

What's the issue here? Are there programs that rely on EFAULT to detect if a memory range is readable/writable?

[ArsenArsen]

I haven't ran into that specifically, but simply the behavior is inaccurate, libc syscall wrappers should never cause a program to crash like this

[Geertiebear]

I think in general we should factor out the errno translation code, and just provide a general function that does the translation instead of open coding it in every sysdep.

[ArsenArsen]

I agree but that would also not fix this, this happens because ioctl is populated in mlibc rather than posix-server

[Geertiebear]

How should ioctl in userspace check if the buffer is valid?

[ArsenArsen]

If I knew that I'd have submitted a PR :P

[avdgrinten]

I'm not sure if we should make an effort to return EFAULT instead of raising a segfault. Relying on EFAULT sounds very strange.

[ArsenArsen]

It's more of a human reliance than a programmatic one, e.g. I discovered this while poking around with ioctls to test SIGWINCH-related changes. I can't think of a very clean way to make a memory access not fail with a synchronous signal, though.

[Geertiebear]

Does glibc or musl do this?

[ArsenArsen]

the kernel does for both (since linux will just produce an EFAULT, I'm also pretty sure this doesn't happen with the linux sysdeps for that reason, hence specifically mentioning sysdeps/managarm in the subject)