Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 25 Jun 2018 13:03:48 +0300
From: Vasily Averin <vvs@...tuozzo.com>
To: Solar Designer <solar@...nwall.com>, owl-dev@...ts.openwall.com
Subject: Re: 32-bit syscall breakage in -431 kernel with KAISER

Dear Alexander,
did you tried to reproduce the problem on original -431.el5 kernel?

On 2018-06-24 22:18, Solar Designer wrote:
> Hi,
> 
> So we got reported this bug (or maybe several bugs, but luckily they all
> look related to me so far):
> 
> http://www.openwall.com/lists/owl-users/2018/06/21/2
> 
> I'm not sure if it's worth our time with so few users left (and
> interested in upgrading the kernel for security fixes), but it is indeed
> weird to release a kernel update with those regressions and then do
> nothing about them.  So I finally looked into this today.
> 
> My preliminary analysis suggests that maybe the KAISER backport broke
> the pt_regs ABI for 32-bit syscalls in x86_64 kernels.  Specifically,
> SIOCGIFCONF might be failing with EFAULT because fs/compat_ioctl.c:
> dev_ifconf() uses compat_alloc_user_space():
> 
> static int dev_ifconf(unsigned int fd, unsigned int cmd, unsigned long arg)
> {
>         struct ifconf32 ifc32;
>         struct ifconf ifc;
>         struct ifconf __user *uifc;
>         struct ifreq32 __user *ifr32;
>         struct ifreq __user *ifr;
>         unsigned int i, j;
>         int err;
> 
>         if (copy_from_user(&ifc32, compat_ptr(arg), sizeof(struct ifconf32)))
>                 return -EFAULT;
> 
>         if (ifc32.ifcbuf == 0) {
>                 ifc32.ifc_len = 0;
>                 ifc.ifc_len = 0;
>                 ifc.ifc_req = NULL;
>                 uifc = compat_alloc_user_space(sizeof(struct ifconf));
>         } else {
>                 size_t len =((ifc32.ifc_len / sizeof (struct ifreq32)) + 1) *
>                         sizeof (struct ifreq);
>                 uifc = compat_alloc_user_space(sizeof(struct ifconf) + len);
> 
> which in turn relies on pt_regs:
> 
> static __inline__ void __user *arch_compat_alloc_user_space(long len)
> {
>         struct pt_regs *regs = task_pt_regs(current);
>         return (void __user *)regs->rsp - len;
> }
> 
> Searching for other uses of compat_alloc_user_space(), I find there are
> not a lot overall, but this includes many uses in ipc/compat.c.  This
> led me to test the ipcs(1) command, and indeed it's partially broken:
> 
> root@...32:/ # ipcs
> 
> kernel not configured for shared memory
> 
> ------ Semaphore Arrays --------
> key        semid      owner      perms      nsems
> 
> ------ Message Queues --------
> key        msqid      owner      perms      used-bytes   messages
> 
> The "kernel not configured for shared memory" line appears in a 32-bit
> container now, but not in 64-bit.
> 
> I also took a look at the 32-bit syscall entry code changes, but don't
> immediately see any breakage of the pt_regs ABI.  So maybe my guess is
> wrong, or maybe I just don't see how it's right.
> 
> The bug might have come from the RHEL5 ELS changes, or it might have
> been introduced in the merging with OpenVZ, or it might have been
> introduced in Owl (such as with our different kernel config and our
> different gcc, whereas our patch is too small and unrelated to be a
> likely culprit).  It doesn't have to be with KAISER - it could also be
> with RETPOLINE, which is disabled in this build but it does make many
> invasive changes anyway (even if no-op'ish for security).
> 
> I tried searching whether this is possibly a known issue for RHEL5 ELS,
> but couldn't find anything.  I guess not many systems use RHEL5 ELS and
> its rebuilds, and those who do are possibly 64-bit only.
> 
> Alexander
> 

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.