lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK8P3a1MJf7-gyZKe8hNaZnahPcatTveBM_zKGzYx9wEh0GXOg@mail.gmail.com>
Date:   Mon, 16 May 2022 23:07:53 +0100
From:   Arnd Bergmann <arnd@...db.de>
To:     Andrew Morton <akpm@...ux-foundation.org>
Cc:     Maxim Zhukov <crazycdeveloper@...il.com>, chi.minghao@....com.cn,
        varad.gautam@...e.com, Arnd Bergmann <arnd@...db.de>,
        Shakeel Butt <shakeelb@...gle.com>, vasily.averin@...ux.dev,
        Manfred Spraul <manfred@...orfullife.com>,
        Davidlohr Bueso <dbueso@...e.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Maxim Zhukov <mussitantesmortem@...il.com>
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@...ux-foundation.org> wrote:
>
> On Sun, 15 May 2022 23:01:03 +0300 Maxim Zhukov <crazycdeveloper@...il.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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ