Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LRH.2.02.1806252211240.30595@argo.troja.mff.cuni.cz>
Date: Mon, 25 Jun 2018 22:48:28 +0200 (CEST)
From: Pavel Kankovsky <peak@...o.troja.mff.cuni.cz>
To: owl-dev@...ts.openwall.com
cc: Vasily Averin <vvs@...tuozzo.com>
Subject: Re: 32-bit syscall breakage in -431 kernel with KAISER

On Mon, 25 Jun 2018, Solar Designer wrote:

> On Mon, Jun 25, 2018 at 07:29:42PM +0200, Pavel Kankovsky wrote:
>> On Sun, 24 Jun 2018, Solar Designer wrote:
>>
>>> 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():
>>
>> Yes. It fails because compat_alloc_user_space returns NULL.
>
> Thanks!  How exactly did you debug this, on which kernel/build?

I made a fresh 3.1 installation into a vm and the rest was the old good if 
somewhat tedious method: I added a bunch of printk's to the function in 
question, rebuilt the kernel, installed it, rebooted and ran ifconfig 
extracted from the 32-bit version of Owl 3.1.

(I know I should learn how to use builtin GDB server in Qemu but...)

To get more information, I added show_regs(task_pt_regs(current)) to the 
beginning of dev_ifconf() and here is the result:

CPU 0, VCPU 0:0
Modules linked in: vzethdev simfs exportfs vzdquota vznetdev vzmon vzdev
Pid: 986, comm: ifconfig32 Tainted:  P     --------------------    2.6.18-431.el5.028stab123.1.owl1xxx #1 028stab123
RIP: 0292:[<0000000000000073>]  [<0000000000000073>]
RSP: 007b:000000000000007b  EFLAGS: bf98675c
RAX: 0000000000008912 RBX: 0000000000000000 RCX: 00000000bf986774
RDX: 0000000000000004 RSI: 00000000bf986774 RDI: 0000000000000036
RBP: ffffffff80065a3e R08: 0000000000000036 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffffffff805b2000(0033) knlGS:00000000b7e44a90
CS:  0060 DS: 007b ES: 007b CR0: 000000008005003b
CR2: 00000000b7eab100 CR3: 000000003f808000 CR4: 00000000000006e0

Userland rsp seems to be 0x7b and this makes compat_alloc_user_space() 
fail.

It seems to me the data are shifted: the value reported as "EFLAGS" looks 
like an actual userland stack pointer, "0000000000000073" should probably 
be CS rather than RIP (the offset) etc.

-- 
Pavel Kankovsky aka Peak                      "Que sçay-je?"

Powered by blists - more mailing lists

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