what you don't know can hurt you
Home Files News &[SERVICES_TAB]About Contact Add New

Iret #GP Pre-Commit Privilege Escalation

Iret #GP Pre-Commit Privilege Escalation
Posted Sep 19, 2009
Authored by Tavis Ormandy, Julien Tinnes

Iret #GP may suffer from a privilege escalation vulnerability due to a pre-commit handling failure.

tags | advisory
advisories | CVE-2009-2793
SHA-256 | 1d79c7e09132c4b89fc124aeed234ca587643164955bcf1f2e6c6711647530a3

Iret #GP Pre-Commit Privilege Escalation

Change Mirror Download
Iret #GP on pre-commit handling failure: the NetBSD case (CVE-2009-2793)

On the Intel architecture, once an operating system kernel has completed
servicing an interrupt or exception, it will generally return to user
mode using iret. The iret instruction will restore the context required
to continue execution, such as code segment, instruction pointer, flags
and so on.

iret is a complex instruction whose pseudocode alone spans several pages
of the software developers manual. Interestingly, in protected mode it
is executed in two distinct stages, a pre-commit stage (before privilege
level is changed) and a post-commit stage (after privilege level is
changed). You can see the commit point in the pseudocode below (taken
from Intel manual, comment is ours)

IF new mode != 64-Bit Mode
IF tempEIP is not within code segment limits
THEN #GP(0); FI;
EIP <- tempEIP;
ELSE (* new mode = 64-bit mode *)
IF tempRIP is non-canonical
THEN #GP(0); FI;
RIP <- tempRIP;
CS <- tempCS; // This is the commit point (privilege switch)

When the processor handles an exception, two cases can arise:
- the handler procedure is executed at the same level of privilege
as the interrupted procedure, no stack switch occurs
- the handler procedure is executed at a different privilege level,
therefore a stack switch occurs

The generated stack frame will be different if a stack switch occurs,
because the processor needs to save the interrupted procedure's stack.

When iret returns to a different privilege level, its behaviour on
failure will depend on which stage of the operation it is currently
executing. A pre-commit failure will induce no stack-switching while a
post-commit failure will induce a stack switching and therefore generate
a different size trap frame.

Affected Software

It's easy to overlook this distinction and we have found multiple cases
where this has had direct security consequences or made other issues

For instance, the NetBSD kernel on x86 does not handle pre-commit failures

We can easily make iret fail pre-commit by having tempEIP outside the
code segment limits.

- The canonical way to do this is to set-up a LDT entry with a code segment
limited to 0x1FFF. mmap memory at 0x1000 and then put some shellcode with
an int 0x80 at the very end of this page, so that when the kernel iret,
tempEIP is past the code segment limits.

- Interestingly, because of the lazy handling of non executable stack
emulation on x86, this bug could be triggered by a non malicious

/* ... */
int main(int argc, char **argv)
jmp_buf env;

void handlesig(int n) {
longjmp(env, 1);

signal(SIGSEGV, handlesig);

if (setjmp(env) == 0) {
( (void(*)(void)) NULL) ();

return 0;

/* ... */
int main(int argc, char **argv)
char baguette;
signal(SIGABRT, (void (*)(int))&baguette);


In the NetBSD case, the kernel stack will get desynchronized. This might
allow an attacker to elevate privileges.


We reported this to NetBSD developpers in May. Obviously, the fix is
non trivial, and after much discussion, we agreed to release this
information to open this issue to the wider NetBSD developement


This bug was discovered by Tavis Ormandy and Julien Tinnes of the Google
Security Team.
Login or Register to add favorites

File Archive:

June 2022

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Jun 1st
    19 Files
  • 2
    Jun 2nd
    16 Files
  • 3
    Jun 3rd
    28 Files
  • 4
    Jun 4th
    0 Files
  • 5
    Jun 5th
    0 Files
  • 6
    Jun 6th
    19 Files
  • 7
    Jun 7th
    23 Files
  • 8
    Jun 8th
    11 Files
  • 9
    Jun 9th
    10 Files
  • 10
    Jun 10th
    4 Files
  • 11
    Jun 11th
    0 Files
  • 12
    Jun 12th
    0 Files
  • 13
    Jun 13th
    0 Files
  • 14
    Jun 14th
    0 Files
  • 15
    Jun 15th
    0 Files
  • 16
    Jun 16th
    0 Files
  • 17
    Jun 17th
    0 Files
  • 18
    Jun 18th
    0 Files
  • 19
    Jun 19th
    27 Files
  • 20
    Jun 20th
    65 Files
  • 21
    Jun 21st
    10 Files
  • 22
    Jun 22nd
    8 Files
  • 23
    Jun 23rd
    6 Files
  • 24
    Jun 24th
    6 Files
  • 25
    Jun 25th
    0 Files
  • 26
    Jun 26th
    0 Files
  • 27
    Jun 27th
    0 Files
  • 28
    Jun 28th
    0 Files
  • 29
    Jun 29th
    0 Files
  • 30
    Jun 30th
    0 Files

Top Authors In Last 30 Days

File Tags


packet storm

© 2022 Packet Storm. All rights reserved.

Hosting By