[Top] [All Lists]

Re: [Bug]syscall fanotify_mark is broken when called indirectly in o32 u

To: Chen Jie <>
Subject: Re: [Bug]syscall fanotify_mark is broken when called indirectly in o32 user land + n64 kernel.
From: Aurelien Jarno <>
Date: Mon, 28 Mar 2011 17:13:31 +0200
In-reply-to: <>
Original-recipient: rfc822;
References: <>
User-agent: Mutt/1.5.20 (2009-06-14)
On Mon, Mar 28, 2011 at 12:19:39PM +0000, Chen Jie wrote:
> Hi all,


> In an o32 user land + n64 kernel, calling 'fanotify_mark' indirectly
> will always fail due to alignment[1]:
> syscall(_NR_fanotify_mark, fanotify_fd, flags, mask, dfd, pathname)
> The prototype of fanotify_mark is "fanotify_mark (int fanotify_fd,
> unsigned int flags,  __u64 mask, int dfd, const char  __user *
> pathname)", which has a 64bit argument.
> In the case of o32 user land + n64 kernel and indirect syscall:
> 1. User calls libc routine syscall(...), MIPS ABI enforce a padding
> word before argument 'mask' to make it 64bit-aligned. The padding word
> resides at a3 register.
> 2. Kernel fetches 4 32bit arguments from a0-a3, and then 4 32bit
> arguments from stack.
> 3. Kernel shifts arguments by one, then redirects to sys_32_fanotify_mark.
> 4. sys_32_fanotify_mark synthesizes the 64bit argument 'mask' by
> merge_64(a2, a3), note a2 is the padding word, so the synthesized
> argument is invalid.
> The syscall routine in libc doesn't know the prototype, so it can't do
> anything. It seems the bug of syscall handling code, any idea?

I can confirm the issue, however it is not specific to a n64 kernel.
Even with an o32 kernel the issue is present. I also have been able to
reproduce the issue on other architectures, like PowerPC.

Aurelien Jarno                          GPG: 1024D/F1BCDB73       

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