linux-kernel - Re: compat: autofs v5 packet size ambiguity

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 22 Feb 2012 08:20:15 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ian Kent <raven@...maw.net>
Cc:	David Miller <davem@...emloft.net>, linux-kernel@...r.kernel.org,
	"H. Peter Anvin" <hpa@...or.com>, autofs@...r.kernel.org,
	Thomas Meyer <thomas@...3r.de>,
	Al Viro <viro@...iv.linux.org.uk>
Subject: Re: compat: autofs v5 packet size ambiguity - update

On Wed, Feb 22, 2012 at 4:45 AM, Ian Kent <raven@...maw.net> wrote:
> diff --git a/fs/autofs4/dev-ioctl.c b/fs/autofs4/dev-ioctl.c
> index 76741d8..85f1fcd 100644
> --- a/fs/autofs4/dev-ioctl.c
> +++ b/fs/autofs4/dev-ioctl.c
> @@ -385,6 +385,7 @@ static int autofs_dev_ioctl_setpipefd(struct file *fp,
>                sbi->pipefd = pipefd;
>                sbi->pipe = pipe;
>                sbi->catatonic = 0;
> +               sbi->compat_daemon = is_compat_task();
>        }
>  out:
>        mutex_unlock(&sbi->wq_mutex);

Yes, this part should do the reconnect correctly (assuming it's the
daemon that does that itself, but I assume it is).

But

> diff --git a/fs/autofs4/inode.c b/fs/autofs4/inode.c
> index e16980b..06858d9 100644
> --- a/fs/autofs4/inode.c
> +++ b/fs/autofs4/inode.c
> @@ -224,6 +225,7 @@ int autofs4_fill_super(struct super_block *s, void *data, int silent)
>        set_autofs_type_indirect(&sbi->type);
>        sbi->min_proto = 0;
>        sbi->max_proto = 0;
> +       sbi->compat_daemon = is_compat_task();
>        mutex_init(&sbi->wq_mutex);
>        mutex_init(&sbi->pipe_mutex);
>        spin_lock_init(&sbi->fs_lock);

the above really is wrong, at least for the autofs sources I looked at.

Because autofs does "spawn()" to fork+exec the mount() system call,
the is_compat_task() check really will be checking the wrong binary.

Now, it's true that in *most* cases you'd hope that 'mount' and
'autofs' both come from the same distro, and have been the compiled
for the same model. So it probably works in practice, and might be
good enough.

But I could easily see somebody building their own 'autofs' tools (or
building their own 'mount', although that sounds less likely to me)
and if they started out with a 32-bit distro but are slowly  upgrading
(like they've upgraded the kernel) the above would get that wrong.

I could also imagine a 64-bit environment wanting to "cross" compile
(and test) a 32-bit binary, and trying that. In fact, I suspect that
is something that you could test yourself: I assume you build your own
'autofs' daemon on a system where you don't build everything else, and
just adding "-m32" to the build should do this and show the problem.

                           Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/