[Top] [All Lists]

RE: Strange bad accesses in compat_exit_robust_list (2.6.26, n32 ABI).

To: "Kaz Kylheku" <>, <>
Subject: RE: Strange bad accesses in compat_exit_robust_list (2.6.26, n32 ABI).
From: "Kaz Kylheku" <>
Date: Fri, 25 Sep 2009 18:05:30 -0700
In-reply-to: <DDFD17CC94A9BD49A82147DDF7D545C501F7053F@exchange.ZeugmaSystems.local>
Original-recipient: rfc822;
Thread-index: Aco+NNVJ+M75nEnzTBCs6uWEZaSwkwAAFr7QAAPRybA=
Thread-topic: Strange bad accesses in compat_exit_robust_list (2.6.26, n32 ABI). wrote:
> Kaz Kylheku wrote:
>> Hi all,
>> We made a strange discovery some time ago. After adding some tracing
>> printk's to the compat_exit_robust_list function for all the cases
>> where fetching the robust entry fails, we discovered that, from time
>> to time, 
>> it's being reported
>> for processes that don't even use threads.
> Hmm. Maybe a syscall is being misrouted? Perhaps user space is calling
> some function that ends up routed to the compat_set_robust_list
> entry in the syscall table, causing a junk value to be installed
> as the robust list. Hmm. But robust mutexes work on our platform;
> so glibc does reach the right syscalls when they are intended.

I have another hypothesis.

The execve syscall does not appear to deal with the robust
mutex list at all. A process can set up these robust pointers
and then call execv. It gets a new memory map, but the
flush_old_exec function does not clean up the robust list pointer,
which refers to a virtual address in the old address space.

I just confirmed it in fact.

I have a 100% repro for this problem when I do a 
``tar xjf file.tar.bz2'' on my board.

The tar process calls compat_sys_set_robust_list, and then
the bzip2 process encounters the problem in the compat_exit_robust_list.

But the PID is the same!  The tar process has exec-ed
bzip2, and the bzip2 image inherited bad robust pointers from
the time when it was tar.

<Prev in Thread] Current Thread [Next in Thread>