Messages in this thread | | | From | Arnd Bergmann <> | Date | Mon, 16 May 2022 23:07:53 +0100 | Subject | Re: [RFC PATCH 1/1] ipc, sem: fix backward compatibility with x86-32 kernels |
| |
On Mon, May 16, 2022 at 10:06 PM Andrew Morton <akpm@linux-foundation.org> wrote: > > On Sun, 15 May 2022 23:01:03 +0300 Maxim Zhukov <crazycdeveloper@gmail.com> wrote: > > > Since with commit 275f22148e87 ("ipc: rename old-style shmctl/semctl/msgctl syscalls") > > we have changed behavior: > > > > ksys_semctl lost parse ipc version (ipc_parse_version), because the > > new syscall works with IPC_64 only, but the parse function has some > > side effect - it removes IPC_64 bit from `cmd`. > > > > Some libc forced sends IPC_64 bit in semctl syscall[1][2][3], this leads to > > a bug - X86-32 kernel does not have compat headers and does not > > correctly parse received command (cmd) from semctl syscall: cmd have actual > > command and IPC_64 bit, thus throw EINVAL error in ksys_semctl > > > > This commit forcibly removes IPC_64 bit from the cmd for restore > > backward compatibility. > > > > [1]: https://elixir.bootlin.com/uclibc-ng/v1.0.40/source/libc/misc/sysvipc/sem.c#L58 > > [2]: https://elixir.bootlin.com/musl/v1.2.3/source/src/ipc/semctl.c#L48 -> https://elixir.bootlin.com/musl/v1.2.3/source/src/ipc/ipc.h#L22 > > [3]: https://elixir.bootlin.com/glibc/glibc-2.35/source/sysdeps/unix/sysv/linux/semctl.c#L124 > > > > Thanks. > > 275f22148e87 was three years ago. Can you suggest why it took so long > for this to be discovered?
I think it only shows up with a uclibc-ng built against 32-bit kernel headers from linux-5.1 or new for m68k, mips-o32, powerpc, s390, sh, sparc, and x86-32 (list is from my original commit 275f22148e87), not for the more popular musl or glibc libraries.
If sysvipc is used this rarely on uclibc-ng, maybe we can fix it by making it behave the same way as glibc instead? I agree the kernel interface is easy to get wrong here because of the subtle difference between ipc() and semctl(), but this was an intentional design choice at the time, and it did not affect the behavior of the existing syscalls, only the newly added calls.
Arnd
| |