Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 28 Jun 2018 16:09:43 +0200 (CEST)
From: Pavel Kankovsky <>
cc: Vasily Averin <>
Subject: Re: 32-bit syscall breakage in -431 kernel with KAISER

On Thu, 28 Jun 2018, Solar Designer wrote:

> At first glance, RHEL6 might also be affected.  From 2.6.32-754.el6 as
> currently used by that OpenVZ branch:

Using vmlinux from CentOS kernel-debuginfo-2.6.32-754.el6.x86_64.rpm:

$ gdb vmlinux
(gdb) p &(((struct tss_struct *)0)->stack)
$1 = (long unsigned int (*)[256]) 0x2090
(gdb) p &(((struct tss_struct *)0)->io_bitmap)
$2 = (long unsigned int (*)[1025]) 0x80
(gdb) p &(((struct tss_struct *)0)->stack_canary)
$3 = (long unsigned int *) 0x2088
(gdb) p &(((struct tss_struct *)0)->x86_tss.io_bitmap_base)
$4 = (u16 *) 0x66
(gdb) p sizeof(struct x86_hw_tss)
$5 = 128

struct x86_hw_tss is somehow padded to 128 bytes (instead of 104 bytes you 
get when you sum its components). This is probably an effect of 

An extra element at then end of io_bitmap[] and the presence of 
stack_canary (not present in vanilla 2.6.32!) conspire to keep stack[] 
aligned at 16 bytes.

It seems they have managed to dodge that bullet.

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.